Free practice · No sign-up required
15 questions with answer explanations. Choose an answer below to begin.
What is the primary purpose of a Kafka producer API?
1.1 Describe the role of producers in event streaming.
0/15 answered · Bookmark questions to review later. Focus the practice area to use keys 1–9 and Enter.
Learn by doing
Use official documentation and hands-on labs to work through topics you missed.
Prefer to read at your own pace? Work through each question below, then open its answer to check your reasoning. You can link directly to a question or print this reference.
What is the primary purpose of a Kafka producer API?
To publish records to Kafka topics
To consume records from Kafka topics
To manage Kafka broker configurations
To monitor cluster health
Correct answer
To publish records to Kafka topics
The producer API is designed to send data records into Kafka topics. Consumers read data, while brokers and monitoring tools handle configuration and health.
Which component is responsible for determining the partition where a record is stored?
Partitioner
Serializer
Coordinator
Controller
Correct answer
Partitioner
The partitioner uses the record key or a custom strategy to decide the target partition. Serializers convert data formats, coordinators manage group membership, and controllers manage cluster state.
What does message ordering guarantee in Apache Kafka?
Ordering is guaranteed within a partition
Ordering is guaranteed across all partitions
Ordering is guaranteed per consumer instance
Ordering is guaranteed only for compacted topics
Correct answer
Ordering is guaranteed within a partition
Kafka preserves the order of records only within a single partition. Ordering across partitions is not guaranteed due to parallelism.
Which configuration property controls how long a Kafka broker retains records?
retention.ms
segment.ms
log.retention.check.interval.ms
max.message.bytes
Correct answer
retention.ms
The retention.ms setting defines the maximum age of a record before it is eligible for deletion. Other options affect segment rolling or message size limits.
What is the role of a Kafka consumer group?
To allow multiple consumers to share the reading of a topic
To ensure that only one producer writes to a topic
To replicate data across brokers
To store metadata about topics
Correct answer
To allow multiple consumers to share the reading of a topic
Consumer groups enable multiple consumers to read from a topic while dividing partitions among group members for parallel processing. Producers are not restricted by groups.
Which data format is commonly used with Kafka Connect for structured data exchange?
JSON
XML
CSV
Plain text
Correct answer
JSON
JSON is widely used in Kafka Connect for structured data due to its compatibility with schemas and widespread support in connectors. Other formats are possible but less common in typical integrations.
What happens when a consumer commits an offset?
Kafka records the last processed message position
Kafka deletes the consumed messages
Kafka stops the broker from accepting new data
Kafka rebalances the consumer group
Correct answer
Kafka records the last processed message position
Committing an offset tells Kafka how far the consumer has processed records. Messages are not deleted immediately, and commits do not directly trigger rebalances.
Which statement best describes Kafka brokers?
They store data and serve client requests
They only handle authentication and authorization
They are responsible for producing messages
They format data before storage
Correct answer
They store data and serve client requests
Brokers are the core servers that store data in topics and handle read/write requests. Producers and consumers are client roles, not broker functions.
What is the purpose of log compaction in Kafka?
To retain the latest value for each key indefinitely
To delete all records after a fixed time period
To compress data to reduce disk usage
To encrypt data at rest
Correct answer
To retain the latest value for each key indefinitely
Log compaction ensures that the most recent value for each key is retained, which is useful for state recovery. Time-based deletion is handled by retention policies.
Which Kafka feature enables real-time processing of data streams?
Kafka Streams
Kafka Connect
Kafka MirrorMaker
Kafka Schema Registry
Correct answer
Kafka Streams
Kafka Streams is a library for building applications that process data in motion with low latency. Connect is for integration, MirrorMaker for replication, and Schema Registry for schema management.
What does idempotence prevent in a Kafka producer?
Duplicate records during retries
Data loss during broker failures
Consumer rebalancing
Partition reassignment
Correct answer
Duplicate records during retries
Idempotence ensures that retries caused by network issues do not result in duplicate records being written to the topic. It does not affect data durability or consumer behavior.
Which scenario is a valid use case for Kafka topics?
Storing application logs for analysis
Serving static website content
Replacing a relational database
Executing complex SQL queries
Correct answer
Storing application logs for analysis
Kafka is well-suited for event and log collection due to its high throughput and append-only model. It is not designed as a web server or a direct database replacement.
Which configuration helps reduce data loss during broker failures?
min.insync.replicas
acks=all
replication.factor
all of the above
Correct answer
all of the above
Setting acks=all ensures the producer waits for all in-sync replicas to acknowledge. min.insync.replicas and a suitable replication factor further protect data availability during failures.
What is a topic in Apache Kafka?
A category or feed name to which records are published
A client library for consuming data
A storage engine for relational data
A monitoring dashboard for cluster metrics
Correct answer
A category or feed name to which records are published
A topic is a logical channel for publishing and subscribing to records. Consumers read from topics, and they are not client libraries, databases, or dashboards.
Which mechanism ensures that a Kafka consumer reads each record at most once under failure conditions?
Exactly-once semantics
At-least-once delivery
Producer idempotence
Log compaction
Correct answer
Exactly-once semantics
Exactly-once semantics prevents duplicate processing by combining transactional writes with consumer offset commits within the same transaction.
Recall the answer before opening each card.
To publish records to Kafka topics. Producers send data to topics, while consumers read from them.
The partitioner. It uses the record key or a custom strategy to assign a partition.
Within a single partition. Ordering across partitions is not guaranteed.
retention.ms. It defines the maximum age of a record before deletion.
To allow multiple consumers to share reading a topic by dividing partitions among members.
JSON. It is widely used due to schema compatibility and connector support.
Kafka records the last processed message position. It helps resume consumption after failure.
Brokers store data and serve client requests. They are the core servers managing topics.
To retain the latest value for each key indefinitely, useful for state recovery.
Kafka Streams. It is a library for building applications that process data in motion.
Duplicate records during retries. It ensures exactly-once write semantics per partition.
Yes, due to high throughput and append-only model. It is designed for event streaming.
acks=all, min.insync.replicas, and a suitable replication factor (e.g., 3).
A category or feed name to which records are published. Consumers subscribe to topics.
Exactly-once semantics, combining transactional writes with consumer offset commits.
The producer waits for all in-sync replicas to acknowledge, minimizing data loss.
It uses the record key (hash) or a custom logic. If no key, round-robin is used.
Some consumers become idle since partitions are assigned exclusively to active consumers.
Delete, based on retention.ms or retention.bytes. Compaction must be explicitly set.
It prevents duplicate records due to retries, ensuring exactly-once semantics per partition.
Read the prompt, commit to an answer, then flip the card. Move through the deck at your own pace and repeat any topic that does not come back quickly.
Card 1 of 20
1 reviewed this session
Connect the concepts
Open a branch to connect a topic with its practice questions and explanations. Use the map to choose your next review topic.
This is an analysis of the practice bank, not a claim about the vendor's live exam blueprint. Use it to identify the knowledge, judgment, and recall patterns exercised here, then verify your coverage against the current official exam guide.
This section covers fundamental roles and APIs in Kafka. The producer API publishes records to topics, while the consumer API reads records, often within consumer groups for parallel processing. Consumer groups allow multiple consumers to share topic reading by assigning partitions to members. Offset commits record the last processed position, enabling fault tolerance. Understanding these roles is essential for building event-driven applications. The practice bank includes questions on producer purpose, consumer groups, and offset commit behavior.
Kafka partitions data across brokers for scalability. The partitioner uses the record key or a custom strategy to determine the target partition. Ordering is guaranteed only within a single partition; across partitions, order is not preserved. This is a critical design consideration for applications that require strict sequencing. The practice bank includes a question on ordering guarantees and another on the partitioner's role, reinforcing that keys influence partitioning and that within-partition order is maintained.
Kafka provides configurations to minimize data loss during failures. The producer's acks=all ensures all in-sync replicas acknowledge writes. The broker setting min.insync.replicas defines the minimum replicas that must be available. A suitable replication factor (e.g., 3) further protects data. The practice bank includes a question on reducing data loss during broker failures, where 'all of the above' is correct, covering acks, min.insync.replicas, and replication factor. Retention policies (retention.ms) control data lifecycle, while log compaction retains the latest value per key.
Kafka Streams enables real-time stream processing with low latency, distinct from connectors or replication tools. Idempotence prevents duplicate records during producer retries by assigning a unique producer ID and sequence numbers. Exactly-once semantics combine idempotent producers with transactional writes to ensure each record is processed exactly once, even under failures. The practice bank includes questions on idempotence, exactly-once semantics, and identifying Kafka Streams as the stream processing tool. These concepts are crucial for building reliable streaming applications.
Study workflow
To enable idempotence, set 'enable.idempotence=true' in the producer configuration. This ensures no duplicate records are written during retries, even if the broker fails. Combine with 'acks=all' for stronger guarantees. Idempotence is a prerequisite for exactly-once semantics.
Configure 'retention.ms' on a topic to control how long records are retained (e.g., 604800000 for 7 days). Use 'retention.bytes' for size-based retention. For log compaction, set 'cleanup.policy=compact' instead of 'delete'. Compaction retains the latest value per key indefinitely.
Use the 'enable.auto.commit' property (default true) to periodically commit offsets automatically. For manual control, set it to false and call 'commitSync()' or 'commitAsync()' after processing. Commit offsets after successful processing to avoid reprocessing on failure.
To enable log compaction, set 'cleanup.policy=compact' on the topic configuration. For a topic that requires both compaction and deletion, use 'compact,delete'. Compaction is useful for state stores or restoring state after failure, ensuring only the latest value per key is retained.
For exactly-once producer, set 'enable.idempotence=true' and 'transactional.id' to a unique string. Use 'initTransactions()', 'beginTransaction()', 'sendOffsetsToTransaction()', and 'commitTransaction()' in the producer. For consumers, set 'isolation.level=read_committed' to read only committed records.
FAQ
Clear boundaries on what the bank covers, how to use it, and where official vendor information still matters.
The partitioner determines which partition a record is sent to. By default, it uses the record key hash if provided, or a round-robin strategy if no key. Custom partitioners can be implemented for advanced routing. The partitioner directly affects ordering and load distribution.
Time-based retention (retention.ms) deletes records older than a threshold. Log compaction (cleanup.policy=compact) retains the most recent value for each key, deleting older versions. Compaction is ideal for state restoration, while time-based retention manages storage for event logs.
Set 'enable.idempotence=true' and provide a unique 'transactional.id'. The producer must use transactional APIs: initTransactions(), beginTransaction(), sendOffsetsToTransaction(), and commitTransaction(). This ensures no duplicates and atomic commits across multiple partitions.
Kafka achieves parallelism by distributing partitions across brokers. Each partition is an ordered, immutable sequence of records. Across partitions, records from different producers or keys are interleaved; ordering is not preserved. Applications needing strict global order must use a single partition, reducing throughput.
The 'acks' property specifies how many partition replicas must acknowledge a write before the producer considers it successful. 'acks=0' (no acknowledgment), 'acks=1' (leader only), 'acks=all' (all in-sync replicas). Higher acks reduce the chance of data loss but increase latency.
Browse another free bank or use the study strategy guide to turn your misses into spaced review.
