Free Practice Questions for Confluent CCDAK Exam

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.

SMTs (Single Message Transforms) arelightweight transformationsapplied to individual messages as they pass through Kafka Connect.

Chaining SMTs: You can applymultiple SMTsin sequence by defining them in order in the connector config.

Masking or modifying fieldsis acommon use case(e.g., redacting sensitive data).

FromKafka Connect Documentation:

“Single Message Transforms (SMTs) are applied to individual messages. You can chain multiple SMTs together.”

SMTsdo not perform joins(B is incorrect).

Converters and SMTs areseparate concerns(D is incorrect).

Low I/O thread activity with blocked throughput often indicates thatproducer callbacks are consuming too much time, causing the sender thread to block while waiting for onCompletion() to finish.

FromKafka Producer Performance Guide:

“Expensive logic in callbacks (e.g., I/O or complex computation) can block the sender thread, reducing throughput.”

Compression (A) may slightly impact CPU but not I/O thread usage.

Large batches (B) improve throughput if managed correctly.

A Layer 2 network issue (C) would lead to packet loss, not specifically low callback metrics.

To skip a corrupted record and avoid failing the application, you mustseek past the failed offsetmanually using consumer.seek(). This allows the application to resume consumption from the next offset.

FromKafka Consumer Error Handling Docs:

“On deserialization failure, you can catch RecordDeserializationException, log the error, and call seek() to the next offset to skip the bad record.”

A does not prevent re-processing the bad record.

C is invalid; there'sno skip() methodin the Kafka consumer API.

D results in service interruption — not ideal for resiliency.

To maintainmessage ordering per bank account, themessage key must be the account number. Kafka guaranteesordering per partition, and the partition is selected based on thehash of the key.

FromKafka Producer Docs:

“All records with the same key will be sent to the same partition, and Kafka preserves the order of records in a partition.”

Using account number ensures:

All messages for the same account go to the same partition

Order is maintained

Workload is evenly distributed if account keys are varied

Other options break ordering or introduce unnecessary randomness.

Session windowsare ideal for trackingperiods of activity separated by inactivity, such as user sessions.

FromKafka Streams Documentation > Windowing:

“A session window captures streams of events that areintermittentand separated by agap of inactivity.”

Tumbling/Hopping/Sliding windows are fixed in size

Session windows are dynamic and close after inactivity timeout

This makes them perfect for identifyinggaps in user interaction.

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.

With acks=all, the leader waits formin.insync.replicasto acknowledge the message. Since min.insync.replicas=3, Kafka will only commit the messageonce 3 brokers (leader + 2 followers)confirm they have the message.

FromKafka Documentation > Acks and Durability:

“If acks=all is specified, the producer will wait until the full set of in-sync replicas has acknowledged the record. The minimum number of in-sync replicas is controlled by min.insync.replicas.”

Even though the replication factor is 4, only3 acknowledgments are needed, as defined by min.insync.replicas.

Thebatch.sizeconfig sets themaximum number of bytes to batch per partitionbefore sending. This allows Kafka producers toamortize I/Oand improve throughput.

FromKafka Producer Configuration Docs:

“batch.size is the maximum amount of data per partition the producer will batch before sending.”

buffer.memory sets total memory for the producer, not per-batch.

send.buffer.bytes is aTCP socket buffer, not a Kafka config.

max.block.ms controls blocking time, not size.