Kafka is a distributed event streaming platform that stores messages in an ordered, replicated log so many systems can publish and consume them independently. Topics include producers and consumers, partitions and ordering, retention and log compaction, delivery semantics, idempotence and exactly-once processing, dead letter queues, event sourcing, stream processing and operations.
All 37 Kafka quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 17 subtopics, so you can revise one part at a time. Choose Try Kafka quiz above to take a scored run and review the questions you got wrong.
Want long-form answers? Read 42 Kafka interview questions with answers — same topic, in more depth.
Answer: A
Partition. Within a consumer group, each partition is read by only one consumer. So a topic with 6 partitions supports at most 6 working consumers; the 7th consumer sits idle.
References
Answer: C
No. Kafka is a log retained by time (retention.ms, default 7 days) or by size. A consumer only moves its own offset cursor; the data stays there for other groups to read or for re-reading.
References
Answer: B
The number of records between the partition's end offset and the consumer's committed offset — i.e. how many records the consumer is behind. This is the most important health metric of a Kafka pipeline.
References
Answer: A
The producer spreads records evenly in batches (sticky partitioner: fills one batch into a partition, then moves to another). With a key, partition = hash(key) % number of partitions, so the same key always goes to the same partition.
References
Answer: D
Each group receives every message, independently, because offsets are stored per group. Work is only divided among consumers *within the same* group — this is how Kafka supports both pub/sub and queuing.
References
Answer: C
Moves data into/out of Kafka using connectors declared via configuration: a source connector reads from Postgres/MySQL/S3 and writes to a topic, a sink connector reads a topic and writes to Elasticsearch/S3/a data warehouse.
References
Answer: C
Each partition exists in 3 replicas on 3 different brokers: one leader handles writes, the followers replicate it and can be elected leader on failure. Losing one broker still leaves 2 replicas, so the cluster keeps running.
References
Answer: C
A monotonically increasing sequence number within a partition, assigned by the broker on write. Only the tuple (topic, partition, offset) uniquely identifies a record — offset alone does not, since every partition starts at 0.
References
Answer: B
--partitions (max parallelism), --replication-factor (fault tolerance, usually 3), and retention.ms or retention.bytes. Don't rely on defaults, since cluster defaults rarely match what the topic needs.
Answer: D
Consumers with the same group id split the partitions among themselves and share the stored read position. Changing the id means creating a new consumer side that starts from the position defined by config — usually the beginning or the end of the topic.
References
Answer: D
Only within a single partition. To keep events of the same entity in order, write them with the same key (e.g. orderId) — same key means same partition.
References
Answer: A
3 consumers each get one partition, 2 consumers are completely idle. They don't fail and stay in the group — useful as backups, since if a consumer dies, the rebalance assigns its partition to an idle consumer.
References
acks=all differ from acks=1?Answer: D
acks=1 only waits for the leader to write; if the leader dies before a replica fetches the data, the message is lost. acks=all waits for all replicas in the ISR to acknowledge, so it's more durable at the cost of higher latency.
References
cleanup.policy=compact keep?Answer: D
The latest record for each key; older records with the same key are gradually cleaned up. The log becomes current state rather than history — used for table-like topics: user info, config, inventory.
References
max.poll.interval.ms stays at the 5-minute default. Result?Answer: B
The consumer gets kicked out of the group, the group rebalances, and that message is handed to another consumer — so it gets reprocessed, potentially in an infinite loop. This is the classic cause of "constant rebalancing".
References
enable.auto.commit=true)?Answer: D
Offsets are committed on a time interval, not according to actual processing progress. If that interval falls mid-processing and the consumer dies, messages that were committed but not yet processed will never be read again — silent data loss.
References
enable.idempotence=true on the producer prevent?Answer: A
Duplicates caused by producer retries: the network fails after the broker has written but the response doesn't come back, the producer resends and creates a second record. An idempotent producer attaches a producer id + sequence number so the broker can discard the duplicate.
References
Answer: A
Dead-letter topic: write the bad record along with error info to a separate topic, commit the offset, then continue processing. Retrying forever blocks the entire partition — records behind it don't get processed even though they're perfectly valid.
Answer: D
When the data is an event stream that needs to be retained: multiple independent consumers reading the same source, needing to replay history, very high throughput. RabbitMQ is better suited for work queues with complex routing, priorities, per-message TTL.
References
Answer: B
The set of replicas that are keeping up with the leader (not lagging beyond replica.lag.time.max.ms). acks=all waits for exactly this set, and when a new leader must be chosen, only replicas in the ISR are eligible if you don't want to lose data.
References
linger.ms from 0 to 20?Answer: B
The producer waits up to 20ms to gather more records into a batch: fewer requests, better compression, higher throughput, at the cost of up to 20ms added latency. For batch pipelines this is a very worthwhile trade-off.
References
auto.offset.reset=earliest and restart the consumersAnswer: A
Stop all consumers in the group, then run kafka-consumer-groups.sh --reset-offsets --to-earliest --execute. auto.offset.reset=earliest does not help here because the group already has committed offsets — it only applies to new groups.
References
UnderReplicatedPartitions greater than zero mean?Answer: B
Some partition has fewer replicas in the ISR than the replication factor. This is a top warning metric: a sustained value above 0 means the cluster is losing fault tolerance.
References
Answer: D
When processing is stateful: windowed counts, joining two streams, aggregating by key. Doing this yourself with a consumer usually means building a durable state store, recovering from failures, and handling late-arriving data.
References
TimeoutException: Expiring N records. What does that mean?delivery.timeout.ms without being sentAnswer: B
The record was already in the producer's buffer but could not be sent within delivery.timeout.ms (2 minutes by default), so it was discarded. Common causes: broker unavailability, network congestion, or the application producing faster than the send rate.
References
Answer: D
Backward compatible: a consumer running the new schema can read records written with the old schema, because the missing field falls back to its default value. This is the default compatibility level of the Schema Registry.
References
Answer: B
No automatic movement. A new broker only receives partitions of topics created after it joined. To move existing data, run kafka-reassign-partitions.sh with a new assignment plan.
References
subscribe() differ from assign()?subscribe can only read one topic per callassign is faster because it skips authentication with the brokersubscribe reads from the start of the topic while assign reads from the endsubscribe joins a group and gets partitions assigned automaticallyAnswer: D
subscribe() joins a consumer group: Kafka assigns partitions and rebalances automatically when consumers join or leave. assign() specifies partitions directly — no group, no rebalance, and the application handles partitioning itself.
References
pause() that partition and resume() it when readysleep inside the processing loop to slow downpoll until the destination system recoversAnswer: A
pause(partitions) then resume(partitions). The key point: keep calling poll() while paused — that keeps heartbeats and the max.poll.interval.ms limit satisfied, so the consumer is not kicked out of the group.
References
Answer: A
Replicating data across clusters: a disaster-recovery cluster in another region, aggregating data from many regions into one analytics place, or migrating to a new cluster. It is built on Kafka Connect.
Answer: C
By default, separate by event type — consumers subscribe only to what they need, with separate retention and schemas. Exception: events of the same entity whose relative order matters (OrderCreated, OrderPaid, OrderCancelled) should go in the same topic, with the same key.
References
client.id the producer declares when connectingAnswer: B
ACLs are tied to a principal from the authentication step (SASL or mTLS): each rule lets a principal perform an operation on a resource. Without authentication, ACLs are meaningless since anyone can claim to be anyone.
References
retention.ms on the topic taking the most diskAnswer: C
Reduce retention.ms (or set retention.bytes) for the biggest topics using kafka-configs.sh --alter. The change takes effect immediately, and the broker will clean up expired segments on the next cleanup cycle. Never delete log files by hand.
References
OffsetOutOfRangeException. Why?Answer: D
The consumer is asking for an offset that no longer exists — the data there has been removed by retention. Classic scenario: the consumer died or was stopped for longer than the topic's retention, and when it comes back its old offset is gone.
References
Answer: D
Record headers — key-value pairs attached to each record, available since Kafka 0.11. They can be read without decoding the payload, making them ideal for trace ids, schema versions, or error info when pushing to a dead-letter topic.
References
Answer: C
Compression happens on the producer side per batch, and the data stays compressed all the way to the consumer. That saves bandwidth between producer and broker, between brokers during replication, and between broker and consumer — not just disk space.
References
Answer: C
They limit read/write bandwidth and request processing time per client or per user. The goal is to stop one application from consuming the whole cluster's capacity and affecting every other application — the noisy neighbor problem in a shared cluster.
References
Advanced goes deep on real-world scenarios and the technical pitfalls candidates actually run into. Included with Pro.
Upgrade to Pro