Pub/Sub is a managed messaging backbone that decouples publishers from subscribers, but the way subscribers actually receive messages is a choice. You either let Pub/Sub push messages to you the moment they arrive, or you ask Pub/Sub for messages on your own schedule. That single choice changes your latency profile, your code complexity, and the kind of subscriber endpoint you can use. The Professional Cloud Architect exam tests whether you can pick the right one for a given scenario.
A subscription is the named pipeline that connects a topic to a subscriber. The topic holds the messages publishers send. The subscription is what tracks delivery state for one consumer (or one consumer group) reading from that topic. Multiple subscriptions can read the same topic independently, and each subscription has its own delivery type. That delivery type is what we are choosing between.
With a push subscription, Pub/Sub initiates the delivery. When a message lands on the topic, Pub/Sub forwards it to the subscriber as an HTTPS POST request. The subscriber does not poll. It does not ask. It just needs to be running and listening at a known URL.
The hard requirement is that the subscriber must be a webhook endpoint that accepts POST over HTTPS. That makes push subscriptions a natural fit for Cloud Run, Cloud Functions, App Engine, or any HTTPS-reachable service you control. The endpoint receives the message in the request body, processes it, and returns a 2xx status code to acknowledge. A non-2xx response (or a timeout) tells Pub/Sub to retry.
Push is the right choice when you want low-latency, real-time delivery. Messages flow as fast as Pub/Sub can dispatch them, which suits event-driven workloads where each message should trigger work as soon as possible. It is also lower-code on the subscriber side because you do not have to write a polling loop or manage acknowledgement explicitly beyond returning the right HTTP status.
With a pull subscription, the subscriber initiates the request. Your code calls the Pub/Sub API and asks for messages. Pub/Sub returns whatever is available, your subscriber processes them, and your code explicitly acknowledges each one so Pub/Sub knows it can stop redelivering.
Pull is better when you are doing batch delivery or processing a large volume of messages where you want control over throughput. Because your subscriber decides when to ask, you can pace ingestion to match downstream capacity. It also works for any subscriber that can speak to the Pub/Sub API, not just HTTPS endpoints. A long-running worker on Compute Engine, a Dataflow job, or a process inside GKE can all pull messages without needing to expose a public webhook.
The cost is more code. You are responsible for the pull loop, batching, acknowledgement, and handling cases where messages arrive faster than you can process them. The Pub/Sub client libraries make this easier with streaming pull, but the model is still subscriber-driven.
The decision tree the Professional Cloud Architect exam expects is short. If the scenario calls out low-latency, real-time, event-driven processing and the subscriber is an HTTPS endpoint (Cloud Run, Cloud Functions, App Engine), pick push. If the scenario describes batch processing, large message volumes, throughput control, or a subscriber that is not a webhook (a Compute Engine worker, a Dataflow pipeline, a GKE pod pulling work), pick pull.
Two phrases that show up in PCA questions are worth memorizing. "Webhook endpoint that accepts POST over HTTPS" points at push. "Batch delivery" or "large volume of messages with control over consumption" points at pull.
In real designs you often see both on the same topic. A push subscription routes messages to a Cloud Run service that handles real-time fan-out (notifications, webhooks, low-latency reactions). A separate pull subscription on the same topic feeds a Dataflow pipeline that batches messages for analytics or archival. Each subscription tracks its own acknowledgement state, so the two consumers do not interfere with each other. That pattern is worth recognizing because it shows up in PCA case studies where one event needs both an immediate response and a downstream batch process.
My Professional Cloud Architect course covers Pub/Sub push vs pull subscriptions alongside the rest of the messaging and pipelines material.
