Google ACE Practice Question: A team builds a document processing pipeline:…

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 Pub/Sub with a subscription per step

  Why it's wrong here

  Cloud Pub/Sub is a serverless, asynchronous messaging service that decouples producers from consumers; it does not manage workflow state or enforce a sequence between steps. Using a subscription per step would require manually tracking topics and subscriptions, and Pub/Sub does not natively guarantee message ordering, so coordinating dependent multi-step logic becomes a custom effort. You would need to build dead-letter queues, acknowledgement handling, and conditional routing yourself, making this approach unsuitable for orchestrated workflows.

• ✗

  Cloud Tasks with per-step queues

  Why it's wrong here

  Cloud Tasks is a task queue service that dispatches HTTP requests to a target with configurable retries and schedule times; it operates as independent work items, not as a workflow state machine. Per-step queues could simulate a sequence by having each task trigger the next, but the service offers no built-in conditional branching, per-execution state, or dependency management. To implement anything beyond a simple linear pipeline, you must embed orchestration logic inside the task handlers, leading to duplicated code and poor operational visibility.

• ✓

  Cloud Workflows

  Why this is correct

  Cloud Workflows is a fully managed orchestration service that defines steps in a YAML specification, allowing sequential or parallel execution, conditionals (e.g., if/switch), and subworkflows. It provides built-in retry with exponential backoff, timeout policies, and automatic state persistence, so every execution is logged and auditable. Direct connectors for Google Cloud services (like Cloud Run, Cloud Functions, BigQuery) let you call APIs without writing HTTP glue code, making it the correct choice for coordinating dependent multi-step pipelines with conditional logic and centralized error handling.

• ✗

  Cloud Functions chained via HTTP calls

  Why it's wrong here

  Chaining Cloud Functions via HTTP calls creates a tight coupling where each function must know the URL of the next function and parse the response, making the system brittle and hard to maintain. Each function invocation is independent and stateless, so there is no centralized place to define retries, timeouts, or error propagation; any failure in the chain leaves the execution in an unknown state. The result is a linear pipeline with no built-in workflow state, conditional branching, or end-to-end visibility, which is exactly the problem a purpose-built orchestration service solves.

Go deeper

Related to this question