PDE Designing Data Processing Systems Practice Question
A data engineer needs to design a streaming pipeline that ingests events from multiple sources, enriches them with a lookup table stored in BigQuery (updated every hour), and writes the results to a BigQuery table for real-time dashboards. The pipeline must handle late-arriving data up to 1 hour. Which Dataflow feature should be configured to manage late data?
⚠ Common exam trap
PDE often tests the confusion between watermark estimation (which controls when the pipeline thinks data is complete) and allowed lateness (which controls how long late data is actually accepted), causing candidates to pick the watermark option.
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
✓
Allowed lateness on the window
Allowed lateness on the window is the Dataflow feature that explicitly defines how long the pipeline will retain window state and accept late-arriving elements after the watermark has passed the end of the window. Setting allowed lateness to 1 hour lets Dataflow keep the window's state for that duration, so events arriving up to 60 minutes late are still processed and emitted with correct results. This directly satisfies the requirement to handle late data up to 1 hour without dropping or misassigning events.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A custom watermark estimation function
Why it's wrong here
A custom watermark estimation function alters when the watermark advances, but it does not by itself retain state for elements arriving after the watermark passes; allowed lateness governs that. Custom watermarking suits sources with irregular event-time skew where the default heuristic misestimates progress.
- ✗
Using side inputs with a periodic refresh
Why it's wrong here
Side inputs with periodic refresh address enrichment against the hourly BigQuery lookup table, not late-arriving event handling; they do not extend window state retention. Side inputs are correct when a pipeline must join a slowly changing reference dataset that is too large to broadcast once.
- ✗
A trigger that fires on every late element
Why it's wrong here
A trigger firing on every late element controls when panes are emitted, but without allowed lateness configured the late elements are discarded before any trigger runs. Per-element triggers suit low-latency speculative output where each arrival should surface immediately.
- ✓
Allowed lateness on the window
Why this is correct
Setting allowed lateness on the window lets Dataflow retain window state and emit updated results for up to one hour after the watermark passes, directly satisfying the stem's late-arriving data constraint. Unlike discarding mode, it triggers late firings so enriched events still reach the BigQuery dashboard table.
Go deeper
Related to this question
About these practice questions
One of 747 original PDE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.