Which command sets a one-day retention on the existing orders topic?

kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name orders --add-config retention.ms=86400000. Topic-level overrides are changed with kafka-configs.sh using --entity-type topics, the topic name, and --add-config. Using --entity-type brokers targets broker configurations, so the orders topic would not change; kafka-topics.sh has no --retention flag.

What is the trade-off of setting unclean.leader.election.enable=true?

It favours availability: an out-of-sync replica may become leader, so acknowledged records can be lost. Unclean leader election lets a replica outside the ISR take over when no in-sync replica is available, which restores availability but may drop records that only the old leader had. The default is false, which means waiting for an in-sync replica, and that is the durability-first behaviour the second option describes.

Which acks setting makes the leader wait for the full set of in-sync replicas to acknowledge a record before responding?

acks=all. acks=all makes the leader wait until every current in-sync replica has the record, giving the strongest durability. acks=1 only waits for the leader's own write, and acks=quorum is not a valid value.

All members of a consumer group run Kafka 3.x clients with the default partition.assignment.strategy. What is the documented way to move this group to cooperative rebalancing?

Perform a single rolling bounce that removes RangeAssignor from partition.assignment.strategy. The default partition.assignment.strategy is [RangeAssignor, CooperativeStickyAssignor]; it uses Range at first but is designed so that one rolling bounce removing RangeAssignor switches the group to the cooperative assignor. A full stop is unnecessary, and classic-cooperative is not a real setting.

A consumer authenticates successfully and has READ on the invoices topic, but fails with GroupAuthorizationException: Not authorized to access group: reporting. Which additional ACL is most likely missing?

READ on the consumer group resource named reporting. Consuming as part of a group needs READ on the topic and READ on the group, and the GroupAuthorizationException points directly at the group. WRITE on the topic is for producing, so it would not fix a consumer's group authorization error.

How does Kafka Streams make a persistent state store fault tolerant by default?

It writes every update to a compacted changelog topic and restores the store from it after a failure. Persistent stores (RocksDB by default) are backed by a compacted changelog topic in Kafka, and a task that moves to another instance rebuilds its store by replaying that changelog. The RocksDB files stay local to the application; brokers never hold them.

What is the difference between source and sink connectors?

Source connectors bring data from external systems into Kafka; sink connectors deliver Kafka data to external systems. The direction of the data defines the connector type: sources bring data into Kafka topics, and sinks deliver data from topics to systems such as databases or search indexes. Both run in Kafka Connect workers, which are separate from the brokers.

A JDBC source connector is configured with tasks.max=10 to copy three tables. The status endpoint shows only three tasks. Why does the connector run only three tasks?

tasks.max is only an upper bound; the connector created as many tasks as it could use, one per table. tasks.max is the maximum number of tasks; the connector may create fewer if it cannot divide the work further, and a JDBC source can split work by table. Workers can run many tasks each, so the number of workers does not limit this.

A topology materialises a count into a store named counts-store. How can a test check the contents of a state store after piping records?

Call driver.getKeyValueStore("counts-store") and read values from the returned store. TopologyTestDriver exposes the topology's stores by name through methods such as getKeyValueStore() and getWindowStore(), so tests can assert on state directly. topology.describe() lists the processors and store names but never their contents.

A client in a Docker container bootstraps successfully to kafka:9092, but then logs repeatedly: Connection to node 1 (localhost/127.0.0.1:9092) could not be established. Node may not be available. What does this log pattern most likely indicate?

The broker's advertised.listeners returns an address that is not reachable from the container. Node -1 is the bootstrap connection, which succeeds; the client then connects to the brokers using the addresses they advertise. An advertised localhost:9092 points back at the client container itself, so the connection fails. That is an advertised.listeners problem, not an authentication one.

A compacted topic stores customer profiles. A service deletes customer 42 by producing a record with key 42 and a null value. A new consumer that replays the topic from offset 0 must learn about the deletion. Which setting bounds how long that consumer has to reach the delete marker before it can disappear?

delete.retention.ms, which defaults to one day. A null-value record is a tombstone, and tombstones are themselves removed once they are older than delete.retention.ms (default 86,400,000 ms, one day). min.compaction.lag.ms defaults to 0 and controls how long ordinary records stay uncompacted, not how long tombstones survive.

After a rolling restart, broker 2 hosts many replicas but leads almost no partitions, and client load is concentrated on the other brokers. Which command restores leadership to the preferred replicas right away?

kafka-leader-election.sh --bootstrap-server b1:9092 --election-type preferred --all-topic-partitions. The preferred leader is the first broker in each partition's replica list, and a preferred election moves leadership back to it without moving data. With auto.leader.rebalance.enable=true the controller would also do this periodically, but the CLI acts immediately. An unclean election is for offline partitions and risks data loss.

An operator notices that a record already appended to a partition leader's log is not returned to consumers until the followers in the ISR have copied it. Which concept limits what consumers can read?

The high watermark, the offset up to which all in-sync replicas have the data. Consumers are only served records below the high watermark, meaning records that every in-sync replica has, so a record that could be lost on leader failover is never exposed. The log end offset includes records not yet replicated, which is exactly what consumers are prevented from reading.

A batch consumer group runs only once a month. After the service is stopped, the group has no members for weeks. On the next run it reprocesses from auto.offset.reset instead of resuming. What caused the committed offsets to disappear?

Committed offsets of an empty group expire after offsets.retention.minutes (seven days). Once a group becomes empty, its committed offsets are kept for offsets.retention.minutes (10,080 minutes, seven days) and then removed, so a monthly job finds none. __consumer_offsets is a compacted topic, and offsets survive coordinator or leader changes because they are persisted there.

A new KRaft cluster will use SCRAM-SHA-256 as sasl.mechanism.inter.broker.protocol. Brokers must authenticate to each other as user admin from their very first start. How do you make that credential available before any broker is running?

Pass --add-scram 'SCRAM-SHA-256=[name=admin,password=...]' to kafka-storage.sh format. In KRaft, SCRAM credentials live in the metadata log, so credentials needed for inter-broker authentication at bootstrap are added while formatting storage with kafka-storage.sh --add-scram. Using kafka-configs.sh requires a broker that can already authenticate, which is the chicken-and-egg problem this option solves; super.users grants authorisation, not authentication.

A broker's TLS certificate on the listener named EXTERNAL expires next week. A new keystore has been copied to /etc/kafka/ssl/broker1-2027.p12 on broker 1. How can you switch the listener to the new keystore without restarting the broker?

Use kafka-configs.sh --entity-type brokers --entity-name 1 --alter to set listener.name.external.ssl.keystore.location and passwords. Listener SSL settings are per-broker dynamic configs, so a listener-prefixed keystore location (with its passwords) can be updated on a running broker with kafka-configs.sh. Brokers do not re-read server.properties at runtime, and changing only the truststore would not replace the broker's expiring certificate.

In a KRaft cluster, broker 5 loses its network path to the controllers but can still reach some clients. broker.session.timeout.ms is at its default. What does the active controller do?

After about 9 seconds without heartbeats it fences broker 5 and moves its leaderships to other ISR members. Brokers hold a lease renewed by heartbeats to the active controller; when it lapses for broker.session.timeout.ms (9,000 ms by default) the controller fences the broker and elects new leaders from the remaining ISR. Fencing prevents a partitioned broker from continuing as leader; replicas are not deleted, and the controller cannot shut a broker down.

A Confluent Platform DR design requires that, after failover, consumers resume on the DR cluster at exactly the same offsets they had on the primary, without any offset translation step. Which replication approach satisfies this?

Cluster Linking with mirror topics, which preserve offsets byte for byte. Cluster Linking mirrors topics with identical offsets and content, so consumer offsets carry over without translation. MirrorMaker 2 produces records afresh on the target, so offsets differ and it relies on checkpoints to translate consumer positions, even when topic names are kept the same.

A sink connector reading plain JSON messages fails with a DataException saying JsonConverter with schemas.enable requires 'schema' and 'payload' fields. The messages have no such envelope. Which connector configuration fixes this?

value.converter=org.apache.kafka.connect.json.JsonConverter with value.converter.schemas.enable=false. With schemas.enable=true the JsonConverter expects each message to embed a schema and payload envelope; turning it off makes it parse plain JSON. errors.tolerance=all would only skip every record, and the error concerns the value, so changing the key converter does not help.

Producers use acks=all. You want a broker alert that fires exactly when those producers would start getting NotEnoughReplicas errors for some partitions. Which metric should the alert use?

kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount > 0. UnderMinIsrPartitionCount counts partitions whose ISR is smaller than min.insync.replicas, the exact condition in which acks=all writes are rejected. AtMinIsrPartitionCount is a useful early warning (one more failure would block writes), but at that point writes still succeed.

CCDAK and CCAAK sample questions with answers

20 free CCDAK and CCAAK sample questions (10 per exam) across the exam's domains, each with its answer and an explanation. No account needed.

CCDAK sample questions

Confluent Certified Developer for Apache Kafka (CCDAK), Confluent.

Question 1
Domain: Apache Kafka Fundamentals
Which command sets a one-day retention on the existing orders topic?
1. kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders --property retention.ms=86400000
2. kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name orders --add-config retention.ms=86400000
3. kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-name orders --add-config retention.ms=86400000
4. kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic orders --retention 1d
Show the answer
Answer: B. kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name orders --add-config retention.ms=86400000
Topic-level overrides are changed with kafka-configs.sh using --entity-type topics, the topic name, and --add-config. Using --entity-type brokers targets broker configurations, so the orders topic would not change; kafka-topics.sh has no --retention flag.
Checked against: https://kafka.apache.org/43/operations/basic-kafka-operations/
Question 2
Domain: Apache Kafka Fundamentals
What is the trade-off of setting unclean.leader.election.enable=true?
1. It favours throughput: followers stop replicating so the leader can accept writes faster
2. It favours durability: the partition stays offline until a replica with every record returns
3. It favours availability: an out-of-sync replica may become leader, so acknowledged records can be lost
4. It favours latency: consumers can read from followers without waiting for the leader
Show the answer
Answer: C. It favours availability: an out-of-sync replica may become leader, so acknowledged records can be lost
Unclean leader election lets a replica outside the ISR take over when no in-sync replica is available, which restores availability but may drop records that only the old leader had. The default is false, which means waiting for an in-sync replica, and that is the durability-first behaviour the second option describes.
Checked against: https://kafka.apache.org/43/configuration/broker-configs/
Question 3
Domain: Apache Kafka Application Development
Which acks setting makes the leader wait for the full set of in-sync replicas to acknowledge a record before responding?
1. acks=all
2. acks=quorum
3. acks=1
4. acks=0
Show the answer
Answer: A. acks=all
acks=all makes the leader wait until every current in-sync replica has the record, giving the strongest durability. acks=1 only waits for the leader's own write, and acks=quorum is not a valid value.
Checked against: https://kafka.apache.org/43/configuration/producer-configs/
Question 4
Domain: Apache Kafka Application Development
All members of a consumer group run Kafka 3.x clients with the default partition.assignment.strategy.
What is the documented way to move this group to cooperative rebalancing?
1. Perform one rolling bounce that adds RoundRobinAssignor ahead of RangeAssignor in partition.assignment.strategy
2. Set group.protocol=classic-cooperative on the brokers and restart the brokers
3. Perform a single rolling bounce that removes RangeAssignor from partition.assignment.strategy
4. Stop every consumer at once, change the strategy, then restart them together
Show the answer
Answer: C. Perform a single rolling bounce that removes RangeAssignor from partition.assignment.strategy
The default partition.assignment.strategy is [RangeAssignor, CooperativeStickyAssignor]; it uses Range at first but is designed so that one rolling bounce removing RangeAssignor switches the group to the cooperative assignor. A full stop is unnecessary, and classic-cooperative is not a real setting.
Checked against: https://kafka.apache.org/43/configuration/consumer-configs/
Question 5
Domain: Apache Kafka Application Development
A consumer authenticates successfully and has READ on the invoices topic, but fails with GroupAuthorizationException: Not authorized to access group: reporting.
Which additional ACL is most likely missing?
1. IDEMPOTENT_WRITE on the cluster resource for the consumer client
2. CREATE on the cluster resource
3. WRITE on the invoices topic
4. READ on the consumer group resource named reporting
Show the answer
Answer: D. READ on the consumer group resource named reporting
Consuming as part of a group needs READ on the topic and READ on the group, and the GroupAuthorizationException points directly at the group. WRITE on the topic is for producing, so it would not fix a consumer's group authorization error.
Checked against: https://kafka.apache.org/43/security/authorization-and-acls/
Question 6
Domain: Apache Kafka Streams
How does Kafka Streams make a persistent state store fault tolerant by default?
1. It writes every update to a compacted changelog topic and restores the store from it after a failure
2. It copies the RocksDB files to every broker after each commit
3. It keeps the store in the brokers' page cache, so the state survives application restarts without any restore
4. It snapshots the store into the application's input topic once an hour and replays the snapshot on restart
Show the answer
Answer: A. It writes every update to a compacted changelog topic and restores the store from it after a failure
Persistent stores (RocksDB by default) are backed by a compacted changelog topic in Kafka, and a task that moves to another instance rebuilds its store by replaying that changelog. The RocksDB files stay local to the application; brokers never hold them.
Checked against: https://kafka.apache.org/43/streams/architecture/
Question 7
Domain: Kafka Connect
What is the difference between source and sink connectors?
1. Source connectors read from compacted topics, while sink connectors read only from topics that use the delete policy
2. Source connectors bring data from external systems into Kafka; sink connectors deliver Kafka data to external systems
3. Source connectors run on brokers; sink connectors run inside consumer applications
4. Source connectors handle schemas; sink connectors handle only raw bytes
Show the answer
Answer: B. Source connectors bring data from external systems into Kafka; sink connectors deliver Kafka data to external systems
The direction of the data defines the connector type: sources bring data into Kafka topics, and sinks deliver data from topics to systems such as databases or search indexes. Both run in Kafka Connect workers, which are separate from the brokers.
Checked against: https://kafka.apache.org/43/kafka-connect/overview/
Question 8
Domain: Kafka Connect
A JDBC source connector is configured with tasks.max=10 to copy three tables. The status endpoint shows only three tasks.
Why does the connector run only three tasks?
1. Kafka Connect caps each connector's tasks at the number of partitions in its internal offsets topic
2. The other seven tasks failed at startup and were removed automatically
3. Each worker can run at most one task at a time, and the Connect cluster currently has only three workers
4. tasks.max is only an upper bound; the connector created as many tasks as it could use, one per table
Show the answer
Answer: D. tasks.max is only an upper bound; the connector created as many tasks as it could use, one per table
tasks.max is the maximum number of tasks; the connector may create fewer if it cannot divide the work further, and a JDBC source can split work by table. Workers can run many tasks each, so the number of workers does not limit this.
Checked against: https://kafka.apache.org/43/kafka-connect/user-guide/
Question 9
Domain: Application Testing
A topology materialises a count into a store named counts-store.
How can a test check the contents of a state store after piping records?
1. Call topology.describe() and inspect the store entries it prints
2. Read the changelog topic with a MockConsumer attached to the driver
3. Create a KafkaStreams instance for the same topology and call store() on it after piping
4. Call driver.getKeyValueStore("counts-store") and read values from the returned store
Show the answer
Answer: D. Call driver.getKeyValueStore("counts-store") and read values from the returned store
TopologyTestDriver exposes the topology's stores by name through methods such as getKeyValueStore() and getWindowStore(), so tests can assert on state directly. topology.describe() lists the processors and store names but never their contents.
Checked against: https://kafka.apache.org/43/javadoc/org/apache/kafka/streams/TopologyTestDriver.html
Question 10
Domain: Application Observability
A client in a Docker container bootstraps successfully to kafka:9092, but then logs repeatedly: Connection to node 1 (localhost/127.0.0.1:9092) could not be established. Node may not be available.
What does this log pattern most likely indicate?
1. The broker's advertised.listeners returns an address that is not reachable from the container
2. The client's request.timeout.ms is too low for the metadata request sent after the bootstrap connection
3. The topic does not exist, so the broker closed the connection
4. The bootstrap server rejected the client's connection because SASL authentication is required on that listener
Show the answer
Answer: A. The broker's advertised.listeners returns an address that is not reachable from the container
Node -1 is the bootstrap connection, which succeeds; the client then connects to the brokers using the addresses they advertise. An advertised localhost:9092 points back at the client container itself, so the connection fails. That is an advertised.listeners problem, not an authentication one.
Checked against: https://kafka.apache.org/43/configuration/broker-configs/

CCAAK sample questions

Confluent Certified Administrator for Apache Kafka (CCAAK), Confluent.

Question 1
Domain: Apache Kafka Cluster Configuration
A compacted topic stores customer profiles. A service deletes customer 42 by producing a record with key 42 and a null value. A new consumer that replays the topic from offset 0 must learn about the deletion.
Which setting bounds how long that consumer has to reach the delete marker before it can disappear?
1. min.compaction.lag.ms, which defaults to one day
2. retention.ms, which defaults to seven days
3. delete.retention.ms, which defaults to one day
4. segment.ms, which defaults to seven days
Show the answer
Answer: C. delete.retention.ms, which defaults to one day
A null-value record is a tombstone, and tombstones are themselves removed once they are older than delete.retention.ms (default 86,400,000 ms, one day). min.compaction.lag.ms defaults to 0 and controls how long ordinary records stay uncompacted, not how long tombstones survive.
Checked against: https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_delete.retention.ms
Question 2
Domain: Apache Kafka Cluster Configuration
After a rolling restart, broker 2 hosts many replicas but leads almost no partitions, and client load is concentrated on the other brokers.
Which command restores leadership to the preferred replicas right away?
1. kafka-leader-election.sh --bootstrap-server b1:9092 --election-type unclean --all-topic-partitions
2. kafka-leader-election.sh --bootstrap-server b1:9092 --election-type preferred --all-topic-partitions
3. kafka-reassign-partitions.sh --bootstrap-server b1:9092 --generate --broker-list "2"
4. kafka-topics.sh --bootstrap-server b1:9092 --alter --preferred-leader 2 --all-topics
Show the answer
Answer: B. kafka-leader-election.sh --bootstrap-server b1:9092 --election-type preferred --all-topic-partitions
The preferred leader is the first broker in each partition's replica list, and a preferred election moves leadership back to it without moving data. With auto.leader.rebalance.enable=true the controller would also do this periodically, but the CLI acts immediately. An unclean election is for offline partitions and risks data loss.
Checked against: https://kafka.apache.org/43/operations/basic-kafka-operations/#balancing-leadership
Question 3
Domain: Apache Kafka Fundamentals
An operator notices that a record already appended to a partition leader's log is not returned to consumers until the followers in the ISR have copied it.
Which concept limits what consumers can read?
1. The log start offset, which moves forward as retention deletes segments
2. The last committed offset of the consumer group on that partition
3. The log end offset of the leader, which includes unreplicated records
4. The high watermark, the offset up to which all in-sync replicas have the data
Show the answer
Answer: D. The high watermark, the offset up to which all in-sync replicas have the data
Consumers are only served records below the high watermark, meaning records that every in-sync replica has, so a record that could be lost on leader failover is never exposed. The log end offset includes records not yet replicated, which is exactly what consumers are prevented from reading.
Checked against: https://kafka.apache.org/43/design/design/#replicated-logs-quorums-isrs-and-state-machines-oh-my
Question 4
Domain: Apache Kafka Fundamentals
A batch consumer group runs only once a month. After the service is stopped, the group has no members for weeks. On the next run it reprocesses from auto.offset.reset instead of resuming.
What caused the committed offsets to disappear?
1. Committed offsets of an empty group expire after offsets.retention.minutes (seven days)
2. The __consumer_offsets topic uses cleanup.policy=delete with a one-day retention.ms by default
3. Committed offsets are held only in the memory of the group coordinator
4. Offsets are removed whenever the partition's leader changes
Show the answer
Answer: A. Committed offsets of an empty group expire after offsets.retention.minutes (seven days)
Once a group becomes empty, its committed offsets are kept for offsets.retention.minutes (10,080 minutes, seven days) and then removed, so a monthly job finds none. __consumer_offsets is a compacted topic, and offsets survive coordinator or leader changes because they are persisted there.
Checked against: https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_offsets.retention.minutes
Question 5
Domain: Apache Kafka Security
A new KRaft cluster will use SCRAM-SHA-256 as sasl.mechanism.inter.broker.protocol. Brokers must authenticate to each other as user admin from their very first start.
How do you make that credential available before any broker is running?
1. Pass --add-scram 'SCRAM-SHA-256=[name=admin,password=...]' to kafka-storage.sh format
2. Create it with kafka-configs.sh against the first broker once it has started
3. Put the admin user in super.users so SCRAM is bypassed for every inter-broker connection
4. Store it in a JAAS file on each broker; SCRAM credentials are read from JAAS
Show the answer
Answer: A. Pass --add-scram 'SCRAM-SHA-256=[name=admin,password=...]' to kafka-storage.sh format
In KRaft, SCRAM credentials live in the metadata log, so credentials needed for inter-broker authentication at bootstrap are added while formatting storage with kafka-storage.sh --add-scram. Using kafka-configs.sh requires a broker that can already authenticate, which is the chicken-and-egg problem this option solves; super.users grants authorisation, not authentication.
Checked against: https://kafka.apache.org/43/security/authentication-using-sasl/#creating-scram-credentials
Question 6
Domain: Apache Kafka Security
A broker's TLS certificate on the listener named EXTERNAL expires next week. A new keystore has been copied to /etc/kafka/ssl/broker1-2027.p12 on broker 1.
How can you switch the listener to the new keystore without restarting the broker?
1. Use kafka-configs.sh --entity-type topics --alter to set ssl.keystore.location on every topic
2. Use kafka-configs.sh --entity-type brokers --entity-name 1 --alter to set listener.name.external.ssl.keystore.location and passwords
3. Edit ssl.keystore.location in server.properties; brokers reload the file every five minutes
4. Use kafka-configs.sh --entity-type brokers --entity-default --alter to set ssl.truststore.location to the new file on every listener
Show the answer
Answer: B. Use kafka-configs.sh --entity-type brokers --entity-name 1 --alter to set listener.name.external.ssl.keystore.location and passwords
Listener SSL settings are per-broker dynamic configs, so a listener-prefixed keystore location (with its passwords) can be updated on a running broker with kafka-configs.sh. Brokers do not re-read server.properties at runtime, and changing only the truststore would not replace the broker's expiring certificate.
Checked against: https://docs.confluent.io/platform/current/kafka/dynamic-config.html
Question 7
Domain: Troubleshooting
In a KRaft cluster, broker 5 loses its network path to the controllers but can still reach some clients. broker.session.timeout.ms is at its default.
What does the active controller do?
1. It waits for replica.lag.time.max.ms to expire, then deletes broker 5's replicas and re-creates them on other brokers
2. It keeps broker 5 as leader because clients can still reach it directly
3. After about 9 seconds without heartbeats it fences broker 5 and moves its leaderships to other ISR members
4. It shuts broker 5 down remotely through the controller listener
Show the answer
Answer: C. After about 9 seconds without heartbeats it fences broker 5 and moves its leaderships to other ISR members
Brokers hold a lease renewed by heartbeats to the active controller; when it lapses for broker.session.timeout.ms (9,000 ms by default) the controller fences the broker and elects new leaders from the remaining ISR. Fencing prevents a partitioned broker from continuing as leader; replicas are not deleted, and the controller cannot shut a broker down.
Checked against: https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_broker.session.timeout.ms
Question 8
Domain: Deployment Architecture
A Confluent Platform DR design requires that, after failover, consumers resume on the DR cluster at exactly the same offsets they had on the primary, without any offset translation step.
Which replication approach satisfies this?
1. MirrorMaker 2 with the default replication policy and heartbeats enabled
2. MirrorMaker 2 with sync.group.offsets.enabled and IdentityReplicationPolicy
3. A Kafka Connect sink that writes each topic to the DR cluster
4. Cluster Linking with mirror topics, which preserve offsets byte for byte
Show the answer
Answer: D. Cluster Linking with mirror topics, which preserve offsets byte for byte
Cluster Linking mirrors topics with identical offsets and content, so consumer offsets carry over without translation. MirrorMaker 2 produces records afresh on the target, so offsets differ and it relies on checkpoints to translate consumer positions, even when topic names are kept the same.
Checked against: https://docs.confluent.io/platform/current/multi-dc-deployments/cluster-linking/index.html
Question 9
Domain: Kafka Connect
A sink connector reading plain JSON messages fails with a DataException saying JsonConverter with schemas.enable requires 'schema' and 'payload' fields. The messages have no such envelope.
Which connector configuration fixes this?
1. value.converter=org.apache.kafka.connect.storage.StringConverter with value.converter.schemas.enable=true
2. value.converter=org.apache.kafka.connect.json.JsonConverter with errors.tolerance=all set to skip them
3. key.converter=org.apache.kafka.connect.json.JsonConverter with key.converter.schemas.enable=false
4. value.converter=org.apache.kafka.connect.json.JsonConverter with value.converter.schemas.enable=false
Show the answer
Answer: D. value.converter=org.apache.kafka.connect.json.JsonConverter with value.converter.schemas.enable=false
With schemas.enable=true the JsonConverter expects each message to embed a schema and payload envelope; turning it off makes it parse plain JSON. errors.tolerance=all would only skip every record, and the error concerns the value, so changing the key converter does not help.
Checked against: https://kafka.apache.org/43/kafka-connect/user-guide/#worker-configuration
Question 10
Domain: Observability
Producers use acks=all. You want a broker alert that fires exactly when those producers would start getting NotEnoughReplicas errors for some partitions.
Which metric should the alert use?
1. kafka.server:type=ReplicaManager,name=AtMinIsrPartitionCount > 0
2. kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions > 0
3. kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount > 0
4. kafka.server:type=ReplicaManager,name=IsrExpandsPerSec > 0
Show the answer
Answer: C. kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount > 0
UnderMinIsrPartitionCount counts partitions whose ISR is smaller than min.insync.replicas, the exact condition in which acks=all writes are rejected. AtMinIsrPartitionCount is a useful early warning (one more failure would block writes), but at that point writes still succeed.
Checked against: https://kafka.apache.org/43/operations/monitoring/

More practice

A 20-question practice sampler is free with an account; Pro adds the full question bank and timed mock exams.

CCDAK and CCAAK course and practice exams: Confluent Apache Kafka certifications: the exam guide, with the format, cost, pass mark and domains from the vendor.

CCDAK and CCAAK sample questions with answers

CCDAK sample questions

Question 1

Question 2

Question 3

Question 4

Question 5

Question 6

Question 7

Question 8

Question 9

Question 10