Pull vs push subscriptions in GCP - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference in message delivery between pull and push subscriptions

In Google Cloud Pub/Sub, what is the main difference in how messages are delivered to subscribers when using pull subscriptions versus push subscriptions?

A Both pull and push subscriptions require the subscriber to request messages manually.

B Pull subscriptions automatically send messages to a subscriber endpoint, while push subscriptions require the subscriber to request messages.

C Both pull and push subscriptions automatically send messages to subscriber endpoints without any requests.

D Pull subscriptions require the subscriber to request messages, while push subscriptions automatically send messages to a subscriber endpoint.

💡 Hint

Think about who initiates the message transfer in each subscription type.

Pull subscriptions require the subscriber to actively request messages from the Pub/Sub service. Push subscriptions send messages automatically to a configured endpoint without the subscriber requesting them.

❓ Architecture

intermediate

Choosing subscription type for a mobile app backend

You are designing a backend for a mobile app that processes notifications. The backend must handle variable load and scale automatically. Which subscription type is better suited for this scenario?

A Pull subscription, because the backend can control when and how many messages to fetch, allowing better load management.

B Push subscription, because messages are sent automatically and the backend does not need to manage message fetching.

C Push subscription, because it requires the backend to poll messages frequently to keep up with load.

D Pull subscription, because it automatically retries sending messages to the backend endpoint.

💡 Hint

Consider which subscription type gives more control over message processing rate.

Pull subscriptions allow the backend to control message fetching rate, which helps manage variable load and scale processing. Push subscriptions send messages automatically and may overwhelm the backend if load spikes.

❓ security

advanced

Securing push subscription endpoints

When using push subscriptions in Google Cloud Pub/Sub, what is a recommended security practice to protect the subscriber endpoint?

A Allow all incoming HTTP requests without authentication to avoid message delivery failures.

B Use HTTPS with authentication tokens and verify JWT tokens sent by Pub/Sub to ensure messages come from a trusted source.

C Use plain HTTP without encryption to reduce latency in message delivery.

D Disable authentication and rely on IP whitelisting only.

💡 Hint

Think about how to verify the identity of the sender and protect data in transit.

Using HTTPS with authentication tokens and verifying JWT tokens from Pub/Sub ensures that messages are securely delivered and come from a trusted source. Other options reduce security and risk unauthorized access.

❓ service_behavior

advanced

Message acknowledgement behavior in pull subscriptions

In a pull subscription, what happens if a subscriber does not acknowledge a message within the acknowledgement deadline?

A The message is automatically acknowledged by the Pub/Sub service.

B The message is permanently deleted and lost.

C The message becomes available again for delivery to the same or another subscriber.

D The message is sent to a dead-letter queue immediately.

💡 Hint

Consider what Pub/Sub does to ensure message delivery reliability.

If a message is not acknowledged within the deadline, Pub/Sub makes it available again for redelivery to ensure it is processed at least once.

✅ Best Practice

expert

Handling high throughput with push subscriptions

You have a push subscription sending messages to a backend service that occasionally experiences spikes in traffic. What is the best practice to ensure reliable message processing without losing messages?

A Implement a retry mechanism with exponential backoff on the backend and use Cloud Pub/Sub's dead-letter topic for failed messages.

B Disable retries and drop messages that fail to process during traffic spikes to reduce load.

C Use pull subscriptions instead of push subscriptions to avoid retries.

D Increase the acknowledgement deadline to several hours to prevent message redelivery.

💡 Hint

Think about how to handle failures and retries gracefully in push delivery.

Implementing retries with exponential backoff helps the backend recover from temporary failures. Using dead-letter topics captures messages that repeatedly fail, preventing message loss.