Pub/Sub Push Subscription Message Retry: HTTP Status Code Impact

Exhibit

Refer to the exhibit.
```
# Pub/Sub subscription config
projects/my-project/subscriptions/my-sub:
  topic: projects/my-project/topics/my-topic
  ackDeadlineSeconds: 10
  pushConfig:
    pushEndpoint: https://my-endpoint.example.com/push
    oidcToken:
      serviceAccountEmail: sa@my-project.iam.gserviceaccount.com
```

A team has set up a push subscription to an HTTPS endpoint. They notice that messages are not being acknowledged and are resent every 10 seconds. What is the most likely issue?

Quick Answer

The answer is that the push endpoint is returning HTTP 500. This is the most likely issue because Google Cloud Pub/Sub push subscriptions require a successful acknowledgment in the form of an HTTP 200 status code; any non-200 response, especially a 500 Internal Server Error, signals to Pub/Sub that the message delivery failed, triggering automatic retries. By default, the minimum retry interval for a push subscription message retry is 10 seconds, which explains the observed behavior of messages being resent every 10 seconds without acknowledgment. On the Google Professional Data Engineer exam, this scenario tests your understanding of how HTTP status code impact directly controls delivery semantics in Pub/Sub push subscriptions—a common trap is confusing client-side errors (4xx) with server errors (5xx), as only 5xx responses trigger retries. Remember the memory tip: "200 is okay, 500 means retry the message."

⚠ Common exam trap

Google Cloud often tests the misconception that the response body or processing time affects acknowledgment, when in fact only the HTTP status code determines whether a message is acknowledged or retried.

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 push endpoint is returning HTTP 500

In Google Cloud Pub/Sub push subscriptions, the subscriber must acknowledge messages by returning an HTTP 200 status code. If the endpoint returns HTTP 500, Pub/Sub interprets this as a failure and will retry delivery with exponential backoff, but the default minimum retry interval is 10 seconds. This matches the observed behavior of messages being resent every 10 seconds without acknowledgment.

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 push endpoint is returning HTTP 200 but taking too long to process
Why it's wrong here
If the endpoint eventually returns 200, Pub/Sub will acknowledge the message after the response.
✓
The push endpoint is returning HTTP 500
Why this is correct
Any non-200 response (e.g., 500) causes Pub/Sub to retry; 500 indicates a server error.
✗
The push endpoint is returning HTTP 200 with 'ack' in the body
Why it's wrong here
Pub/Sub only considers HTTP status code; body content does not affect acknowledgment.
✗
The push endpoint is returning HTTP 400
Why it's wrong here
A 400 error also causes retries, but 500 is more indicative of a failure; however, both cause retries, but B is a common issue.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on PDE

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Drag and drop the steps to set up a Pub/Sub topic with a push subscription to an HTTPS endpoint into the correct order.

medium

✓ A.Create a Pub/Sub topic, then create a push subscription with the HTTPS endpoint URL
B.Create a push subscription without an endpoint, then create the topic, then update the subscription with the endpoint
C.Configure the HTTPS endpoint to accept messages, then create the topic, then create the subscription
D.Create a topic, then create a pull subscription, then change it to a push subscription

Why A: The correct order to set up a Pub/Sub topic with a push subscription to an HTTPS endpoint is to first create the topic, then create a push subscription specifying the HTTPS endpoint URL. This ensures the topic exists before the subscription references it, and the push endpoint is configured at subscription creation time. Common mistakes include creating the subscription before the topic, omitting the endpoint, or attempting to convert a pull subscription to push, which is not supported.

Last reviewed: Jun 30, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

This PDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PDE exam.