Study Confluent CCDAK Poll Loops and Offset Reset: key concepts, common traps, and exam decision cues.
On this page
This lesson matters because offset management is where Kafka application correctness becomes visible. The exam expects you to understand whether processing happened before progress was recorded, and what that means during failure.
Offset-control chooser
Requirement
Strongest first fit
easier setup with less control
auto commit
process then record progress
manual commit after successful handling
replay old data for a new group
auto.offset.reset=earliest when appropriate
start only from new data
auto.offset.reset=latest when appropriate
What the exam is really testing
If the scenario shows…
Strong reading
duplicate replay after failure
commit timing is under test
missing records after a crash
commit happened too early or the reset path is wrong
new group startup behavior
offset reset policy matters
desire for stronger control
auto commit may be too weak
Common traps
Trap
Better rule
assuming offset commits and processing are the same event
they are separate steps with semantic consequences
treating auto.offset.reset like a recovery tool for any case
it mainly affects where a consumer starts when there is no prior committed position
using auto commit without accepting its weaker control
convenience changes behavior
Decision order that usually wins
Start by separating processing from progress recording: commits describe position, not successful business handling by themselves.
If the stem is about replay after failure, inspect commit timing first.
If the stem is about how a new group begins reading, inspect auto.offset.reset.
If the application needs tighter correctness control, prefer explicit commit discipline over convenience-first auto commit.