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 cluster in a data streaming platform?
Understand core streaming concepts and the role of Kafka
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 cluster in a data streaming platform?
To store and stream events in real time
To serve static web content
To manage relational database backups
To compile application source code
Correct answer
To store and stream events in real time
A Kafka cluster is designed to capture, store, and forward streams of records as they occur. This enables real-time data pipelines and event-driven applications.
Which component is responsible for maintaining cluster metadata in Kafka?
The controller broker
The producer client
The consumer group
The schema registry
Correct answer
The controller broker
One broker in the cluster is elected as the controller, which manages and coordinates cluster metadata such as topic configurations and partition assignments.
What does data replication help achieve in a Kafka cluster?
High availability and fault tolerance
Reduced network bandwidth usage
Faster data compilation
Simplified user authentication
Correct answer
High availability and fault tolerance
Replication copies partition leaders across multiple brokers so that data remains available if a broker fails. This is essential for resilient streaming workloads.
Which practice helps secure access to Kafka topics?
Using ACLs to control operations
Disabling all network ports
Removing topic compaction
Increasing producer timeouts
Correct answer
Using ACLs to control operations
Access Control Lists (ACLs) define which users or applications can read, write, or manage specific topics and resources.
What is a common use case for compacted topics?
Storing the latest state of keys
Archiving full message history
Encrypting payloads at rest
Balancing network traffic
Correct answer
Storing the latest state of keys
Compacted topics retain the most recent value for each key, making them suitable for configuration stores or device state tracking.
Which factor most directly affects the throughput of a Kafka cluster?
Number of partitions and producer batching
Length of topic names
Color of broker hostnames
Client library documentation quality
Correct answer
Number of partitions and producer batching
Throughput is influenced by partition count, which enables parallelism, and producer batching, which reduces request overhead.
What is a consumer group in Kafka?
A set of consumers that share the workload of reading a topic
A team of developers managing the cluster
A backup of the broker configuration
A monitoring dashboard for metrics
Correct answer
A set of consumers that share the workload of reading a topic
Each consumer group maintains its own offset per partition, allowing multiple applications to independently process the same stream.
Which configuration helps prevent data loss during broker failures?
Setting a suitable replication factor
Increasing client-side cache size
Using a single availability zone
Disabling log compaction
Correct answer
Setting a suitable replication factor
A replication factor greater than one ensures that copies of data exist on multiple brokers, protecting against node outages.
What does log compaction do in Kafka?
Removes old messages while preserving the latest value per key
Compresses all messages to reduce disk usage
Encrypts logs for compliance
Balances partitions across brokers
Correct answer
Removes old messages while preserving the latest value per key
Compaction retains the most recent message for each key, which is useful for stateful lookups without storing full history indefinitely.
Which metric is most useful for detecting under-replicated partitions?
UnderReplicatedPartitions
ActiveProducers
ConsumerLagMax
DiskReadBytesPerSec
Correct answer
UnderReplicatedPartitions
This metric indicates partitions that do not have the expected number of replicas, which may require administrative attention to restore redundancy.
What is a common cause of increased consumer lag?
Slow processing or insufficient consumer instances
High disk I/O on the broker
Too many partitions
Enabling encryption at rest
Correct answer
Slow processing or insufficient consumer instances
Consumer lag grows when consumers cannot keep up with the rate of incoming messages, often due to processing bottlenecks or inadequate parallelism.
Which action should be taken before scaling the number of partitions?
Evaluate key distribution and workload impact
Disable all producers temporarily
Delete old consumer groups
Reset broker configurations
Correct answer
Evaluate key distribution and workload impact
Increasing partitions affects data distribution and consumer behavior, so planning is necessary to avoid rebalancing issues or uneven loads.
What is a typical symptom of a broker that has lost connectivity?
Rising under-replicated partitions and controller logs
Decreased producer batch size
Lower consumer group cardinality
Reduced topic compaction rate
Correct answer
Rising under-replicated partitions and controller logs
Network or hardware issues can isolate a broker, leading to under-replicated partitions and controller re-elections.
Which strategy helps maintain orderly failover in a Kafka cluster?
Ensuring multiple in-sync replicas
Using a single network switch
Limiting topic count
Disabling quotas
Correct answer
Ensuring multiple in-sync replicas
Having multiple in-sync replicas allows leadership to transfer smoothly when a broker becomes unavailable, minimizing disruption.
What is a best practice for managing Kafka configurations?
Document changes and test in a non-production environment
Apply identical settings to all clusters without review
Modify broker configs directly on all nodes at once
Avoid version control for configuration files
Correct answer
Document changes and test in a non-production environment
Controlled, documented changes with validation in staging reduce the risk of unintended behavior in production streaming workloads.
Recall the answer before opening each card.
To capture, store, and forward events in real time, enabling data pipelines and event‑driven applications.
The controller broker, which is elected from the cluster to manage topic configs, partition assignments, and ISRs.
High availability and fault tolerance by copying partition leaders across multiple brokers.
Use ACLs to control which users or applications can read, write, or manage specific topics.
For storing the latest state per key, such as configuration stores or device state tracking.
Number of partitions (parallelism) and producer batching (reduces request overhead).
A set of consumers that share the workload of reading a topic; each group maintains independent offsets per partition.
A replication factor greater than one, which copies data to multiple brokers.
Removes old messages while preserving the latest value for each key.
UnderReplicatedPartitions, indicating partitions with fewer in‑sync replicas than expected.
Slow processing or too few consumer instances, causing consumers to fall behind the produce rate.
Key distribution and workload impact to avoid rebalancing issues or uneven load.
Rising under‑replicated partitions and controller logs indicating leader re‑elections.
Ensuring multiple in‑sync replicas (ISRs) so leadership can transfer smoothly.
Document changes and test in a non‑production environment before applying to production.
To specify how many copies of each partition are kept, providing redundancy against broker failures.
By configuring batch.size and linger.ms to accumulate more messages per request, reducing network overhead.
It detects the failure and reassigns partition leadership to in‑sync replicas, triggering re‑elections if needed.
To detect if consumers cannot keep up; persistent lag can lead to data staleness or eventual offset expiry.
An Access Control List that grants or denies specific operations (e.g., READ, WRITE) on resources like topics to principals.
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.
A Kafka cluster relies on one elected controller broker to manage cluster metadata such as topic configurations and partition assignments. Understanding the controller’s role helps you diagnose coordination failures and rebalancing delays. The practice bank highlights that the controller is responsible for maintaining this metadata, not ZooKeeper or a separate service. In Confluent Cloud, this internal election process is automated but requires monitoring for stability.
Replication is the cornerstone of fault tolerance in Kafka. By setting a suitable replication factor (≥2), you ensure that partition leaders have in‑sync replicas on other brokers. This allows seamless leader failover when a broker fails. The practice questions emphasize that multiple in‑sync replicas (ISRs) are required for orderly failover, and that under‑replicated partitions signal redundancy loss. Compacted topics also contribute to durability by retaining the latest value per key for stateful workloads.
Throughput is most directly affected by the number of partitions and producer batching. More partitions increase parallelism, while batching reduces network overhead. The practice bank also links consumer lag to slow processing or insufficient consumer instances—a key monitoring concern. Operators must evaluate key distribution before scaling partitions to avoid uneven load and rebalancing storms. Monitoring UnderReplicatedPartitions and consumer lag metrics helps detect performance bottlenecks early.
Access to Kafka topics is secured using ACLs (Access Control Lists), which define allowed operations per user or application. For configuration management, the practice bank advises documenting changes and testing in a non‑production environment to prevent unintended behavior. Monitoring for broker connectivity loss is done via under‑replicated partitions and controller logs. These practices ensure that streaming workloads remain secure, stable, and auditable.
Study workflow
Start by checking the UnderReplicatedPartitions metric for each broker. If any partitions show under‑replication, identify the missing replicas and verify network connectivity or broker health. Ensure the replication factor is at least 2 for critical topics to maintain fault tolerance.
Define ACLs for each principal that needs access. Use the kafka-acls.sh tool or Confluent Cloud CLI to grant specific operations (READ, WRITE, DESCRIBE) on targeted topics. Restrict admin operations to a minimal set of users to follow least privilege.
Adjust producer batch.size (e.g., 65536) and linger.ms (e.g., 5–10) to increase batching. Monitor producer throughput and request latency. If partitions are few, consider increasing partition count after evaluating key distribution to avoid hot spots.
Set up alerts on consumer group lag metrics. If lag grows, add more consumer instances in the same group to increase parallelism, or optimize processing logic. Ensure consumers commit offsets frequently but not excessively to balance fault tolerance and performance.
Before adding partitions to a topic, analyze the key distribution to ensure an even split. Use tools like kafka-reassign-partitions.sh to redistribute data if needed. Communicate changes to downstream consumers to update their assignment strategies.
FAQ
Clear boundaries on what the bank covers, how to use it, and where official vendor information still matters.
The controller broker is a single broker elected from the cluster to manage cluster metadata, including topic configurations, partition leaders, and ISR lists. It ensures consistent state across brokers. If the controller fails, a new one is elected, which can briefly disrupt cluster operations until metadata is re‑established.
Log compaction retains the most recent message for each unique key, while deletion removes messages older than a retention threshold. Compaction is ideal for stateful stores (e.g., configurations) where only the latest value matters, whereas deletion is used for time‑sensitive event streams.
Key metrics include UnderReplicatedPartitions, which shows partitions missing expected replicas, and controller logs that record leader re‑elections. A sudden rise in these metrics often indicates a broker is unreachable. Also watch network metrics and request latency for early signs.
Production Kafka clusters handle critical data streams. A misconfiguration can cause data loss, performance degradation, or availability issues. Testing in staging validates the change’s impact on throughput, replication, and consumer behavior, reducing the risk of incidents in production.
ACLs (Access Control Lists) define granular permissions for principals (users or applications) on resources like topics, consumer groups, and clusters. For example, you can allow a service account only WRITE on a specific topic. Confluent Cloud enforces these rules at the broker level, blocking unauthorized operations.
Browse another free bank or use the study strategy guide to turn your misses into spaced review.
