Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud Scheduler — cron-based job scheduling.

  Why it's wrong here

  Cloud Scheduler is a fully managed cron-based job scheduler that sends a single, predetermined trigger (e.g., an HTTP request, Pub/Sub message, or App Engine call) at the specified time or interval. It has no concept of a workflow graph, does not track dependencies between jobs, and cannot conditionally branch or pass data from one step to the next. Retries are only for the individual scheduled call, not for a chain of dependent tasks, and there is no centralized visibility into the progress of a multi-step pipeline. While you could assemble a workflow by chaining Scheduler triggers with Cloud Functions, this pattern becomes unmanageable for complex dependencies and lacks the built-in DAG logic, logging, and retry coordination of Cloud Composer.

• ✓

  Cloud Composer (managed Apache Airflow)

  Why this is correct

  Cloud Composer is a fully managed Apache Airflow service that allows you to author complex workflows as directed acyclic graphs (DAGs) in Python. It provides first-class operators for GCP services (e.g., Dataflow, Dataproc, BigQuery, Cloud Functions) and manages task dependencies, scheduling, retries, backfills, and execution history through the Airflow UI and REST API. The Airflow architecture includes sensors for polling external conditions, XComs for passing data between tasks, and a metadata database that tracks the state of each DAG run, making it the appropriate tool for coordinating multi-step pipelines across many systems. Its explicit DAG-based model ensures that all dependencies are captured and failures can be retried in the correct order, which is exactly what the question requires.

• ✗

  Cloud Dataflow — stream and batch processing.

  Why it's wrong here

  Cloud Dataflow is a fully managed service for executing Apache Beam pipelines, offering unified stream and batch data processing with capabilities like windowing, triggering, and auto-scaling. It is a powerful engine for transforming and processing data at scale, but it is scoped to a single, linear pipeline topology; it does not manage dependencies across multiple independent jobs or provide workflow-level scheduling, retries, or coordination with non-data services. You could implement a simple sequence of PTransforms within a pipeline, but cross-service orchestration (e.g., calling Cloud Functions, sending notifications, invoking ML training jobs) is out of its scope. Therefore, Dataflow is best used as a step inside an orchestrated workflow, not as the orchestrator itself.

• ✗

  Cloud Functions — event-driven function execution.

  Why it's wrong here

  Cloud Functions is a serverless compute platform that executes a single, stateless function in response to specific events (e.g., HTTP calls, Pub/Sub messages, or Cloud Storage changes). It is ideal for lightweight, event-driven tasks but has no built-in mechanism for defining multi-step dependencies, passing state between steps, or orchestrating complex workflows across heterogeneous services. Retries are limited to the function invocation itself, not the broader pipeline, and execution timeouts (up to 9 minutes for 1st Gen, 60 minutes for 2nd Gen) are unsuitable for long-running orchestration. Thus, while it can be a step performed by an orchestrator, it is not itself an orchestration platform.

Go deeper

Related to this question