PDE Ingesting and Processing the Data Practice Question
A media company ingests clickstream events into Pub/Sub and processes them with a Dataflow streaming pipeline that writes to BigQuery. The pipeline uses a fixed window of five minutes and discards late data. A product manager reports that events arriving more than five minutes after their event timestamp never appear in reports. Which change should you make to capture those events?
⚠ Common exam trap
The trap here is assuming that a larger window automatically captures late events, when lateness handling is governed by allowed lateness and triggers, not by window length.
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
✓
Configure an allowed lateness on the window and adjust the trigger to emit updated results.
Discarding late data is a consequence of the window's allowed lateness and trigger configuration, not of window duration. Setting an allowed lateness period and a trigger that emits on late arrivals lets the pipeline accept events beyond the five-minute boundary and update the affected windows, so the stragglers appear in reports.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Switch the pipeline to use the Pub/Sub message publish time as the element timestamp.
Why it's wrong here
Using publish time instead of event time would make the window boundaries reflect when Pub/Sub received the message, not when the user action occurred. Late-arriving events would still be late relative to their true occurrence, and the reports would misrepresent event timing, so this does not solve the underlying problem.
- ✗
Add a GroupByKey transform before the window to buffer all events.
Why it's wrong here
Grouping by key without a windowing and triggering strategy does not change the discard policy. The pipeline would still drop elements that arrive after the window's allowed lateness, and an unbounded group would hold state indefinitely, risking memory pressure without guaranteeing the late events are emitted.
- ✗
Increase the fixed window size to thirty minutes.
Why it's wrong here
Enlarging the window changes how events are grouped but does not change the fact that the pipeline is configured to discard data arriving after the window closes. Late events would still be dropped once the watermark passes, so widening the window only delays the drop rather than capturing the stragglers.
- ✓
Configure an allowed lateness on the window and adjust the trigger to emit updated results.
Why this is correct
Allowed lateness extends how long a window accepts elements after its end, and a trigger that fires on late data emits revised results for those windows. Together they let events arriving beyond five minutes be incorporated into the aggregation instead of being discarded, which directly addresses the missing late arrivals.
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.