What Does the Confluent CCDAK Exam Cover?

Confluent CCDAK is a 60-question, 90-minute exam priced at $150 USD and graded pass or fail without a published threshold. It covers six weighted domains: Apache Kafka Application Development (28%), Apache Kafka Fundamentals (23%), Kafka Connect (15%), Application Observability (13%), Apache Kafka Streams (12%), and Application Testing (8%).

Question style and pacing

Ninety seconds per question is comfortable, which tells you the difficulty is conceptual rather than time-driven. Questions tend to describe a behaviour – messages duplicated, a partition unassigned, throughput collapsing – and ask for the cause or the configuration that fixes it.

Where the marks concentrate

Development and fundamentals together are 51 percent, so more than half the exam rests on producers, consumers, and the mental model beneath them. Candidates who spend their preparation on Streams because it sounds hardest are optimising for seven questions while neglecting thirty-one. Official programme details are on Confluent’s certification page.

Kafka Fundamentals Is 23% – What Must You Know Cold?

Apache Kafka Fundamentals covers topics, partitions, offsets, brokers, replication, and the guarantees the log provides. At 23 percent it is the second-largest domain, and it underpins every other one – a shaky mental model here produces wrong answers throughout the exam.

The partition: the core concept

The partition is the single most important concept. A topic is a logical name; the partition is the physical, ordered, append-only log that actually stores records. Kafka guarantees ordering within a partition and offers no ordering guarantee across partitions – which is the root cause of most “why did my messages arrive out of order” questions.

How keys drive partitioning and ordering

That leads directly to keys. A record with a key is assigned to a partition by hashing that key, so all records sharing a key land in the same partition and preserve their relative order. A record without a key is distributed across partitions, sacrificing ordering for balance. Choosing a key is therefore an ordering decision, not a metadata decision.

• Partition – ordered append-only log; the unit of parallelism and of ordering
• Offset – position within a partition; monotonically increasing and never reused
• Replication factor – number of copies of each partition across brokers
• ISR – the in-sync replica set, replicas sufficiently caught up to the leader
• Retention – how long records persist, by time or size, independent of consumption

Why retention breaks queue intuition

Retention is worth emphasising because it violates the intuition of anyone arriving from traditional message queues. Consuming a record does not remove it – records persist for the configured retention period regardless of how many consumers have read them, which is precisely what allows replay and multiple independent consumer groups. The Apache Kafka documentation is the authoritative reference for these guarantees.

Application Development Carries 28% – Where Do Candidates Lose Marks?

Apache Kafka Application Development is the largest domain at 28 percent, covering producer and consumer implementation, configuration, serialisation, and consumer group behaviour. Marks are lost most often on configuration semantics – knowing what a setting does rather than that it exists.

Producer settings that recur

On the producer side, the settings that recur are acks, retries, and the batching controls. Understand that acks=0 never waits, acks=1 waits for the leader only, and acks=all waits for the full in-sync replica set – and that acks=all alone does not guarantee durability unless min.insync.replicas is configured sensibly alongside it. That pairing is a favourite exam trap.

Batching and throughput

Batching is the throughput lever. Records accumulate into batches controlled by batch.size and linger.ms; increasing linger deliberately adds latency to gain throughput. Questions often describe a throughput problem and expect you to identify the batching trade-off rather than reach for more partitions.

Consumer groups

On the consumer side, consumer groups are the concept to master. Partitions are distributed among consumers in a group so that each partition is consumed by exactly one member – which means adding more consumers than partitions leaves the surplus idle. This single fact answers a surprising number of questions about consumers “doing nothing”.

Offset management and its trade-off

Offset management is the other high-value area. Know the difference between automatic and manual commits, and understand that committing before processing risks message loss while committing after processing risks duplicates. There is no configuration that eliminates both – which leads directly into delivery semantics.

How Do Delivery Semantics Actually Work in Kafka?

Kafka supports at-most-once, at-least-once, and exactly-once semantics, and CCDAK expects you to explain what each guarantees and what configuration produces it. Exactly-once is real but narrower than the name suggests – it applies within Kafka, not to arbitrary external side effects.

The three semantics, defined

At-most-once means a record may be lost but never duplicated, achieved by committing offsets before processing. At-least-once means a record is never lost but may be redelivered, achieved by committing after processing – and it is the default expectation for most systems. Exactly-once means each record affects state once, achieved through the idempotent producer and transactions.

The idempotent producer

The idempotent producer deserves specific attention. It assigns sequence numbers so a broker can discard a retried duplicate, which eliminates duplicates introduced by producer retries – a common cause of duplication that many engineers wrongly attribute to consumer behaviour.

The exactly-once limitation to remember

The critical limitation, and a reliable exam target, is that exactly-once covers reads and writes within Kafka. If your consumer writes to an external database, that write is outside the transaction, so idempotent handling in the destination remains your responsibility.

What Does Kafka Connect Contribute at 15%?

Kafka Connect is worth 15 percent and covers the framework for moving data between Kafka and external systems without writing custom code. The exam tests architecture and configuration concepts – source versus sink connectors, workers, tasks, converters, and transformations.

Source versus sink connectors

The core distinction is directional: a source connector pulls data into Kafka from an external system, a sink connector pushes data from Kafka out to one. Candidates occasionally invert this under pressure, and several questions hinge on getting it right.

Workers, tasks, and scaling

Understand the execution model. A connector is a configuration; the work is performed by tasks, which are distributed across workers. Scaling means increasing task count, bounded by what the source can actually parallelise – a database table with a single incrementing column cannot be split arbitrarily.

Converters and transforms

Converters are the subtle topic. They handle serialisation between Kafka’s byte arrays and the connector’s data model, and are configured independently for keys and values. A mismatch between the converter used to write and the one used to read is a classic failure that questions like to describe indirectly. Single Message Transforms round out the domain, performing lightweight per-record changes such as renaming or masking a field in flight; anything requiring joins or aggregation belongs in Streams instead. Confluent’s platform documentation covers connector configuration in depth.

Is Kafka Streams Worth Deep Study at Only 12%?

Apache Kafka Streams is worth 12 percent – roughly seven questions – so it merits solid conceptual understanding rather than deep mastery. The exam tests the stream and table duality, stateful versus stateless operations, windowing, and how state stores work.

The stream-table duality

The stream-table duality is the central idea and the most likely question source. A stream is an unbounded sequence of events, each independently meaningful. A table is a snapshot of current state derived from those events, where a later record for the same key replaces the earlier one. The same underlying topic can be interpreted either way depending on what you need.

Stateless versus stateful operations

Stateless operations – filtering, mapping, branching – process each record independently and require no memory of what came before. Stateful operations – aggregations, joins, windowed counts – require retained state, which Kafka Streams keeps in local state stores backed by changelog topics so that state survives a restart or migration.

Windowing types

Windowing is where the remaining marks sit. Tumbling windows are fixed and non-overlapping; hopping windows are fixed but overlap by an advance interval; session windows are defined by gaps in activity rather than by clock boundaries. Knowing which windowing type a described requirement implies is usually enough. The Kafka Streams documentation covers the processing topology if you want more depth than the exam requires.

Why Does Application Observability Carry 13%?

Application Observability is worth 13 percent – more than Streams – because Kafka problems are usually operational rather than logical. The domain covers metrics, consumer lag, monitoring producer and consumer health, and diagnosing performance from observable signals.

Consumer lag: the key metric

Consumer lag is the metric that matters most. It measures how far behind a consumer group is relative to the latest offset in each partition, and it is the primary health indicator for any streaming pipeline. Steady lag means the consumer is keeping pace; growing lag means it cannot, and the cause could be slow processing, insufficient consumers, or an unbalanced partition assignment.

Which metric answers which question

Know which metrics answer which question. Producer-side record error rate and request latency indicate whether writes are succeeding and how quickly. Consumer-side fetch rate and records-consumed rate indicate throughput. Rebalance frequency is the diagnostic candidates most often overlook – frequent rebalances stall consumption entirely and usually indicate that processing is exceeding the poll interval.

The rebalance causal chain

That last point is worth internalising as a causal chain, because the exam describes it as a symptom rather than naming it: processing takes too long, the consumer misses its poll deadline, the group considers it dead, a rebalance triggers, consumption stops, and the backlog grows – making the next poll even slower.

How Is Application Testing Examined?

Application Testing is the smallest domain at 8 percent, roughly five questions, covering approaches to testing Kafka applications including embedded clusters, test utilities, and the topology test driver for Streams. It rewards awareness of the options rather than mastery of any framework.

Real broker versus no broker

The examinable distinction is between testing against a real broker and testing without one. Embedded or containerised clusters give realistic behaviour at the cost of speed and complexity; mock producers and consumers run fast and deterministically but cannot reproduce broker behaviour such as rebalancing.

The topology test driver

For Streams applications, the topology test driver is the specific tool worth knowing. It allows a processing topology to be tested without any running Kafka cluster by feeding records in and asserting on what comes out – making it the standard choice for unit-testing stream logic.

A testing pyramid for streaming

The reasoning the exam wants is a testing pyramid applied to streaming: fast deterministic tests for business logic, a smaller number of integration tests against a real broker for the behaviours only a broker exhibits. Given five questions, understanding when each approach is appropriate is sufficient preparation.

Who Should Pursue the CCDAK Credential?

CCDAK suits backend and data engineers building event-driven systems, platform engineers supporting streaming infrastructure, and developers whose organisations have adopted Kafka as a core integration layer. It assumes working programming ability and targets developers rather than cluster administrators.

Developer or administrator?

The developer-versus-administrator split is the key selection question. CCDAK covers building applications against Kafka – producers, consumers, Connect configuration, Streams topologies. The administrator credential covers running the cluster itself: broker configuration, capacity, security, and operations. Choose by which side of that line your work sits.

Value for data engineers

For data engineers the value is strongest where architectures are shifting from batch to streaming. Understanding delivery semantics, partitioning strategy, and consumer group behaviour is what distinguishes a pipeline that survives production from one that quietly loses or duplicates records under load.

How Should You Prepare for CCDAK?

Six to eight weeks at six to eight hours per week suits developers with some Kafka exposure. Effective CCDAK preparation runs a real cluster throughout, because the exam describes observable behaviours and you learn those fastest by producing them deliberately.

1. Weeks one to two – fundamentals. Run a local cluster, create topics with multiple partitions, and produce records with and without keys. Watch how keying changes partition assignment and ordering.
2. Weeks three to four – producers and consumers. This is the 28 percent domain. Work through acks, retries, batching, and offset commits. Deliberately create both a duplicate and a lost message so you understand the trade-off physically rather than theoretically.
3. Week five – Connect. Configure a source and a sink connector, then deliberately mismatch a converter so you recognise the failure signature.
4. Week six – Streams and testing. Build a simple topology with an aggregation and a windowed operation, and test it with the topology test driver.
5. Weeks seven to eight – observability and review. Monitor consumer lag under load, trigger a rebalance by exceeding the poll interval, then move to timed practice.

Weight time by the blueprint, not difficulty

Weight your time by the table rather than by difficulty. Development and fundamentals are 51 percent of the exam; Streams and testing together are 20 percent. The instinct to over-study Streams because it feels advanced is the most common preparation mistake this exam punishes. Timed work through the CCDAK practice exam questions shows whether your coverage matches the weightings.

Frequently Asked Questions

How many questions are on the CCDAK exam?

The exam contains 60 questions to be completed in 90 minutes, allowing roughly 90 seconds per question. The pace is comfortable, so difficulty comes from conceptual depth rather than time pressure.

What is the passing score for CCDAK?

Confluent reports results as pass or fail and does not publish a numeric threshold. Prepare for solid competence across all six domains rather than targeting a specific score.

How much does the CCDAK exam cost?

The exam fee is $150 USD. Confluent offers free self-paced training through its developer portal, so preparation can be done without additional cost beyond the exam itself.

Which domain carries the most weight?

Apache Kafka Application Development at 28 percent is the largest, followed by Kafka Fundamentals at 23 percent. Together they account for 51 percent, so producers, consumers, and the underlying log model deserve the most study time.

What is the difference between CCDAK and CCAAK?

CCDAK is the developer credential covering application building – producers, consumers, Connect, and Streams. CCAAK is the administrator credential covering cluster operation, broker configuration, security, and capacity management.

Does Kafka guarantee message ordering?

Only within a partition. Records in a single partition are strictly ordered by offset, but there is no ordering guarantee across partitions. Using a message key routes related records to the same partition and preserves their relative order.

Is exactly-once delivery genuinely possible in Kafka?

Yes, within Kafka, using the idempotent producer together with transactions. It does not extend to external side effects – if your consumer writes to a separate database, that write sits outside the transaction and needs its own idempotency handling.

How much Kafka Streams knowledge does the exam require?

Kafka Streams is only 12 percent, roughly seven questions. You need the stream-table duality, stateless versus stateful operations, windowing types, and how state stores work – not deep implementation expertise.

What causes frequent consumer group rebalances?

Most commonly, processing that exceeds the maximum poll interval. The consumer misses its deadline, the group treats it as failed, and a rebalance stops consumption entirely – which makes the growing backlog worse on the next attempt.

Do I need to know a specific programming language?

The exam is oriented toward Java client concepts, but it tests configuration semantics and behaviour rather than language syntax. Developers comfortable in any language can prepare successfully by focusing on client configuration and its consequences.

Conclusion

CCDAK rewards a correct mental model over broad familiarity. Almost every question traces back to a small set of ideas: the partition is the unit of ordering and parallelism, records persist independently of consumption, and every delivery guarantee is a deliberate trade between loss and duplication.

The published weightings are the most useful planning tool available. Development and fundamentals carry 51 percent between them while Streams carries 12 – so the instinct to spend weeks on stream processing because it feels like the hard part is exactly backwards.

Run a cluster from week one and break it deliberately. Produce a duplicate, lose a message, trigger a rebalance, mismatch a converter. The exam describes symptoms and asks for causes, and there is no faster way to learn those than to have caused them yourself.