Google PCA Practice Question: Analyze and optimize technical and business processes

Which THREE steps can reduce processing costs in a Dataflow streaming pipeline? (Choose three.)

⚠ Common exam trap

Google Cloud often tests the misconception that scaling out (increasing workers) always reduces costs, when in fact it increases costs unless the pipeline is bottlenecked; the trap is to confuse throughput optimization with cost reduction.

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

✓

Use side inputs instead of a cross join.

Option A is correct because replacing a cross join with side inputs avoids the expensive fan-out of every element being paired with every element of the other collection, which drastically reduces the number of elements processed and shuffled in the streaming pipeline. Option B is correct because running non-critical data through a batch pipeline lets Dataflow use cheaper batch pricing and more efficient batch-optimized execution rather than paying for continuously running streaming workers. Option C is correct because GroupByKey in streaming mode forces a shuffle and holds state for each key until the window fires, so minimizing it (for example by using Combine or pre-aggregation) lowers shuffle volume, state storage, and processing cost. Option D is not correct because a custom runner does not reduce Dataflow processing costs and is not a cost-optimization step. Option E is not correct because increasing the number of workers raises the amount of compute used and therefore increases, rather than reduces, processing costs.

Answer analysis

Option-by-option breakdown

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

✓
Use side inputs instead of a cross join.
Why this is correct
Side inputs broadcast a small lookup dataset to each worker, letting the pipeline enrich events locally instead of performing a cross join. A cross join forces every element to pair with every other, exploding shuffle volume; replacing it with side inputs removes that multiplication, cutting processing cost.
✓
Use a batch pipeline for non-critical data.
Why this is correct
Batch pipelines bill per vCPU-hour without the streaming engine's continuous resource reservation, so non-critical data processed in batches costs less. Routing only delay-tolerant data to batch preserves streaming for time-sensitive events while reducing overall processing spend, satisfying the cost-reduction requirement.
✓
Minimize the use of GroupByKey in streaming mode.
Why this is correct
GroupByKey forces a shuffle that buffers all values for a key, so streaming pipelines hold data in persistent disks and trigger repeated triggering overhead. Avoiding it in favour of combiners or windowed aggregations reduces the shuffle volume and worker time that Dataflow bills for.
✗
Use a custom runner.
Why it's wrong here
A custom runner changes where and how pipeline code executes, not the volume of worker compute consumed, so it does not reduce processing charges. It tempts because custom runners can cut costs for non-Dataflow workloads, but Dataflow billing is driven by worker vCPU and memory hours.
✗
Increase the number of workers.
Why it's wrong here
Adding workers increases the total vCPU and memory hours billed, raising processing cost rather than reducing it. It tempts because more workers shorten wall-clock runtime, but Dataflow charges for aggregate resource consumption, so throughput gains do not offset the extra capacity.

Go deeper

Google PCA Practice Question: Analyze and optimize technical and business processes

Why each option matters

Option-by-option breakdown

Related to this question