CCAAK common mistakes
CCAAK · Understand the traps and how to avoid them.
Writing broker settings such as log.dirs, broker.id/node.id, and listeners into server.properties but leaving controller.quorum.voters (or the older zookeeper.connect) pointing at stale or placeholder endpoints, so the broker starts and immediately exits with a quorum or connection error.
Candidates memorize the KRaft and ZooKeeper property names separately and treat the quorum/connection line as boilerplate, copying a sample config without updating it for the actual hostnames and ports in the scenario.
What to do instead
Before starting anything, walk the config top-down and confirm every inter-broker address resolves to a real host and port in the described topology. In KRaft, verify controller.quorum.voters lists all controllers with matching node IDs, and that process.roles is set correctly (broker, controller, or both) on each node.
Configuring replication and durability by feel: setting default.replication.factor below 3, leaving min.insync.replicas at 1, or enabling unclean.leader.election.enable without acknowledging the durability trade-off the scenario asks for.
Candidates know the property names but not the interaction between acks, min.insync.replicas, and replication factor, so they pick values that look reasonable but break the stated availability or durability requirement.
What to do instead
Reason explicitly about the acks=all path: producer acks=all succeeds only when min.insync.replicas replicas acknowledge, so RF must be at least min.insync.replicas plus one for tolerance of a single failure. State the failure budget the scenario implies and choose RF and min.insync.replicas to match it.
Sizing and placing log.dirs without separating them across physical devices, and forgetting that adding a new directory to log.dirs does not rebalance existing partitions onto it.
Candidates assume Kafka automatically redistributes data when a disk is added, or they put multiple log directories on the same volume and expect throughput gains that never materialize.
What to do instead
Place each log.dirs entry on a distinct device, and after adding a directory use kafka-reassign-partitions or kafka-log-dirs to move partitions deliberately. Explain in the answer that new directories only receive newly created partitions.
Deploying a multi-node cluster without giving each broker a unique node.id/broker.id, or reusing an ID after replacing a node without formatting its metadata log, causing duplicate-ID registration or split-brain-style conflicts.
Candidates clone a working server.properties across hosts to save effort, changing only the hostname, and forget the ID field is per-node state, not a shared setting.
What to do instead
Assign IDs from a documented range, one per node, and never reuse an ID while the old node may still be reachable. When rebuilding a node, format its storage with the correct cluster ID (kafka-storage format --cluster-id ... --config ...) before starting it.
Bringing up brokers in an order or timing that leaves the cluster without a controller quorum - starting brokers before controllers are established, or restarting controllers one at a time without waiting for the quorum to recover.
Candidates treat broker startup as order-independent and apply rolling-restart habits from stateless services, not realizing a KRaft cluster needs a majority of controllers before metadata operations succeed.
What to do instead
Start controller nodes first and confirm a leader is elected, then start brokers. For restarts, take down one node at a time and verify quorum health (kafka-metadata-quorum describe --status) before proceeding to the next.
Assuming a fresh deployment can be scaled by simply adding brokers and expecting existing topics to spread across them, without running a partition reassignment or using a rebalance tool.
Candidates conflate broker registration with data distribution; the new broker joins the cluster but owns no partitions until partitions are explicitly moved to it.
What to do instead
After adding brokers, generate a reassignment plan (kafka-reassign-partitions with a JSON topic list), execute it, and verify with kafka-topics --describe that replicas land on the new nodes. Mention throttling reassignment to avoid saturating the network.
Monitoring only broker liveness (process up, port open) and missing the signals that actually predict failure: under-replicated partitions, offline partitions, active controller count, and request queue saturation.
Candidates default to generic host metrics and never map them to Kafka's own JMX and cluster-level indicators, so a cluster that is technically running but losing replicas looks healthy.
What to do instead
Name the specific metrics to watch: UnderReplicatedPartitions, OfflinePartitionsCount, ActiveControllerCount (should be exactly 1), LeaderElectionRateAndTimeMs, and request handler idle ratio. Tie each to a threshold and an alert action.
Diagnosing consumer lag with only the consumer group offset and ignoring the log-end offset and time lag, or blaming the broker when the lag is caused by a slow consumer or a rebalance loop.
Candidates read a single lag number and jump to a broker-side conclusion, without checking whether lag is growing (producer outpaces consumer) or whether rebalances are repeatedly resetting progress.
What to do instead
Compare current offset, log-end offset, and lag over time, and check consumer group state for repeated rebalances (session.timeout.ms, max.poll.interval.ms, partition assignment strategy). Separate producer-side load from consumer-side capacity in the diagnosis.
Troubleshooting a producer or consumer failure by changing client config blindly (retries, timeouts, acks) without reading the exception class or checking broker-side logs and the controller state.
Candidates pattern-match on symptoms like 'messages are being lost' or 'consumer keeps disconnecting' and apply a remembered fix rather than confirming the actual failure layer.
What to do instead
Work the layer explicitly: identify the exception (e.g. NotEnoughReplicas, OffsetOutOfRange, RebalanceInProgress), check broker logs for the matching event, confirm ISR membership and controller health, and only then adjust the specific setting that addresses the confirmed cause.
Handling a broker failure by deleting or reformatting its log directory, or by clearing the metadata log, instead of letting the surviving replicas re-replicate and catching the node up.
Candidates reach for a clean-slate fix under time pressure and do not realize that wiping storage discards replicas the cluster could have used and can force leader elections or data loss.
What to do instead
Treat broker recovery as rejoin, not rebuild: fix the underlying fault, restart the node with intact log.dirs, and let it rejoin the ISR. Only format storage when the node is genuinely unrecoverable and the topic's replication factor guarantees another copy exists.