Free CCAAK Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The Confluent REST Proxy exposes an HTTP API for clients to interact with a Kafka cluster. To secure the communication channel between a REST client and the REST Proxy server, the standard web security protocol, Transport Layer Security (TLS), is used. This encrypts the HTTP traffic, resulting in HTTPS. Configuring HTTPS on the REST Proxy ensures that all data in transit between the client and the proxy is encrypted, providing confidentiality and integrity. This is the primary and standard method for securing this specific communication link.

B. MD5: This is a cryptographic hash function used for verifying data integrity, not a protocol for securing a communication channel.

C. SCRAM: This is a SASL (Simple Authentication and Security Layer) mechanism used for authenticating clients to Kafka brokers. The REST Proxy itself may use SCRAM to authenticate to the brokers, but this is not used for the REST client-to-proxy connection.

D. Kerberos: This is a network authentication protocol, also typically used via SASL for authenticating components within the Kafka ecosystem (e.g., REST Proxy to brokers), not for encrypting the transport layer between a standard REST client and the proxy's HTTP endpoint.

1. Confluent Documentation, "REST Proxy Security": In the section "Encrypt traffic between REST clients and the REST Proxy," the documentation explicitly states: "To encrypt traffic between REST clients and the REST Proxy, configure HTTPS for the REST Proxy. To enable HTTPS for the REST Proxy, set the listeners configuration property to use HTTPS..." This directly confirms that TLS (HTTPS) is the supported method.

Source: Confluent Documentation, REST Proxy Security, Section: "Encrypt traffic between REST clients and the REST Proxy".

2. Confluent Documentation, "REST Proxy Configuration Options": The configuration options for the REST Proxy include a suite of ssl. properties such as ssl.keystore.location, ssl.keystore.password, and ssl.key.password. These properties are standard for configuring TLS/SSL on a Java-based server, which is necessary to enable HTTPS.

Source: Confluent Documentation, REST Proxy Configuration Options, Section: "SSL".

Kafka brokers in a ZooKeeper-based cluster maintain an active session with the ZooKeeper ensemble by sending regular heartbeats. A long "stop-the-world" JVM garbage collection (GC) pause can prevent a broker from sending these heartbeats. If the duration of the GC pause exceeds the configured ZooKeeper session timeout (zookeeper.session.timeout.ms), ZooKeeper will assume the broker has failed. It will close the session and remove the broker's ephemeral znode, signaling to the rest of the cluster (specifically the controller) that the broker is dead. This initiates leader re-elections for partitions hosted on that broker.

A. The log cleaner thread is triggered based on log size and time configurations for compacted topics, not by a GC pause. A long pause would halt this thread, not trigger it.

C. While clients will experience backpressure because the broker is unresponsive, this is a secondary effect. The primary, cluster-level event is the failure detection by ZooKeeper.

D. Loading log files into the page cache is a standard operating system memory management function related to file I/O, which would be suspended during a GC pause.

1. Confluent Documentation, Broker Configurations: The documentation for zookeeper.session.timeout.ms explains its function: "Zookeeper session timeout. If the broker fails to heartbeat to Zookeeper for this period of time it is considered dead." A long GC pause directly causes this failure to heartbeat.

Source: Confluent Documentation, "Broker Configurations", section on zookeeper.session.timeout.ms.

2. Shapira, G., Narkhede, N., & Palino, T. (2021). Kafka: The Definitive Guide (2nd ed.). O'Reilly Media, Inc.

Reference: In Chapter 8, "Reliability," the section "Cluster Membership" details how brokers use ZooKeeper sessions to maintain their status in the cluster. It explicitly mentions that "long garbage-collection pauses" are a common reason for a broker's session to time out, causing ZooKeeper to declare it dead.

3. Confluent Developer, "Apache Kafka and Garbage Collection":

Reference: This official resource explains the impact of GC on Kafka brokers: "A long GC pause can cause a broker to miss its heartbeat to ZooKeeper, which will cause ZooKeeper to declare the broker as dead. This will in turn cause all the leaders on the dead broker to be moved to other replicas." This directly confirms that a long GC pause leads to the broker being considered dead by ZooKeeper.

The core principle to avoid a single point of failure for data in Kafka is replication. The topic's replication-factor determines how many copies of each partition's data are stored across different brokers in the cluster. Setting the replication factor to 3 (a common best practice) ensures that for each partition, there is one leader and two follower replicas on three separate brokers. If one broker fails, the data remains available on the other two, and a new leader can be elected from the in-sync followers, thus preventing data loss and service interruption.

A. Setting min.insync.replicas to 1 weakens durability. It allows a producer's write to be considered successful after only the leader broker has received it, risking data loss if that broker fails before replication occurs.

B. Partitions are for parallelism and scaling, not fault tolerance. A topic with many partitions but a replication factor of 1 still has a single point of failure for the data in each partition.

C. linger.ms is a producer-side configuration that controls batching to optimize throughput. It has no impact on how data is stored on the brokers for fault tolerance.

1. Confluent Documentation, "Kafka Topics": "Replication is at the core of Kafka's fault tolerance. The replication factor specifies how many copies of the data are made... For a replication factor of N, Kafka can tolerate up to N-1 server failures without losing any committed messages. A typical replication factor is 3."

Source: Confluent Documentation, "Manage Topics" section.

2. Apache Kafka Documentation, "3.4 Replication": "Replication is at the heart of Kafka's fault-tolerance... We recommend using a replication factor of 3, which allows for tolerating 2 broker failures."

Source: Apache Kafka 3.7 Documentation, Section 3.4 "Replication".

3. Confluent Documentation, "Producer Configs": The documentation for min.insync.replicas states, "When set to 1, the producer will get an acknowledgement as soon as the leader has written the message to its local log." This highlights the risk associated with this setting, which contradicts the goal of high availability.

Source: Confluent Documentation, "Producer Configuration Settings".

The requirement to prevent both duplicate message processing and skipping messages is the definition of exactly-once processing semantics. In ksqlDB, which is built on Kafka Streams, this guarantee is enabled by setting the processing.guarantee property to exactlyonce. This configuration ensures that each input record is processed once and only once, even in the event of failures, by leveraging Kafka's transactional capabilities to atomically write output records and commit consumer offsets.

B. ksql.streams auto offset.reset=earliest: This property only defines where a consumer starts reading from a topic partition when no committed offset exists. It does not guarantee exactly-once processing during ongoing operations.

C. ksql.streams auto.offset.reset=latest: This setting would cause the consumer to start at the end of the log, explicitly skipping messages that arrived while the application was down, directly violating the requirement.

D. ksql.fail.on.production.error=false: This property (or its equivalent) controls error handling when writing to an output topic. Setting it to false would cause the application to continue on production errors, potentially skipping messages that failed to be written.

1. Confluent Documentation, "ksqlDB Configuration Parameter Reference": This document lists the server configuration parameters. The ksql.streams.processing.guarantee property is described as controlling the processing semantics.

Reference: Confluent Documentation > ksqlDB > Reference > Configuration Parameter Reference > ksql.streams.processing.guarantee. It states, "The processing guarantee that should be used. Possible values are atleastonce (default) and exactlyonce."

2. Confluent Documentation, "Process events with exactly-once semantics": This guide explains the concept and implementation of exactly-once in ksqlDB.

Reference: Confluent Documentation > ksqlDB > Develop > Process events with exactly-once semantics. It explicitly states: "To get exactly-once processing, you must set the processing.guarantee property in your ksqlDB server properties file to exactlyonce."

3. Apache Kafka Documentation, "Kafka Streams Configs": As ksqlDB uses Kafka Streams, the underlying stream configuration is relevant.

Reference: Apache Kafka Documentation > Kafka Streams > Developer Guide > Kafka Streams Configs > processing.guarantee. The documentation details that setting this to exactlyonce enables the exactly-once guarantee.

Kafka brokers can be configured with multiple listeners, each bound to a different network interface and port. This allows for the separation of traffic types. Each listener can be assigned a distinct security protocol using the listener.security.protocol.map configuration property. For instance, an "INTERNAL" listener can be configured for inter-broker communication using PLAINTEXT within a secure network, while an "EXTERNAL" listener can be configured with SASLSSL for authenticated and encrypted client connections from outside the network. The inter.broker.listener.name property specifies which listener the brokers should use for their internal communication, completing the separation.

A. Configure multiple brokers.

Configuring multiple brokers is for scalability and fault tolerance, not for differentiating authentication mechanisms for internal and external traffic on a single broker.

C. Configure multiple security protocols on the same listener.

A single Kafka listener can only be configured with one security protocol (e.g., PLAINTEXT, SSL, SASLSSL). It cannot support multiple protocols simultaneously.

D. Configure LoadBalancer.

A load balancer distributes client traffic across brokers but does not configure the authentication methods on the brokers themselves. Authentication is a broker-level setting.

1. Confluent Documentation, "Configure Kafka Brokers": This document details the key configuration properties.

listeners: "A comma-separated list of listeners and the host/IP and port to which Kafka binds to for listening."

listener.security.protocol.map: "A map of listener names to security protocols... If you are using a different security protocol for inter-broker and client communication, you must define this property."

inter.broker.listener.name: "Name of the listener used for communication between brokers."

Source: Confluent Platform Documentation, Self-Managed Configuration, "Configure Kafka Brokers", Section on Networking.

2. Apache Kafka Documentation, "Security": The official Kafka documentation explains how listeners work in the context of security.

"It is common to configure several listeners on a broker... For example, an operator may configure a PLAINTEXT listener for traffic originating from the same datacenter and a SSL listener for traffic from outside."

Source: Apache Kafka Documentation, Version 3.7, Section 7.1 "Security".

3. KIP-103: Separation of Internal and External traffic: This Kafka Improvement Proposal is the official design document that introduced the functionality.

"This KIP proposes adding the ability to configure multiple listeners with different security protocols on a single broker and designating one of the listeners for inter-broker communication."

Source: Apache Kafka Confluence, KIP-103: Separation of Internal and External traffic.

Each Kafka partition is mapped to a directory on the broker's filesystem, which contains log and index files. The broker must maintain open file handles for these files, particularly for active log segments being written to or read from. A significant increase in the total number of partitions on a broker directly increases the number of required file handles. If this number exceeds the operating system's configured limit for open files (often managed by ulimit), the broker can fail with "Too many open files" errors, leading to instability. Therefore, verifying this system-level limit is a critical prerequisite before scaling partitions.

A. Producer batch and buffer sizes are client-side configurations that affect performance and memory usage on the producer, not the broker's ability to host partitions.

B. Compression is a data-level optimization that reduces network and disk utilization; it does not impact the number of file handles a broker requires for its partitions.

D. The acks=all setting is a producer configuration that governs write durability and latency; it is unrelated to broker resource limits like file handle capacity.

1. Confluent Documentation, Apache Kafka > Operations > Running Kafka in Production: In the "File Descriptors and mmap" section, it states, "A Kafka broker uses a large number of open file handles... If you have a large number of partitions in a broker, the file descriptor limit will be hit. We recommend at least 100,000 allowed open file descriptors for the Kafka process." This directly links the number of partitions to the file descriptor limit.

2. Confluent Documentation, Apache Kafka > Design Details > Persistence: This section explains the on-disk format: "The data log for a partition is split into a set of segment files... The broker keeps an index that maps from an offset to a position in the segment file." This architectural detail clarifies why each partition requires multiple files, thus consuming file handles.

3. Kreps, J., Narkhede, N., & Rao, J. (2011). Kafka: A Distributed Messaging System for Log Processing. Proceedings of the NetDB, 1-7. While not a Confluent document, this foundational academic paper on Kafka's design describes the log-structured storage where each partition is a "log," which is implemented as a set of files on disk, reinforcing the link between partitions and file system resources. (Section 2.2, "Persistence and Caching").

Kafka Connect, when running in distributed mode, relies on three internal Kafka topics to share connector configurations, task statuses, and offset data among its worker processes. These topics are essential for fault tolerance and scalability. The default names for these topics are connect-configs (for storing connector and task configurations), connect-status (for storing connector and task state updates), and connect-offsets (for storing source connector offsets). Option A contains a common typo ("confiqs" instead of "configs"), but it clearly refers to the configuration storage topic.

B. connect-distributed: This refers to the distributed mode of operation for Kafka Connect workers, not an internal topic name.

D. connect-standalone: This refers to the standalone mode of operation for a single Kafka Connect worker, not an internal topic name.

1. Confluent Documentation, Kafka Connect, Configuration Properties: The official documentation lists the worker configuration properties that define the names of these internal topics.

config.storage.topic: "The name of the topic where connector and task configuration data are stored." The default value is connect-configs.

offset.storage.topic: "The name of the topic where connector offsets are stored." The default value is connect-offsets.

status.storage.topic: "The name of the topic where connector and task status data are stored." The default value is connect-status.

Source Reference: Confluent Documentation, "Worker Configuration Properties for Kafka Connect", Section: "Distributed Worker Configuration".

2. Apache Kafka Documentation, Kafka Connect 3.7: The official Apache Kafka documentation corroborates these configuration properties and their purpose for distributed workers.

Source Reference: Apache Kafka Documentation, Section 8.2 "Connect Configuration". The properties config.storage.topic, offset.storage.topic, and status.storage.topic are detailed for the distributed worker (connect-distributed.properties).

The output Leader: -1 for a partition signifies that there is currently no active leader. This happens when the broker that was the leader becomes unavailable, and no other in-sync replica can be elected to take its place. In this specific case, the output for Topic: t2 Partition: 1 shows Replicas: 1. This indicates that Broker 1 is the only broker assigned to hold a replica for this partition. Therefore, if Broker 1 fails or becomes unreachable, the partition has no available replicas, the controller cannot elect a new leader, and the leader ID is set to -1 to indicate its unavailability.

B. Log cleaning is a background process for compacted topics and does not cause a partition to lose its leader or become unavailable.

C. Data compression is a configuration that affects the size of messages but has no impact on broker availability or the leader election process.

D. Kafka's architecture for identifying partitions (by topic name and partition index) prevents naming clashes; this is not a recognized failure mode.

1. Kafka: The Definitive Guide, 2nd Edition by Narkhede, N., Shapira, G., & Palino, T. (O'Reilly Media, 2021).

Chapter 6, Reliability, "Replication" section: Explains that if a broker containing the only replica of a partition fails, that partition becomes unavailable. The controller cannot elect a new leader because no other replicas exist. This state is reflected by a leader ID of -1.

2. Apache Kafka Official Documentation, Section 8.2 Replication:

"The leader for a partition is one of the brokers... If the leader broker fails, one of the follower brokers will become the new leader." This documentation establishes the direct link between broker failure and leader re-election. In a scenario with a replication factor of 1 (Replicas: 1), the failure of the single broker means there are no followers to become the new leader.

3. Confluent Documentation, "Unbalanced Kafka Clusters":

In discussions about cluster health, a partition with no leader (-1) is a critical indicator of a problem, most commonly an offline broker that is the sole member of that partition's replica set. The documentation on monitoring and balancing frequently cites offline brokers as the cause for partitions lacking a leader.

Continuous event stream processing is designed for use cases that require immediate analysis and action on data as it is generated. Fraud detection (A) must analyze transaction patterns in real-time to block malicious activity instantly. Context-aware recommendations (B) leverage a user's live clickstream data to provide relevant suggestions on-the-fly, enhancing user experience. Log monitoring and fault detection (D) continuously ingests and analyzes logs and metrics from distributed systems to identify and alert on anomalies or errors as they occur, enabling rapid response. These applications are inherently event-driven and depend on low-latency, continuous data processing to be effective.

C. End-of-day financial settlement processing: This is a quintessential batch processing workload, operating on a finite set of data at a scheduled time, not a continuous, unbounded stream.

E. Historical dashboards: These typically run analytical queries against data stored in a data warehouse or database, representing a batch or ad-hoc query pattern, not real-time stream processing.

1. Confluent Documentation, "Apache Kafka Use Cases": This official resource explicitly lists the correct answers as primary use cases. It states, "Kafka is used for real-time fraud detection," "Real-time recommendations...by capturing and analyzing user behavior in real time," and "Log analysis and monitoring...Kafka can be used to collect and process log data in real time."

Source: Confluent Documentation, "Learn Apache Kafka", Section: "Apache Kafka Use Cases".

2. Narkhede, N., Shapira, G., & Palino, T. (2021). Kafka: The Definitive Guide (2nd ed.). O'Reilly Media. Chapter 1, "Meet Kafka," introduces the core drivers for Kafka's creation and its common applications. It details "Website Activity Tracking" (the basis for recommendations), "Log Aggregation" (for monitoring), and real-time processing of event data, which is fundamental to fraud detection.

Source: Chapter 1, Sections: "Website Activity Tracking" and "Log Aggregation".

3. Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media. Chapter 11, "Stream Processing," contrasts batch processing with stream processing. It describes use cases like "Complex event processing (CEP)," which includes fraud detection and monitoring systems, as prime examples of stream processing where timely responses to event patterns are critical. End-of-day jobs are used as a counterexample of batch processing.

Source: Chapter 11, Section: "Stream Processing", Subsection: "Applications of Stream Processing".

Kafka's security model is designed to be granular and responsive. The broker's authorizer component intercepts every single client request that involves a resource (e.g., a Produce request to a topic, a Fetch request from a topic, or a Describe request for a consumer group). For each of these requests, the authorizer checks the principal's permissions against the currently defined Access Control Lists (ACLs). This per-request authorization ensures that any changes to ACLs, such as revoking a permission, are enforced immediately on the next client operation, providing a robust and real-time security mechanism.

B. Checking only on the initial access would create a significant security vulnerability, as permissions revoked during a client's session would not be enforced.

C. This is incorrect. While Kafka brokers cache ACLs from ZooKeeper/KRaft to improve performance, the authorization check itself is still performed on every request against the cached ACLs, not skipped for an interval.

D. Authorization is performed on a per-operation basis against specific resources (like topics), not just once when a TCP connection is established.

1. Confluent Documentation, "Authorization using ACLs": "For every request from a client to a broker, the broker checks for the appropriate permissions for the authenticated user. The permissions are based on access control lists (ACLs) that are defined for each resource." This statement explicitly confirms that the check is performed for every request.

Source: Confluent Documentation, Security > Authorization > Authorization using ACLs > How Authorization Works in Kafka.

2. Apache Kafka Documentation, "Security - Authorization": The documentation describes the request processing flow where authorization is a distinct step after authentication for each request. It states, "Kafka has a pluggable Authorizer interface... The Authorizer is used by the broker to authorize an action on a resource." The architecture implies this check is part of the processing logic for every API call that requires authorization.

Source: Apache Kafka Documentation, Section 7.3 Authorization.

To allow for a gradual migration from non-secure to secure connections, the Kafka cluster must support both connection types simultaneously. The correct way to achieve this is by configuring multiple listeners on the brokers. By adding a new listener configured for SSL on a different port, the existing PLAINTEXT listener can remain active. This allows existing applications to continue connecting without interruption while new or updated applications can be configured to use the new, secure SSL listener. This approach provides the necessary transition period without causing a service outage for legacy clients.

A. Enable SSL on the current Listener, and do not enable mTLS.

Modifying the existing listener to use SSL would immediately break all current non-SSL client connections, violating the requirement for a gradual migration.

B. Modify the advertised listeners setting on brokers to use SSL.

The advertised.listeners setting tells clients how to connect. Changing this without adding a corresponding SSL listener will cause connection failures and does not enable coexistence.

D. Enable SSL on the current listener, and do not implement SSL on application side.

This is a technically non-functional scenario. If a broker listener requires SSL, a client application cannot connect to it without also being configured for SSL.

1. Confluent Documentation, "Encryption and Authentication with SSL for Apache Kafka": In the "Configuring Kafka Brokers" section, the documentation explicitly states how to configure multiple listeners. It provides an example: listeners=PLAINTEXT://kafka1:9092,SSL://kafka1:9093. The text clarifies, "This allows clients to connect to the broker using either plaintext or SSL," which is the exact requirement for the migration scenario.

Source: Confluent Documentation, Security > Encryption and Authentication with SSL for Apache Kafka > Configuring Kafka Brokers.

2. Apache Kafka Documentation, "Security": Section 3.3, "Configuring Kafka Brokers," describes the listeners configuration property. It specifies that this property is a "comma-separated list of listeners" and provides an example of configuring both PLAINTEXT and SSL listeners on different ports (listeners = PLAINTEXT://:9092,SSL://:9093), confirming this is the standard method for supporting multiple protocols.

Source: Apache Kafka Documentation, Section 3. Security > 3.3 Encryption and Authentication using SSL.

The kafka-consumer-groups.sh command is the standard administrative tool for managing and inspecting consumer groups. When used with the --describe flag, it provides detailed information about a consumer group, including the current offset for each partition, the log-end-offset (the offset of the last message), and the calculated lag. Lag is the difference between the log-end-offset and the consumer's current offset, indicating how far behind the consumer is. This makes it the correct tool for quickly checking consumer lag as requested in the scenario.

A. bin/kafka-consumer-lag.sh: This is not a standard command-line tool provided with Apache Kafka or the Confluent Platform. It does not exist in the official distribution.

C. bin/kafka-consumer-group-throughput.sh: This command does not exist in the standard Apache Kafka or Confluent Platform toolset. Throughput is a different metric from lag.

D. bin/kafka-reassign-partitions.sh: This tool is used for cluster administration, specifically for moving topic partitions between brokers. It is not used for monitoring consumer performance or lag.

1. Confluent Documentation: "kafka-consumer-groups". The documentation explicitly states that the --describe option can be used to "list the topic partitions, current-offset, log-end-offset, and lag for a consumer group."

Source: Confluent Platform Documentation, CLI Tools, kafka-consumer-groups, "Describe a consumer group" section.

2. Apache Kafka Documentation: "Kafka Operations - Consumer Groups". The official Apache Kafka documentation details the usage of kafka-consumer-groups.sh. The "Describing a Consumer Group" section shows an example output with columns for CURRENT-OFFSET, LOG-END-OFFSET, and LAG.

Source: Apache Kafka 3.6 Documentation, Section 4.4 "Consumer Groups".

3. Gwen Shapira, Todd Palino, Rajini Sivaram (2021): Kafka: The Definitive Guide, 2nd Edition. Chapter 11, "Administering Kafka," describes the kafka-consumer-groups.sh script as the primary tool for inspecting consumer group state, including offsets and lag.

Source: O'Reilly Media, ISBN: 978-1098108035, Chapter 11, "Consumer Groups" section.

Apache Kafka provides two primary mechanisms for data retention, configured via the cleanup.policy topic-level setting. The delete policy, which is the default, discards entire log segments after a configured retention period (time-based) or size limit is reached. This is suitable for transient data. The compact policy enables log compaction, which retains at least the last known value for each message key within a partition. This is ideal for use cases requiring a full snapshot of the latest state, such as restoring a database. It is also possible to set the policy to compact,delete to both compact the log and then delete records older than a certain age.

B. default is not a valid value for the cleanup.policy configuration. The policy that is used by default is delete.

D. cleanup is part of the configuration parameter's name (cleanup.policy), not a valid value for the policy itself.

1. Confluent Documentation: In the "Topic-Level Configs" section, the cleanup.policy parameter is defined. It explicitly states, "A string that is either delete, compact, or both (compact,delete). This string designates the retention policy to use on old log segments."

Source: Confluent Documentation, "Server Configuration Properties," Section: cleanup.policy.

2. Apache Kafka Documentation: The official Apache Kafka documentation corroborates this in its "Topic Configs" section. It specifies the valid values for cleanup.policy are "delete, compact".

Source: Apache Kafka Documentation, "3.7 Configuration," Section: "Topic Configs," Parameter: cleanup.policy.

3. Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media. Chapter 11 discusses log-structured storage and messaging systems. It details the concepts of log compaction (as used in Kafka's compact policy) and time-based retention (as used in the delete policy) as fundamental strategies for managing log data.

Source: Chapter 11, "Stream Processing," Section: "Messaging Systems." (Note: While a book, it is a peer-reviewed and highly respected academic-level text in the field).

The setting unclean.leader.election.enable directly addresses the trade-off between availability and data consistency. When a partition leader fails, Kafka normally elects a new leader from the set of in-sync replicas (ISRs). If no ISRs are available, the partition becomes unavailable for writes. By enabling unclean leader election, Kafka is permitted to elect a leader from out-of-sync replicas as a last resort. This keeps the partition available (high availability), but at the cost of potentially losing messages that the new leader had not yet replicated (lower message reliability).

B. An odd number of brokers is a best practice for the fault tolerance of the consensus protocol (ZooKeeper or KRaft controllers), not a direct trade-off between availability and message reliability.

C. linger.ms is a producer configuration that balances latency and throughput by batching records. It does not influence the cluster's availability during a broker failure.

D. retention.ms determines how long messages are stored. Setting it to -1 (infinite retention) enhances data durability but does not impact the system's availability during a leader failure.

1. Apache Kafka Documentation, Broker Configs: The official documentation for the unclean.leader.election.enable parameter states: "Indicates whether to enable replicas that are not in the ISR set to be elected as leader as a last resort, even though doing so may result in data loss." This explicitly describes the trade-off.

Source: Apache Kafka Documentation, Section 3.3 Broker Configs, unclean.leader.election.enable.

2. Confluent Documentation, High Availability: "If all replicas for a partition are unavailable, Kafka by default will wait for a replica to come back online... This default behavior prefers avoiding data loss over availability. This preference can be changed... by setting the broker property unclean.leader.election.enable=true... This trades durability for availability."

Source: Confluent Documentation, "High Availability" section within the Apache Kafka Technical Overview.

3. Designing Event-Driven Systems, by Ben Stopford (O'Reilly, 2018): "There is one final configuration parameter that affects the availability/durability trade-off: unclean.leader.election.enable. If this is set to true, it will allow a nonsynchronized replica to become the leader. This means you will have a leader, but you will have lost data."

Source: Chapter 10, "Building a Reliable System with Kafka," Section on "Durability vs. Availability." (Note: Ben Stopford is a technologist at Confluent).

In any Apache Kafka cluster, there is always exactly one active Controller at any given time. This Controller is one of the brokers, elected through a consensus mechanism (like ZooKeeper or KRaft). Its primary responsibility is to manage the cluster's state, including partition leadership, broker failures, and topic creation/deletion. The number of brokers, topics, partitions, or consumers in the cluster does not alter this fundamental architectural principle of having a single active Controller to ensure consistent metadata management and avoid "split-brain" scenarios.

B. two: A Kafka cluster is designed with a single active controller to prevent conflicting state changes and ensure metadata consistency.

C. three: Having multiple active controllers is not supported by Kafka's architecture as it would lead to an inconsistent and unstable cluster state.

D. Four: While any of the four brokers is eligible to become the controller, only one broker is elected to be active in that role at any time.

1. Confluent Documentation, Apache Kafka® Internals: "One of the brokers in the cluster is designated as the controller. The controller is responsible for electing a leader for each partition." This statement confirms the single-controller design.

Source: Confluent Documentation, "Apache Kafka Internals" section.

2. Kreps, J., Narkhede, N., & Rao, J. (2011). Kafka: A Distributed Messaging System for Log Processing. In Proceedings of the NetDB '11: 6th International Workshop on Networking Meets Databases. "One of the brokers is elected as the 'controller'. This controller detects broker failures and is responsible for electing new leaders for all partitions on the failed broker."

Source: Section 3.2, "Distribution".

3. Narkhede, N., Shapira, G., & Palino, T. (2017). Kafka: The Definitive Guide. O'Reilly Media. "The controller is a broker that has additional responsibilities... At any given time, there is only one controller in a Kafka cluster."

Source: Chapter 6, "Data Delivery", section "Replication".