Pub/Sub questions on the Professional Data Engineer exam love to probe two related ideas: how Google Cloud guarantees that messages reach subscribers, and what happens when a subscriber takes too long to process one. Both of those topics come down to two settings you configure on the subscription itself. Delivery semantics tell you whether duplicates are possible, and the acknowledgement deadline controls how long a subscriber gets before Pub/Sub decides the message needs to be redelivered. If you understand how these two settings interact, a surprising number of streaming-ingestion questions become easy.
I want to walk through both in the order they tend to show up on the Professional Data Engineer exam, with the gotchas that trip people up.
Pub/Sub offers two delivery modes on a subscription. The default is at-least-once delivery. The opt-in mode is exactly-once delivery. They are not interchangeable, and the exam will almost always frame a scenario where only one is correct.
At-least-once delivery guarantees that every message published to the topic will be delivered to the subscriber at least one time. No message is lost. The catch is that duplicates can occur. If the subscriber pulls a message but does not acknowledge it quickly enough, or if the ack reply gets lost on the way back to Pub/Sub, the service will redeliver the message. Your subscriber might end up seeing the same payload twice or even three times.
Exactly-once delivery is an additional feature that you have to enable explicitly on the subscription. When it is on, Pub/Sub guarantees that a successfully acknowledged message will not be redelivered to the same subscription. There are still some narrow edge cases involving message republishing from the publisher side, but from the subscriber's point of view, you stop having to write deduplication logic for retries inside Pub/Sub itself.
Here is the practical way to choose between them on the Professional Data Engineer exam:
The reason that last point matters is that exam questions sometimes test whether you understand that exactly-once delivery is not always the right answer. If the consumer already handles dedup, adding exactly-once at the Pub/Sub layer is unnecessary overhead.
Once a message is delivered, the subscriber has a window to acknowledge that it received and processed the message. That window is the acknowledgement deadline. If the subscriber does not send an ack within that window, Pub/Sub assumes processing failed and redelivers the message.
The default ack deadline on a new subscription is 10 seconds. You can change it up to a maximum of 10 minutes. There is no setting longer than 10 minutes. If you see an exam choice claiming you can configure a 30-minute ack deadline, that is the wrong answer.
The way I think about tuning this value:
There is also a separate mechanism called modifyAckDeadline, which lets the subscriber extend the deadline for a specific message on the fly. This is useful when processing time is variable. The subscriber can call modifyAckDeadline to push the deadline out while it works, and ack normally when done. Client libraries like the high-level Pub/Sub library do this automatically through a feature called lease management, which is why you sometimes see ack deadline behavior that seems longer than what is configured on the subscription itself.
This is where the Professional Data Engineer exam likes to set traps. Delivery semantics and the ack deadline are not independent. They reinforce each other.
Under at-least-once delivery, a too-short ack deadline practically guarantees duplicates. The subscriber needs more time, the deadline expires, Pub/Sub redelivers, and now the subscriber sees the same message twice. The fix is not to enable exactly-once. The fix is to extend the ack deadline so the subscriber stops missing it.
Under exactly-once delivery, the ack deadline still matters, but Pub/Sub will track the ack state for each message ID and avoid redelivering one that was already successfully acked. A subscriber that hits the deadline will still trigger a redelivery, but the dedup guarantees kick in to prevent two successful processings of the same logical message.
Most Pub/Sub questions on the Professional Data Engineer exam boil down to picking the right combination of these two settings for a given workload. Once you have the four bullet points above memorized, the scenarios get a lot easier to read.
My Professional Data Engineer course covers Pub/Sub delivery semantics, ack deadlines, and the full streaming ingestion path from publisher to Dataflow in detail.
