Landing a continuous stream of data into storage

In Microsoft Fabric, streaming data is ingested and loaded using Eventstream for capturing and routing event data, and can be processed with KQL (for Eventhouse/KQL Database) or Spark Structured Streaming (for Lakehouse) before landing in a queryable store. Choosing the right loading pattern depends on latency needs, destination (Lakehouse tables vs. KQL Database), and whether transformation happens in-flight or after landing.

Must-know

• Eventstream provides a no-code way to ingest streaming data from sources like Azure Event Hubs, IoT Hub, Kafka, and Fabric's own CDC connectors, then route it to destinations such as Lakehouse, KQL Database, or Eventhouse.
• For Lakehouse destinations, streaming ingestion typically uses Spark Structured Streaming with a defined trigger interval and checkpoint location to ensure exactly-once or at-least-once processing guarantees.
• KQL Database (via Eventhouse) is optimized for high-throughput, low-latency streaming ingestion and near-real-time analytics, using update policies to transform data as it lands.
• Structured Streaming jobs in a Lakehouse should write to Delta tables using mergeSchema or explicit schema definitions to avoid failures when the incoming streaming schema evolves.
• Windowing (tumbling, hopping, sliding) and watermarking are essential patterns for aggregating streaming data within Eventstream or Spark to handle late-arriving events correctly.
• A common gotcha: checkpoint location misconfiguration or reuse across different streaming queries can cause duplicate processing or job failures on restart, so each stream should have its own dedicated checkpoint path.

Coverage checked against the published exam guide on Aug 11, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.