Free CCAAK practice test: 30 questions with answers

With acks=all, min.insync.replicas=2 means a write needs two in-sync replicas. With one broker down two remain and writes succeed; with two down, producers get NotEnoughReplicas errors. The other settings govern leader eligibility, compaction and age-based retention, not the acknowledgement rule.

unclean.leader.election.enable allows an out-of-sync replica to become leader when no in-sync replica is available, which can discard messages the old leader had acknowledged. It is disabled by default to protect durability. The other settings control topic auto-creation, the log cleaner and default replica counts.

Turning off auto.create.topics.enable makes brokers reject writes to unknown topic names, so the typo produces an error instead of a stray topic. Retention, compression and replica lag thresholds do not control whether a topic gets created.

Log compaction keeps the latest record for each key, which suits changelog-style topics where the newest state matters. Keeping the earliest value is the opposite behaviour. Removing data by age or size is the job of the delete policy, not compaction.

Retention limits apply independently, so once either the age or the size limit is exceeded, the oldest closed segments become eligible for deletion. Requiring both limits, letting the age setting win, or deleting the active segment are all wrong, because retention never removes the active segment.

Clients bootstrap through one broker and then use the advertised addresses in metadata to reach each partition leader. An extra listener that advertises a name reachable from the external network fixes this. Broker IDs, network thread counts and topic auto-creation do not change which address clients are given.

retention.ms and cleanup.policy are topic-level configurations that override broker defaults for that topic. listeners, log.dirs and broker.id are broker-level settings and cannot be set on an individual topic.

Client quotas, set per user or client ID, can cap a client's produce rate with producer_byte_rate, which protects other producers on the cluster. Compaction, a higher replication factor and disabling idempotence do not limit how fast a client may write.

A KRaft quorum needs a majority of voters, so three controllers can lose one node and still elect a leader. Two controllers cannot survive any failure and one has no redundancy. Four controllers also tolerate only one failure, so three is the usual minimum for this goal.

process.roles set to broker,controller makes one process act as both a broker and a metadata controller, which is combined mode. It is convenient for development, but production clusters usually run isolated controllers. The other options describe roles that this setting does not express.

Labelling brokers with zone-based broker.rack values lets Kafka spread each partition's replicas across zones, so a single zone outage leaves replicas elsewhere. Single-zone placement, one physical host and replication factor 1 all remove the redundancy the requirement depends on.

Formatting the storage with the cluster ID writes the metadata the node needs to join, and it must happen before the first start. Kafka creates the cluster metadata log during formatting rather than by hand, and client configuration files and acks settings play no part in preparing storage.

A rolling upgrade restarts one broker at a time and waits for replicas to catch up, so partitions stay available throughout. Stopping everything causes an outage, disabling replication weakens durability, and moving all leaders to one broker creates a bottleneck.

KRaft stores cluster metadata in a Raft-based log on controller nodes, and ZooKeeper support was removed in Kafka 4.0. New clusters do not need ZooKeeper, consumers do not hold cluster metadata, and producers do not elect controllers.

Each node needs its own node.id, and every node's storage must be formatted with the cluster ID before first start. controller.quorum.voters lists only controller nodes, ZooKeeper is not needed for KRaft, and production clusters commonly run isolated controllers rather than combined mode.

Persistent volumes attached to stateful workloads, often managed by an operator such as Strimzi, keep log directories across pod reschedules. Ephemeral storage is lost when a pod is replaced, changing hostnames does not preserve data, and in-memory-only records are lost on restart.

UnderReplicatedPartitions counts partitions where some replicas are missing from the in-sync set, so a follower is lagging or unreachable even though the partition still has a leader. Controller leadership, idempotence settings and consumer group deletion do not affect this replication metric.

Exactly one controller should be active across the cluster at any time. The other options describe controllers that do not exist per topic or per partition, or a state with no active controller, which would block metadata changes.

OfflinePartitionsCount counts partitions with no active leader, so reads and writes to them fail until a leader is elected. Slow consumers, compression ratios and retention size can cause lag or deletion but do not make partitions unavailable.

Describing the group shows the current offset, log end offset and LAG for each partition, which reveals the lagging partition or member. Deleting the group, lowering acks or disabling compaction does not address a consumer that is processing too slowly.

If a consumer does not call poll within max.poll.interval.ms, the group treats it as failed and rebalances, and large batches per poll make that more likely. min.insync.replicas, segment size and producer compression do not govern consumer group membership.

A follower that cannot keep up within the replica lag time limit is removed from the ISR, and repeated shrink and expand events under heavy disk I/O point to that broker's follower. Controller changes, partitioner choice and partition counts do not produce this pattern.

UnderReplicatedPartitions shows replicas missing from the ISR, and OfflinePartitionsCount shows partitions with no leader at all. Send rate, group membership and topic creation counts describe workload or inventory and do not indicate lost replication or availability on their own.

With acks=all the leader rejects writes when the in-sync set has fewer members than min.insync.replicas. Losing two of three replicas leaves one in-sync member for the affected partitions, so NotEnoughReplicas is returned. Retention limits, consumer commits and batch sizes do not produce this error.

Offset resets require the group to be inactive, so every consumer in it must stop before kafka-consumer-groups.sh can change committed offsets. Adding partitions, changing producer acks and restarting brokers do not clear group membership.

kafka-reassign-partitions.sh takes a JSON plan, --execute starts the move, and --verify checks whether it has completed. Deleting data, editing segment files or changing broker IDs would lose data or corrupt the cluster.

Keyed records are assigned by hashing the key modulo the partition count, so after the count changes, new records for a key can land on a different partition than earlier ones, which breaks per-key order across the change. Existing data is not rewritten and replication is unaffected.

When the committed offset is out of range, the consumer applies auto.offset.reset, which picks the earliest available record, the latest one, or fails. Replica fetch sizes, ISR thresholds and flush intervals do not change where a consumer resumes.

A preferred leader election moves leadership back to the preferred replica, which is the first replica in each partition's assignment list, provided it is in sync. Changing unclean election, deleting and recreating topics, or lowering the replication factor does not restore preferred leaders and can add risk.

Reassigning partitions away and letting a controlled shutdown move leadership both move the work off the broker before it stops, without relying on unclean elections. Enabling unclean election, deleting log directories and lowering min.insync.replicas all increase the risk of losing acknowledged data.