DP-700 - Ingest and Transform Data (33% of the exam) - Section 2.3

Design and implement a loading pattern for streaming data into Microsoft Fabric.

Design a streaming ingestion pattern selecting Eventstream destinations and Eventhouse or Lakehouse targets based on latency requirements. Compare micro-batch and continuous ingestion modes, and recognise when landing streaming data to a Lakehouse table enables downstream batch processing.

streaming ingestion to an EventhouseEventstream destinationsnear-real-time loads to a Lakehousemicro-batch versus continuous ingestionlanding streaming data for downstream batch

Practice question for this objective

Free sampleIngest and Transform Datamedium

A logistics team ingests vehicle telemetry through a Microsoft Fabric Eventstream. Downstream, a nightly Spark job in a Lakehouse aggregates the day's telemetry into a Delta gold table. The streaming events do not need sub-second queries, but they must be durably landed in open Delta format so the batch job can read a full day at a time. Which Eventstream destination best lands the stream for this downstream batch?

ASend the Eventstream to an Eventhouse destination so the events are indexed in a KQL database, then have the nightly Spark job query the KQL database for each day.
BSend the Eventstream to a Lakehouse destination so events are written as Delta files in OneLake, ready for the nightly Spark job to read a full day in batch. Correct
CSend the Eventstream to a Microsoft Fabric Activator destination so each event triggers an action, then collect the triggered actions into the Delta gold table nightly.
DSend the Eventstream to a custom endpoint destination so an external service receives the events, then re-ingest them later from that service into the Delta gold table.

When streaming data only needs to land for downstream batch processing, route the Eventstream to a Lakehouse destination so events write as open Delta files. The requirement is durable open-format landing for a nightly full-day Spark read, not low-latency querying; a Lakehouse destination writes the Eventstream into OneLake as Delta, which Spark reads natively per day, whereas an Eventhouse adds query indexing the scenario does not need and Activator and custom endpoints do not durably store the stream.

Why A is wrong: An Eventhouse is the right choice when sub-second queries are needed, but the scenario explicitly does not require them; indexing the stream for low-latency querying adds cost and is a poor source shape for a full-day Spark batch read.

Why B is correct: A Lakehouse destination lands the stream as Delta files in OneLake in open format, which is exactly what a nightly Spark batch job needs to read a whole day; durability and open format are met without paying for low-latency query indexing.

Why C is wrong: Activator reacts to event conditions by firing alerts or actions; it is not a durable landing store for the raw stream, so it cannot supply a full day of telemetry in Delta format to the batch job.

Why D is wrong: A custom endpoint forwards events out of Fabric to another consumer, adding a round trip and an external dependency; it does not durably land the data in OneLake, so it is the wrong fit for a Fabric-native batch read.

See more DP-700 practice questions, answers explained.

Exam traps in Ingest and Transform Data

Answers that look right on this material and are not. Each one is a distractor from a different question in the DP-700 bank for this domain.

Land the stream only in a Lakehouse Delta table with Spark structured streaming, then have the dashboard query that Delta table directly for its interactive needs.
Why it is wrong: Querying a Lakehouse Delta table directly cannot reliably deliver sub-second interactive KQL, so the operations dashboard's latency requirement is not met even though the data-science side is satisfied.
Configure a Data Factory pipeline with a tumbling window trigger that copies the accumulated source events into the Eventhouse every five minutes.
Why it is wrong: A scheduled tumbling window copy loads in fixed batches, so events wait up to five minutes before they are queryable, which misses the second-level freshness target.
Send the Eventstream only to a Lakehouse destination, then build a OneLake shortcut from an Eventhouse to the landed Delta files so they are queryable sub-second for troubleshooting.
Why it is wrong: A shortcut surfaces the Delta files in place but does not give the KQL engine its streaming index, so queries over landed files are not sub-second on arrival; the low-latency troubleshooting requirement is not met by reading batch-landed files.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.