PDE Practice Question: Refer to the exhibit

Exhibit

Refer to the exhibit.

Cloud Pub/Sub subscription configuration:

{
  "name": "projects/my-project/subscriptions/my-sub",
  "topic": "projects/my-project/topics/my-topic",
  "pushConfig": {},
  "ackDeadlineSeconds": 10,
  "messageRetentionDuration": "86400s",
  "expirationPolicy": {
    "ttl": "604800s"
  },
  "enableMessageOrdering": false,
  "retryPolicy": {
    "minimumBackoff": "10s",
    "maximumBackoff": "600s"
  },
  "deadLetterPolicy": {
    "deadLetterTopic": "projects/my-project/topics/dead-letter-topic",
    "maxDeliveryAttempts": 5
  }
}

Refer to the exhibit. A Dataflow streaming pipeline subscribes to this Pub/Sub subscription. The pipeline occasionally takes more than 10 seconds to process a message. Which behavior will occur?

⚠ Common exam trap

Google Cloud often tests the distinction between ack deadline expiration and dead letter topics, trapping candidates who assume any processing delay immediately triggers a dead letter or that Pub/Sub uses exponential backoff like some other messaging systems.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The message will be redelivered after 10 seconds if not acknowledged.

Pub/Sub delivery requires an acknowledgment within the configurable `ackDeadlineSeconds` (default 10 seconds). If the pipeline takes longer than the ack deadline to process a message, Pub/Sub considers the message unacknowledged and redelivers it. This is the standard behavior for at-least-once delivery in Google Cloud Pub/Sub.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The message will be sent to the dead letter topic immediately.
Why it's wrong here
Pub/Sub redelivers a message when its acknowledgement deadline expires; exceeding ten seconds triggers redelivery, not immediate dead-lettering. Dead-lettering occurs only after the configured maximum delivery attempts are exhausted, so a slow message is retried rather than discarded at once.
✗
The message will be retried with exponential backoff as per retry policy.
Why it's wrong here
Pub/Sub retry policies apply only to acknowledged failures; a message still within its ack deadline is neither redelivered nor backed off, so the pipeline's slow processing simply continues until the deadline lapses. Retry policy with exponential backoff suits push subscriptions where the endpoint returns an error.
✓
The message will be redelivered after 10 seconds if not acknowledged.
Why this is correct
The subscription's acknowledgement deadline is 10 seconds, so a message still unacknowledged when that window expires becomes eligible for redelivery. Because processing occasionally exceeds 10 seconds, the pipeline may receive duplicates, requiring idempotent handling or an extended deadline to avoid repeated processing.
✗
The message will be dropped after 10 seconds due to expiration policy.
Why it's wrong here
Expiration policy governs how long Pub/Sub retains an unacknowledged message before discarding it, typically days, not the 10-second ack deadline. Dropping after 10 seconds describes the ack deadline expiring, which triggers redelivery rather than deletion. Expiration policy is the right control for discarding stale backlog.

Go deeper

PDE Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question