Google ACE Practice Question: A payment service publishes an event to a message…

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 Tasks with one queue per downstream service

  Why it's wrong here

  Cloud Tasks is a managed task executor that dispatches an HTTP request to a single endpoint per queue, not a fan-out message bus. To reach three downstream services you would have to create three separate queues and enqueue three separate copies of every payment event, which forces the payment service to know each consumer's URL and manage per-service task duplication. That reintroduces the coupling and operational overhead the architecture is meant to eliminate, and there is no built-in guarantee that each queue receives the same message set for independent consumption.

• ✓

  Cloud Pub/Sub with one subscription per downstream service on a shared topic

  Why this is correct

  Cloud Pub/Sub's fan-out model is exactly this scenario: the payment service publishes each business event once to a single topic, and then each downstream service creates its own subscription to that same topic. Pub/Sub delivers every message to every subscription independently, with each subscription maintaining its own acknowledgment state, so consumers can process different views of the same event without coordinating with one another or with the publisher. This provides at-least-once delivery, independent retries, and horizontal scaling per service, which is why it's the correct decoupled pattern.

• ✗

  Cloud Storage event notifications with three separate buckets

  Why it's wrong here

  Cloud Storage event notifications are scoped to object operations like upload, overwrite, or delete inside a specific bucket, not to arbitrary business events from a service. To use three buckets as a fan-out you would need to write a copy of each payment event as an object to every bucket, which is slow, costs extra storage and writes, and still forces the payment service to know about each consumer's bucket. Moreover, these notifications lack message-level acknowledgment, dead-lettering, and retention features that a proper eventing system provides, so they are not a suitable message bus.

• ✗

  Directly calling each downstream service's API synchronously from the payment service

  Why it's wrong here

  Making synchronous point-to-point API calls from the payment service means the payment action's latency becomes the sum of all downstream response times, and if any one service is down or slow the entire payment operation is blocked. It also hard-codes the payment service to the exact endpoints, schemas, and versions of every consumer, so adding a new downstream service requires changing and redeploying the payment code. There is no buffering or retry isolation, so failures in one consumer can directly fail or roll back a completed payment, breaking the decoupling that event-driven design requires.

Go deeper

Related to this question