Confluent • CCAAK
Validates expertise in managing Apache Kafka clusters in production, covering Kafka fundamentals, cluster configuration, security, deployment architecture, Kafka Connect administration, observability, and troubleshooting.
Questions
624
Duration
90 minutes
Passing Score
70%
Difficulty
AssociateLast Updated
Feb 2026
The Confluent Certified Administrator for Apache Kafka (CCAAK) is a professional certification that validates the skills required to deploy, configure, monitor, and maintain Apache Kafka clusters in production environments. It covers a broad spectrum of administrative competencies, including broker and topic configuration, ZooKeeper management, security implementation (SSL/TLS, SASL, ACLs), Kafka Connect administration, Schema Registry, observability practices, and production troubleshooting. The certification is offered by Confluent, the company founded by the original creators of Apache Kafka, and is recognized across the industry as a credible benchmark for Kafka operations expertise.
The exam tests both conceptual understanding and scenario-based knowledge, requiring candidates to demonstrate proficiency with real-world challenges such as managing consumer group rebalances, diagnosing replication health, configuring listener protocols correctly, and resolving consumer lag. Candidates must understand the roles of brokers, leaders, group coordinators, and how components like Kafka Streams and ksqlDB interact within the broader ecosystem. The certification expires after two years, requiring recertification to remain current.
The CCAAK is designed for professionals who are responsible for the day-to-day administration and operation of Apache Kafka clusters. This includes platform engineers, site reliability engineers (SREs), DevOps engineers, and infrastructure administrators who manage Kafka in self-managed, Kubernetes-based, or cloud-hosted environments. Candidates typically have hands-on experience with Kafka CLI tooling and configuration files, and are comfortable diagnosing issues such as replication lag, consumer timeouts, and partition imbalances.
The certification is well-suited for professionals who want to formalize their Kafka administration skills and distinguish themselves in the job market. It is not intended for developers building Kafka-based applications (who would be better served by the CCDAK developer certification), but rather for those responsible for the health, security, and operational performance of Kafka infrastructure.
Confluent does not enforce formal prerequisites to register for the CCAAK exam. However, candidates are strongly recommended to have practical, hands-on experience running Kafka in a production or production-like environment before attempting the exam. This includes comfort with broker configuration files, CLI tools (kafka-topics, kafka-consumer-groups, kafka-configs, etc.), and experience troubleshooting common operational issues such as under-replicated partitions, consumer lag, and connectivity errors.
Familiarity with Kafka's core components — brokers, producers, consumers, consumer groups, ZooKeeper (or KRaft mode), Kafka Connect, and Schema Registry — is essential. Confluent recommends reviewing the official online study guide and, optionally, completing their formal training courses (available in live and self-paced formats) prior to sitting the exam. Most candidates report studying between 30 and 120 hours depending on their existing Kafka experience.
The CCAAK is a 90-minute, proctored, multiple-choice exam delivered online or at authorized testing centers worldwide. The exam consists of multiple-choice and multi-select questions, with the total question count reported at approximately 40–60 questions depending on the exam version. Remote delivery requires a webcam for proctor monitoring throughout the session. The exam is administered in English only, and results are displayed immediately upon completion.
The passing score is 70%, and the cost per attempt is $150 USD. The certification is valid for two years, after which recertification is required. Upon passing, candidates receive a Confluent digital badge and certificate and are authorized to use the certification title and logo in professional materials.
Earning the CCAAK demonstrates verified expertise in Apache Kafka administration, a skill set in high demand as organizations across financial services, e-commerce, telecommunications, and technology sectors scale their event streaming infrastructure. Kafka administrators and platform engineers with this credential are well-positioned for roles such as Senior Kafka Administrator, Platform Engineer, Data Infrastructure Engineer, and Site Reliability Engineer. The certification serves as a credible differentiator in both salary negotiations with current employers and job applications with new ones.
Apache Kafka skills consistently command above-average compensation in the data engineering and platform engineering space, with experienced Kafka administrators in North America typically earning $130,000–$180,000+ USD annually. The CCAAK pairs well with cloud certifications (AWS, GCP, Azure) and complements the Confluent Certified Developer for Apache Kafka (CCDAK) for professionals seeking full-stack Kafka expertise. As organizations increasingly adopt event-driven architectures, demand for credentialed Kafka operators continues to grow.
5 sample questions with correct answers and explanations. Start a practice session to test yourself across all 624 questions.
1. A financial services application uses Kafka transactions with transactional.id=payment-processor-1, enable.idempotence=true, acks=all, and max.in.flight.requests.per.connection=5. A consumer reads from the transactional topic with isolation.level=read_committed. The producer sends 100 messages within a transaction but crashes before committing. What does the consumer see? (Select one!)
Explanation
With isolation.level=read_committed, consumers only see messages from committed transactions. When the producer crashes before committing, the transaction is aborted and the 100 messages are never visible to read_committed consumers, even though they exist in the log with transaction markers. After transaction.timeout.ms, the transaction coordinator aborts the transaction rather than committing it. Messages do not appear temporarily, they remain hidden until transaction completion. Producers using read_uncommitted isolation would see the messages, but this consumer is configured as read_committed.
2. A development team deploys a Kafka Streams application with num.standby.replicas=2 and replication.factor=3 for changelog topics. The application uses RocksDB state stores. What is the purpose of configuring standby replicas? (Select one!)
Explanation
Standby replicas in Kafka Streams create shadow copies of RocksDB state stores on additional application instances. When a partition reassignment occurs due to instance failure or rebalancing, an instance with a standby replica can immediately take over processing without rebuilding the entire state store from the changelog topic. This dramatically reduces failover time from potentially hours to seconds for large state stores. Standby replicas are separate from changelog topic replication; the changelog replication factor controls Kafka topic durability while num.standby.replicas controls in-memory state store redundancy. Standby replicas do not affect load balancing, which is handled by partition assignment. Interactive queries can access local state stores but standby replicas specifically optimize recovery time.
3. A monitoring system tracks broker metrics and observes kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions showing a value of 15 for 8 minutes after a planned broker restart. The cluster has replication.factor=3, min.insync.replicas=2, and all producers use acks=all. What should the administrator investigate first? (Select one!)
Explanation
Under-replicated partitions persisting for 8 minutes after a restart indicates that follower replicas are not catching up quickly enough. The most common cause is insufficient disk I/O bandwidth on the recovering broker, which slows catch-up replication. Investigating disk performance, num.replica.fetchers configuration, and replication throttles should be the first step. Increasing min.insync.replicas to 3 does not help replication speed and would require all three replicas to be in-sync for writes to succeed. Preferred leader election addresses leadership distribution, not replication lag. Restarting all brokers would worsen the situation by creating more under-replicated partitions.
4. A data engineering team uses kafka-reassign-partitions.sh to rebalance partition assignments across brokers after adding three new brokers to a cluster. The administrator executes the reassignment with --throttle 50000000 (50 MB/s) to avoid overwhelming the network. The reassignment completes successfully after 6 hours. Three days later, monitoring shows replication traffic remains limited to 50 MB/s during normal operation. What action should the administrator take? (Select one!)
Explanation
Running kafka-reassign-partitions.sh with the --verify option confirms the reassignment completed successfully and automatically removes all throttle configurations that were applied during the reassignment, including broker-level throttle rates and topic-level throttled replica lists. Throttles persist indefinitely after reassignment unless explicitly removed, causing ongoing replication performance degradation. Manually removing broker-level throttle configurations requires removing both leader.replication.throttled.rate and follower.replication.throttled.rate, but this approach is error-prone and the --verify command handles all cleanup automatically. Restarting brokers does not clear dynamic configurations like throttles, which are persisted in ZooKeeper or the metadata log. Deleting only the topic-level throttled.replicas configuration without removing broker-level throttles would not fully resolve the performance limitation.
5. A Kafka administrator configures a broker with num.io.threads=8, num.network.threads=3, and num.replica.fetchers=1. The cluster experiences high latency during peak loads. Monitoring shows network threads are saturated while I/O threads have capacity. Which configuration change should improve performance? (Select one!)
Explanation
Network threads handle request parsing and response transmission from clients and other brokers. When network threads are saturated (100 percent busy) while I/O threads have capacity, the bottleneck is network thread count, not disk operations. Increasing num.network.threads allows the broker to handle more concurrent connections and requests. Increasing I/O threads would not help since they already have spare capacity. Replica fetchers affect follower replication speed, not client-facing latency. Decreasing socket buffers would worsen performance by limiting throughput.
One-time access to this exam