87 claims across the knowledge base

Unverified claims

Every statement in the modules that I could not confirm against the Kafka 4.3 documentation or the lab cluster. Each one is also marked in red where it appears. Check these before you rely on them.

What "verified" means here. A config default counts as verified when I read it from the Kafka 4.3 reference pages or from the running lab cluster. A behaviour counts as verified when a lab command showed it. Everything else that is specific to a version is in this list.

Module	Claim	Why it is not verified
02	The broker remembers the last five batches from each producer id for each partition.	From memory of the idempotence design. The lab showed sequence numbers in the log but did not test the limit of five.
02	linger.ms was 0 before Kafka 4.0.	The 4.3 reference confirms the current default of 5. The older value is from memory.
03	group.initial.rebalance.delay.ms defaults to 3000.	The lab cluster sets it to 0, so the default could not be read from it.
04	How eligible leader replicas work, beyond the two effects the labs showed.	The labs showed the Elr column and the stalled high watermark. The rules are described from memory.
05	Before a first start, a data directory is prepared with kafka-storage.sh format.	The Docker image does this itself. I did not run the tool.
05	controller.quorum.bootstrap.servers allows adding and removing controllers without a full restart.	The setting exists on the lab broker and is empty. Its behaviour was not tested.
05	controller.quorum.auto.join.enable applies only to the newer, changeable quorum.	The setting exists with the default false. Its behaviour was not tested.
05	With no controller majority, brokers keep serving the partitions they already lead.	The lab showed that metadata commands hang. It did not test produce and consume in that state.
05	How a controller with a lost disk is replaced, and the role of the directory id.	Not tested.
05	The upgrade order, and that lowering metadata.version afterwards is limited.	From memory. Read the upgrade notes for your target version.
06	Aborted transactions are filtered with a transaction index file for each segment.	The filtering was observed. The file was not inspected.
06	Why the producer epoch rises at the end of every transaction in Kafka 4.	The lab showed the numbers (3 after three transactions, 5 after two more). The reason is from memory.
06	What transaction.two.phase.commit.enable is for.	The setting exists with the default false. Not tested.
06	processing.guarantee defaults to at_least_once in Kafka Streams.	The reference page I read listed the allowed values but not clearly the default.
07	With exactly_once_v2 the commit interval defaults to 100 milliseconds.	From memory.
07	The status of group.protocol=streams.	The lab broker accepts the streams protocol. I did not run an application with it.
08	auto.register.schemas defaults to true in the schema registry serializers.	From memory. The lab used the registry through its HTTP interface, not through a serializer.
09	Size the page cache to hold the last 30 seconds to a few minutes of writes.	A rule of thumb, not a measured value.
10	The release in which share groups became production-ready.	The lab cluster has them turned on (share.version level 1) and the lab used them. The release history was not checked.
10	The default values in the MirrorMaker 2 config table.	The lab values are verified to work. The defaults column is from memory.
10	Setting the copying consumer to read_committed stops aborted records from being mirrored.	The lab showed the problem with the default setting. I did not rerun it with the fix.
11	How SCRAM, token and certificate authentication work.	The lab ran SASL PLAIN only.
11	ssl.endpoint.identification.algorithm defaults to https.	From memory.
11	Why a read-only user gets a cluster authorization error when it tries to write.	The error is from the lab. The explanation, the idempotent producer asking for a producer id, is from memory.
11	Brokers can load a new keystore without a restart.	Certificate rotation was not run.
12	A request-time metric exists for FetchConsumer as for Produce.	Only the Produce metric was read.
12	Why the exporter could not read consumer groups from Kafka 4.3.	The failure was observed. I did not find the exact cause.
12	Request time splits into queue, local, follower-wait and send parts.	The lab read only the total time.
13	What the "before" part of a change record holds when REPLICA IDENTITY is not FULL.	Never tested.
13	Where the event type travels in an outbox message.	The consumer output shown did not include it.
13	Decimals arrive as base64 because of the default decimal handling, and a setting fixes it.	From memory; not tested.
13	Why the replication slot looked stuck after a resume, and why the idle outbox slot kept the log.	Offsets confirmed on a flush interval and an idle table: from memory.
13	Settings that exist but were not tested: snapshot.mode, heartbeat.interval.ms, max.queue.size, publication.autocreate.mode, slot.drop.on.stop, decimal.handling.mode, tombstones.on.delete, offset.flush.interval.ms.	Named only; no defaults claimed.
13	Duplicates after a connector restart; behaviour on a table schema change; a large initial snapshot; ordering with a changed key.	Not forced in the lab.
14	What the __remote_log_metadata topic contains.	The topic was seen, not read.
14	Real object-store backends and which backends the plug-in release supports.	Only the filesystem backend was run.
14	The meaning of chunk.size, overwrite.enabled, task.interval.ms and the metadata listener setting.	Taken from the setting names.
14	The plug-in works across other Kafka and plug-in versions; its support terms.	One pair was tested.
14	A quiet topic never tiers, and a lower segment.ms is the fix.	Reasoned from the facts; not run.
14	Behaviour when remote storage is down.	Not tested.
14	A cold read is slower than a local read and costs requests.	No timing was taken.
14	Replica rebuild and rebalancing get shorter with tiering; recent data still needs replication.	One broker only.
14	Production values for local retention.	None tested.
drills	Drills 1 and 6: docker kill timings, and the 45-second session timeout wait.	The modules show only clean stops.
drills	Drill 7: a consumer that crashes on a poison record, and --shift-by 1.	No lab has consumer code; only --shift-by -100 was run.
drills	Drill 10: registering the corrected schema.	Not run in module 08.
drills	Drill 11: a run of a minute or more shows the quota.	Module 09 only advises it.
drills	Drill 12: the real repair (new topic, copy, switch).	No module runs it.
drills	Drill 13: filling a disk, and --delete-config retention.ms.	Neither is shown in the modules.
drills	Drill 14: stopping MirrorMaker mid-drill to measure loss; the read_committed fix.	Module 10 marks the fix unverified and names no property.
drills	Drill 15: an ACL for group snoop.	Reuses bob's command form with another principal.
reading guide	KIP-890: the first version that shipped it.	The sources disagree (3.7.0, 4.1.0, and a phase 2 note in 4.0).
reading guide	KIP-345 version 2.4.0.	From a Jira ticket whose title does not name the KIP.
reading guide	KIP-500 version label 2.8.0, and the KIP-595 version.	Jira fix versions only; KIP-595's ticket has none.
reading guide	KIP-966: the release in which it became the default.	Preview in 4.0 is confirmed; the default release is not.
reading guide	KIP-405 and KIP-932 "Rejected Alternatives" sections.	Not seen among the headings read.
reading guide	Section names for KIP-848, KIP-429 and KIP-833.	The fetches did not return headings.
reading guide	A separate KIP for removing ZooKeeper.	None found; KIP-833 names 4.0 and the upgrade guide overrules it.
reading guide	The date of Kreps's article, 16 December 2013.	From a search summary; the page fetch failed.
reading guide	Edition years of the two books, and the Kafka docs "Design" subsections.	Not confirmed.
capstone	psql through docker exec pg, in the capstone steps.	No earlier module uses it by that exact form.
capstone	The registry does not check records written with the lab's JSON converters.	Inference from the configuration.
capstone	Stopping two brokers then makes an acks=all send fail, with the exact error.	Based on module 04; the error text was not re-checked.
capstone	Naming operators in your own Streams code keeps internal topic names stable.	Module 07 says to name them; no API shown.
capstone	Starting the cdc and monitoring profiles together.	Not run.
interview	Answer q05d: moving combined-mode controllers to dedicated ones one voter at a time.	The module itself says this migration was not run.
case studies	Recipe 1: step sizes, the time and docker stats commands, and laptop capacity for thousands of partitions.	Not in any module; not run.
case studies	Recipe 2: rack labels in the lab compose file, and any delay-injection tool.	Not run; no tool named.
case studies	Recipe 3: a before and after comparison of controller load.	Commands are from module 05; the comparison was never run.
case studies	Recipe 4: docker kill, a one-second polling loop, and its timestamps.	Module 04 uses only docker stop.
case studies	Recipe 5: cold-read pressure, and that a Docker VM cache differs from the host.	Advice only; not run.
case studies	Recipes 6 and 7: a quota run of a minute or more; wait times and broker order for an upgrade; a version upgrade itself.	Not run.
case studies	Case 8: whether a later change closed KAFKA-3861.	The page cannot tell; the ticket was open when fetched.
projects	docker stats --no-stream; timing a loop with date +%s; du on __cluster_metadata-0.	No module shows them.
projects	A poison-record crash in project C.	No lab has a consumer with code.
projects	Project D: output for a partition with no committed offset; adding a Prometheus scrape target and reaching a laptop process.	Not shown in any module.
projects	Project E: a consumer on kafka-dr with a group copied from main; failback; the MirrorMaker 2 read_committed property.	Not run; module 10 marks the property unverified.
interview	x02: skipping a record with a positive --shift-by.	Drill 7 says the step was not run.
interview	x04: upgrade order and downgrade limits.	Module 05 says they are from memory.
interview	x10: behaviour when a whole zone is lost.	Only a single-broker failover was measured.
interview	x11: the leader epoch rising under load.	Not tested.
interview	x12: a 100 MB/s rebuild rate, and that tiering copies only the local part.	The rate is an assumption; no replica was rebuilt.
interview	x13: failover timing for a kill.	Drill 1 says a kill was not run.
interview	x15: the failover step and the read_committed fix.	Neither was run or rerun.
interview	x16 and x17: cold reads slower and billed per request; behaviour when remote storage is down.	No timing taken; not tested.
interview	x18: a 50 MB/s restore rate.	Module 07's example rate, not measured.
interview	x22 and x23: a quota run of a minute or more; any Kafka backup tool.	Not run; not tested.

Also worth knowing

Five items that were on this list are now verified by labs: broker metric names (module 12), security (module 11), Debezium behaviour and a stopped connector (module 13), and tiered storage (module 14).
The case studies are public write-ups read from the outside. Three candidate cases (a "Kafka 4.0 on Kubernetes" postmortem, a "$2.3M fintech" story, and Uber's multi-region disaster recovery blog) were dropped because they could not be confirmed. The question and recipe items above are advice, not measurements.
Lab outputs are from one run on one laptop, on 4 and 5 October 2026, with image apache/kafka:4.3.1. Throughput and timing numbers will differ on your machine.
The Java code sample in module 07 was not compiled. The lab ran the original example from the Kafka image.
The last step of module 07's lab, the application reset, was not run after the wait it needs.
Explanations of long-standing designs, such as the page cache, the in-sync set and Raft voting, are from general knowledge. They are not marked one by one.