Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

A logistics company needs to send millions of shipment status updates per day from IoT tracking devices to backend systems for processing and storage. The solution must decouple the tracking devices from the backend and handle traffic spikes without losing messages. Which Google Cloud product best fits this asynchronous messaging requirement?

⚠ Common exam trap

The GCDL exam often tests the distinction between decoupling (asynchronous messaging) and load distribution (synchronous traffic management), so the trap here is confusing Cloud Load Balancing's ability to distribute requests with Pub/Sub's ability to buffer and decouple, leading candidates to pick D when they see 'traffic spikes' and 'distribute' in the question.

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

✓

Cloud Pub/Sub, Google's fully managed messaging service that decouples producers from consumers and handles massive message volumes reliably

Cloud Pub/Sub is the correct choice because it is a fully managed, asynchronous messaging service designed to decouple producers (IoT devices) from consumers (backend systems). It can handle millions of messages per second, provides at-least-once delivery, and buffers messages during traffic spikes, ensuring no data loss without requiring the backend to be always available.

Answer analysis

Option-by-option breakdown

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

✗
Cloud SQL, to store each tracking update as a row in a relational database as it arrives
Why it's wrong here
Cloud SQL is a transactional database, not a messaging service. It doesn't decouple producers from consumers or provide message buffering during traffic spikes. Writing millions of rows directly from IoT devices would create a tight coupling and potential bottleneck.
✓
Cloud Pub/Sub, Google's fully managed messaging service that decouples producers from consumers and handles massive message volumes reliably
Why this is correct
Pub/Sub is purpose-built for this pattern. IoT devices publish messages to a Pub/Sub topic; backend systems subscribe and process at their own rate. Pub/Sub buffers messages during spikes, guarantees at-least-once delivery, and scales to millions of messages per second without configuration changes.
✗
Cloud Storage, to have each device upload a file containing its status update
Why it's wrong here
Cloud Storage is an object store designed for durable, scalable file and binary storage, not for fine-grained event ingestion. Requiring each device to upload a distinct file forces backend subscribers to poll buckets or rely on object-finalize notifications, adding latency and coupling, and the granularity of files is a poor fit for millions of discrete tracking updates. It also lacks Pub/Sub's push/pull subscription model and per-message at-least-once delivery guarantee, so it cannot reliably buffer and stream a high-velocity telemetry feed to downstream processors.
✗
Cloud Load Balancing, to distribute incoming tracking requests evenly across backend servers
Why it's wrong here
Cloud Load Balancing distributes synchronous HTTP(S) requests across healthy backend instances at the network/application layer, but it provides no durable queue or decoupling between producers and consumers. When a traffic burst exceeds backend capacity, load balancers do not buffer messages; they apply configured balancing policies and can return 5xx errors, leading to data loss from the IoT perspective. It does not support topic-based fan-out or subscriber-managed checkpointing, so it cannot serve as the ingestion backbone for an event streaming architecture.

Visual reference

Go deeper

Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

Why each option matters

Option-by-option breakdown

Related to this question