A Microsoft Fabric process must run four steps every morning in a fixed order: copy files from a source, run a Dataflow Gen2 that curates them, run a notebook that builds aggregates only after the dataflow succeeds, and send a failure alert if any step fails. The team currently triggers each artefact on its own schedule a few minutes apart and finds the notebook sometimes starts while the dataflow is still running. Which change best gives true dependency-aware ordering with retries and alerts across all four steps?
- AStagger the four independent schedules further apart so each artefact has more time to finish before the next one is triggered, reducing the chance of an early start.
- BCombine the copy, curation, and aggregation into one large Spark notebook whose cells run top to bottom, so cell order enforces the dependency and a final cell sends the alert.
- CExpand the Dataflow Gen2 so its Power Query graph performs the copy, the curation, and the aggregation in one refresh, then add a separate alert dataflow for failures.
- DBuild a Data Factory pipeline that chains a Copy activity, a Dataflow activity, and a Notebook activity with on-success dependencies, activity retries, a schedule trigger, and a failure notification. Correct
Why A is wrong: Wider time gaps still do not wait for a step to actually succeed; a slow or failed dataflow lets the notebook start anyway, so this gives no real dependency control, retries, or built-in alerting.
Why B is wrong: A notebook can sequence its own cells but cannot natively invoke the separate Dataflow Gen2 with managed retries and per-step failure alerts across distinct artefacts, so it is the wrong orchestration surface here.
Why C is wrong: A Dataflow Gen2 transforms data within one query graph but cannot call the separate notebook or impose cross-artefact ordering with retries and alerting, so it cannot orchestrate four distinct steps in sequence.
Why D is correct: A pipeline is Fabric's orchestration surface: it sequences a Copy, a Dataflow Gen2, and a notebook with on-success dependency links, adds per-activity retries, runs on a schedule trigger, and raises a failure alert, which is the dependency-aware control flow required.