CCDAK Exam Guide: Scope, Weighting, Registration, and Study Plan

CCDAK is a certification focused on Kafka application development: Producer/Consumer, Schema Registry, Kafka Streams, Kafka Connect, and security/observability. It tests design decisions (delivery guarantees, schema evolution, parallelism, and operational trade-offs) rather than rote terminology.

This guide is based on the stable specs in the official documentation and explains the most frequently tested topics from a hands-on perspective. Always confirm the latest exam specifications on the Confluent certification page.

CCDAK Overview and Real-World Value

CCDAK is a certification for developers building Kafka-based applications. It evaluates correctness in data design and API usage, plus your ability to reason about availability, fault tolerance, and consistency. Its main focus areas are Producer/Consumer implementation, schema management with Schema Registry, stream processing with Kafka Streams, and data integration with Kafka Connect.

The exam covers vendor-neutral Kafka core concepts (topics/partitions, replication, ISR, leader election, consumer groups), delivery guarantees (at-most/at-least/exactly-once), security (TLS/SSL and SASL concepts), and monitoring (key broker and client metrics), along with practical usage of the Confluent platform (Schema Registry, Connect, Streams).

• Target roles: application developers, data engineers, and tech leads for streaming platforms
• Tasks covered: Producer/Consumer implementation, designing zero/one/many delivery guarantees, schema evolution and compatibility, Streams topology design, and Connect sink/source integration
• Skills emphasized: being able to justify the right configuration choices (acks, idempotence, retries, offset management, and the scope of ordering guarantees)

Exam Scope and Weighting Estimates

The exact weighting is adjusted by exam version. The ranges below are estimates based on the official domains. Questions rarely stay inside a single domain (for example, Producer retry control combined with the broker's min.insync.replicas), so you need to be able to reason across domains.

Streams and Schema Registry/SerDes are tested at the design level: state management, repartitioning, and compatibility strategies. Operational commands stay within a developer's perspective: checking consumer groups and reading latency and throttle metrics.

• Kafka fundamentals (topics/partitions/replication/ISR/leaders): ~15-20%
• Producer/Consumer (acks, retries, idempotence, transactions, offset management): ~25-30%
• Schema Registry and SerDes (Avro/JSON Schema/Protobuf, compatibility modes, evolution): ~10-15%
• Kafka Streams (state stores, repartitioning, processing guarantees, joins/aggregations): ~20-25%
• Kafka Connect (sources/sinks, distributed mode, error handling/DLQ, transforms): ~10-15%
• Security/monitoring (SSL/SASL concepts, key metrics, client and broker settings): ~10-15%

Registration, Delivery Modes, and Exam Day Flow

Register through the Confluent certification page. After creating an account, select CCDAK from the exam catalog and book your delivery mode (online proctored or test center) and time. Complete the environment requirements (camera, microphone, stable connection, ID) and the system check in advance.

Exam length, question count, and passing criteria are adjusted by version. The exam is primarily delivered in English. Always check the official policies for retakes, cancellations/reschedules, expiration, and the handling of fees and vouchers.

• Book through the official certification page; government-issued ID is required
• For online proctoring: quiet private room, clear desk, camera and microphone on at all times
• Run the system check (connection, browser, security settings) ahead of time
• Rules for retakes and reschedules vary by version and region; check the official policies

Pass Roadmap (Sample 4-Week Plan)

Build up in a focused sprint: fundamentals first, then APIs, then the processing platform. Every week, include hands-on exercises (running locally or in containers, breaking things and then fixing them) and tie each configuration to the behavior you observe.

Aim to explain how behavior changes when you tweak configuration (duplicates, ordering, latency, rebalancing, throughput/fault-tolerance trade-offs) rather than memorizing facts.

• Week 1: core concepts (partitions/replication/ISR, consumer groups, rebalancing) and the key CLI tools
• Week 2: Producer/Consumer API (acks, retries, delivery.timeout.ms, idempotence, offset commits)
• Week 3: Schema Registry (compatibility modes/evolution) and Kafka Streams (state, repartitioning, EOS)
• Week 4: Kafka Connect (distributed mode, DLQ/retries), security concepts, plus mock exams and weak-spot drills
• Hands-on exercises tied to real work: schema evolution with Avro, aggregations with Streams, and RDB→Kafka→object storage via Connect

Deep Dive: Delivery Guarantees and Exactly-Once

Producer delivery guarantees emerge from the interaction of acks, retries, enable.idempotence, max.in.flight.requests.per.connection, and delivery.timeout.ms. Combining an idempotent producer with transactions (transactional.id) gives you duplicate-free, commit-level atomicity inside Kafka. On the consumer side, set isolation.level=read_committed so you only read committed records, completing the EOS picture.

In Kafka Streams, use processing.guarantee=exactly_once_v2. It bundles the underlying producer/consumer settings (transactions and idempotence) correctly and guarantees consistency between state stores and output topics. End-to-end EOS that includes external systems is system-dependent: if a sink outside Kafka is not idempotent or transactional, design for at-least-once at minimum.

• Pair acks=all with min.insync.replicas. When the ISR drops below the threshold, writes fail safely instead of silently losing data
• With idempotence on, cap max.in.flight at 5 or below (1 for strict ordering). High retries no longer create duplicates
• Transactional producers need a unique transactional.id, and consumers must use read_committed
• For Streams, prefer exactly_once_v2. The legacy setting remains compatible, but v2 is the stable choice for new code

Data flow and consumer-group parallelism

Configuration example: Idempotent Producer and Kafka Streams EOS

// Java Producer (idempotence + transactions)
Properties p = new Properties();
p.put("bootstrap.servers", "localhost:9092");
p.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("acks", "all");
p.put("enable.idempotence", "true");
p.put("retries", Integer.toString(Integer.MAX_VALUE));
// Use 1 for strict ordering, <=5 for throughput
p.put("max.in.flight.requests.per.connection", "1");
p.put("transactional.id", "orders-txn-001");
KafkaProducer<String, String> producer = new KafkaProducer<>(p);
producer.initTransactions();
try {
  producer.beginTransaction();
  producer.send(new ProducerRecord<>("orders", "k1", "v1"));
  // Bundle multiple records into a single transaction
  producer.commitTransaction();
} catch (Exception e) {
  producer.abortTransaction();
}
producer.close();

// Java Consumer (read committed)
Properties c = new Properties();
c.put("bootstrap.servers", "localhost:9092");
c.put("group.id", "orders-app");
c.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
c.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
c.put("isolation.level", "read_committed");

// Kafka Streams (EOS v2)
Properties s = new Properties();
s.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
s.put(StreamsConfig.APPLICATION_ID_CONFIG, "payments-streams");
s.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, StreamsConfig.EXACTLY_ONCE_V2);
StreamsBuilder b = new StreamsBuilder();
KStream<String, String> in = b.stream("payments");
in.groupByKey().count(Materialized.as("cnt")).toStream()
  .to("payments-agg", Produced.with(Serdes.String(), Serdes.Long()));
KafkaStreams app = new KafkaStreams(b.build(), s);
app.start();

Building Mock Drills and Test-Day Techniques

Many questions ask "which configuration best satisfies these requirements?". Fix your reading order (eliminate unrealistic options first), then between the remaining two pick the one closest to the requirements. For numeric and timeout settings, keep their interactions in mind (for example delivery.timeout.ms with retries x linger x batch.size).

Build your own mocks as requirement → configuration → observation triples. For example, compare Producer configurations under three constraints (no duplicates, strict ordering, high throughput) and observe the failure modes when you change the broker's min.insync.replicas. Be ready to use the CLI to check consumer-group lag and to verify a topic's partition count and assignment.

• Classic wrong answers: claiming acks=1 is "safe", claiming EOS without idempotence, or consuming while still on read_uncommitted
• Spot when Streams needs a repartition (parallelism and shuffling after keyBy/groupBy)
• Schema compatibility shines on questions about whether adding fields is safe (when to use BACKWARD / FORWARD / FULL)
• Time management: lock in the easy questions on pass 1, mark the hard ones, and review them carefully on pass 2

Check Your Understanding

Frequently Asked Questions