Confluent · CCDAK
Confluent Certified Developer for Apache Kafka (CCDAK) Practice Test
Validates proficiency in building applications with Apache Kafka, covering Kafka fundamentals, application development using producer and consumer APIs, Kafka Streams, Kafka Connect, testing, and observability.
Exam Details
Questions
624
Duration
90 minutes
Passing Score
70%
Difficulty
AssociateLast Updated
Feb 2026
Confluent Certified Developer for Apache Kafka (CCDAK) Practice Exam Preparation
Use this CCDAK practice exam to prepare for Confluent Certified Developer for Apache Kafka (CCDAK) with realistic questions, detailed explanations, and focused study modes. The practice bank includes 624 questions for Confluent CCDAK, so you can review the exam steadily instead of relying on one long cram session.
As you practice, pay extra attention to patterns in your missed answers. Start with short sessions to identify weak areas, then move into timed quizzes once your accuracy is consistent.
The explanations are especially useful when you want to connect exam wording to the responsibilities and scenarios described in the official certification guidance. Use the free preview first, then unlock the full question bank when you are ready to build a complete study routine.
Exam Domain Breakdown
Apache Kafka Fundamentals23%
Apache Kafka Application Development28%
Apache Kafka Streams12%
Kafka Connect15%
Application Testing8%
Application Observability13%
Exam Overview
The Confluent Certified Developer for Apache Kafka (CCDAK) is a vendor-issued certification from Confluent — the company founded by the original creators of Apache Kafka — that validates a developer's ability to build, deploy, and maintain production-grade applications on the Kafka platform. The exam covers the full spectrum of Kafka application development: core architecture, the Producer and Consumer APIs, Kafka Streams for real-time stream processing, Kafka Connect for data integration, Schema Registry with Avro serialization, and application testing and observability practices.
The certification is positioned at the associate level and reflects hands-on proficiency rather than surface-level familiarity. It tests knowledge of delivery semantics (at-most-once, at-least-once, and exactly-once), partition and offset management, serialization strategies, connector configuration, and stream processing topology design. The exam was last updated to align with the current Confluent Platform and covers both Apache Kafka open-source features and Confluent-specific components such as Confluent Schema Registry and ksqlDB basics.
Who Should Take This Exam
The CCDAK is aimed at software developers, backend engineers, and solutions architects who work with Kafka-based event streaming systems in professional environments. Ideal candidates have 6–12 months of hands-on experience working with Apache Kafka or Confluent Platform and are comfortable reading and writing code in Java, Python, or through RESTful interfaces.
This certification is particularly relevant for engineers building real-time data pipelines, event-driven microservices, or stream processing applications at companies in finance, healthcare, technology, and media — industries where Kafka is commonly deployed at scale. It is also a strong credential for architects who design Kafka-based solutions and need to validate their technical depth to employers or clients.
Prerequisites
Confluent does not enforce formal prerequisites for the CCDAK, but the exam assumes 6–12 months of practical experience with Apache Kafka or Confluent Platform. Candidates should be comfortable with core distributed systems concepts — topics, partitions, replication, brokers, and consumer groups — before attempting the exam.
Proficiency in at least one of Java, Python, or a RESTful API client is recommended, as the exam tests application-level knowledge of the Kafka client libraries. Familiarity with the Confluent Schema Registry, Avro serialization, and basic stream processing concepts will also be beneficial. No formal training course or prior Confluent certification is required.
Exam Format
The CCDAK consists of 55 multiple-choice and multiple-select questions delivered in a 90-minute timed session. The exam is fully remote and proctored online, and can be taken from any location worldwide that meets Confluent's internet connectivity, security, and privacy requirements; in-person testing center options are also available globally. The exam costs $150 USD and is valid for two years from the date of passing.
The passing threshold is 70%. Results are provided immediately upon completion. The exam does not include unscored pilot questions in its published format. There is no partial credit on multiple-select questions.
Skills Measured
- 1.Apache Kafka Fundamentals (23%): Kafka architecture including brokers, topics, partitions, offsets, and replication; producer and consumer internals; delivery semantics (at-most-once, at-least-once, exactly-once); Kafka configuration tuning for performance and reliability; ZooKeeper and KRaft (KIP-500) awareness.
- 2.Apache Kafka Application Development (28%): Writing and configuring Java Producer and Consumer applications using the official Kafka client library; message serialization and deserialization; offset management strategies (auto vs. manual commit); consumer group coordination and partition assignment; use of Confluent Schema Registry with Avro, JSON Schema, and Protobuf; REST Proxy usage.
- 3.Apache Kafka Streams (12%): Building stateless and stateful stream processing topologies using the Kafka Streams DSL and Processor API; windowing operations (tumbling, hopping, sliding, session); KTable and KStream joins; interactive queries; fault tolerance and state store management.
- 4.Kafka Connect (15%): Architecture of Kafka Connect workers, source connectors, and sink connectors; connector configuration and deployment (standalone vs. distributed mode); Single Message Transforms (SMTs); dead letter queues; managing connectors via the REST API.
- 5.Application Testing (8%): Unit testing Kafka producers and consumers with MockProducer and MockConsumer; integration testing with EmbeddedKafka and Testcontainers; testing Kafka Streams topologies using the TopologyTestDriver; mocking Schema Registry for test environments.
- 6.Application Observability (13%): Kafka producer and consumer metrics (lag, throughput, error rates); JMX metric collection and monitoring strategies; logging best practices for Kafka clients; end-to-end latency measurement; alerting on consumer group lag using tools such as Confluent Control Center or third-party monitoring systems.
Study Tips
- Download the official Confluent CCDAK exam guide from training.confluent.io/examdetail/confluent-dev and map your study plan directly to the six published domains and their weights — prioritize Application Development (28%) and Kafka Fundamentals (23%) as they together account for over half the exam.
- Complete Confluent's official self-paced training courses on their training portal, particularly 'Apache Kafka Fundamentals Accreditation' and the Developer-focused courses — these are built by the same team that writes the exam.
- Practice hands-on coding: write Producer and Consumer applications in Java using the kafka-clients library, build at least one Kafka Streams topology with stateful operations, and deploy both a source and a sink connector using the Kafka Connect REST API in a local Docker environment.
- Use the TopologyTestDriver in your Kafka Streams studies — not only because it is a testable exam topic (Application Testing domain), but because building and running test topologies forces you to understand how Kafka Streams processes records and manages state stores.
- Study Confluent Schema Registry deeply: understand subject naming strategies (TopicNameStrategy, RecordNameStrategy, TopicRecordNameStrategy), schema evolution compatibility modes (BACKWARD, FORWARD, FULL, NONE), and how to configure producers and consumers to use Avro with the KafkaAvroSerializer.
- Take timed practice exams under real conditions to reinforce time management — with 55 questions in 90 minutes, you have roughly 98 seconds per question. Stephane Maarek's CCDAK practice exams on Udemy are widely recommended by the community as representative of the actual exam difficulty.
- Review Kafka configuration properties thoroughly: memorize key producer configs (acks, retries, batch.size, linger.ms, compression.type), consumer configs (group.id, auto.offset.reset, enable.auto.commit, max.poll.records), and broker-level settings relevant to developers — these appear frequently in scenario-based questions.
Career Benefits
Earning the CCDAK signals verified, hands-on competence to employers in a market where Apache Kafka has become the de facto standard for real-time event streaming. Major technology companies — including Netflix, Uber, Spotify, LinkedIn, and thousands of financial services firms — operate Kafka at scale, creating sustained demand for certified Kafka developers. As of 2024, the average annual salary for Kafka developers in the United States is approximately $125,000, with senior roles and architects earning substantially more. In Europe, salaries range from roughly €57,500–€82,500 in Germany and £70,000–£80,000 in the UK.
The certification is issued by Confluent, the company founded by Kafka's original creators, which gives it strong industry credibility compared to third-party Kafka credentials. It differentiates candidates in hiring processes, supports salary negotiation, and can serve as a stepping stone toward the Confluent Certified Operator for Apache Kafka (CCOAK) or solutions architect roles leading event-driven architecture initiatives. The credential is valid for two years, requiring renewal to stay current with the evolving platform.
Sample Questions
5 sample questions with answers and explanations. Start a practice session to test yourself across all 624 questions.
Preview — answers shown1. A developer is writing a producer application that must send a 3 MB message to a Kafka topic. The broker is configured with message.max.bytes=1048576 (1 MB). What happens when the producer attempts to send this message? (Select one!)
AThe producer automatically splits the message into three separate messages
BThe broker accepts the message and stores it across multiple segment files
CThe producer receives a RecordTooLargeException, which is a non-retriable exception
DThe message is compressed and sent successfully if compression.type is configured
Explanation
RecordTooLargeException is thrown when a message exceeds the broker's message.max.bytes limit. This is a non-retriable exception because retrying will not resolve the fundamental problem that the message is too large. The producer must either reduce the message size, split it at the application level, or coordinate with administrators to increase broker limits (message.max.bytes, replica.fetch.max.bytes, and consumer fetch.message.max.bytes). Kafka does not automatically split messages; the application must implement message splitting if needed. While compression reduces message size, a 3 MB message is unlikely to compress to under 1 MB, and the size check occurs after compression. Brokers enforce maximum message sizes and reject oversized messages; they do not split messages across segment files.
2. A topic is configured with min.insync.replicas=2, replication.factor=3, and unclean.leader.election.enable=false. A producer uses acks=1. One replica is in the ISR along with the leader. What is the behavior when the producer sends a message? (Select one!)
AThe message is rejected because min.insync.replicas requires 2 replicas but acks=1 only waits for the leader
BThe message is accepted because 2 replicas (leader + 1 follower) are in the ISR meeting the min.insync.replicas requirement
CThe message is accepted because acks=1 only requires leader acknowledgment regardless of min.insync.replicas
DThe message waits until a third replica joins the ISR before acknowledgment
Explanation
The min.insync.replicas setting only applies when acks=all (or acks=-1). With acks=1, the producer only waits for the leader's acknowledgment and does not verify the ISR size. The message is accepted as soon as the leader writes it to its local log, regardless of whether min.insync.replicas is satisfied. This creates a potential data loss scenario: if the leader fails before followers replicate the message, and unclean.leader.election.enable=false prevents out-of-sync replicas from becoming leader, the topic becomes unavailable. For data durability, use acks=all which enforces min.insync.replicas. The acks setting and min.insync.replicas work together only when acks=all.
3. A Kafka Streams application joins two KStreams with a 5-minute time window. Messages arrive out of order due to network delays. The application uses grace period configuration to handle late-arriving messages. What is the purpose of the grace period? (Select one!)
AExtends the window size by the grace period duration
BDelays window closing to accept late messages after the window end time
CBuffers messages before processing to reorder them by timestamp
DSets the maximum allowed time difference between joined messages
Explanation
The grace period delays window closing to accept late-arriving messages that fall within the window time range but arrive after the window would normally close. This prevents premature window closure and allows complete results despite out-of-order delivery. The grace period does not extend the window size itself, only the time before the window is finalized. Kafka Streams does not reorder messages in a buffer. The window size, not grace period, defines the maximum time difference between joined messages.
4. A Kafka Streams application must count the number of orders per customer using a KTable. The source topic contains order events with customerId as the key. Multiple orders from the same customer arrive continuously. Which operation correctly implements this requirement? (Select one!)
Atable.toStream().groupByKey().count()
Btable.groupBy((key, value) -> KeyValue.pair(key, value)).count() where table is a KTable
Cstream.groupByKey().count() where stream is a KStream
Dstream.groupByKey().aggregate(() -> 0L, (key, value, aggregate) -> aggregate + 1)
Explanation
Converting the KTable to a KStream with toStream, then grouping and counting produces the correct running count of orders per customer. KTables represent changelog streams where each record is an update. Converting to KStream treats each changelog event as a discrete event to count. Simply calling count on a grouped KTable counts the number of unique keys, not the number of update events. Calling groupByKey().count() on a KStream is valid but the question specifies the source is used as a KTable, suggesting the data should be treated as updates. Using aggregate on a KStream counts events correctly but is more verbose than needed. The key insight is understanding when to use KTable versus KStream semantics and that toStream conversion allows treating updates as countable events.
5. A Kafka cluster has three brokers with broker IDs 0, 1, and 2. An administrator needs to dynamically increase log.cleaner.threads from 1 to 3 on broker 1 without restarting the broker. Which kafka-configs.sh command accomplishes this? (Select one!)
Akafka-configs.sh --zookeeper localhost:2181 --entity-type brokers --entity-name 1 --alter --add-config log.cleaner.threads=3
Bkafka-configs.sh --bootstrap-server localhost:9092 --entity-type cluster --alter --add-config log.cleaner.threads=3
Ckafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 1 --alter --add-config log.cleaner.threads=3
Dkafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=3
Explanation
The correct command uses --bootstrap-server with --entity-type brokers and --entity-name 1 to target the specific broker by its broker ID. Dynamic broker configurations in modern Kafka use the bootstrap server connection and entity-type brokers with the specific broker ID as entity-name. This allows changing configurations like log.cleaner.threads without broker restart. Using --entity-type cluster would apply the configuration cluster-wide as a default, not to a specific broker. Using --zookeeper is deprecated in modern Kafka versions; all configuration management now uses --bootstrap-server, especially in KRaft mode where ZooKeeper doesn't exist. Using --entity-default sets default configurations rather than targeting a specific broker instance.
$17.99
One-time access to this exam
Full access to all 624 questions
Or $15/mo for all 253 exams
Detailed explanations
Free preview stays available