Microsoft Fabric Data Engineer (DP-700) practice questions

A data engineering team runs many small notebook jobs in a Microsoft Fabric workspace. Each job currently waits several minutes before its Spark session is ready, and the delay dominates the short run times. The team wants new sessions to start in a few seconds without permanently reserving compute. Which Spark workspace setting should they configure to meet this requirement?

• AKeep the starter pool enabled so pre-warmed nodes back the workspace, letting Spark sessions begin in seconds without reserving a dedicated cluster.check_circle Correct
• BRaise the default node size on the starter pool so each session has more memory and processing power available the moment it begins running.
• CEnable high concurrency for the workspace so several notebooks share one Spark session and a new notebook reuses the already-running session.
• DCreate a custom Spark pool with autoscale disabled and a fixed minimum node count so the cluster is always sized and ready for incoming jobs.

Why A is correct: The starter pool holds pre-allocated, pre-warmed nodes for the workspace, so a session attaches in a few seconds and the nodes are released when idle, which matches the need for fast starts without permanently reserved compute.

Why B is wrong: Larger nodes give each session more compute but do nothing about the cold-start delay; provisioning time is the stated problem, and bigger nodes can actually take longer to acquire rather than shortening startup.

Why C is wrong: High concurrency lets notebooks share a session and helps once a session exists, but the very first session in the workspace still pays the full provisioning cost, so it does not on its own deliver the few-second start the team wants.

Why D is wrong: A custom pool with a fixed floor would be ready, but a cold custom pool still provisions on demand and a permanent floor reserves compute continuously, which contradicts the requirement to avoid permanently reserving capacity.

A nightly pipeline ingests an append-only sales event table from an on-premises SQL Server source into a bronze Delta table in a Microsoft Fabric Lakehouse. Each event row carries an immutable EventId and an ever-increasing CreatedUtc timestamp, and rows are never updated or deleted at source. The team wants each run to copy only rows added since the previous run while keeping operational overhead low. Which design best meets this requirement?

• AStore the highest CreatedUtc loaded so far as a high-water mark, then on each run copy only source rows whose CreatedUtc exceeds that stored value and update the mark.check_circle Correct
• BTruncate the bronze Delta table at the start of every run and reload the entire source table so the destination always matches the source exactly.
• CEnable change data capture on the source table and stream the captured insert, update, and delete records into the bronze Delta table on each run.
• DCopy the full source each run into a staging table, then MERGE staging into bronze on EventId so unchanged rows are skipped during the upsert step.

Why A is correct: An append-only source with a monotonically increasing timestamp is the textbook case for a high-water-mark watermark; querying rows above the stored mark loads only new rows with minimal overhead and no source-side change tracking.

Why B is wrong: A full truncate-and-reload guarantees a match but reads the whole source nightly, which scales poorly and ignores the append-only nature; it adds cost and time the stated low-overhead requirement is trying to avoid.

Why C is wrong: Change data capture is built for sources that change rows; this source is insert-only, so capturing updates and deletes adds source-side configuration and overhead for change types that never occur here.

Why D is wrong: A MERGE on EventId would avoid duplicates, but it still reads the entire source every run; the expensive full read is exactly what a watermark removes, so this keeps the cost the requirement wants to cut.

A data engineer manages dozens of scheduled Data Factory pipelines, Dataflows Gen2, and Spark notebooks across a single Microsoft Fabric workspace. Each morning they need one place that lists the recent runs of all of these item types together, with status and start time, so they can quickly spot any that failed overnight without opening each item individually. Which Fabric feature should they use?

• AOpen the run history on each individual pipeline and notebook in turn, reading the per-item activity output to confirm whether the most recent overnight run completed.
• BInstall the Microsoft Fabric Capacity Metrics app and read its timepoint detail page to see which scheduled items ran and whether any of them failed overnight.
• CCreate a Data Activator reflex that watches each pipeline and raises an alert, then review the alert history every morning to learn which runs failed.
• DOpen the Monitoring hub, which lists recent runs of pipelines, Dataflows Gen2, and notebooks together with their status and start time so failures are visible in one view.check_circle Correct

Why A is wrong: Per-item run history does show that item's runs, but checking each item separately is exactly the manual, item-by-item effort the requirement rules out and gives no single consolidated view.

Why B is wrong: The Capacity Metrics app reports compute consumption and throttling against a capacity, not a consolidated success or failure list of individual runs, so it is the wrong tool for spotting failed overnight jobs.

Why C is wrong: Data Activator can alert on conditions, but building and maintaining a reflex per item is heavier than needed and is forward-looking alerting rather than the consolidated run list the engineer asked to review each morning.

Why D is correct: The Monitoring hub aggregates run activity across item types in one filterable list with status and timing, which is precisely the single cross-item view needed to spot overnight failures quickly.