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, which triggers a series of jobs at specified cron intervals

  Why it's wrong here

  Cloud Scheduler is a fully managed cron service that fires a single target (HTTP endpoint, Pub/Sub topic, or App Engine service) on a fixed time schedule. It does not maintain state between invocations, evaluate prior job results, or implement conditional branching such as 'if the build passed, deploy; otherwise notify'. While Cloud Scheduler can trigger a Workflows execution at a set interval, relying on it alone to orchestrate a multi-step CI/CD pipeline would require stitching together many independent schedules and external logic to simulate conditions and error handling, which is exactly what Workflows is designed to do natively.

• ✓

  Google Cloud Workflows, which orchestrates multi-step processes by calling APIs in sequence with conditional logic, error handling, and state management

  Why this is correct

  Workflows is the purpose-built orchestration service. It defines steps that call Cloud Build API, evaluate results, and conditionally proceed to Cloud Run deployment or notification — exactly the described use case. It handles retries, parallelism, and state automatically.

• ✗

  Cloud Pub/Sub, by publishing messages between pipeline stages to trigger each subsequent step

  Why it's wrong here

  Cloud Pub/Sub is an asynchronous, durable messaging service that decouples event producers from consumers, enabling fan-out, event-driven architectures, and at-least-once delivery. It can be used to connect pipeline stages via topics and subscriptions, but it has no built-in concept of a 'workflow' — it does not sequence steps, preserve the overall execution state, evaluate intermediate outcomes, or decide the next step based on previous results. Moreover, message ordering is only guaranteed within a single ordered key and retries can cause duplicate messages, so building the described conditional deployment logic on Pub/Sub alone would require substantial custom code (e.g., lock states, idempotency, and a state store). Pub/Sub is a transport layer, not an orchestration engine.

• ✗

  Cloud Run, by writing the orchestration logic as a container application that calls other services sequentially

  Why it's wrong here

  You could write orchestration logic as a Cloud Run application, but this requires custom code for retry handling, state management, and error recovery that Workflows provides out of the box. Using the purpose-built service is more maintainable.

Go deeper

Related to this question