A platform team must automate two distinct flows. The first chains roughly forty interdependent Spark and BigQuery steps every night, needs per-task retries and visibility into each step, and must back-fill missed dates after an outage. The second reacts to a single file arriving in Cloud Storage by calling three REST APIs in sequence with light branching, finishing in seconds, and the team wants no always-on orchestration cost for it. Which TWO service choices, each matched to the right flow, make both workloads repeatable while fitting their orchestration needs? (Select TWO.)
- AUse Cloud Composer for the forty-step nightly pipeline, so the DAG expresses the inter-step dependencies, provides per-task retries, exposes per-step run history, and can back-fill missed logical dates after an outage. Correct
- BUse Cloud Composer for the event-driven file flow as well, keeping the environment running continuously so the same orchestrator handles both the nightly pipeline and the quick API calls under one tool.
- CUse Cloud Scheduler alone for the forty-step nightly pipeline, defining one cron job per step and ordering them purely by staggered cron times so each step fires after the previous one is expected to finish.
- DUse Google Cloud Workflows for the file-triggered flow, invoking it from an Eventarc trigger on the Cloud Storage event so it sequences the three REST calls with light branching and bills only per execution. Correct
- EUse Google Cloud Workflows for the forty-step nightly pipeline too, modelling every Spark and BigQuery dependency in a single workflow definition so both flows share one serverless orchestration engine.
Why A is correct: Cloud Composer runs managed Airflow, whose DAGs model many interdependent steps with per-task retries, a per-step run history, and catch-up back-filling of missed logical dates, which matches every requirement of the long nightly pipeline.
Why B is wrong: Consolidating on one tool is tempting, but a Composer environment runs continuously and bills for that capacity, which is the wrong fit for a seconds-long event-driven flow where the team explicitly wants no always-on orchestration cost.
Why C is wrong: Cloud Scheduler can fire jobs on a cron cadence, but staggering forty cron times does not express real dependencies, retries, or back-fill, so a slow or failed step would let later steps run anyway, which fails the ordered nightly pipeline.
Why D is correct: Workflows is a serverless orchestrator that sequences REST and API calls with conditional branching and charges per step executed rather than for idle capacity, and an Eventarc trigger on the object event starts it, which fits the seconds-long event-driven flow with no always-on cost.
Why E is wrong: Workflows suits short API-style sequences, but it lacks the rich DAG scheduling, catch-up back-fill, and per-task operational tooling that a forty-step data pipeline with missed-date recovery needs, so it is the wrong engine for the heavy nightly flow.