Confluent · CCDAK
Confluent Certified Developer for Apache Kafka (CCDAK) Practice Tests
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
Practice Questions
624
≈ 10 practice exams
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. The full bank has 624 questions, enough for 10 full-length practice exams.
Preview — answers shown1. An operations team monitors a Kafka cluster and notices that the high watermark for a partition is significantly behind the log end offset for the leader replica. The partition has replication.factor=3 and min.insync.replicas=2. Investigation shows one follower replica has fallen behind due to network issues. What impact does this have on consumers and producers? (Select two!)
Multiple correct answersAConsumers can only read up to the high watermark, missing recently produced messages
BProducers with acks=all will experience write failures until the follower catches up
CProducers with acks=1 can continue writing successfully to the leader
DConsumers with isolation.level=read_committed can read beyond the high watermark
EThe partition becomes read-only until all replicas synchronize
Explanation
The high watermark represents the highest offset replicated to all in-sync replicas, and consumers can only read up to this point to ensure they only see committed data. With one follower behind but min.insync.replicas=2, the leader plus one in-sync follower still satisfy the requirement, so producers with acks=all can continue writing. Producers with acks=1 only require leader acknowledgment and are unaffected by follower lag. Consumers cannot read beyond the high watermark regardless of isolation level settings. The partition remains writable as long as min.insync.replicas is satisfied.
2. A data engineering team uses kafka-consumer-groups.sh to reset consumer group offsets to reprocess data from 7 days ago. The command fails with error 'Consumer group is not empty'. The application pods are scaled to zero replicas and no consumers are connected. What is the most likely cause? (Select one!)
AThe consumer group metadata has not yet been cleaned up by the group coordinator
BCommitted offsets are stored in the __consumer_offsets topic which prevents reset
CPrevious consumers did not call close() which leaves group membership active
DThe consumer group state is 'Empty' but must be 'Dead' for offset reset
Explanation
After all consumers leave, the group coordinator transitions the group to Empty state, but this transition is not instantaneous. There is a brief period where the coordinator still considers the group active during cleanup. The consumer group must be in 'Empty' or 'Dead' state for offset reset to succeed. Waiting a few seconds for coordinator cleanup typically resolves this issue. Committed offsets in __consumer_offsets don't prevent reset; offset reset specifically modifies these offsets. The group state terminology is correct - both Empty and Dead states allow reset, but the error indicates the group hasn't finished transitioning. The close() method triggers graceful leave, but scaling to zero achieves the same result; the issue is coordinator cleanup timing.
3. A financial services application requires that a consumer processes messages in strict order within each partition but wants to commit offsets asynchronously for better performance. The developer implements the following pattern. Which statement correctly describes the behavior? (Select one!)
AAsynchronous commits block the consumer poll loop until the broker acknowledges the offset commit
BAsynchronous commits invalidate ordering guarantees because they allow the consumer to process subsequent batches before previous offsets are committed
CAsynchronous commits automatically retry failed commits in the background until successful or the consumer closes
DAsynchronous commits provide no retry mechanism, so network failures may result in offset commit loss and duplicate processing after rebalance
Explanation
The commitAsync method does not retry failed commits automatically because retrying an older offset commit after a newer commit has already succeeded could result in incorrect offset positions. If a network failure prevents an async commit from succeeding, the offset will not be committed, and after a rebalance, the consumer will restart from the last successfully committed offset, potentially reprocessing messages. Synchronous commitSync provides automatic retry on failure, but commitAsync does not. Asynchronous commits are non-blocking and allow the consumer to continue polling and processing while the commit request is sent to the broker in the background. Ordering guarantees within a partition are maintained because message processing order is independent of when offsets are committed; commitAsync affects only the persistence of progress tracking, not the order of message consumption.
4. A developer implements a Kafka Streams application with a state store. After a failure and restart, the application must restore state before resuming processing. Where does Kafka Streams restore the state store data from? (Select one!)
AFrom a changelog topic that mirrors all state store updates
BFrom the source topic by replaying all messages from the beginning
CFrom a centralized state server configured in the application properties
DFrom a local disk snapshot created during the last checkpoint
Explanation
Kafka Streams automatically creates changelog topics that mirror all updates to state stores, providing fault tolerance and recovery capabilities. When a state store needs restoration after failure, Kafka Streams reads the corresponding changelog topic to rebuild the state. The changelog topic is compacted to remove obsolete updates, keeping only the latest value for each key. While local disk snapshots exist and can speed up recovery (using RocksDB checkpoints), the source of truth is the changelog topic stored in Kafka. Replaying the source topic would be inefficient and wouldn't work for aggregations or joins that require intermediate state. Kafka Streams has no centralized state server; state is distributed across application instances.
5. A Kafka Streams application performs a hopping window aggregation with TimeWindows.ofSizeAndGrace(Duration.ofMinutes(5), Duration.ofMinutes(2)) and advanceBy(Duration.ofMinutes(1)). An event with timestamp 10:00:00 arrives. How many windows will contain this event? (Select one!)
A1 window from 10:00:00 to 10:05:00
B5 windows from 9:56:00 to 10:01:00, 9:57:00 to 10:02:00, 9:58:00 to 10:03:00, 9:59:00 to 10:04:00, and 10:00:00 to 10:05:00
C2 windows from 9:59:00 to 10:04:00 and 10:00:00 to 10:05:00
D7 windows including the 2-minute grace period extension
Explanation
Hopping windows have a fixed size and advance interval that can overlap. With a 5-minute window size and 1-minute advance, each event appears in multiple windows. An event at 10:00:00 falls into all windows that started within the past 5 minutes: windows starting at 9:56:00 (ending 10:01:00), 9:57:00 (ending 10:02:00), 9:58:00 (ending 10:03:00), 9:59:00 (ending 10:04:00), and 10:00:00 (ending 10:05:00). That's 5 windows total. The grace period of 2 minutes affects when late-arriving data can still be accepted into windows, not the number of windows an on-time event appears in. If the advance interval equaled the window size (tumbling window), each event would appear in only one window.
$17.99
One-time access to this exam
624 questions (10 practice exams' worth)
Unlimited timed exam simulations
Yours forever — no subscription
Detailed explanations
Free preview stays available