PDE Maintaining and Automating Data Workloads Practice Question
Your Dataflow streaming pipeline writes to BigQuery and occasionally fails with `QuotaExceededError` on streaming inserts during peak hours. You want to reduce insert-driven quota pressure without changing the pipeline's output schema or losing exactly-once semantics. Which change should you make?
⚠ Common exam trap
The trap here is assuming that scaling Dataflow workers or batching requests raises the BigQuery insert quota, when the quota is enforced server-side and only a different ingestion API changes which limit applies.
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
✓
Switch the pipeline from the BigQueryIO streaming insert method to the Storage Write API with exactly-once semantics.
Legacy BigQuery streaming inserts draw on a quota pool that is easy to saturate at peak throughput. The Storage Write API is a separate ingestion path with higher and separately metered limits, and its exactly-once mode uses write streams with offsets so retries do not duplicate rows. Switching the sink preserves the output schema while relieving the quota bottleneck.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a `GroupByKey` before the BigQuery sink to batch records into larger write requests.
Why it's wrong here
Batching reduces request count but each streaming insert request still consumes quota units proportional to rows, and grouping introduces unbounded keyed state that risks data loss or delays. It also does not change the underlying quota pool, so the `QuotaExceededError` during peak hours is not fundamentally eliminated.
- ✓
Switch the pipeline from the BigQueryIO streaming insert method to the Storage Write API with exactly-once semantics.
Why this is correct
The Storage Write API uses a different quota pool than legacy streaming inserts and supports exactly-once delivery when configured with the appropriate commit strategy. Migrating the sink reduces pressure on streaming insert quotas while preserving the schema and the exactly-once guarantee the pipeline relies on, directly addressing the peak-hour failures.
- ✗
Increase the number of Dataflow workers and set `--maxNumWorkers` higher so inserts are spread across more threads.
Why it's wrong here
Adding workers increases parallelism but does not raise the BigQuery streaming insert quota, which is enforced per project and per table. More concurrent writers can actually hit the quota faster. This change consumes more compute without resolving the root cause, and the peak-hour `QuotaExceededError` would persist.
- ✗
Enable `--enableStreamingEngine` and raise the pipeline's `--diskSizeGb` to buffer failed inserts locally.
Why it's wrong here
Streaming Engine changes how Dataflow executes the pipeline but does not alter BigQuery insert quotas, and larger disks only affect shuffle and state storage. Buffering failed inserts locally does not make the rejected API calls succeed; they will still be throttled once retried, so the quota error remains unresolved.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PDE question from scratch — 747 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This PDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PDE exam.