State, checkpoints & exactly-once — surviving a TaskManager crash

7 h
requires FLK-05

From your world. SOX accuracy & completeness: a ledger with no dropped and no double-posted entries, even across a crash

Practice quiz with instant feedback. For a scored run that counts toward your local progress, use uv run de quiz FLK-06.

1A TaskManager gets SIGKILL in the middle of a run. Which combination makes the final committed output contain every input exactly once? AA replayable source + checkpointed state + a sink that commits on checkpoint BA non-replayable source + checkpointing CCheckpointing disabled + an idempotent sink DA print sink + a high parallelism

2What is a checkpoint barrier? AA lock that stops all processing while state is saved BA marker that Flink injects into the streams and that flows with the records. An operator snapshots its state when it has received the barrier on all inputs CA network buffer limit DA savepoint taken by the user

3Flink recovers from the last completed checkpoint. What happens to the sources? AThey start from the very beginning of the stream BFlink rewinds them to the offsets recorded in that checkpoint, so processing resumes at the consistent cut CThey move ahead to the latest offset DThey are unaffected; only state is restored

4How does a commit-on-checkpoint (transactional/2PC) sink avoid duplicates after a crash? AIt deduplicates by scanning previous output BIt makes data visible only when Flink confirms that the checkpoint that produced it is complete. On restart, Flink rolls back the output since the last complete checkpoint CIt writes every record twice and keeps one DIt disables retries

6Why must a source be 'replayable' for exactly-once? ATo increase throughput BSo on restart it can rewind to the offset recorded in the checkpoint. A source that cannot rewind would lose records or send the wrong records again CBecause sinks require it DReplayability is only needed in batch mode

7A crash happens in the middle of a run. Which 'ledger invariants' must hold over the committed sink output? (choose all) (select all that apply) AEvery source id appears at least once (no loss) BNo source id appears more than once (no duplication) CThe committed record count equals the number of source records (balanced) DThe job finished within a fixed wall-clock time

8What happens to keyed state (for example a running balance for each account) during a checkpoint? AFlink discards it and rebuilds it from scratch BFlink includes it in the snapshot, so it is restored on recovery. The balance stays correct across the crash CFlink keeps it only if parallelism is 1 DFlink stores it only in the JobManager heap