I85PREP
⌘ K
Confluent Kafka Developer study materials
Confluent Kafka Developer study resources

Confluent Kafka Developer practice questions

One question at a time. Build your Confluent Kafka Developer understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Kafka Fundamentals

In Kafka, which resource is the basic unit of parallelism for a consumer group?

  1. Topic
  2. Partition Correct answer.
  3. Broker
  4. Consumer group

Explanation

A partition is the smallest unit that can be assigned to a consumer, so the maximum useful parallelism of a consumer group equals the number of partitions it consumes. Topics are logical containers, and brokers merely host partitions.

Question 2Kafka Fundamentals

Within a single Kafka partition, what ordering guarantee does the broker provide for records?

  1. Records are returned sorted by their key.
  2. Records are returned in append order by increasing offset. Correct answer.
  3. Records within a partition have no defined order.
  4. Records are returned sorted by producer timestamp.

Explanation

A partition is an append-only log, and each record receives a monotonically increasing offset when appended. Consumers therefore read a partition in exactly the order the records were written.

Question 3Kafka Fundamentals

A consumer group has no committed offset for a partition. Which auto.offset.reset value makes the consumer begin at the oldest retained record?

  1. none
  2. smallest
  3. latest
  4. earliest Correct answer.

Explanation

The earliest setting resets the position to the log start offset, which is the oldest record still retained on the partition. It applies only when no valid committed offset exists.

Question 4Kafka Fundamentals

Which broker setting determines how many partitions a topic gets when the broker auto-creates it?

  1. min.insync.replicas
  2. log.retention.bytes
  3. num.partitions Correct answer.
  4. default.replication.factor

Explanation

num.partitions is the broker-level default partition count used when a topic is created without an explicit partition count, including auto-creation. It has no effect on topics that specify their own partition count.

Question 5Kafka Fundamentals

A producer sends a record whose key is null. Who chooses the partition for that record?

  1. The producer's partitioner Correct answer.
  2. The broker leader
  3. The group coordinator
  4. The controller

Explanation

When no key is supplied, the producer-side partitioner selects the partition and spreads records across the topic's partitions. The broker simply appends the record to whatever partition the producer targets.

Question 6Kafka Fundamentals

Which internal Kafka topic stores committed consumer offsets?

  1. __transaction_state
  2. __consumer_offsets Correct answer.
  3. kafka-offsets
  4. __offset_store

Explanation

Committed offsets for consumer groups are written to the compacted internal topic __consumer_offsets. The group coordinator is the broker that leads the relevant partition of that topic.

Question 7Kafka Fundamentals

With default broker settings, how long are records retained in a Kafka topic?

  1. 24 hours
  2. 30 days
  3. 7 days Correct answer.
  4. Indefinitely

Explanation

The default log.retention.hours value is 168, which equals seven days, after which eligible log segments are deleted. Retention can be overridden per topic or per broker.

Question 8Kafka Fundamentals

A topic has a replication factor of 3. What does this mean for each partition?

  1. Each partition has three replicas, one leader and two followers. Correct answer.
  2. The producer sends each record three times.
  3. Each partition has three leaders.
  4. Each record is written to three different topics.

Explanation

Replication factor 3 means each partition has three copies on three different brokers, with one replica acting as leader and the others as followers. Producers write to the leader, and followers fetch to stay in sync.

Question 9Kafka Fundamentals

A partition has replication.factor=3, min.insync.replicas=2, and the producer uses acks=all. Which condition must hold for a write to succeed?

  1. Every in-sync replica must acknowledge, or the write fails. Correct answer.
  2. All three replicas must acknowledge or the write is rejected.
  3. Only the leader must acknowledge the write.
  4. At least two replicas must acknowledge, chosen by the controller.

Explanation

acks=all makes the leader wait for all replicas currently in the ISR, while min.insync.replicas requires at least two of them to be present. If the ISR shrinks below two, the broker rejects the write with NotEnoughReplicas.

Question 10Kafka Fundamentals

A producer is configured with acks=1. When does it consider a record successfully written?

  1. The leader has written the record to its local log. Correct answer.
  2. The record has been flushed to disk on every replica.
  3. All in-sync replicas have written the record.
  4. At least one follower has replicated the record.

Explanation

With acks=1 the leader acknowledges as soon as it has appended the record to its own log, without waiting for followers. This reduces latency but risks data loss if the leader fails before replication occurs.

Question 11Kafka Fundamentals

What does enabling enable.idempotence=true on a producer guarantee?

  1. Exactly-once delivery across multiple topics.
  2. Atomic writes spanning several partitions.
  3. Prevention of duplicate writes caused by retries. Correct answer.
  4. Compression of records before sending.

Explanation

An idempotent producer attaches a producer id and sequence number so the broker can discard retried records that were already written. This prevents duplicates from retries and preserves ordering per partition.

Question 12Kafka Fundamentals

A topic has four partitions and a consumer group has five consumers. What is the result after rebalancing?

  1. One consumer stays idle with no assigned partitions. Correct answer.
  2. One partition is shared by two consumers.
  3. Each consumer receives all four partitions.
  4. The group fails to rebalance.

Explanation

Each partition is assigned to at most one consumer in a group, so four partitions can occupy only four consumers. The fifth consumer remains in the group but receives no partitions.

Question 13Kafka Fundamentals

Which situation causes a consumer to process some records twice?

  1. The consumer sets isolation.level to read_committed.
  2. The consumer uses auto.commit.interval.ms.
  3. The consumer commits offsets before processing records.
  4. The consumer processes records but crashes before committing offsets. Correct answer.

Explanation

If records are processed but the offsets are never committed, the next consumer to own the partition resumes from the last committed offset and re-reads them. This is the at-least-once behavior that follows from committing after processing.

Question 14Kafka Fundamentals

A topic is configured with cleanup.policy=compact. Which records are retained?

  1. Records are retained until the segment is rolled.
  2. All records are retained for seven days.
  3. The latest record for each key is retained. Correct answer.
  4. Only records with null keys are retained.

Explanation

Log compaction keeps at least the most recent record for every key and removes older values with the same key. Records with null keys cannot be compacted by key and are eventually removed.

Question 15Kafka Fundamentals

A consumer in a group does not call poll() within max.poll.interval.ms. What happens?

  1. The consumer is removed from the group and a rebalance occurs. Correct answer.
  2. The broker deletes the consumer's committed offsets.
  3. The consumer switches to manual partition assignment.
  4. The consumer keeps its partitions but stops fetching.

Explanation

If the interval between poll() calls exceeds max.poll.interval.ms, the coordinator considers the consumer failed and triggers a rebalance so its partitions can be reassigned. Committed offsets are unaffected by this.

Question 16Kafka Fundamentals

Which consumer configuration caps how long the broker waits before answering a fetch request that has too little data?

  1. request.timeout.ms
  2. session.timeout.ms
  3. fetch.max.wait.ms Correct answer.
  4. max.poll.records

Explanation

fetch.max.wait.ms bounds how long the broker holds a fetch request when fetch.min.bytes has not yet been satisfied. It works together with fetch.min.bytes to trade latency for efficiency.

Question 17Kafka Fundamentals

What does the consumer setting session.timeout.ms control?

  1. How long the broker keeps a fetch request open.
  2. How often the consumer sends heartbeats.
  3. How long the coordinator waits for a heartbeat before removing the consumer. Correct answer.
  4. How long a consumer may go between poll() calls.

Explanation

session.timeout.ms is the maximum time the group coordinator waits to hear from a consumer before declaring it dead and starting a rebalance. Heartbeat frequency is set separately by heartbeat.interval.ms.

Question 18Kafka Fundamentals

What is the typical effect of increasing linger.ms on a producer?

  1. It caps the number of records returned per poll.
  2. It sets the maximum size of a single record batch.
  3. It increases batching and throughput at the cost of latency. Correct answer.
  4. It reduces latency by sending each record immediately.

Explanation

linger.ms tells the producer to wait a little before sending so more records accumulate in a batch. Larger batches improve throughput but add delay before the records are transmitted.

Question 19Kafka Fundamentals

Which broker configuration allows a topic to be created automatically the first time a record is produced to it?

  1. log.auto.create
  2. auto.create.topics.enable Correct answer.
  3. delete.topic.enable
  4. num.partitions

Explanation

auto.create.topics.enable permits the broker to create a topic on demand when a client references a topic that does not exist. It is often disabled in production to keep topic creation under administrative control.

Question 20Kafka Fundamentals

How is the group coordinator for a consumer group determined?

  1. It is the leader of the __consumer_offsets partition for the group. Correct answer.
  2. It is always the controller broker.
  3. It is the broker with the lowest node id in the cluster.
  4. It is the broker the consumer first connects to.

Explanation

The group id is hashed to select one partition of __consumer_offsets, and the broker that leads that partition acts as the group coordinator. That broker handles membership and offset commits for the group.

Question 21Kafka Fundamentals

A consumer uses isolation.level=read_committed. How does it treat transactional records?

  1. It blocks until every open transaction commits.
  2. It returns records from aborted transactions too.
  3. It filters out records from aborted transactions. Correct answer.
  4. It reads only records written without a transaction.

Explanation

With read_committed the consumer only returns records from committed transactions and skips those belonging to aborted ones. It advances to the last stable offset rather than waiting for open transactions indefinitely.

Question 22Kafka Fundamentals

A partition has replicas in sync {A, B}, min.insync.replicas=2, and the producer uses acks=all. Replica B then fails and drops out of the ISR. What happens to new writes?

  1. Writes fail with NotEnoughReplicas until another replica catches up. Correct answer.
  2. The producer automatically falls back to acks=1.
  3. The controller immediately elects a new leader.
  4. Writes continue because the leader is still available.

Explanation

With only one in-sync replica left, the partition no longer satisfies min.insync.replicas=2, so acks=all writes are rejected with NotEnoughReplicas. The producer must retry until the ISR grows again.

Question 23Kafka Fundamentals

A broker has unclean.leader.election.enable=true. What risk does this introduce?

  1. The new leader is chosen only from the ISR.
  2. Producers must switch to acks=0.
  3. A replica that is not in sync can become leader, risking data loss. Correct answer.
  4. The partition stays offline until the old leader returns.

Explanation

Unclean leader election lets an out-of-sync replica take over when no in-sync replica is available, which restores availability but can lose records that the failed leader had acknowledged. Disabling it prioritizes consistency over availability.

Question 24Kafka Fundamentals

Why can increasing a topic's partition count break ordering for records that share a key?

  1. Existing records are rehashed and moved immediately.
  2. The replication factor must be increased first.
  3. Consumers must re-read from the earliest offset.
  4. Records with the same key may land in different partitions. Correct answer.

Explanation

The key-to-partition mapping is computed from the hash of the key modulo the partition count, so adding partitions can send future records with the same key to a different partition. Ordering is only guaranteed within a partition, so per-key order can break.

Question 25Kafka Fundamentals

A consumer fetches from offset 100, but the log start offset of the partition is now 120 because older segments were deleted. What does the broker do?

  1. The broker returns OffsetOutOfRange and the consumer applies auto.offset.reset. Correct answer.
  2. The fetch returns the deleted records from cache.
  3. The consumer silently jumps to the log end offset.
  4. The coordinator deletes the committed offset.

Explanation

An offset below the log start offset no longer exists, so the broker responds with OffsetOutOfRange. The consumer then follows its auto.offset.reset policy, which defaults to starting at the latest records.

Question 26Kafka Fundamentals

Within a single Kafka partition, what does a record's offset identify?

  1. The broker that currently leads the partition
  2. The number of replicas that acknowledged the write
  3. The consumer group that last read the record
  4. Its position in the partition's append-only log Correct answer.

Explanation

Kafka assigns offsets sequentially within each partition as records are appended. An offset is unique only inside its partition, so the same offset value can exist in many partitions. Consumers use these offsets to track their read position.

Question 27Kafka Fundamentals

What is a Kafka topic best described as?

  1. A physical disk on a broker that stores log segments
  2. A temporary buffer used only during consumer rebalances
  3. A named stream of records split into partitions Correct answer.
  4. A client process that publishes records to brokers

Explanation

A topic is a logical name for a stream of records, and it is divided into partitions for scalability and parallelism. Producers publish to topics and consumers subscribe to them. The partitions themselves are stored on brokers.

Question 28Kafka Fundamentals

What is the primary role of a Kafka broker?

  1. To assign partitions to consumers in a group
  2. To store partitions and serve client requests Correct answer.
  3. To compress records before they reach the producer
  4. To elect the consumer group coordinator for each topic

Explanation

Brokers store partition replicas and handle produce and fetch requests from clients. They also participate in replication and cluster metadata management. Partition assignment to consumers is handled by the group coordinator and client-side assignors.

Question 29Kafka Fundamentals

What defines a Kafka consumer group?

  1. A set of topics that share the same retention policy
  2. A producer configuration that enables transactions
  3. Consumers with the same group.id that share partitions Correct answer.
  4. A broker-side cache of records awaiting delivery

Explanation

Consumers that use the same group.id form a group, and the group assigns each partition to at most one consumer at a time. This lets multiple consumers share the work of reading a topic. Different groups read independently of one another.

Question 30Kafka Fundamentals

If a consumer has no committed offset for a partition and auto.offset.reset is left at its default, where does it begin?

  1. At offset zero, even if it is no longer available
  2. At the earliest available offset in the partition
  3. At the latest offset in the partition Correct answer.
  4. At the partition's high watermark minus one

Explanation

The default value of auto.offset.reset is latest, so a consumer with no committed offset starts at the end of the partition. It will see only records produced after it begins reading. Setting the value to earliest changes this behavior.

Question 31Kafka Fundamentals

With acks=0, what does a producer do after sending a record?

  1. It does not wait for broker acknowledgment Correct answer.
  2. It waits for the leader to acknowledge the write
  3. It retries until the broker returns an acknowledgment
  4. It waits until all in-sync replicas acknowledge

Explanation

With acks=0 the producer sends the record and considers the send complete without waiting for any broker response. This gives the lowest latency but allows silent data loss if the write fails. It also means retries are not driven by acknowledgment failures.

Question 32Kafka Fundamentals

A producer sends records with a non-null key using default partitioning. How are they assigned to partitions?

  1. They rotate across partitions regardless of key
  2. They all go to the partition with the least data
  3. By hashing the key and mapping it to a partition Correct answer.
  4. By the order in which brokers register with the cluster

Explanation

The default partitioner hashes the record key and maps the hash to one of the topic's partitions. Records with the same key therefore normally go to the same partition, preserving their order there. Records with null keys are distributed differently.

Question 33Kafka Fundamentals

What is a Kafka log segment?

  1. A single record with its key and headers
  2. A replica that has fallen behind the leader
  3. A file holding a contiguous offset range Correct answer.
  4. A range of offsets owned by one consumer

Explanation

A partition log is divided into segment files, each covering a contiguous range of offsets. The broker appends to the active segment and rolls to a new one based on size or time limits. Retention and compaction operate on segments.

Question 34Kafka Fundamentals

After a topic has been created, which change to its partition count is supported?

  1. Increasing it, but not decreasing it Correct answer.
  2. Both increasing and decreasing it at any time
  3. Neither increasing nor decreasing it after creation
  4. Decreasing it, but not increasing it

Explanation

Kafka allows a topic's partition count to be increased, but not reduced. Decreasing partitions would require discarding data and would break the mapping of keys to partitions. Increasing partitions also changes which partition a given key maps to.

Question 35Kafka Fundamentals

What does consumer setting max.poll.records control?

  1. The maximum records returned by one poll() call Correct answer.
  2. The maximum number of partitions assigned to a consumer
  3. The maximum bytes returned by one fetch request
  4. The maximum time allowed between poll() calls

Explanation

max.poll.records limits how many records a single poll() call returns to the application. It is used to bound the amount of work done between calls to poll(). It does not control fetch byte limits or the poll interval timeout.

Question 36Kafka Fundamentals

A producer has retries enabled and max.in.flight.requests.per.connection greater than 1. What ordering risk can occur without idempotence?

  1. Records with different keys can be reordered across partitions
  2. The broker can reorder records within a single batch
  3. Consumers can receive records out of order within one offset
  4. A retried batch can arrive after a later batch Correct answer.

Explanation

With multiple requests in flight, a failed earlier batch may be retried after a later batch has already succeeded. That can make the later batch appear first in the partition log. Setting max.in.flight to 1 or enabling idempotence prevents this reordering.

Question 37Kafka Fundamentals

A topic has retention.ms set to seven days and retention.bytes set to a finite value. When does Kafka delete a log segment?

  1. Only when retention.ms is exceeded
  2. When either the time or size limit is exceeded Correct answer.
  3. Only after both limits are exceeded
  4. Only when the segment is compacted

Explanation

Kafka applies both time-based and size-based retention limits to eligible log segments. If either the configured age or the configured byte limit is exceeded, old segments can be deleted. The active segment is not removed by retention.

Question 38Kafka Fundamentals

What is a typical effect of setting compression.type on a producer?

  1. Fewer bytes are sent and stored, at extra CPU cost Correct answer.
  2. The broker decompresses each record before appending it
  3. Records are encrypted before being written to disk
  4. Consumer offsets are compressed in the internal topic

Explanation

Producer compression reduces the size of record batches sent over the network and stored by brokers. The tradeoff is additional CPU work for compression and decompression. Brokers generally store the compressed batch as received.

Question 39Kafka Fundamentals

What does the consumer setting fetch.min.bytes control?

  1. The maximum bytes a consumer will cache per partition
  2. The smallest message size the broker will accept
  3. The minimum number of records required per batch
  4. The minimum data a broker should return in a fetch Correct answer.

Explanation

fetch.min.bytes tells the broker how much data to accumulate before answering a fetch request. A larger value can improve throughput by reducing request count but adds latency. It interacts with fetch.max.wait.ms, which bounds the wait.

Question 40Kafka Fundamentals

With enable.auto.commit=true, when are offsets committed by default?

  1. When the consumer is assigned a new partition
  2. Only when the consumer calls commitSync()
  3. Periodically in the background during poll() Correct answer.
  4. After every record is processed by the application

Explanation

Auto-commit commits the consumer's current position periodically while poll() is being called. The interval is controlled by auto.commit.interval.ms. Because the commit may happen before application processing finishes, this can lead to at-least-once delivery.

Question 41Kafka Fundamentals

What does producer configuration batch.size control?

  1. The number of records allowed per topic partition
  2. The maximum size of a single record's value
  3. The maximum bytes buffered for a partition batch Correct answer.
  4. The total memory reserved for all producers

Explanation

batch.size sets an upper bound on how many bytes the producer buffers for a batch going to one partition. When the batch reaches that size, it can be sent sooner. It does not cap the size of an individual record.

Question 42Kafka Fundamentals

In a replicated partition, what do follower replicas do?

  1. They assign offsets to incoming records independently
  2. They fetch records from the leader to stay caught up Correct answer.
  3. They serve produce requests from clients by default
  4. They commit consumer offsets for the group

Explanation

Followers replicate a partition by fetching from the current leader. They do not normally serve client produce or consume requests unless they become leader. A follower that is sufficiently caught up is part of the in-sync replica set.

Question 43Kafka Fundamentals

What is a key responsibility of the Kafka controller?

  1. Compressing producer batches before storage
  2. Assigning offsets to records within a partition
  3. Storing consumer group offsets durably
  4. Choosing partition leaders when brokers fail Correct answer.

Explanation

The controller manages cluster metadata and coordinates leader election for partitions when brokers become unavailable. In KRaft mode this role is handled by the controller quorum rather than a single ZooKeeper-elected broker. It does not assign record offsets.

Question 44Kafka Fundamentals

A consumer calls seek(tp, 500). What happens on the next poll()?

  1. It skips records until offset 500 is reached
  2. It begins fetching from offset 500 in that partition Correct answer.
  3. It commits offset 500 for the partition
  4. It resets all assigned partitions to offset 500

Explanation

seek() changes the consumer's next read position for the specified partition. The next poll() fetches from offset 500 in that partition. It does not commit an offset or affect other partitions.

Question 45Kafka Fundamentals

What is the in-sync replica (ISR) set for a partition?

  1. The replicas that are currently offline
  2. The replicas sufficiently caught up with the leader Correct answer.
  3. Every replica configured for the partition
  4. The replicas that hold the oldest log segments

Explanation

The ISR contains the leader and followers that are caught up enough to be eligible for acknowledgment and leadership. Replicas that fall too far behind are removed from the ISR. The ISR is used by acks=all and min.insync.replicas checks.

Question 46Kafka Fundamentals

To use an idempotent producer, which producer settings are required?

  1. acks=all and max.in.flight at most 5 Correct answer.
  2. acks=1 and max.in.flight at most 1
  3. acks=all and compression disabled
  4. acks=0 and retries disabled

Explanation

Idempotence requires acks=all so that writes are acknowledged by the in-sync replicas. It also requires retries to remain enabled and max.in.flight.requests.per.connection to be at most 5. Compression is not prohibited.

Question 47Kafka Fundamentals

What does a partition's high watermark represent?

  1. The offset of the next record to be appended
  2. The offset up to which replicas are fully in sync Correct answer.
  3. The largest offset ever committed by a consumer
  4. The first offset still retained after deletion

Explanation

The high watermark is the highest offset that has been replicated to all in-sync replicas. Consumers using default read isolation do not read beyond it. It therefore reflects the replicated portion of the log rather than the leader's latest append.

Question 48Kafka Fundamentals

What advantage does the cooperative-sticky assignor provide over eager rebalancing?

  1. It eliminates the need for a group coordinator
  2. It revokes only partitions that need to move Correct answer.
  3. It lets consumers read from any partition without assignment
  4. It guarantees no duplicate processing during rebalances

Explanation

Cooperative rebalancing lets consumers keep partitions that are not moving and revokes only the partitions that must be reassigned. This reduces stop-the-world disruption during a rebalance. It does not eliminate duplicate processing or the need for coordination.

Question 49Kafka Fundamentals

In a compacted topic, what does delete.retention.ms control?

  1. How long compacted records are kept before recompaction
  2. How long a consumer may take to process a tombstone
  3. How long the broker retains transaction markers
  4. How long tombstones remain before being removed Correct answer.

Explanation

A tombstone is a record with a null value that marks a key for deletion during compaction. Kafka keeps tombstones for delete.retention.ms so consumers can observe the deletion before the tombstone itself is removed. This setting is specific to compacted topics.

Question 50Kafka Fundamentals

In KRaft mode, how is the metadata quorum kept available?

  1. Any single controller node can serve metadata alone
  2. Every controller node must be active at once
  3. A majority of controller nodes must be active Correct answer.
  4. The oldest broker in the cluster acts as controller

Explanation

KRaft uses a metadata quorum of controller nodes, and the quorum remains available as long as a majority can communicate. This is similar to a Raft consensus group. It does not require every controller to be active.