Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Dataproc

  Why it's wrong here

  Dataproc is a managed Spark and Hadoop service designed for batch-oriented data processing, ETL, and analytics on large datasets. While it can read from Pub/Sub via Spark Streaming, it requires you to manage a cluster lifecycle, and its latency and operational overhead make it a poor fit for a continuously running, low-latency event ingestion path. For raw event ingestion, you need a fully managed, push-based message broker that can hold messages until subscribers are ready, not a batch compute engine.

• ✓

  Pub/Sub

  Why this is correct

  Pub/Sub is the correct foundational service for ingesting streaming events because it is a scalable, durable, asynchronous messaging middleware that decouples event producers from consumers. It provides at-least-once delivery, supports push and pull subscriptions, and can buffer spikes in event volume, ensuring that events are not lost before downstream processing. As the entry point of a data pipeline, Pub/Sub is specifically designed to receive high-throughput event streams and make them available to streaming processors like Dataflow.

• ✓

  Dataflow

  Why this is correct

  Dataflow is a fully managed, serverless stream and batch processing service that can consume events from Pub/Sub in near real time. It is the correct complement to Pub/Sub for transforming, enriching, and windowing the ingested events before they land in a destination like BigQuery. Dataflow provides exactly-once processing semantics and autoscaling, making it the standard choice for the 'process' stage of a streaming pipeline rather than the 'ingest' stage.

• ✗

  Cloud Functions

  Why it's wrong here

  Cloud Functions is a serverless, event-driven compute service that runs short-lived, single-purpose functions and is not designed for continuous, long-running stream processing. It is triggered by discrete events (e.g., a Pub/Sub message, a Cloud Storage upload) and has a maximum timeout (typically 540 seconds), making it unsuitable for high-throughput, stateful, or streaming analytics. While it can respond to individual messages, it lacks the ability to maintain state across messages or handle backpressure for sustained streams, so it is the wrong tool for processing a continuous event pipeline.

• ✓

  BigQuery

  Why this is correct

  BigQuery is a fully managed, serverless data warehouse that serves as the destination for processed streaming data, not as an ingestion or processing layer. It supports real-time analytics via the Storage Write API and can query data as soon as it is written, but it is not built to buffer or route events between producers and consumers. In a streaming pipeline, BigQuery is where the processed data lands for analysis, while Pub/Sub handles ingestion and Dataflow handles transformation.

Go deeper

Related to this question