Confluent • CCAC
Validates the ability to operate and manage Apache Kafka on Confluent Cloud, covering core cloud concepts, Kafka operations, streaming pipelines, data governance, and cloud resilience.
Questions
630
Duration
90 minutes
Passing Score
70%
Difficulty
AssociateLast Updated
Feb 2026
The Confluent Cloud Certified Operator (CCAC) certification validates a candidate's ability to operate and manage Apache Kafka workloads on Confluent Cloud. It covers the full operational lifecycle of cloud-native Kafka deployments, including cluster provisioning, configuration, monitoring, security, stream processing, and data governance. The certification is specifically oriented toward Confluent Cloud's managed service offerings—such as fully managed connectors, Cluster Linking, Schema Registry, and ksqlDB—rather than self-managed or on-premises deployments.
The exam is structured around seven weighted domains that span core cloud concepts through resilience and disaster recovery. With 60 multiple-choice questions delivered in 90 minutes and a passing threshold of 70%, the CCAC is positioned at the associate difficulty level, making it accessible to professionals with foundational Kafka knowledge who are transitioning into or actively working within Confluent Cloud environments. The certification is valid for two years, after which recertification is required.
This certification is best suited for cloud engineers, DevOps engineers, site reliability engineers (SREs), platform engineers, and Kafka administrators who are responsible for day-to-day operations of Confluent Cloud deployments. It is particularly relevant for professionals who manage topics, partitions, connectors, access controls, and streaming pipelines within Confluent Cloud rather than self-managed Kafka clusters.
Candidates should have hands-on experience deploying and managing Confluent Cloud clusters, working with the Confluent Cloud Console and CLI, and operating streaming data infrastructure in production environments. It is also appropriate for infrastructure engineers moving from traditional Kafka administration (CCAAK) toward fully managed cloud operations.
There are no formal prerequisites required to register for the CCAC exam. However, Confluent strongly recommends that candidates have practical experience operating Kafka clusters within Confluent Cloud before attempting the exam. Familiarity with core Apache Kafka concepts—such as topics, partitions, consumer groups, producers, offsets, and replication—is assumed and will not be taught as part of exam preparation.
Candidates are encouraged to complete Confluent's official training courses available through training.confluent.io, particularly those covering Confluent Cloud administration, Stream Governance, and connector management. Hands-on practice using Confluent Cloud's free tier or a trial environment is highly recommended to reinforce operational knowledge across all seven exam domains.
The CCAC exam consists of 60 multiple-choice questions to be completed within a 90-minute time limit. The exam is proctored and can be taken either remotely (from any location meeting internet, security, and privacy requirements) or at an authorized testing center worldwide. Remote delivery requires a webcam, as a proctor monitors the candidate throughout the session. All exams are administered in English.
Candidates receive their pass/fail results immediately upon completing the exam on the testing screen. The passing score is 70%. The exam costs $150 USD. Upon passing, candidates receive a Confluent digital badge and certificate, which can be shared directly to LinkedIn. The certification remains valid for two years from the date of passing.
Earning the CCAC certification demonstrates verified expertise in operating Confluent Cloud, which is increasingly adopted by enterprises building real-time data platforms and event-driven architectures. Roles that commonly list Confluent Cloud experience as a requirement or differentiator include Senior Data Engineer, Kafka Platform Engineer, Cloud Infrastructure Engineer, and SRE. The certification complements existing cloud certifications (AWS, GCP, Azure) by validating streaming data infrastructure skills that are not covered by general cloud provider exams.
The CCAC is positioned at the associate level and serves as a natural entry point before pursuing more advanced Confluent certifications such as the Confluent Certified Developer for Apache Kafka (CCDAK) or the Confluent Certified Administrator for Apache Kafka (CCAAK). The digital badge issued upon passing can be added to LinkedIn profiles and email signatures, providing visible credentialing for job searches and salary negotiations in a market where real-time data expertise commands a premium.
5 sample questions with correct answers and explanations. Start a practice session to test yourself across all 630 questions.
1. A development team creates a ksqlDB query to join real-time order events from an orders STREAM with customer data from a customers TABLE. The join fails with an error indicating co-partitioning requirements are not met. The orders stream uses orderId as the key while the customers table uses customerId as the PRIMARY KEY. How should they resolve this issue? (Select one!)
Explanation
Stream-table joins require joining on the table's PRIMARY KEY and proper co-partitioning. Since orders are keyed by orderId but need to join with customers keyed by customerId, the orders stream must be repartitioned by customerId first using a statement like CREATE STREAM orders_by_customer AS SELECT * FROM orders PARTITION BY customerId. Changing the join key to orderId would not work because the customers table PRIMARY KEY is customerId and cannot be changed mid-stream. Converting the table to a stream changes the semantic model and requires WITHIN clauses which are inappropriate for reference data. Auto-repartitioning is not a configurable option in Confluent Cloud ksqlDB.
2. A data engineering team notices their ksqlDB queries using session windows show unexpected behavior where very old events are triggering window updates. They want to limit how long windows remain open for late events. Which configuration should they add? (Select one!)
Explanation
GRACE PERIOD controls how long after a window ends that late-arriving events are still accepted and included in the window results. Setting GRACE PERIOD 2 HOURS means events arriving within 2 hours of the window end time are processed, while events arriving later are rejected. This prevents indefinite window updates from very late events. RETENTION controls how long completed window results are kept in state stores for querying, not when windows close for updates. WINDOW TIMEOUT is not a valid ksqlDB configuration parameter. MAX_LATENESS is not a ksqlDB configuration; grace period serves this purpose.
3. A financial services company uses RecordNameStrategy for their Schema Registry subjects to allow multiple event types in shared topics. They attempt to configure a ksqlDB application to process these events, but encounter errors during stream creation. What is the cause of this issue? (Select one!)
Explanation
ksqlDB in Confluent Cloud only supports TopicNameStrategy for Schema Registry subject naming. This limitation means each topic can only have one schema for keys and one for values when using ksqlDB. RecordNameStrategy and TopicRecordNameStrategy, which allow multiple schemas per topic by deriving subject names from the record type, are not supported by ksqlDB. The issue is not related to edition, serialization format, or cluster-level configuration. Teams using ksqlDB must design their topic architecture around the TopicNameStrategy constraint.
4. A data platform team implements disaster recovery using Cluster Linking between an AWS us-east-1 source cluster and an Azure westus2 destination cluster. They configure consumer.offset.sync.enable=true and consumer.offset.sync.ms=30000 on the cluster link. During a regional outage affecting the source cluster, they need to immediately switch production traffic to the mirror topic. Which operation should they execute? (Select one!)
Explanation
The failover command is designed for disaster recovery scenarios when the source cluster is unreachable or experiencing an outage. Failover executes immediately without checking lag or source cluster reachability, which is critical during an outage. The promote command requires the source cluster to be online and verifies there is no mirroring lag, configuration lag, or consumer offset lag before converting the mirror topic. Since the source cluster is unavailable due to regional outage, promote will fail. Waiting for source recovery defeats the purpose of disaster recovery. Manual offset reset is unnecessary because consumer offset sync is already enabled.
5. A data platform team configures Schema Registry subject-level compatibility for a payment processing topic. They set the subject payments-value to FULL compatibility mode. A developer attempts to register a new schema version that adds a field amount_usd without a default value and removes the field currency without a default value. What will happen when the schema is submitted for registration? (Select one!)
Explanation
FULL compatibility mode combines both BACKWARD and FORWARD compatibility requirements. This means new schemas can read old data and old schemas can read new data. To achieve this, any added fields must have default values so old schemas can read new data, and any deleted fields must have default values in the previous schema so new schemas can read old data. Since the new schema adds amount_usd without a default value and removes currency without a default value in the previous version, it violates both BACKWARD and FORWARD compatibility rules causing registration to fail. FULL compatibility does not simply allow all field additions and deletions without constraints. Partial success is not possible as schema validation is atomic.
One-time access to this exam