Confluent's CCDAK exam guide fits on four pages, and almost everything useful in it is in one table: six domains with a percentage next to each. Application Development carries 28%, Fundamentals 23%, and the other four share the remaining 49%. If you plan your study hours from that table rather than from a course's chapter list, you are already ahead of most candidates.
Quick Facts
Everything below comes from official CCDAK exam documentation. Where Confluent does not state something, the table says so.
| Item | What Confluent states |
|---|---|
| Exam | Confluent Certified Developer for Apache Kafka (CCDAK) |
| Duration | 90 minutes, proctored |
| Delivery | Remote proctoring from anywhere that meets the internet, security and privacy requirements |
| Question formats | Multiple choice, multiple response, matching, build list (ordering) |
| Question count | Not published in the exam guide |
| Passing score | Not published in the exam guide |
| Retake policy | Wait 7 days before purchasing and taking the exam again |
| Validity | The certification expires after two years; you re-certify every two years |
| Results | Shown immediately on the testing screen |
| Prerequisites | A training class is not required |
| Exam fee | Not stated on the pages above; check Confluent's registration page for the current price |
TL;DR
- Six domains, with weights that add to 100%: Fundamentals 23%, Application Development 28%, Kafka Streams 12%, Kafka Connect 15%, Application Testing 8%, Application Observability 13%.
- The guide lists several areas as out of scope: Confluent components (RBAC, ksqlDB, CFK), system-specific connectors, plugins and extensions, networking, administering and deploying Kafka, and infrastructure provisioning.
- The exam is built around developer tasks: producing and consuming, configuring clients, modelling topics, writing Streams applications, deploying connectors, testing and monitoring.
- You get 90 minutes, a webcam-and-microphone proctored session in Google Chrome, and no reference materials.
- Confluent does not publish a question count or a pass mark, so you cannot calibrate to a target score. Practise by domain instead.
What the Exam Guide Actually Says
The CCDAK guide describes a candidate who can publish data to and subscribe from an Apache Kafka cluster and use Kafka to develop streaming applications. It names Software Engineers, Data Engineers, Analysts, Administrators and Developers as the audience.
It then lists product knowledge you are expected to hold: Kafka basic principles, data replication, data retention, security, the data model of topics, partitions and offsets, client configuration and tuning (batching and parallelism), tools and APIs, application metrics, error handling (retryable versus non-retryable), message headers and Kafka Connect.
The general IT knowledge list is just as concrete: fluency in a language such as Java, Python or C#, serialization formats (Avro, JSON, Proto), schema evolution, deploying applications including Kafka Streams apps with Docker or Kubernetes, message keying and key hashing, data modelling, data security (encryption), distributed systems, and performance tuning and scaling.
Notice what is missing. There is no operations content. The out-of-scope list includes administering and deploying Kafka, networking and infrastructure provisioning, so time spent on broker tuning or cluster rollouts should go toward client code instead.
The guide also says plainly that its example topics are there to clarify the objectives and "should not be construed as a comprehensive listing". Treat every bullet as a pointer to a whole area, not as a checklist you can tick off with one reading.
The Six Domains and Their Weights
Map your hours to the official weights before you open a course.
| Section | Official name | Weight |
|---|---|---|
| 1 | Apache Kafka Fundamentals | 23% |
| 2 | Apache Kafka Application Development | 28% |
| 3 | Apache Kafka Streams | 12% |
| 4 | Kafka Connect | 15% |
| 5 | Application Testing | 8% |
| 6 | Application Observability | 13% |
If you have 50 hours, a proportional split gives about 14 hours to Application Development, 11.5 to Fundamentals, 7.5 to Connect, 6.5 to Observability, 6 to Streams and 4 to Testing. That is a starting point for your own plan, not a Confluent recommendation. Shift hours toward the domains where your practice scores are weakest.
Section 1: Apache Kafka Fundamentals (23%)23%
This section covers the data model and the guarantees underneath it: brokers, topics, partitions, offsets, replicas, leader election and in-sync replicas. Know why ordering is guaranteed within a partition and not across a topic, and how the message key decides which partition a record lands in.
Replication and durability settings belong here too. Be able to explain how acks=all and min.insync.replicas interact when a replica falls behind, and what a producer sees when too few replicas are in sync.
Retention and compaction are part of the data-retention knowledge the guide lists. Know what time-based and size-based retention delete, what log compaction keeps (the latest value per key), and how a tombstone record signals deletion.
Serialization and schema evolution sit alongside these topics in the guide's knowledge lists. Schema Registry compatibility modes (backward, forward, full) determine which side, producers or consumers, can be upgraded first without breaking the other.
Section 2: Apache Kafka Application Development (28%)28%
The largest domain is where most of the exam's practical weight sits. The task list includes connecting to a secured cluster, producing and consuming, defining topic configurations such as partitions, understanding compression, using the Admin API, deploying and tuning clients, and implementing processing semantics such as exactly-once and at-least-once.
Producer batching is a good example of a tuning area. linger.ms, batch.size and compression interact: a longer linger and a larger batch raise throughput and add latency. Practise predicting the effect of changing one setting while holding the others fixed.
For delivery guarantees, learn the chain rather than single settings. An idempotent producer (enable.idempotence=true) prevents duplicates caused by retries within a producer session. Adding a transactional.id enables the transactions API for atomic writes across partitions. A consumer reads only committed transactional data when isolation.level=read_committed. Each piece does a specific job, and exactly-once questions usually test whether you can see which piece is missing.
Consumer groups deserve hands-on time: partition assignment, rebalancing, and offset commits. Know the trade-off between commitSync (blocks until the broker confirms) and commitAsync (higher throughput, but you handle failures in a callback), and what happens to uncommitted work when a rebalance happens.
Error handling is listed in the guide as retryable versus non-retryable. Be able to say which producer and consumer errors are worth retrying, and which should be surfaced or routed elsewhere.
Finally, work with Kafka from the command line, as the task list says. Create a topic, produce and consume with the console tools, and inspect consumer group lag.
Section 3: Apache Kafka Streams (12%)12%
Streams is a smaller domain at 12%, but the vocabulary is specific. Know the difference between a KStream (an unbounded sequence of events) and a KTable (the latest value per key), and how a GlobalKTable is replicated to every application instance instead of being partitioned.
Joins deserve careful study. A stream-table join looks up the current table value for each stream record, while a stream-stream join needs a time window because both sides are streams. Co-partitioning (same key, same partition count) is required for most joins; a GlobalKTable avoids that requirement.
Windowing comes in tumbling, hopping, sliding and session forms. Learn how each decides which records belong together, and how state stores back aggregations. The guide's task list also names deploying Streams applications, with Docker or Kubernetes as examples, so know that state and scaling are tied to partitions and tasks.
For processing guarantees, Streams exposes a single setting, processing.guarantee, and exactly_once_v2 is the current exactly-once option. Understand that it builds on the same transactions concept you studied for producers.
Section 4: Kafka Connect (15%)15%
The guide expects you to configure and deploy connectors and to understand core concepts including sink, source and CDC (change data capture). It also lists system-specific connectors as out of scope, so you do not need to memorise the options of any one connector.
Know the two deployment modes. Standalone runs one worker and keeps offsets in a local file, which suits development. Distributed mode runs a cluster of workers that store configuration, offsets and status in Kafka topics and rebalance work when a worker leaves.
Learn the pieces of a connector configuration: converters (key and value), transforms (Single Message Transforms applied in order), and error handling (errors.tolerance and a dead letter queue for sink connectors). Mismatched converters between the data in a topic and the connector configuration are one of the most common real-world failures, so they make good practice material.
Drive Connect through its REST API at least once. Creating, pausing, resuming, restarting and deleting a connector with curl makes the lifecycle concrete in a way reading never does.
Section 5: Application Testing (8%)8%
Testing is the smallest domain. The guide's task is simply to test Kafka client applications. In practice that means knowing the testing utilities that ship with the Kafka libraries: MockProducer and MockConsumer for client code, and TopologyTestDriver for Streams topologies, which runs a topology without a broker.
Because it is only 8%, give it a short, focused session rather than a week. Write one unit test for a producer, one for a consumer and one for a small topology, and you will have covered the idea.
Section 6: Application Observability (13%)13%
The guide lists monitoring applications and troubleshooting Kafka applications. Concentrate on metrics that tell you whether a client is healthy: consumer lag, request latency, record send and error rates, and batch size. Learn what each one means and what a sensible reaction is when it moves.
Know also how to tell apart similar-sounding metrics, such as a lagging consumer and an under-replicated partition. They point at different problems, one in the application and one in the cluster.
How to Study
Start with the free CCDAK practice questions at CertCompanion to identify your weakest domains, then study those domains using the official exam guide and the official Confluent learning resources it names: the Apache Kafka Fundamentals learning path, Kafka Connect 101, Kafka Streams 101, Designing Events and Event Streams, Practical Event Modeling, and Designing Event Driven Microservices. The official exam guide also recommends a three-day instructor-led class (Developing with Confluent) for candidates who want structured classroom coverage, though a training class is not required to sit the exam.
Build as you read. A local Docker Compose environment with a broker, Schema Registry and Connect is enough to try every task in the guide: configure an idempotent and a transactional producer, read with read_committed, run a Streams topology, deploy a connector through the REST API, and watch consumer lag change as you pause a consumer.
Date every resource you use. Confluent's current guide marks ksqlDB, RBAC and CFK as out of scope, so older material that spends chapters on them is covering content the guide excludes.
A Real Question That Shows How the Exam Thinks
Reasoning Through a Kafka Connect Converter Question
The question below tests a configuration trap that appears in real deployments: converter settings that do not match the data in the topic. Read the scenario, work out the answer yourself, then compare with the reasoning.
A Kafka Connect distributed worker is configured with key.converter=org.apache.kafka.connect.json.JsonConverter and value.converter=io.confluent.connect.avro.AvroConverter. A source connector produces records with string keys and Avro values. Where does the conversion from internal Connect format to wire format occur? (Select one!)
- A. In the Kafka Connect worker after receiving from the connector
- B. In the source connector before sending to the worker
- C. In the Schema Registry when registering the schema
- D. In the Kafka broker when writing to the topic
Show the answer and the reasoning
Correct answer: A. In the Kafka Connect worker after receiving from the connector
Kafka Connect uses a two-step conversion process. Source connectors produce records in Kafka Connect's internal format (SourceRecord objects). The Kafka Connect worker then applies the configured converters (key.converter and value.converter) to transform these internal records into the wire format before sending to Kafka topics. This separation allows connectors to be reusable with different serialization formats. Converters run in the worker, not in the connector code itself. The broker stores data as bytes without conversion. Schema Registry is used by AvroConverter to register schemas and retrieve schema IDs, but the actual serialization happens in the worker.
The takeaway is that connector configuration is layered. Worker-level defaults and connector-level overrides both apply, so a symptom in the sink often traces back to a converter choice made somewhere else.
Practice Questions: What's in the CertCompanion Bank
| CCDAK question bank | |
|---|---|
| Questions | 624 |
| Single-answer | 574 |
| Select-all-that-apply | 50 (8%) |
| Median explanation length | 99 words |
The CertCompanion CCDAK bank is organised around the six domains in Confluent's exam guide. Start with the free set at /exams/confluent-developer-apache-kafka to see which domains need the most attention, then spend your hours where your scores are lowest.
You can also browse the full Confluent exam library to see what else is available if you are planning a broader Confluent certification path.
Booking and Exam Day
Confluent's exams are 90-minute proctored sessions that you can take remotely. You need a computer with a camera, a microphone and speakers, the Google Chrome browser, a strong internet connection and a government ID to verify your identity. Install the Honorlock Chrome extension and run its system check before your exam; Confluent warns that an attempt may be forfeited if your connection does not meet the requirements.
Reference materials and mobile phones are not allowed during the exam. Proctors monitor you for the whole session.
Confluent lets you reschedule or cancel an appointment five or more calendar days before it. Within five days, rescheduling is not available, and a candidate who cancels in that window has to reapply before scheduling a new appointment. If you miss the window, the exam fee is nonrefundable.
If you need an accommodation for a disability, Confluent asks you to contact its certification team at least 21 days before your test date.
After the exam, results appear immediately on the testing screen. If you pass, you earn the credential and may use the certification title and logo, in line with the Confluent Certification Agreement. If you do not pass, wait 7 days before purchasing and taking another attempt.
Because the exam is 90 minutes and Confluent does not publish a question count, pace yourself by checking the clock at regular intervals rather than against a fixed seconds-per-question figure. Flag anything that needs a second read and come back to it.
Frequently Asked Questions
Does ksqlDB appear on the CCDAK exam? Confluent's exam guide lists RBAC, ksqlDB and CFK together as out of scope Confluent components. Spend your Streams time on the Kafka Streams library.
Is there a published passing score? Not in the exam guide. Confluent's exam guide does not state a pass mark, so treat any number you see elsewhere as unofficial.
How many questions are on the exam? The exam guide does not state a question count. It gives the 90-minute duration and the item formats.
What question formats should I expect? The guide lists multiple choice, multiple response, matching and build list, where you put items into the right order.
How long does the CCDAK certification last? Official exam documentation states the certification expires after two years and that you re-certify every two years.
What is the retake policy? Official exam documentation states candidates must wait 7 days before purchasing and taking another exam.
Do I need to attend a training class? No. Confluent says a class is not required, though it recommends the online study guide and the training listed in the exam guide.
Where can I find free practice questions? CertCompanion's CCDAK question bank has a free starter set with explanations, which is the quickest way to find your weakest domains before you commit to a study plan.
The CCDAK rewards developers who have written Kafka client code. Use the weights in the exam guide to plan your hours, build each task on the guide's list at least once, and use practice questions to find the domains that still need work.
Start with the free CCDAK practice questions at CertCompanion and find out which domains need the most attention before you book the exam.
Checked against official Confluent CCDAK exam documentation and current candidate reports. Last verified 2026-11-01.