CCDAK Questions and Answers

For Kafka Streams to performjoins, topics must beco-partitioned, meaning:

They have thesame number of partitions(A), and

They use thesame partitioning strategy(typically by key) (B)

FromKafka Streams Documentation > Joins:

“Co-partitioning is required for Kafka Streams joins. Topics must have the same number of partitions and use the same key-based partitioner.”

Value schema (C) and retention time (D) have no bearing on join compatibility.

Log compactionensures that Kafka retains at least thelatest value per keyin a topic. Compaction happensin the backgroundand removes older records with the same keyin inactive log segments, not immediately.

From theKafka Documentation > Log Compaction:

“Kafka guarantees that thelast message for each keywill be retained in the log after compaction, even if earlier messages with the same key are deleted.”

So, D is correct. A is incorrect because compaction does not overwrite; it's a background process. B is incorrect—deletion is not immediate. C incorrectly suggests client-side hashmap behavior.

max.poll.interval.ms defines themaximum delay between invocations of poll()before the consumer is considered failed. It essentially gives consumers more time to process records before needing to poll again.

FromKafka Consumer Configuration Reference:

“max.poll.interval.ms: The maximum delay between invocations of poll() when using consumer group management. If poll() is not called before expiration, the consumer is considered failed.”

session.timeout.ms and heartbeat.interval.ms relate to group coordination and heartbeats.

fetch.max.wait.ms affects how long the broker waits to accumulate data before sending a fetch response.

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.

RetriableException is a subclass of KafkaException, indicating transient issues thatmight succeed if retried. Examples include:

LeaderNotAvailableException: Happens when metadata is not yet propagated or leader election is in progress.

NotEnoughReplicasException: Happens when the number of in-sync replicas is insufficient. This can be transient if replicas come back online.

From theApache Kafka Java Client documentation:

"These exceptions (like LeaderNotAvailableException, NotEnoughReplicasException) are transient and the client will retry them automatically depending on retry configuration."

RecordTooLargeExceptionandAuthorizationExceptionarenon-retriableas they indicate client-side or permission errors.

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.

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.

This syntax is a clear match toProtocol Buffers (Protobuf). It defines a schema with fields, types, and tags, which is a format supported by Kafka when usingProtobuf-based schema registry serialization.

FromConfluent Schema Registry Docs:

“Kafka supports Protobuf serialization, where schemas are written in .proto files and include fields with tags.”

int32, double, and string are standard Protobuf types.

Avro uses JSON-style schema.

JSON Schema uses JSON object structure, not .proto.

YAML is unrelated.

TheKafka Streams DSLprovides three primary abstractions:

KStream: Represents an unbounded stream of records (append-only).

KTable: Represents a changelog stream where each key has the latest value (like a materialized view).

GlobalKTable: A fully replicated version of KTable across all stream instances, enabling global joins.

FromKafka Streams Developer Guide:

“Kafka Streams provides three core abstractions: KStream, KTable, and GlobalKTable, each serving different purposes in stream processing and joins.”

GlobalKStream and StreamTable donot existin Kafka’s API.

Kafka Connectsink connectorsuse thestandard Kafka consumer mechanismto track offsets, which means offsets are stored in the__consumer_offsets internal topic.

FromKafka Connect Documentation:

“Sink connectors are regular Kafka consumers and store their offsets in the __consumer_offsets topic like any other consumer.”

The other options refer tosource connectorsor worker configuration.

offsets.storage.topic is relevant forsource connectors.

AGlobalKTableis a replicated, read-only table available in full on all instances. It's best forreference or lookup datasetssuch as:

Product catalog

Customer profiles

Warehouse inventory

FromKafka Streams Developer Guide:

“Use GlobalKTable when you need to perform joins using non-partition-aligned reference data that's small enough to replicate.”

Purchases and transactions are high-throughput, time-sensitive streams, not static reference data.

Frequentrebalancesin a consumer group occur when:

Consumers are too slowand miss heartbeats (A), or

Instances crash or restart, triggering group membership changes (D)

FromKafka Consumer Group Coordination Docs:

“If a consumer fails to send a heartbeat in time (due to slowness or crash), it is removed from the group, causing a rebalance.”

Option B (partition mismatch) affectsload balancing, not rebalance frequency.

Option C (broker storage) doesn't trigger consumer rebalances.

A:Kafka batches storecompression metadata in their headers, indicating how the batch was compressed.

B:Compression is controlled via theproducer config compression.type, which defaults to none. Producers explicitly set Gzip or other formats.

FromKafka Producer Docs:

“Compression is done by the producer, and the type is stored in the message batch metadata. The broker does not recompress.”

C is false: messages are serializedbeforecompression.

D is false: messages without keys are distributed acrossmultiple partitions.