Confluent Certified Developer for Apache Kafka (CCDAK) Study Guide

Domain 1: Apache Kafka Application Development

Key concepts you must know · 210 practice questions

The default partitioner hashes the record key, so every record sharing a key lands on one partition and is read back in the order it was written. That single mechanism is the whole basis of per entity ordering, and it is also why adding partitions to a keyed topic is a disruptive change rather than a routine one.
Acknowledgements are a three-way choice: none at all for the lowest latency and silent loss, the leader only, or every in sync replica. Only the last survives the loss of the broker that accepted the write, and only when the topic also requires a minimum in sync replica count above one.
Idempotence removes duplicates caused by a producer retry by having the broker recognise a sequence it has already seen. It implies acknowledgements set to all and retries above zero, and it is the foundation the transactional producer is built on.
A consumer group divides the partitions of its subscribed topics among its members, one partition to one member at a time. Parallelism is therefore capped by the partition count, and members beyond that number sit idle rather than helping.
Committing offsets after processing gives at least once delivery and duplicates on a crash; committing before processing gives at most once and gaps. Exactly once in a consume, process and produce loop requires the offsets to be committed inside the producer transaction and the downstream consumer to read committed records only.
The session timeout and the maximum poll interval detect different failures. The first notices a process that has died or become unreachable; the second notices a process that is alive but taking too long between polls, which is the usual cause of a consumer that appears to restart under load.
Serialization is a contract between applications. A schema registry lets a producer register a structure and a consumer fetch it by an identifier carried in the record, which keeps records small and lets an incompatible change be rejected before it ships.
Batching and compression work together: compression is applied across a batch, so a producer sending one record at a time gets neither the throughput nor the compression ratio the settings promise. Linger time is the lever that lets a batch fill.

Domain 2: Apache Kafka Fundamentals

Key concepts you must know · 173 practice questions

A partition is an append only log with its own offsets, and offsets are unique within a partition rather than across a topic. A position is always a topic, a partition and an offset together.
The in sync replica set is the group of replicas currently caught up with the leader. It shrinks when a follower falls behind in time rather than in records, and it expands again on its own once that follower catches up.
The high water mark is the highest offset replicated to every in sync replica, and consumers cannot read past it. That is what stops a consumer acting on a record that a leader failure would erase.
Retention removes records by age or by size and knows nothing about consumer progress, so shortening it on a topic with a lagging group silently loses records that group never read.
Compaction is a different policy entirely: it keeps at least the latest value for each key, which turns the topic into a changelog. It requires keyed records, and a deletion is expressed as a tombstone - a key with a null value.
Storage is the daily volume multiplied by the retention period and again by the replication factor. Forgetting the last term understates a three way replicated topic by two thirds.
Metadata tells a client which broker leads each partition, which is why a metadata refresh is what follows a leader change and why a rolling restart shows up as a brief burst of retriable errors rather than an outage.
Under replicated partitions mean the configured redundancy is temporarily absent; offline partitions mean there is no leader at all and neither reads nor writes are possible. Both should be zero on a healthy cluster.

Domain 3: Kafka Connect

Key concepts you must know · 113 practice questions

A source connector reads from an external system into Kafka and tracks its position there; a sink connector consumes from Kafka into an external system and behaves as an ordinary consumer group, so its progress shows up as consumer lag.
A connector divides its work into tasks, and the maximum task setting is an upper bound rather than a guarantee. A sink cannot usefully run more tasks than the topics have partitions.
Converters decide how records are serialized between the framework's internal form and the bytes stored in Kafka, and the key and value are configured separately. A mismatch is the most common Connect configuration error.
Single message transformations are stateless and per record: masking a field, renaming one, routing to a different topic. Anything that needs memory of other records belongs in a stream processing application instead.
Distributed mode keeps connector configuration, offsets and status in internal Kafka topics, which is what allows any worker to pick up the work when another fails. Those topics deserve a replication factor of three in production.
A sink connector normally delivers at least once, because the write to the destination and the offset commit cannot be made atomic for an arbitrary system. The usual answer is an idempotent write keyed on something stable in the record.
Error tolerance without a dead letter destination is data loss with extra steps. Enable the destination, enable the headers that record the origin and the failure, and alert on the volume arriving there.
The management interface is a control plane: anybody who can reach it can create a connector that copies a sensitive topic somewhere else, so it belongs behind authentication.

Domain 4: Application Observability

Key concepts you must know · 98 practice questions

Consumer lag is the log end offset minus the group's committed offset. Watch it per partition rather than only in aggregate, because a healthy total can hide one member that is stuck.
The trend matters more than the value. A batch application can sit on a large lag quite healthily, while a small lag that grows every minute is heading towards an incident.
On the producer side, the failed send rate says whether records are arriving at all, and the request latency separates a slow cluster from an application producing faster than the cluster accepts.
Time spent between successive poll calls shows work being lost inside the application rather than in Kafka, which is exactly the case where adding brokers or partitions changes nothing.
Breaking broker request latency into queue time, local write time and replication wait points at three different causes: not enough request handlers, a struggling disk, or replication falling behind.
A meaningful client identifier is what lets a misbehaving application be traced from broker side logs and lets a quota be applied to one team rather than to everything.
A synthetic produce and consume probe catches the class of failure where every component metric looks healthy and yet no real client can write, such as a permissions change or a network path broken only for clients.
An alert is useful when it fires on something that needs a person to act and points at what to check first. Everything else trains people to ignore the next page.

Domain 5: Apache Kafka Streams

Key concepts you must know · 90 practice questions

A stream is an unbounded sequence of independent facts; a table is a view where the latest record for each key is the current value. Each can be derived from the other, which is why a compacted topic can back a state store.
One task is created per input partition and tasks are spread over the running instances, so the partition count caps parallelism exactly as it does for a plain consumer group.
The application identifier names the consumer group and prefixes the internal topics, so changing it creates a brand new application with no committed offsets and no state.
Changing a record's key requires a repartition, which is a genuine write to an internal topic and a read back. Joins additionally require co-partitioning, and a mismatch produces silently missing matches rather than an error.
State stores are local and backed by a compacted changelog topic, which is what lets a failed instance rebuild elsewhere. Standby replicas and a persistent state directory are the two ways to shorten that restore.
Event time makes results reproducible on a replay; processing time does not. Stream time advances only as records arrive, which is why a quiet topic leaves windows open long after the wall clock has moved on.
Tumbling windows do not overlap, hopping windows do, and session windows are bounded by a gap in activity and vary in length. A grace period trades promptness against accepting late records.
Exactly once processing writes the results and the offsets in one transaction, so a failure part way through leaves neither. The cost is the commit interval showing up as end to end latency.

Domain 6: Application Testing

Key concepts you must know · 67 practice questions

A topology test driver runs the topology in the test process with no cluster at all, which makes the tests fast and deterministic enough to run on every commit.
Supply timestamps with the input records rather than waiting on a clock. One test can then exercise an on time record, a late one and an out of order one precisely.
Mock producers and consumers let the application's own logic be asserted - which topic, which key, how many records, and what happens to a record that cannot be processed - without any network.
Test the unhappy paths deliberately: a payload that cannot be deserialized and a well formed record that fails a business rule are handled quite differently and both need covering.
Integration tests earn their cost only where real serialization, real network conditions or real access rules are involved. Everything else belongs in the fast suite.
Give each integration test its own topic names and consumer group so tests can run in parallel and no run inherits state from the last one.
Verify at least once behaviour by injecting a failure between processing and the commit, then asserting that the replay leaves the destination unchanged. That is what proves the write is genuinely idempotent.
Put a schema compatibility check in the build. Failing a build is far cheaper than failing a deployment, and it protects the consumers other teams own.

Confluent Certified Developer for Apache Kafka (CCDAK) exam tips

When a question describes a symptom, decide first whether it lives in the client, the cluster or the application's own processing loop. Most CCDAK scenarios resolve as soon as that boundary is drawn.
Read every durability question as a pair. Acknowledgements set to all mean nothing without a minimum in sync replica count above one, and the minimum means nothing without the acknowledgements.
Anything that mentions ordering is really asking about the key and the partition. Ordering exists inside a partition and nowhere else.
For consumer group questions, count the partitions. If the option adds members beyond the partition count, it adds idle processes rather than throughput.
Treat at least once as the default and idempotent writes as the remedy. A question that offers to remove duplicates at the broker is offering something that does not exist.
Connect moves data between Kafka and external systems; Streams processes data within Kafka. When an option puts one of them in the other's job, it is usually the wrong answer.
In windowing questions, check whether stream time can actually advance. A window that never closes on a quiet topic is expected behaviour, not a defect.
For testing questions, ask what the option needs a real cluster for. If the answer is nothing, it belongs in the fast in process suite.

Study guide FAQ

What is the CCDAK exam format?

The Confluent Certified Developer for Apache Kafka exam is proctored, runs for 90 minutes and is delivered in English. Confluent does not publish a numeric pass mark, so a result is reported as a pass or a fail rather than as a score out of a hundred.

How long is the certification valid?

The certification expires two years after it is awarded. Plan a refresh before that date, particularly because the Kafka client and Connect surface both move meaningfully over a two year period.

Is CCDAK a developer exam or an operations exam?

It is aimed at developers building applications on Kafka. Cluster fundamentals are covered because applications depend on them - replication, retention, metadata and the in sync replica set all shape what a client can rely on - but the questions are asked from the application's point of view rather than the operator's.

How much Kafka Streams knowledge is required?

Enough to reason about the model rather than to recall an API. Streams and tables, tasks and partitions, state stores and their changelogs, event time and stream time, the window types, joins and their co-partitioning requirement, and what exactly once processing does and costs.

Do I need to know Kafka Connect in detail?

You need the shape of it: source and sink connectors, workers and tasks, converters and transformations, the internal topics that distributed mode relies on, the delivery guarantee a sink normally provides, and how error tolerance and dead letter routing should be configured together.

What is the most common reason candidates lose marks?

Choosing an answer that is true in isolation but does not address the scenario. Several options in a typical question describe real Kafka behaviour; the one that scores is the one that answers the question actually asked, which is usually about a trade-off rather than a fact.

Related Data resources

Test yourself: 751 Confluent Certified Developer for Apache Kafka (CCDAK) practice questions