Medium1 markMultiple Choice
Domain 5: Managing Implementation and Ensuring ReliabilityDomain 5Cost OptimizationCloud Pub/SubIoT Edge
This question is part of a case study — click to read the full scenario(Case 16)

CASE STUDY: AutoMakers Inc

Company Overview:
AutoMakers Inc is a global vehicle manufacturer. They have recently launched a line of connected cars.

Current Technical Environment:

  • 1 million connected cars currently on the road
  • Cars send telemetry data (speed, engine temp, location) every 5 seconds
  • Current on-premises MQTT brokers are crashing under the load

Business Requirements:

  • Enable predictive maintenance to alert drivers before parts fail
  • Provide real-time fleet tracking for commercial customers
  • Support over-the-air (OTA) software updates

Executive Statements:

  • CEO: "Data is our new revenue stream. We need to monetize this telemetry data."
  • CTO: "We expect to have 10 million connected cars in 3 years. The architecture must scale infinitely without manual intervention."
  • CFO: "The cost of ingesting and storing this data must be strictly controlled. We cannot pay for idle capacity."

Technical Requirements:

  • Ingest up to 100,000 messages per second
  • Low-latency processing for real-time alerts
  • Time-series data storage for historical analysis
  • Handle variable network connectivity (cars driving through tunnels)

Constraints:

  • Strict budget for data ingestion
  • Small data engineering team

QUESTION:
To meet the CTO's requirement for infinite scaling and the technical requirement to ingest 100,000 messages per second, which ingestion and processing pipeline should you design?

GCP PCA · Question 18 · Domain 5: Managing Implementation and Ensuring Reliability

CASE STUDY: AutoMakers Inc

Company Overview:
AutoMakers Inc is a global vehicle manufacturer. They have recently launched a line of connected cars.

Current Technical Environment:

  • 1 million connected cars currently on the road
  • Cars send telemetry data (speed, engine temp, location) every 5 seconds
  • Current on-premises MQTT brokers are crashing under the load

Business Requirements:

  • Enable predictive maintenance to alert drivers before parts fail
  • Provide real-time fleet tracking for commercial customers
  • Support over-the-air (OTA) software updates

Executive Statements:

  • CEO: "Data is our new revenue stream. We need to monetize this telemetry data."
  • CTO: "We expect to have 10 million connected cars in 3 years. The architecture must scale infinitely without manual intervention."
  • CFO: "The cost of ingesting and storing this data must be strictly controlled. We cannot pay for idle capacity."

Technical Requirements:

  • Ingest up to 100,000 messages per second
  • Low-latency processing for real-time alerts
  • Time-series data storage for historical analysis
  • Handle variable network connectivity (cars driving through tunnels)

Constraints:

  • Strict budget for data ingestion
  • Small data engineering team

QUESTION:
To address the CFO's concern about the cost of ingesting millions of messages, how should you optimize the data transmission from the cars to Cloud Pub/Sub?

Answer options:

A.

Compress the messages using gzip before sending them to Pub/Sub.

B.

Batch the telemetry data on the car's edge device and send it to Pub/Sub every 30 seconds instead of every 5 seconds.

C.

Switch from Cloud Pub/Sub to Cloud Storage for direct ingestion.

D.

Use Preemptible VMs to run the Pub/Sub service.

How to approach this question

Understand Pub/Sub pricing. It is billed by data volume, but with a minimum of 1KB per request. Sending tiny payloads frequently wastes money. Batching at the edge is the solution.

Full Answer

B.Batch the telemetry data on the car's edge device and send it to Pub/Sub every 30 seconds instead of every 5 seconds.✓ Correct
Cost optimization in IoT architectures often happens at the edge. Because Cloud Pub/Sub has a minimum billable message size (1KB), sending tiny telemetry payloads every 5 seconds is highly inefficient. By batching the data on the car and sending a larger payload less frequently, you drastically reduce the number of Pub/Sub publish requests, saving significant costs while still meeting the near-real-time requirements.

Common mistakes

Choosing compression (A). Compression is good, but if the message is already under 1KB, compressing it further doesn't save any money in Pub/Sub.

Practice the full GCP Professional Cloud Architect Practice Exam 3

50 questions · hints · full answers · grading

More questions from this exam