Question 1

What is Cloud Pub/Sub?

Accepted Answer

Pub/Sub is a fully managed, globally distributed messaging service implementing the publish-subscribe pattern. Publishers send messages to a topic, subscribers receive them through subscriptions, and Pub/Sub decouples the two — publishers do not know who consumes, and consumers can be added without changing the publisher. It scales to millions of messages per second with no capacity planning. The property to emphasise is decoupling in both time and space: a subscriber that is down does not block the publisher, and messages are retained until acknowledged or until the retention window expires. That is what makes it the backbone of event-driven architectures.

Question 2

What is the difference between a topic and a subscription?

Accepted Answer

A topic is the named channel publishers write to. A subscription is a named stream of messages from that topic for one consumer group — each subscription receives its own copy of every message. So two subscriptions on one topic means two independent consumers each get everything; two consumer instances on one subscription share the load. This is the fan-out versus load-balancing distinction and candidates get it wrong constantly. If you want three services to react to an order event, you create three subscriptions. If you want ten workers sharing the load, they all pull from one subscription.

Question 3

What is the difference between a push and a pull subscription?

Accepted Answer

With a pull subscription, the subscriber calls Pub/Sub to fetch messages and controls its own rate — good for high throughput and for consumers that manage their own concurrency. With a push subscription, Pub/Sub sends an HTTP POST to an endpoint you configure and treats a 2xx response as an acknowledgement — good for serverless targets like Cloud Run that scale on incoming requests. The backpressure difference is the substance: with pull, a slow consumer simply pulls less; with push, Pub/Sub applies flow control based on your success rate and latency, and a slow endpoint causes retries and duplicate delivery. Streaming pull is the modern high-throughput variant worth naming.

Question 4

What delivery guarantee does Pub/Sub provide?

Accepted Answer

At-least-once delivery by default: every message is delivered at least once, but duplicates are possible — after a redelivery, a network retry, or when an acknowledgement deadline expires. Pub/Sub also offers exactly-once delivery within a region for pull subscriptions, which removes duplicates caused by redelivery, though the consumer must still be designed carefully. The engineering consequence is that consumers must be idempotent regardless. Interviewers ask this expecting you to volunteer the idempotency requirement without prompting; a candidate who assumes exactly-once semantics and designs a non-idempotent handler has failed the real question.

Question 5

How do you make a Pub/Sub consumer idempotent?

Accepted Answer

Give each message a stable business identifier — an order ID, an event ID — and record processed identifiers in a store with a uniqueness constraint, checking before acting. Alternatively make the operation naturally idempotent, such as an upsert keyed on the business ID rather than an increment, or use a transactional outbox so processing and state change commit together. The important detail is to deduplicate on a *business* key, not on the Pub/Sub message ID, because a genuine republish after a failure produces a new message ID for the same logical event. Naming that distinction is what shows real experience.

Question 6

What is the acknowledgement deadline and what happens if it expires?

Accepted Answer

The ack deadline is how long a subscriber has to acknowledge a message before Pub/Sub considers it unprocessed and redelivers it, defaulting to 10 seconds and configurable up to 600. Client libraries automatically extend the deadline while processing continues, up to a maximum total. The classic failure is a handler that takes longer than the deadline without extension, so the message is redelivered while still being processed — producing duplicates and, in the worst case, an infinite loop of expensive reprocessing. Recognising that symptom is a strong practical signal.

Question 7

What is a dead letter topic and why use one?

Accepted Answer

A dead letter topic receives messages that have failed delivery more than a configured maximum number of times, so a permanently unprocessable message — a poison message — is moved aside instead of blocking or endlessly retrying. You then inspect and remediate those messages separately. Without it, a single malformed message can be redelivered forever, consuming resources and, if ordering is enabled, blocking every subsequent message on that key. The configuration detail is that the Pub/Sub service account needs publish permission on the dead letter topic and subscribe permission on the source subscription.

Question 8

How does message ordering work in Pub/Sub?

Accepted Answer

Ordering is off by default because it constrains throughput. When you enable it and publishers set an ordering key, messages with the same key are delivered to the subscriber in the order they were published. Messages with different keys are unordered relative to each other, which is what preserves parallelism. The cost to name is head-of-line blocking: if a message for a key cannot be processed, later messages for that same key wait. Choosing the ordering key granularity is therefore a throughput decision — per user or per entity is usually right, per topic is a mistake.

Question 9

What is message retention and seek?

Accepted Answer

A subscription retains unacknowledged messages for up to seven days by default. If you enable retention of acknowledged messages, you can also seek backwards to a timestamp or a snapshot and replay messages that were already processed. Seek forward discards messages up to a point. Replay is the disaster-recovery capability that makes Pub/Sub more than a queue: after a bug corrupts downstream data, you fix the consumer, seek to before the bug, and reprocess. That requires idempotency, which is why the two topics always come up together.

Question 10

What is a Pub/Sub snapshot?

Accepted Answer

A snapshot captures the acknowledgement state of a subscription at a point in time. You can later seek the subscription — or a different subscription on the same topic — back to that snapshot, replaying everything unacknowledged as of then. It is the standard safety net before deploying a risky consumer change. The deployment pattern to describe: take a snapshot, deploy the new consumer, and if it misbehaves, seek back to the snapshot and replay with the previous version. That turns a risky consumer deployment into a recoverable one.

Question 11

How does Pub/Sub compare with Apache Kafka?

Accepted Answer

Pub/Sub is fully managed with no partitions, brokers or capacity planning, scales elastically, and is global by default. Kafka gives you a durable, replayable partitioned log with consumer-controlled offsets, a rich ecosystem including Kafka Streams and Connect, and portability across clouds, at the cost of operating a cluster or paying for a managed one. The technical distinction that matters is the log model: Kafka consumers manage offsets and can rewind arbitrarily within retention, while Pub/Sub tracks acknowledgements per message and replays through seek. GCP also offers Managed Service for Apache Kafka for teams that need the Kafka API specifically.

Question 12

What is Pub/Sub Lite and when would you use it?

Accepted Answer

Pub/Sub Lite was a lower-cost, zonal or regional service where you provision throughput and storage capacity yourself, trading elasticity and global availability for a much lower price at high, predictable volume. Google has since deprecated it in favour of Pub/Sub and Managed Service for Apache Kafka. Knowing it is deprecated is more valuable than knowing its features, because recommending it now would be wrong. The general lesson to draw is that partition-provisioned messaging on GCP is now served by managed Kafka rather than a Pub/Sub variant.

Question 13

What is a BigQuery subscription?

Accepted Answer

A BigQuery subscription writes messages from a topic directly into a BigQuery table with no intermediate processing service, using the topic schema to map fields. It removes the need for a Dataflow job when all you want is to land raw events in the warehouse. The trade-off is that it does no transformation, enrichment or validation, so it is right for raw event landing and wrong when you need to join reference data or apply business logic. Cloud Storage subscriptions serve the same role for file-based landing.

Question 14

What are Pub/Sub schemas?

Accepted Answer

A schema — Avro or Protocol Buffers — can be attached to a topic so that published messages are validated against it and rejected if they do not conform. It enforces a contract between producer and consumer and supports controlled schema evolution with revisions. The value is catching a breaking change at publish time rather than in a downstream consumer at 3am. The evolution rules matter: adding an optional field is safe, removing a field or changing a type is not, and knowing which changes are compatible is the practical skill.

Question 15

How does Pub/Sub handle flow control and backpressure?

Accepted Answer

For pull subscriptions, the client library applies flow control limits on outstanding messages and bytes, so a subscriber only holds as much as it can process. For push subscriptions, Pub/Sub adapts the push rate based on the endpoint's success rate and latency, backing off on errors with exponential retry. The failure to describe is unbounded concurrency: a consumer that pulls without flow-control limits will accept more messages than it can process, exhaust memory, miss ack deadlines and trigger mass redelivery. Setting outstanding-message limits is the fix and it is frequently omitted.

Question 16

How is Pub/Sub priced?

Accepted Answer

Primarily by the volume of message data published and delivered, measured in bytes with a minimum billable size per message, plus storage for retained messages and any cross-region egress. There are no per-partition or per-instance charges because there is nothing to provision. The minimum billable message size is the detail that matters: a design that publishes a very large number of tiny messages pays a premium, so batching small events is a genuine optimisation. Fan-out also multiplies delivery cost — one publish to five subscriptions is five deliveries.

Question 17

What is the difference between Pub/Sub and Cloud Tasks?

Accepted Answer

Pub/Sub is for broadcasting events to potentially many consumers at high throughput, with no per-message scheduling. Cloud Tasks is a task queue with per-task control — schedule a task for a specific future time, deduplicate by task name, and rate-limit dispatch to protect a downstream system. The selection rule is whether you need to control the *rate* at which work reaches a specific target. Calling a fragile third-party API is a Cloud Tasks job; publishing an order-created event for several services to react to is a Pub/Sub job.

Question 18

What is Eventarc and how does it use Pub/Sub?

Accepted Answer

Eventarc is the unified eventing layer that routes events from GCP services, custom sources and third parties to targets such as Cloud Run, GKE and Workflows, in the CloudEvents format. Many of its sources are delivered through Pub/Sub underneath, so its delivery semantics inherit at-least-once behaviour. The practical implication is that Eventarc triggers also need idempotent handlers, and that audit-log-based triggers have noticeably higher latency than direct sources. Knowing when Eventarc adds value — a uniform trigger model — versus when a direct Pub/Sub subscription is simpler is the judgement being tested.

Question 19

A Pub/Sub subscription has a growing backlog. How do you investigate?

Accepted Answer

Check the oldest unacknowledged message age and the undelivered message count metrics first. Then determine whether consumers are failing (high nack or error rate), too slow (processing latency above the publish rate), too few (not scaling out), or blocked by ordering keys. Also check whether ack deadlines are expiring, which causes redelivery and makes the effective throughput worse. The metric to name explicitly is oldest_unacked_message_age, because it is the right alerting signal — backlog count alone can be misleading during a legitimate spike, while a growing age means you are falling permanently behind.

Question 20

How do you scale a Cloud Run push consumer with Pub/Sub?

Accepted Answer

Cloud Run scales on incoming request rate, so a push subscription naturally drives scale-out. Set maximum instances to protect downstream systems, tune concurrency so each instance handles an appropriate number of messages, ensure the handler acknowledges only after successful processing by returning a non-2xx on failure, and configure a dead letter topic with a retry policy. The downstream protection point is essential: without a max-instances cap, a backlog burst can spin up hundreds of instances that overwhelm a database. Naming that connection between messaging backpressure and database connection limits is a senior-level observation.

Question 21

What is the difference between a nack and letting the ack deadline expire?

Accepted Answer

A nack explicitly tells Pub/Sub that the message was not processed, triggering immediate redelivery. Letting the deadline expire achieves redelivery too, but only after the deadline passes, wasting that time. Nacking is therefore preferable for a known failure, while deadline expiry is the safety net for a crashed consumer. The subtlety is that immediate redelivery on nack can produce a tight retry loop for a permanently failing message. Combining nack with an exponential retry policy and a dead letter topic is the complete configuration.

Question 22

What is an exponential backoff retry policy in Pub/Sub?

Accepted Answer

A subscription-level retry policy that spaces out redelivery attempts with increasing delay between a configured minimum and maximum backoff, rather than redelivering immediately. It prevents a failing consumer or a temporarily unavailable dependency from being hammered by retries. The pairing to describe is retry policy plus dead lettering: backoff handles transient failures gracefully, and the dead letter topic catches permanent ones after the maximum attempts. Configuring one without the other leaves a gap.

Question 23

How do you secure Pub/Sub?

Accepted Answer

Grant fine-grained IAM at the topic and subscription level — roles/pubsub.publisher on the topic to producers, roles/pubsub.subscriber on the subscription to consumers — using dedicated service accounts per workload. Use CMEK for message encryption at rest, VPC Service Controls to prevent exfiltration, and for push endpoints, an OIDC token so the endpoint can verify the caller. The push endpoint authentication is the piece most often missed: without an OIDC token and endpoint-side verification, anyone who discovers the URL can post fake events. That is a real vulnerability, not a theoretical one.

Question 24

What is message attribute filtering?

Accepted Answer

A subscription can specify a filter expression on message attributes, so it only receives messages whose attributes match. Non-matching messages are automatically acknowledged and not delivered, and — importantly — you are not charged delivery for them. It lets you use one topic for a family of events and have each consumer subscribe to the slice it cares about, instead of creating many topics or filtering in application code. The cost benefit of not paying for filtered-out deliveries is the detail that makes it more than a convenience.

Question 25

What is the maximum message size in Pub/Sub and how do you handle larger payloads?

Accepted Answer

The maximum message size is 10 MB. For larger payloads, use the claim-check pattern: write the payload to Cloud Storage and publish a message containing only the object path and metadata, so the consumer fetches the body when it needs it. The claim-check pattern also reduces cost, since Pub/Sub bills by delivered bytes and a fan-out of large messages multiplies that. Naming the pattern by name is a good signal of architectural literacy.

Question 26

How do Pub/Sub and Dataflow work together?

Accepted Answer

Dataflow reads from Pub/Sub as a streaming source, applies windowing, transformation, enrichment and aggregation, and writes to BigQuery, Cloud Storage, Bigtable or another sink. Dataflow handles the acknowledgement lifecycle, checkpointing and exactly-once processing semantics within the pipeline. The value Dataflow adds over a plain consumer is stateful streaming: windowing, watermarks for late data, and exactly-once state updates. If the requirement is just to move messages somewhere, a plain consumer or a BigQuery subscription is simpler and cheaper — knowing when Dataflow is overkill is part of the answer.

Question 27

What is the transactional outbox pattern and why does it matter with Pub/Sub?

Accepted Answer

It solves the dual-write problem: writing to your database and publishing an event are two separate operations, and either can fail after the other succeeds. The outbox pattern writes the event into an outbox table in the same database transaction as the business change, and a separate process publishes from the outbox and marks it sent. On GCP, Spanner change streams or Datastream can replace a hand-built outbox by publishing changes directly from the database log. Being able to name both the classic pattern and the managed alternative is a strong architectural signal.

Question 28

How do you test a Pub/Sub-based system locally?

Accepted Answer

Use the Pub/Sub emulator, which runs locally and implements the API so you can create topics and subscriptions and publish and consume without touching a real project. Point client libraries at it with the PUBSUB_EMULATOR_HOST environment variable. The caveat worth stating is that the emulator does not reproduce every production behaviour — ordering, exactly-once semantics, IAM and quota behaviour differ — so integration tests against a real test project are still necessary before release.

Question 29

What is fan-out and fan-in, and how does Pub/Sub support each?

Accepted Answer

Fan-out is one event reaching many consumers, achieved with multiple subscriptions on a topic. Fan-in is many producers writing into one stream, achieved by having many publishers write to the same topic. Pub/Sub handles both natively without configuration changes. The cost consequence of fan-out is worth adding: each subscription is a separate delivery and is billed separately, so a topic with twenty subscriptions costs twenty times the delivery volume. That shapes whether you fan out at the messaging layer or downstream.

Question 30

What ordering guarantee does Pub/Sub give without ordering keys?

Accepted Answer

None. Without ordering keys, messages may be delivered in any order, and this is deliberate — it is what allows the service to parallelise delivery across many servers and scale without limit. Any system that requires order must either use ordering keys or carry sequence information in the message and reorder downstream. The design advice is to prefer messages that are order-independent — carrying full state rather than deltas, or including a version so a stale update can be discarded. That is more robust than depending on ordering, and interviewers value that instinct.

Question 31

How would you migrate from Kafka to Pub/Sub?

Accepted Answer

Map topics to topics and consumer groups to subscriptions. Run both in parallel with a bridge — Kafka Connect with the Pub/Sub connector, or Dataflow — so consumers can be migrated one at a time. Replace offset-based replay logic with snapshots and seek, and add idempotency where consumers previously relied on offset management. Cut producers over last. The consumer-side semantic change is the substance: Kafka consumers own offsets and can rewind arbitrarily, while Pub/Sub tracks acknowledgements. Any consumer that depended on offset arithmetic needs redesign, and identifying that up front is what makes the migration plan credible.

Question 32

What metrics would you alert on for a Pub/Sub system?

Accepted Answer

Oldest unacknowledged message age as the primary indicator of falling behind; undelivered message count for backlog size; dead letter topic message count, which should normally be zero; push subscription error rate and latency; and publish request error rate on the producer side. Alerting on dead letter arrivals is the one that catches silent data loss — messages are being dropped from the main flow and nobody notices unless something watches that topic. Naming it unprompted is a good operational signal.

Question 33

What is the claim-check pattern and when do you use it on GCP?

Accepted Answer

Store a large payload in Cloud Storage and publish only a reference — bucket, object path, size, checksum — through Pub/Sub. Consumers fetch the payload when they need it. Use it whenever payloads approach the message size limit, when many subscribers do not need the full body, or when the payload contains data subject to separate access controls. The access-control angle is the least obvious and most valuable: the message can flow through a general topic while the sensitive payload stays behind bucket IAM, so a subscriber that should not see the contents simply cannot fetch it.

Question 34

How does Pub/Sub achieve global availability?

Accepted Answer

A topic is a global resource. Publishers connect to the nearest Google front end and messages are stored redundantly across zones in the region where they were published, with the service routing to subscribers wherever they connect. There is no region to choose unless you apply a message storage policy. The message storage policy is the compliance lever: it restricts which regions messages may be persisted in, which matters for data residency requirements. Knowing that the default is global and that residency must be explicitly configured is the practical point.

Question 35

What happens if a subscriber is offline for a week?

Accepted Answer

Messages accumulate in the subscription up to the retention duration, which defaults to seven days and can be configured up to 31 days. Once the retention period is exceeded, unacknowledged messages are deleted and lost. When the subscriber returns it receives the surviving backlog, potentially all at once. The thundering-herd risk on recovery is worth raising: a week of backlog delivered at full rate can overwhelm the consumer and its downstream dependencies. Flow control and a deliberately throttled catch-up are the mitigation.

Question 36

What is exactly-once delivery in Pub/Sub and what are its limits?

Accepted Answer

Exactly-once delivery, available for pull subscriptions within a single region, guarantees that an acknowledged message is not redelivered, eliminating duplicates from redelivery. It does not eliminate duplicates caused by a publisher publishing the same logical event twice, and it comes with somewhat lower throughput and regional restriction. The precision that matters is exactly-once *delivery* versus exactly-once *processing* — the latter also requires the consumer's side effects to be transactional. Interviewers ask this specifically to see whether you conflate the two.

Question 37

How do you handle a poison message that keeps failing?

Accepted Answer

Configure a dead letter topic with a maximum delivery attempt count so the message is moved aside automatically, alert on arrivals in that topic, and build a small process to inspect, correct and optionally republish. In the consumer, distinguish transient failures (nack and retry) from permanent ones (acknowledge and record, or route to a quarantine store). The distinction between transient and permanent failure inside the handler is the part most candidates miss — retrying a validation error forever is pointless. Deciding that in code, rather than relying only on delivery counts, is the more robust design.

Question 38

Design an event-driven order processing system on GCP using Pub/Sub.

Accepted Answer

The order service writes to its database and emits an order-created event through a transactional outbox or Spanner change stream into a Pub/Sub topic with an ordering key of the order ID. Separate subscriptions feed payment, inventory, notification and analytics consumers on Cloud Run, each idempotent and keyed on the order ID. Each subscription has an exponential backoff retry policy and a dead letter topic with alerting. A BigQuery subscription lands raw events for analytics. Cloud Tasks handles rate-limited calls to the external logistics API, and Workflows orchestrates the multi-step fulfilment saga with compensation steps. The closing scenario. The senior markers are solving the dual-write problem explicitly, one subscription per consumer rather than one shared, idempotency on a business key, dead lettering with alerts, and using Cloud Tasks rather than Pub/Sub where rate control is the requirement.

Question 39

What is the difference between choreography and orchestration in an event-driven system?

Accepted Answer

In choreography, each service reacts to events independently and emits its own — there is no central controller, which gives loose coupling but makes the overall flow hard to see and debug. In orchestration, a coordinator such as Workflows explicitly drives each step, which gives visibility, error handling and compensation at the cost of a central component. The pragmatic position to take is that choreography suits simple, genuinely independent reactions, while any multi-step business process with compensation logic — a saga — benefits from orchestration. Answering with a blanket preference in either direction is weaker than naming the criterion.

Question 40

What is Managed Service for Apache Kafka on GCP?

Accepted Answer

It is a fully managed Kafka offering that runs open-source Apache Kafka clusters with Google handling provisioning, scaling, patching and availability, while you keep the Kafka API, existing clients, Connect and Streams ecosystem. It is the path for teams that need Kafka semantics specifically rather than Pub/Sub's model. The reason to choose it over Pub/Sub is portability and ecosystem: existing Kafka applications, a multi-cloud requirement, or a dependency on Kafka Streams. The reason to choose Pub/Sub instead is that there is nothing to size and it scales without capacity planning.

GCP Pub/Sub & Messaging Interview Questions and Answers

How to use this set