Sample questions
St Flink Time Watermarks WindowsDifficulty 1
In the Flink DataStream API, what does the single duration argument in TumblingEventTimeWindows.of(Time.seconds(10)) specify?
- aThe interval at which watermarks are generated for the stream
- bThe fixed length of each window✓
- cThe duration for which late events are still accepted after the window closes
- dThe offset used to shift window boundaries away from the epoch
Explanation:A tumbling window assigner takes a single size argument that defines how long each window is; tumbling windows have no separate slide because slide equals size. Watermark generation interval is a separate execution config, allowed lateness is set with a different method, and boundary offset is a distinct optional parameter — none of them is what this single argument controls.
St Flink Time Watermarks WindowsDifficulty 2
With SlidingEventTimeWindows.of(Time.minutes(1), Time.seconds(15)), how many overlapping windows does a single event get assigned to?
- a4 — the window size (60s) divided by the slide (15s)✓
- b1, because each event only ever belongs to exactly one sliding window
- c15, mistaking the slide value itself for the overlap count
- d60, mistaking the window size value itself for the overlap count
Explanation:Sliding windows overlap: an event falls into every window whose range covers its timestamp, and that count equals size/slide (60000ms/15000ms = 4). Treating sliding windows as if they behaved like tumbling windows (one window per event) ignores the overlap, and reading the slide or size value directly as the answer confuses the parameters with the derived count.
St Flink Time Watermarks WindowsDifficulty 1
With EventTimeSessionWindows.withGap(Time.minutes(5)), under what condition does a session window for a given key become eligible to close?
- aExactly 5 minutes after the window opened, regardless of any further events for that key
- bOnce the whole stream, across every key in it, has been sitting idle for 5 minutes
- cOnce exactly 5 events in a row have accumulated for that specific key
- dWhen the watermark reaches the key's
maxTimestamp (latest event + 5min − 1ms)✓
Explanation:Session windows are gap-based and per-key. Each event extends the session end to its timestamp plus the configured gap; since windows are half-open ([start, end)), the window's maxTimestamp() is that end minus 1 ms, and the event-time trigger fires when the watermark reaches that maxTimestamp. Flink need not observe a later event merely to prove that the gap elapsed. This is neither a fixed duration from the first event, global stream idleness, nor an event-count rule.
St Flink Time Watermarks WindowsDifficulty 2
If you window a stream with GlobalWindows.create() and do NOT attach a custom Trigger, what happens?
- aFlink silently falls back to a fixed 1-minute tumbling window behavior instead
- bEvery single incoming event fires the window and emits a result immediately
- cThe window never emits a result, since the default trigger never returns FIRE✓
- dThe job fails to even start, rejected with a compile-time error
Explanation:GlobalWindows assigns every element to one single, never-ending window and relies entirely on an explicit Trigger to decide when to fire; without one, the built-in default trigger simply never fires, so nothing is ever emitted. There is no automatic fallback to a different window type, no per-event firing, and this is a runtime behavior, not something the compiler can catch.
St Flink Time Watermarks WindowsDifficulty 1
For which kind of source is WatermarkStrategy.forMonotonousTimestamps() an appropriate choice?
- aA stream whose timestamps are already non-decreasing at the source✓
- bA stream where events regularly arrive several seconds out of order relative to each other
- cA stream that carries no timestamp at all and relies purely on processing-time instead
- dA stream fed by several partitions with no ordering guarantee across any of them
Explanation:The monotonous strategy emits the watermark as the current maximum timestamp itself, i.e. it assumes zero out-of-orderness; if timestamps genuinely arrive out of order, this strategy immediately advances the watermark past every new maximum, so smaller-timestamped events that arrive after a larger timestamp end up behind the watermark and get treated as late even though they are otherwise valid. Sources with real disorder or no ordering guarantee across partitions call for a bounded-out-of-orderness strategy instead, and a source without any timestamp doesn't need a timestamp-based watermark strategy at all.
St Flink Time Watermarks WindowsDifficulty 2
WatermarkStrategy
.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((e, ts) -> e.eventTime);
How does this definition affect watermark generation?
- aEvery event older than 5 seconds is filtered out at the source
- bThe watermark trails the largest event-time seen so far by about 5 seconds✓
- cThe checkpoint interval is now fixed and pinned to exactly 5 seconds
- dA watermark is emitted exactly 5 seconds after each individual event arrives
Explanation:The bound is a delay subtracted from the running maximum timestamp, so the watermark trails the highest timestamp seen by roughly that amount; it does not drop any data, it has nothing to do with checkpointing, and it is not a per-event fixed delay — it depends on the periodic watermark emission interval, not a fixed 5 seconds after each record.