Most Professional Cloud Architect questions about Pub/Sub start with the basic flow, but the exam scenarios that trip people up live downstream of acknowledgment. Once a subscriber acks a message, what happens next depends entirely on how you configured retention, whether you have a snapshot, and whether you know what Seek does. I want to walk through the message lifecycle in order, then dig into the three features that make replay possible.
Every Pub/Sub message moves through the same five steps. Understanding the order matters because retention and Seek both operate on the boundary between acknowledgment and deletion.
First, a topic is created. The topic is a named channel inside Pub/Sub that holds messages until a subscription serves them. Second, a publisher sends a message to that topic. The publisher could be an application, a microservice, or a fleet of sensors. Pub/Sub queues the message and waits for a subscriber to receive it. Third, the subscriber receives the message either by pulling from the topic or by having Pub/Sub push the message to an HTTPS endpoint. Fourth, the subscriber acknowledges the message back to Pub/Sub, which signals successful processing. Fifth, Pub/Sub deletes the message from the queue.
That fifth step is where retention, snapshots, and Seek become interesting. Without those features, an acknowledged message is gone forever. With them, you have several ways to bring it back.
The message retention duration is the time period for which Pub/Sub retains messages before deleting them. The point of retention is to make messages available for replay so you can reprocess or re-consume them.
There are two retention scopes you can configure, and they behave differently. Topic retention keeps messages within the topic itself, even after every subscriber has acknowledged them. This is what lets you replay an acknowledged message later, which is the use case auditors and reprocessing pipelines care about. Subscription retention only keeps unacknowledged messages, scoped to a specific subscription. Subscription retention is the safety net for a subscriber that goes down before it can ack. Once it recovers, the messages it missed are still waiting.
The defaults are easy to remember and they show up in exam questions. Topic retention defaults to 7 days and maxes out at 31 days. Subscription retention defaults to no retention at all, with the same 31 day maximum. If a question describes a team that needs to replay messages from a week ago and they never touched the retention settings, the topic might still have those messages but only because of the 7 day default. If the scenario stretches beyond a month, retention alone cannot help.
A snapshot captures a specific state of a subscription as a recovery point for potential future use. The mental model is a picture of your subscription at a moment in time, recording exactly which messages had been acknowledged.
The use case Google highlights is creating a known good state before a major update to your processing logic. You take the snapshot, deploy the change, and if the new logic produces bad results you have a clean rollback target. Without the snapshot, rolling back means you have lost the original acknowledgment state and you cannot reliably replay only the messages the new logic mishandled.
Snapshots are tied to subscriptions, not to topics. A snapshot is only useful in combination with the third feature, which is what actually performs the replay.
Seek is the tool that changes the acknowledgment state of messages in bulk, including messages that have already been acknowledged. Retention keeps messages around. Snapshots record a state. Seek is what flips messages back to unacknowledged so they get redelivered.
You can seek to a snapshot or to a specific time. Seeking to a snapshot returns the subscription to the acknowledgment state captured by that snapshot, so anything the snapshot recorded as unacknowledged becomes unacknowledged again. Seeking to a time is simpler but blunter. Every message received before that timestamp gets marked acknowledged, and every message received after that timestamp gets marked unacknowledged. The post-timestamp messages will be redelivered to the subscriber.
Seek works in combination with retention. Retention determines how far back in time you can replay, and Seek is what triggers the replay. If your topic retention is 7 days and you try to seek to a point 14 days ago, the messages from 14 days ago are gone and Seek has nothing to bring back. The Professional Cloud Architect exam loves this kind of dependency. A scenario that asks for a 30 day replay window needs both 30 day retention and the ability to seek into it.
The pattern I see most often in Professional Cloud Architect scenarios is a question that mixes a recovery requirement with a configuration choice. The setup describes a team that needs to reprocess messages from a specific window or roll back from a bad deploy, and the answers offer combinations of retention durations, snapshot timing, and Seek operations.
The decision tree is short. If the requirement is replaying acknowledged messages, you need topic retention long enough to cover the window plus a Seek to a time or snapshot. If the requirement is recovering messages a downed subscriber missed, subscription retention covers it without snapshots. If the requirement is rolling back a processing logic deploy, you take a snapshot before the deploy and seek to it after. If retention is shorter than the window the question describes, no combination of snapshots and Seek will save you.
One detail worth holding onto: Seek can also be used to update the message retention duration in some flows, which is occasionally useful when you realize mid-incident that you need a longer window. The primary mechanic is still the acknowledgment-state flip.
My Professional Cloud Architect course covers Pub/Sub message lifecycle alongside the rest of the messaging and pipelines material.
