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 producer application experiences message rejections with RecordTooLargeException. The messages are 1.5 MB each. Which configuration changes are required to send these messages successfully? (Select two!)
Multiple correct answersAIncrease producer max.request.size to at least 1572864
BIncrease broker message.max.bytes to at least 1572864
CIncrease consumer fetch.max.bytes to at least 1572864
DEnable compression.type=gzip to reduce message size below 1 MB
EIncrease producer buffer.memory to accommodate larger messages
Explanation
Both the producer max.request.size and broker message.max.bytes configurations must be increased to send messages larger than 1 MB. The producer max.request.size (default 1 MB) controls the maximum size of a request the producer will send. The broker message.max.bytes (default 1 MB) controls the maximum size of messages the broker will accept. Both must be configured to at least 1.5 MB (1572864 bytes) for 1.5 MB messages. Consumer fetch.max.bytes should also be increased for consumers to read these messages, but it's not required for the producer to send successfully. Compression reduces size but doesn't eliminate the need for configuration changes. Buffer.memory affects total producer memory, not individual message size limits.
2. An application sends messages to Kafka with keys to ensure related events are processed in order. The producer is configured with default partitioning. The topic initially has 4 partitions, and the operations team increases it to 8 partitions. What impact does this have on message ordering? (Select one!)
AAll existing messages are automatically rebalanced across the new partitions
BThe producer will throw an InvalidPartitionException until restarted
CMessages with the same key will continue going to the same partition number as before the change
DMessages with keys sent after the partition increase will be distributed differently, potentially breaking key-based ordering guarantees for new messages
Explanation
Increasing partition count changes the partitioning calculation for keyed messages. The default partitioner uses murmur2 hash: Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions. When numPartitions changes from 4 to 8, the modulo operation produces different results, causing messages with the same key to route to different partitions than before. This breaks ordering guarantees for those keys across the partition increase boundary. Existing messages already written to partitions remain in their original partitions and are not moved. Messages with the same key sent before and after the partition count change will likely go to different partitions, breaking ordering. The producer does not throw exceptions when partition counts increase, it simply recalculates partition assignments. This is why increasing partitions is a breaking change for keyed messages.
3. A financial application uses a consumer with enable.auto.commit=true and auto.commit.interval.ms=5000. The consumer polls records, processes them, and the processing takes 12 seconds per batch. After a consumer restart, the application processes many duplicate records. What explains this behavior? (Select one!)
AAuto-commit commits offsets returned by the last poll during the next poll call, so unprocessed records from the previous batch are marked as committed
BThe session.timeout.ms is shorter than processing time, causing rebalances that reset offsets
CAuto-commit interval is too low causing frequent offset commits before processing completes
DThe consumer commits offsets asynchronously during processing, creating race conditions with failures
Explanation
Auto-commit commits offsets during the poll call for records returned by the previous poll, not after processing completes. When enable.auto.commit is true, if auto.commit.interval.ms has elapsed, the next poll automatically commits offsets for all records returned by the last poll. If processing fails after the next poll but before those records are fully processed, the offsets are already committed, and a restart will skip those records. However, if the consumer crashes during processing before the next poll, offsets are not committed, causing reprocessing and duplicates. The 5-second interval being too low is incorrect because commits only occur during poll calls regardless of interval. Session timeout would cause rebalances but not duplicate processing patterns. Auto-commit does not commit asynchronously during processing, only during poll calls.
4. A consumer application processes messages slowly due to complex business logic. The application sometimes takes 6 minutes to process a batch of records between poll calls. The operations team observes frequent consumer group rebalances. Which configuration change will prevent rebalances while maintaining failure detection? (Select one!)
AIncrease max.poll.interval.ms to 400000
BIncrease heartbeat.interval.ms to 60000
CIncrease session.timeout.ms to 400000
DDecrease max.poll.records to 100
Explanation
The max.poll.interval.ms configuration controls the maximum delay between poll invocations. The default is 300000 milliseconds (5 minutes), which is exceeded by the 6-minute processing time. Increasing this value to 400000 (6.67 minutes) prevents the consumer from being considered failed during long processing periods. Increasing session.timeout.ms addresses heartbeat-related failures but not processing delays. Decreasing max.poll.records reduces batch size which may help indirectly but doesn't address the root timeout issue. Increasing heartbeat.interval.ms to 60 seconds would violate the requirement that it must be less than session.timeout.ms and could delay failure detection.
5. A consumer group with 6 consumers subscribes to topics orders and shipments, each with 8 partitions. The consumer group is configured with partition.assignment.strategy=org.apache.kafka.clients.consumer.RangeAssignor. How are partitions distributed? (Select one!)
AAll 16 partitions are distributed round-robin with some consumers receiving 3 partitions and others receiving 2 partitions
BConsumers 1-2 receive 2 partitions each from orders; consumers 3-4 receive 2 partitions each from orders; consumers 5-6 receive 2 partitions each from orders; the same pattern repeats for shipments
CEach consumer receives 2 partitions from orders and 2 partitions from shipments for a total of 4 partitions per consumer
DConsumers 1-2 receive 3 partitions each from orders; consumers 3-4 receive 3 partitions each from orders; consumers 5-6 receive 2 partitions each from orders; the same pattern repeats for shipments
Explanation
RangeAssignor operates per-topic independently. For each topic with 8 partitions and 6 consumers, the calculation is 8/6 = 1 partition per consumer with remainder 2. The first 2 consumers (lexicographically sorted) receive 2 partitions each, while the remaining 4 consumers receive 1 partition each. This pattern applies separately to orders topic and shipments topic. Consumers 1-2 get 2 partitions from orders plus 2 from shipments (4 total). Consumers 3-6 get 1 partition from orders plus 1 from shipments (2 total). RangeAssignor does not distribute evenly across all topics; it creates imbalance when partitions don't divide evenly. Round-robin distribution would require RoundRobinAssignor.
$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