Google ACE Practice Question: Designing an application that needs to process…

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 Functions subscribed to the Pub/Sub topic with idempotent logic.

  Why it's wrong here

  Cloud Functions triggered by Pub/Sub receive each message at-least-once; a function may be invoked multiple times for the same message due to redelivery or retries. Writing idempotent logic (e.g., using the message ID as a primary key or checking a side-effect store) can prevent double-side effects, but it does not convert the delivery system into exactly-once. The function itself may not be re-run under the same execution context if a partial failure occurs, and the correctness relies on the developer implementing a safe dedup strategy. It's a workaround, not a native exactly-once mechanism.

• ✓

  Dataflow with Pub/Sub as the source using the Beam SDK.

  Why this is correct

  Dataflow's Beam runner leverages the Pub/Sub I/O source that checkpoints its read position and assigns each message a unique ID when it is pulled; on replay, the runner deduplicates message IDs so that the pipeline processes each message exactly once even if Pub/Sub redelivers. This is a built-in, distributed, and managed capability of Dataflow, enabling exactly-once semantics without custom application code. It also supports autoscaling and checkpointing with Apache Beam's stateful processing. Therefore, it is the correct choice for a managed exactly-once processing guarantee.

• ✗

  BigQuery Subscriptions connected directly to the Pub/Sub topic.

  Why it's wrong here

  A Pub/Sub BigQuery subscription is a direct, write-only pipeline that streams messages into a BigQuery table using the Storage Write API with at-least-once delivery. Pub/Sub will retry a write if the ack isn't sent or fails, and the subscription performs no deduplication or transformation, so the table can contain duplicate rows. It also cannot apply custom processing logic or aggregate across messages, making it unsuitable for a data processing pipeline that needs exactly-once semantics.

• ✗

  Cloud Run with a Pub/Sub push subscription and database deduplication table.

  Why it's wrong here

  With Cloud Run, an HTTP endpoint receives each Pub/Sub push message at least once, and retries occur unless the service returns an ack. You would need to implement a deduplication table that records every unique Pub/Sub message ID before processing, then atomically check-and-insert or use a transaction to avoid concurrent duplicates. However, that table is itself a data store with its own consistency model, and a failure between insertion and processing can still cause a gap or duplicate, so the guarantee is only as strong as your custom logic, not an infrastructure-level guarantee. This adds significant complexity and operational overhead.

Go deeper

Related to this question