Confluent CCAAK Confluent Certified Administrator for Apache Kafka Exam Practice Test

To support gradual migration to SSL, Kafka supports configuring multiple listeners. You can run both a PLAINTEXT listener (for legacy clients) and an SSL listener (for new clients), allowing dual access.

From Kafka documentation:

“You can configure multiple listeners on a broker with different security protocols. This allows rolling out SSL while supporting legacy connections.”

A → Incorrect: Modifying the current listener breaks current clients.

B → Misleading: Changing advertised listeners affects how clients connect, which breaks backward compatibility.

C → Correct: Dual listeners allow phased SSL migration.

D → SSL must be configured on both ends to be effective.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 10, p. 305

Apache Kafka Documentation: Configuring Multiple Listeners

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

Kafka follows a specific sequence for evaluating permissions:

If a user is listed as a Super User → Access granted.

Otherwise, Kafka checks if there's an explicit Allow ACL → Grants access.

If not allowed, it checks for an explicit Deny ACL → Denies access.

If no ACL matches → Denied by default.

From Apache Kafka documentation:

“The evaluation order is: Superuser → Allow ACL → Deny ACL → Default deny.”

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 9, p. 286

Apache Kafka Documentation: “Kafka Authorization – Evaluation Order”

The Kafka REST Proxy, provided as part of Confluent Platform, allows clients to interact with Kafka over REST APIs. When securing communication between REST Proxy and REST clients, it uses TLS (HTTPS).

As per the official Confluent documentation for REST Proxy security:

“The REST Proxy supports HTTPS to encrypt communication between REST clients and the REST Proxy.”

TLS/SSL encryption ensures that data in transit is secure and private.

Other options listed, such as MD5 (a hashing algorithm), SCRAM (an authentication mechanism), and Kerberos (an authentication protocol), do not provide direct encryption of the communication channel itself for REST Proxy. They can be part of broader security configurations (e.g., SCRAM for Kafka brokers, Kerberos for SASL authentication), butTLS (HTTPS)is the explicit mechanism for encrypting data between the REST Proxy and its clients.

Page Reference:

Confluent Kafka: The Definitive Guide, 1st Edition, Chapter 9 (“Kafka Security”), Section “REST Proxy Security” (p. 288–289).

Confluent Platform REST Proxy Documentation, “Encryption (HTTPS)”.

Let’s break it down step by step using official Kafka architecture principles:

Total partitions: 10

Each partition stores: 25 GB per day

Total data for the topic per day (no replication): 10 partitions × 25 GB = 250 GB

Replication factor: 3 → three copies of each partition across the brokers

Each partition is replicated across three brokers. Since the replication factor is three, each broker will have one full replica of one-third of the partitions. In a balanced cluster with three brokers:

Each broker stores a replica of every partition (since replication factor = number of brokers).

So, each broker will store the full 250 GB of data for that topic.

Hence:

Each broker will consume: 250 GB

This is confirmed in the official Apache Kafka documentation:

“A replica is a fully-qualified copy of a partition. When the replication factor equals the number of brokers, each broker contains a full copy of the topic data.”

“Each broker stores the total size of data for the topic, regardless of which partitions it leads.”

Page Reference:

Confluent Kafka: The Definitive Guide, 1st Edition, Chapter 6 (Kafka Cluster), p. 209–210.

Apache Kafka Documentation, “Replication” and “Storage” sections.

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

The kafka-consumer-groups.sh script is used to monitor consumer group offsets and lag. It shows the current offset, log end offset, and lag for each partition consumed by a consumer group.

From Kafka documentation:

“You can use kafka-consumer-groups.sh with the --describe flag to get the offset lag per consumer group.”

A → Incorrect: No such built-in script.

B → Correct: Official script for viewing consumer group lag.

C → Incorrect: Does not exist as a built-in Kafka tool.

D → Incorrect: Used for partition reassignment, unrelated to lag monitoring.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 10, p. 308

Apache Kafka Documentation: kafka-consumer-groups.sh usage

To ensure that duplicate messages are not processed and no messages are skipped, ksqlDB’s persistent queries must be configured to provide exactly-once processing guarantees. This is achieved by setting the processing.guarantee property to exactly_once. This configuration ensures that messages are neither lost nor processed more than once in the event of failures or restarts.

As per the official Confluent documentation:

“ksqlDB persistent queries can be configured for either at-least-once or exactly-once processing semantics by setting the processing.guarantee configuration property.”

“When processing.guarantee is set to exactly_once, ksqlDB ensures that messages are processed only once, even in failure scenarios. This eliminates duplicates and guarantees strong message delivery semantics.”

Other options:

Option B and C (ksql.streams.auto.offset.reset) only control the starting offset for new consumers, and do not enforce exactly-once semantics.

Option D (ksql.fail.on.production.error) controls whether errors during message production should fail the query, and does not affect exactly-once processing.

Page Reference:

Confluent Kafka: The Definitive Guide, 1st Edition, Chapter 11 (Stream Processing with ksqlDB), p. 365.

Confluent Documentation, “ksqlDB Configuration Properties” (processing.guarantee).

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

Kafka Connect allows parallelism via tasks. The setting tasks.max=1 limits the connector to a single task, meaning it can only process one table at a time. To increase throughput and reduce lag, the number of tasks should be increased, allowing parallel processing of multiple tables.

From Kafka documentation:

“A single connector can have multiple tasks to maximize parallelism. Increasing tasks.max allows the connector to process more data in parallel.”

A → Increasing Connect nodes won’t help unless more tasks are configured.

B → Correct: Enables parallelism for each table.

C → Unrelated to source connector lag.

D → Increasing replication factor doesn’t improve connector performance.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 8, p. 245–246

Apache Kafka Documentation: Kafka Connect Concepts – tasks.max

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

Kafka uses a pull model for consumers. The consumer polls the broker for available data. This contrasts with push models (used in traditional messaging systems), where the server pushes messages to consumers.

From Kafka documentation:

“Kafka’s consumers use a pull model, where the consumer requests messages from the broker at its own pace.”

A → Incorrect: Kafka does not push messages.

B → Incorrect: Kafka is a publish-subscribe system, but not the model used for message delivery to consumers.

C → Correct: Consumers explicitly pull messages.

D → Invalid in Kafka terminology.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 4, p. 126

Apache Kafka Documentation: Consumer Design Overview

Upon detecting a broker failure, the Controller performs leader election among in-sync replicas and updates the new leader and ISR information in ZooKeeper. It then broadcasts this metadata update to all brokers in the cluster.

From Kafka documentation:

“The controller writes the new leader and ISR list to ZooKeeper and informs all brokers so they can update their metadata cache.”

B → Correct: New metadata written to ZooKeeper.

C → Correct: Brokers are updated via metadata propagation.

A → Incorrect: The Controller makes the decision, not ZooKeeper.

D → Incorrect: Producers and consumers learn about changes via brokers, not directly.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 6, p. 190–191

Apache Kafka Documentation: Controller Behavior & ZooKeeper Interactions

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

Confluent Schema Registry supports the following schema types for use with Kafka:

Avro

Protobuf

JSON Schema

These schemas are officially supported for subject versioning, compatibility checks, and REST interface integration.

From Confluent documentation:

“The Confluent Schema Registry supports Avro, JSON Schema, and Protobuf formats.”

Incorrect Options:

gRPC is not supported as a schema format.

Thrift is not supported in Schema Registry.

Page Reference:

Confluent Kafka: The Definitive Guide, 1st Edition, Chapter 7, p. 208–210

Confluent Schema Registry Documentation: Overview Section (Schema Types)

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

In Kafka Connect, sink connectors consume data from Kafka topics and send it to external systems (e.g., databases, object storage, search indexes).

From Kafka documentation:

“Sink connectors receive data from Kafka topics and write it to external systems.”

A → Correct: Moves data out of Kafka.

B → Moves data into Kafka.

C → Not a connector type.

D → Not a standard connector classification.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 8, p. 241

Apache Kafka Documentation: Kafka Connect – Sink Connectors

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

Kafka Replicator does not preserve source cluster offsets. Offsets in the destination DR cluster are generated independently, and there is no guarantee they match those from the source cluster.

From Confluent Replicator documentation:

“Replicator does not guarantee preservation of message offsets between source and destination. Offsets in the destination cluster are newly assigned.”

C → Correct: Offsets may differ even for the same data.

A → Incorrect: Lag is not the issue if offsets inherently differ.

B → Misleading: Kafka does not overwrite committed messages.

D → Invalid: Kafka messages are immutable; no "update" happens.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 10, p. 313

Confluent Replicator Documentation: “Offset Mapping and Limitations”

Kafka architecture maintains exactly one active Controller at any given time, regardless of the number of brokers. The Controller is responsible for administrative tasks like partition leader election and topic creation. The remaining brokers are replicas, ready to take over if the Controller fails.

From Kafka documentation:

“At any given time, there is only one active controller in the Kafka cluster.”

Even in a cluster with 4 brokers, only 1 broker acts as the Controller.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 6, p. 189

Apache Kafka Documentation: Controller Role Description

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

In Kafka, the Controller is responsible for managing partition leadership. When a broker that was leader for certain partitions goes down, the Controller immediately detects the failure and:

Triggers a new leader election among the in-sync replicas (ISRs) of those partitions.

Updates the partition metadata to reflect the new leaders and notifies the cluster.

Kafka documentation states:

“When a broker fails, the controller triggers a leader election for all partitions previously led by the failed broker.”

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 6, p. 190–191

Apache Kafka Documentation: “Kafka Controller and Leader Election”

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

Kafka’s default authorizer implementation is the SimpleAclAuthorizer, which stores ACLs in ZooKeeper and reads them on each access.

From Kafka documentation:

“Apache Kafka includes an out-of-the-box authorizer implementation that stores ACLs in ZooKeeper.”

A → RBAC is Confluent-specific and not stored in ZooKeeper.

B → Correct: Built-in ACL mechanism uses ZooKeeper.

C → Ranger is an external plugin, not bundled with Apache Kafka.

D → LDAP is used for authentication, not authorization.

Page Reference:

Kafka: The Definitive Guide, 1st Edition, Chapter 9, p. 285

Apache Kafka Documentation: ACLs and Authorizers

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

In Kafka, a partition is a fundamental unit of parallelism and storage. Each topic in Kafka consists of one or more partitions, which are ordered, immutable sequences of records. Importantly, partitions themselves are broken down into segments on the disk. According to the official Kafka documentation:

“A partition is made up of one or more segment files on disk. Each segment is a continuous sequence of messages and each segment file is named after the offset of the first message it contains.”(Apache Kafka Documentation, "Log Basics" section).

Each partition resides in its own directory under the log.dirs configuration on the broker. The documentation states:“The log for each topic partition is stored in its own directory under the log.dirs configuration.”

Given these official clarifications:

Option A is incorrectbecause a partition is not represented by a single segment; rather, it can have multiple segments (as log segments are created to manage file sizes and facilitate compaction or deletion).

Option B is correctas it accurately states that a partition consists of multiple segments.

Option C is correctas all segments for a partition reside in a single directory.

Option D is incorrectbecause partition size is determined by the sum of all its segments, not just the largest one.