Kafka Exam Sample Questions: Domain-by-Domain Drills and Practical Notes

Confluent's CCDAK and CCAAK both ask whether you can use Kafka safely and predictably from development and operations angles. This article distills the recurring exam-style decision points across the core domains, anchored in past patterns and the stable behaviors documented in the official spec.

The sample questions are practice-flavored sketches, but each one comes with settings and trade-offs that translate to real work — try reproducing them on your own cluster as you read.

Delivery Guarantees and Controlling Duplicates and Loss

Kafka message delivery falls into three patterns: at-least-once, exactly-once, and at-most-once. On the producer side, the outcome depends on the combination of acks, retries, enable.idempotence, and max.in.flight.requests.per.connection. On the consumer side, the offset-commit timing matters, along with transactions and the read isolation level.

Exactly-Once Semantics (EOS) is reachable when you treat Kafka's read-process-write loop as a single atomic unit with an idempotent producer, transactions, and read_committed reads. Extending exactly-once to external systems is only possible when those systems also support transactional coordination.

• At-least-once: avoids loss but allows duplicates. retries>0 with acks=all is the standard recipe; dedupe downstream.
• At-most-once: tolerates loss but never produces duplicates. Typically you commit before sending, but it sees limited use in normal business scenarios.
• Exactly-once: enable.idempotence=true, acks=all, transactional.id set, and consumers using isolation.level=read_committed. The Streams API makes EOS easy to wire up.
• Keep max.in.flight.requests.per.connection low (typically 1-5) under EOS so retries cannot reorder messages.

Producer → broker → consumer flow under EOS

Example producer configuration (EOS)

bootstrap.servers=broker:9092
aacks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5
transactional.id=orders-txn-01

Partitioning and Key Design

Ordering is guaranteed per partition. If you need to preserve order for a particular key, you must set the key. Without a key, current clients default to the sticky partitioner, which batches into the same partition for short windows and boosts throughput, but it cannot guarantee strict ordering.

To avoid hot partitions: keep key cardinality high, plan partition count against consumer parallelism, and reach for a custom partitioner when needed. You can grow partition count in a backward-compatible way, but shrinking it is hard — keep that asymmetry in mind.

• Fix the key per event or entity that requires ordering.
• The sticky partitioner improves batching even without keys, but do not rely on it when ordering is required.
• Size partition count as max consumer parallelism plus headroom. Be aware that growing it can shift key → partition mappings.

Java producer key-specification example

producer.send(new ProducerRecord<>("orders", customerId, payload));
// customerIdで順序保証（同一キーは同一パーティション）

Retention Policy and Log Cleaning

Time-based retention is controlled by retention.ms and size by retention.bytes. Data becomes eligible for removal only after it crosses a segment boundary (segment.ms / segment.bytes). When cleanup.policy=delete, old segments are removed once they hit the time or size cap.

With cleanup.policy=compact, the latest record per key is retained and earlier ones become compaction candidates. Deletes are expressed as a tombstone for the key and physically removed after delete.retention.ms. Compaction is eventually consistent, not immediate.

• Time-based retention depends on the record timestamp. Mind the difference between record.timestamp.type=CreateTime and LogAppendTime.
• Combining compact+delete lets you keep the latest value while still aging out old segments.
• Tune cleaning efficiency via min.cleanable.dirty.ratio and segment size.

Representative per-topic retention and compaction settings

kafka-topics.sh --bootstrap-server broker:9092 \
  --alter --topic users \
  --config cleanup.policy=compact,delete \
  --config retention.ms=604800000 \
  --config segment.ms=3600000

Replication and Fault Tolerance

Replication factor (e.g., 3) and ISR (In-Sync Replicas) form the bedrock of availability. acks=all returns success only after every ISR replica has caught up. min.insync.replicas sets the minimum ISR count required for writes; pairing it with acks=all raises durability during failures.

Leader election normally picks from the ISR. Setting unclean.leader.election.enable=false forbids elections from out-of-sync followers and prevents data loss, although downtime may extend. Rack awareness uses broker placement data to spread replicas across different racks.

• RF=3, min.insync.replicas=2, acks=all is a robust combination. Writes are refused once ISR drops to 1, but durability is excellent.
• Disable unclean.leader.election to prioritize data integrity, understanding the availability trade-off.
• Make it a habit to monitor reassignment and rebalancing during broker failures.

Key points for the server configuration

min.insync.replicas=2
unclean.leader.election.enable=false
# ラックアウェアネス
broker.rack=az1

Schema Management and Compatibility (Schema Registry)

Schema Registry manages Avro/Protobuf/JSON Schema and codifies compatibility modes (BACKWARD, FORWARD, FULL, and others). BACKWARD compatibility is the usual choice for adding events. Removing fields or adding required ones breaks backward compatibility, and exams often surface these as 'inappropriate' changes.

The Confluent wire format embeds a schema ID after a leading magic byte (0). Clients use the ID for deserialization, and compatibility checks are applied at registration time.

• BACKWARD: new consumers can read old data. Add fields with default values.
• FORWARD: old consumers can read new data. Prioritizes forward compatibility.
• FULL: bidirectional compatibility. The strictest constraint.
• It helps to split compatibility policies by subject naming strategy and topic key vs. value.

Compatibility mode configuration example

curl -s -X PUT -H "Content-Type: application/json" \
  --data '{"compatibility":"BACKWARD"}' \
  http://schema-registry:8081/config/subjects/orders-value

Security and Operational Basics

Encryption uses TLS, and you can choose authentication from SASL/PLAIN, SASL/SCRAM, OAuthBearer, mTLS, and so on. ACLs are granted as resource (Topic, Group, Cluster, etc.) × operation (Read, Write, Create, Describe, etc.). In operations, manage ACL principals and patterns (literal/prefix) explicitly.

Monitoring consumer lag, setting quotas, performing phased rolling upgrades, and leveraging cooperative rebalancing are the keys to stable operations. The cooperative-sticky rebalance minimizes pauses during rebalances.

• Separate SASL/TLS settings per listener to clearly delineate external and internal paths.
• Grant ACLs with least privilege. Missed Group permissions easily affect other teams' consumers.
• Integrate the organization's standard certificate management and key-rotation flow into Kafka.

ACL grant example (Write for producer, Read for consumer)

kafka-acls.sh --bootstrap-server broker:9092 \
  --add --allow-principal User:alice \
  --operation Write --topic payments
kafka-acls.sh --bootstrap-server broker:9092 \
  --add --allow-principal User:bob \
  --operation Read --topic payments --group payments-cg

Check Your Understanding

Frequently Asked Questions