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.

• ✗

  Cloud Dataproc

  Why it's wrong here

  Cloud Dataproc is a managed Apache Hadoop/Spark service designed primarily for batch jobs over bounded datasets. Although Spark Structured Streaming can consume from Pub/Sub and write to BigQuery, Dataproc requires you to provision, manage, and size clusters manually, and its autoscaling lags behind the millisecond-level elasticity of a serverless stream processor. For a continuous clickstream pipeline with unpredictable spikes, the operational overhead and cold-start delays make it less streamlined for real-time BigQuery ingestion than Dataflow.

• ✓

  Cloud Dataflow

  Why this is correct

  Cloud Dataflow is the correct choice because it is a fully managed, serverless service for both stream and batch processing, built on the Apache Beam model. It provides native, optimized BigQuery I/O with exactly-once processing semantics, event-time windowing, and automatic scaling to handle unbounded clickstream data from Pub/Sub. Dataflow's built-in support for watermarks, triggers, and stateful transformations makes it ideal for running low-latency, continuous ETL pipelines that land directly in BigQuery.

• ✗

  Cloud Pub/Sub

  Why it's wrong here

  Cloud Pub/Sub is an asynchronous messaging service that ingests and delivers event streams, but it does not perform data transformation, aggregation, or enrichment. It acts merely as the ingestion layer in a streaming pipeline: producers publish click events to topics, and consumers subscribe to receive them. Without a separate processing engine like Dataflow, Pub/Sub cannot window, join, or clean the data, nor write directly to BigQuery in a transformed format, so it is not sufficient by itself for this use case.

• ✗

  Cloud Functions

  Why it's wrong here

  Cloud Functions is designed for short-running, event-driven code triggered by discrete events, with execution timeouts (currently up to 540 seconds) and no built-in support for stateful stream processing or backpressure. It would require you to run separate invocations for each message or micro-batch, making it impractical for high-throughput clickstream transformations that need sliding windows, joins, and exactly-once writes to BigQuery. For sustained streaming workloads, Dataflow's auto-scaling pipeline model is far more appropriate than the haphazard composition of serverless functions.

Go deeper

Related to this question