A data engineer is designing the full nightly digitisation-ingestion pipeline from scratch: a Copy activity should retry a few times on transient network blips, a reformatting notebook should run only once the copy genuinely succeeds, and a Teams alert should fire only if the copy ultimately fails after its retries are exhausted. What combination of orchestration features achieves all three requirements together?
Select an answer to reveal the explanation.
Short Explanation
Three separate jobs, three separate settings: retries handle the little network blips, a Succeeded dependency hands off to the reformatting notebook once the copy truly worked, and a Failed dependency routes to the Teams alert only when retries run out entirely. Put all three together and the whole nightly flow takes care of itself.
Full Explanation
Each requirement maps to a distinct, well-defined pipeline feature: a retry count and interval on the Copy activity absorbs transient network blips automatically before ever counting the run as failed; a Succeeded dependency condition from the Copy activity to the reformatting notebook ensures the notebook only ever processes data from a copy that genuinely completed, retries included; and a Failed dependency condition from the Copy activity to the Teams alert activity fires the alert specifically when the copy exhausts its retries and truly fails, not on every run. Combining all three in one pipeline satisfies every stated requirement without extra machinery. Putting all the logic in a single notebook with no pipeline discards retry handling, dependency branching, and orchestration visibility entirely, none of which a bare notebook provides on its own. A schedule trigger alone determines only when the pipeline starts; it says nothing about retries or about which path a failure or success should take afterward, so it can't satisfy the other two requirements by itself. Looping the Copy activity indefinitely inside a ForEach until it eventually succeeds, with no alert step, abandons the requirement for a Teams alert on failure altogether and risks a pipeline that never terminates against a genuinely broken source. The caveat: retry count and interval should be tuned to the nature of the failure — enough attempts to ride out a brief blip, not so many that a real outage silently stalls the whole night's run. A concrete check: simulate a persistent copy failure in a test run and confirm the retries exhaust, the notebook does not execute, and the Teams alert fires exactly once.