Free Confluent CCDAK Practice Exam with Questions & Answers

When using Kafka Connect with sink connectors (like S3 Sink),each task is assigned one or more topic partitions. Thetotal number of partitions (6)isevenly distributedacross the available tasks (2). Thus, each task will handle3 partitions.

FromKafka Connect Documentation:

“Kafka Connect divides the topic partitions among available tasks. For example, a topic with six partitions and two tasks results in each task handling three partitions.”

These three metrics are critical for cluster health:

OfflinePartitionsCount: Indicates partitions without active leaders — a sign of broker failure.

ActiveControllerCount: There should beexactly one active controller. A count ≠ 1 signals controller failure.

UncleanLeaderElectionsPerSec: Tracks leader elections where out-of-sync replicas were selected — risky for data loss.

FromKafka Monitoring Documentation:

“Offline partitions and unclean leader elections should trigger alerts. Also, ensure a single active controller is running.”

A is about topics pending deletion — not critical.

E is a per-topic record metric, not broker-level.

Increasingtasks.maxallows the connector to createmultiple tasks, each responsible for processing different tables or table partitions. If onlyone taskis used,adding more workers has no effect.

FromKafka Connect JDBC Connector Docs:

“Use tasks.max to configure how many tasks are created for the connector. Each task can process a subset of the data.”

A and C help only if the bottleneck is in Kafka, not Connect.

D is a large architectural change, not the first step.

Kafka Streams usestransactional producersto guaranteeexactly-once semantics (EOS). This ensures that both theoutput recordsandstate store updatesare committed atomically, avoiding duplication or partial writes.

FromKafka Streams Documentation > Processing Guarantees:

“Kafka Streams leveragesKafka’s transactional APIsto commit the output records and internal state updatesas a single atomic unit, thereby providing exactly-once semantics.”

Option A is incorrect because log compaction is not disabled for EOS.

Option C incorrectly describes a checkpointing system Kafka Streams does not use.

Option D refers to deduplication, which is not how EOS is achieved in Streams.

Each of these settings plays a key role inKafka Connect offset management:

offset.flush.interval.ms=60000 → Offset commits happen every 60 seconds.

offset.flush.timeout.ms=500 → The flush operation times out if it takes more than 500 ms.

offset.storage.topic=connect-offsets → This is the internal topic for storing source offsets.

offset.storage.replication.factor=-1 → This uses thebroker's default replication factor(commonly set via default.replication.factor).

FromKafka Connect Docs:

“If offset.storage.replication.factor=-1, the value will be determined by the broker's default replication factor.”

To change the replication factor of an existing topic, you must perform apartition reassignment, because the replication factor is not directly modifiable via kafka-topics.sh. Thekafka-reassign-partitions.shtool is the official command-line utility to handle partition reassignments, including changing the replication factor.

This tool allows you to generate a reassignment JSON specifying new replica assignments per partition and then apply it.

From official documentation:

“To change the replication factor, use the kafka-reassign-partitions tool to assign the partitions to more or fewer brokers.”

Neither kafka-topics.sh nor kafka-reassign-topics.sh exists for this purpose, and kafka-recreate-topic.sh isnotan official Kafka tool.

The default maximum message size that a Kafka broker accepts is1MB (1,048,576 bytes), controlled by the config propertymessage.max.bytes.

FromKafka Broker Configuration Docs:

“The default maximum message size is 1MB. To accept larger messages, configure message.max.bytes and the producer’s max.request.size.”

Producers also have a matching limit via max.request.size, and consumers via fetch.message.max.bytes.

If the consumer fails to send heartbeats in time (due to being slow under load), it is considereddead, causing a rebalance. Increasing session.timeout.ms gives the consumermore time to process messages and send heartbeats, preventing premature removal.

FromKafka Docs > Heartbeats and Failures:

“If the consumer does not send a heartbeat in session.timeout.ms, it is considered dead and the group coordinator will trigger a rebalance.”

Reducing max.poll.records mightslow consumption further. More consumers won’t help since each partition already has a dedicated consumer.

Kafka Connectsource connectorsuse theoffset.storage.topicconfiguration parameter to define where to storeoffsets that track the connector's positionin the source system (e.g., database, file, etc.).

FromKafka Connect Worker Configuration:

“offset.storage.topic specifies the topic in Kafka where the connector stores offsets for each source partition.”

This allows Kafka Connect toresumefrom the correct position on restart.

The other options (B–D) are not valid Kafka configs.

ForSASL/PLAIN authentication over SSL, the correct combination is:

security.protocol=SASL_SSL

sasl.jaas.config=...PlainLoginModule required username=... password=...

FromKafka Security Documentation:

“For SASL/PLAIN over SSL, configure security.protocol=SASL_SSL and provide login module configuration using sasl.jaas.config.”

Options B and D are incorrect because they do not pair the correct protocol with the authentication method.