You work for a large ecommerce company. You are using Pub/Sub to ingest the clickstream data to Google Cloud for analytics. You observe that when a new subscriber connects to an existing topic to…

Question

Options

• ACreate a new topic, and publish the last 30 days of data each time a new subscriber connects to an existing topic.
• BSet the topic retention policy to 30 days.
• CSet the subscriber retention policy to 30 days.
• DAsk the source system to re-push the data to Pub/Sub, and subscribe to it.

• A
  6% (1)
• B
  76% (13)
• C
  12% (2)
• D
  6% (1)

Explanation

Option B is correct because Pub/Sub's topic retention policy stores messages on the topic itself for the specified duration (up to 31 days), allowing any new subscriber - even one created after the messages were published - to seek back and read historical data from the retention window.

Why the distractors fail:

• A is operationally impractical and doesn't scale - manually republishing 30 days of data every time a new subscriber connects is not a managed, persistent solution.
• C is the most common trap: subscriber (subscription) retention only extends how long unacknowledged messages are held on an existing subscription - it does nothing for brand-new subscribers who have no prior subscription to retain from.
• D relies on the upstream source system cooperating and re-sending data, which is fragile, not self-contained within GCP, and doesn't solve the problem going forward automatically.

Memory tip: Think of it this way - topic retention is like a DVR recording on the channel itself; anyone who tunes in later can rewind. Subscription retention is like a personal queue that only works if your DVR was already recording when the show aired.

No community discussion yet for this question.