Pub/Sub gives you a choice between two delivery semantics, and it gives subscribers a deadline to acknowledge each message before a retry kicks in. These two settings sit at the heart of how reliable, idempotent, and timely your messaging pipeline is, and the Professional Cloud Architect exam expects you to know exactly what each one does.
Delivery semantics describe the guarantee Pub/Sub gives you about how many times a message will reach a subscriber. There are two options.
At-least-once delivery guarantees that no message is lost. Every message will be delivered to the subscriber at least one time. The trade-off is that duplicates may occur. If a subscriber is slow to acknowledge a message or if a transient failure happens, Pub/Sub will retry, and the same message can land in the subscriber more than once.
This is the default behavior in Pub/Sub. If you create a topic and a subscription and do nothing else, you are operating under at-least-once delivery.
Exactly-once delivery guarantees that no message is lost and no duplicates are created. Every message reaches the subscriber exactly one time. This is not the default. You have to enable exactly-once delivery on the subscription if you want it. Alternatively, you can achieve the same effect by combining Pub/Sub with Dataflow and using windows and triggers to keep ordering and ensure each message is processed once.
At-least-once is the default because it is the cheaper and simpler guarantee to provide at scale. Pub/Sub is designed to be massively distributed, and getting strict exactly-once semantics across a global distributed system has real costs in throughput and latency. By defaulting to at-least-once and letting you opt into exactly-once, Pub/Sub keeps the common path fast.
For a lot of workloads, at-least-once is fine, because the subscriber is already designed to be idempotent. If you process the same message twice and the result is the same, duplicates do not hurt you. The Professional Cloud Architect exam often tests whether you can recognize when idempotency saves you from needing exactly-once at all.
The acknowledgement deadline, or ack deadline, is the time window within which a subscriber must acknowledge a received message before Pub/Sub retries delivery. If the subscriber sends an ack before the deadline expires, the message is considered processed and Pub/Sub stops tracking it. If the deadline passes without an ack, Pub/Sub assumes the message was not successfully processed and redelivers it.
You can shorten or extend the ack deadline depending on what your subscriber needs.
Extend it when your subscriber is struggling to keep up. If processing each message takes longer than the current deadline, you will end up with retries piling on top of retries, and the system will look like it is failing even though the subscriber is doing the work. A longer deadline gives the subscriber breathing room and prevents unnecessary duplicate deliveries.
Shorten it when you need faster retries. If a subscriber instance crashes, you do not want to wait minutes before another subscriber picks up the message. A short deadline makes the system recover quickly from subscriber failures at the cost of more retries when subscribers are merely slow.
The maximum ack deadline is 10 minutes. If you have work that legitimately takes longer than that, you need to use modAckDeadline calls to extend the deadline on a per-message basis while the work is in progress, rather than setting a longer subscription-level deadline.
The ack deadline is the main reason at-least-once delivery produces duplicates. If a subscriber processes a message successfully but the ack does not reach Pub/Sub before the deadline expires, Pub/Sub will redeliver. The subscriber sees the same message a second time even though it already finished the work.
This is why tuning the ack deadline matters even when you are using exactly-once delivery. Exactly-once removes the duplicate delivery, but it does not remove the redelivery cost if the deadline is too short for your processing time.
For the Professional Cloud Architect exam, hold onto a few clear facts. At-least-once is the default. Exactly-once must be enabled, or it can be approximated by pairing Pub/Sub with Dataflow. The ack deadline controls when Pub/Sub gives up waiting and retries, and 10 minutes is the upper bound at the subscription level. Extend the deadline when subscribers are slow, shorten it when you want fast recovery from subscriber failures.
My Professional Cloud Architect course covers Pub/Sub delivery semantics and the acknowledgement deadline alongside the rest of the messaging and pipelines material.
