Free CCAC Practice Questions: Confluent Cloud Operator

These 24 original IT Mastery practice questions cover all seven CCAC domains. The set contains 20 single-answer questions, four Select TWO questions and four diagrams. Read the requested answer count and supplied operating evidence before revealing an explanation.

This short preview uses an editorial sample length and interaction mix. Its length and interface do not reproduce the official exam, and its score does not predict passing. The issuer’s printed topic percentages total 99%; practice normalizes their proportions and rounds to whole questions. These are not official Confluent exam questions, copied live-exam content or exam dumps.

After each answer, explain which fact rules out the closest alternative. A correct guess is a reason to review the underlying distinction. Repeating this fixed set can reflect answer recognition; use fresh app questions and hands-on practice to check understanding.

Practice-set coverage

Practice questions

Questions 1-24

Question 1

Topic: Confluent Cloud Core Concepts

An operator receives this approved change request:

In organization org-7k2, update topic orders in the orders-prod Kafka cluster within environment env-p91. Change its retention from one day to seven days.

The inventory contains repeated display names:

Which action targets the requested resource and records sufficient scope evidence before the change? Select ONE.

Options:

• A. Use org-7k2, env-p91, and lkc-4aa; record the environment’s organization membership and the cluster’s parent environment before updating the topic.

• B. Use org-3m8, env-d28, and lkc-2cc; record the environment’s organization membership and the cluster’s parent environment before updating the topic.

• C. Use org-3m8, env-p22, and lkc-8bb; record the environment’s organization membership and the cluster’s parent environment before updating the topic.

• D. Use org-7k2, env-d17, and lkc-9zz; record the environment’s organization membership and the cluster’s parent environment before updating the topic.

Best answer: A

Explanation: Confluent Cloud resources must be traced through their ownership hierarchy before an operational change. An organization contains environments, and each Kafka cluster belongs to an environment. Display names are insufficient because identical names can appear in different operating boundaries.

The request supplies immutable identifiers for the organization and environment. The inventory maps org-7k2 and env-p91 to Kafka cluster lkc-4aa. Before changing topic configuration, the operator should preserve evidence that env-p91 belongs to org-7k2 and that lkc-4aa belongs to env-p91. This confirms that the topic operation will affect the intended cluster rather than another orders-prod cluster with an identically named orders topic.

Why each option fits or fails:

A. The identifiers trace the requested hierarchy from org-7k2 through env-p91 to lkc-4aa, despite the repeated display names.

B. This hierarchy targets both a different organization and a different environment, even though the cluster and topic display names match.

C. Matching Production and orders-prod display names do not override the request’s different organization and environment identifiers.

D. This hierarchy belongs to the requested organization but targets the DR environment rather than the specified environment env-p91.

Question 2

Topic: Confluent Cloud Core Concepts

A team plans a 3-month experiment followed by 9 months of production. Select the plan with the lowest quoted 12-month cost that meets all requirements.

Workload:

• Experiment peak: 8 MB/s ingress and 12 MB/s egress; no uptime SLA required.
• Production peak: 32 MB/s ingress and 48 MB/s egress.
• Production requires private AWS connectivity, idempotent producers, and eligibility for a 99.99% SLA.
• Changing the offering or network model requires a new cluster and an estimated $8,500 migration.

Current capacity assessment and quote:

The capacity assessment confirms that 1 eCKU supports the experiment and 2 eCKUs support production for the elastic offerings. The quoted Dedicated and Freight configurations also support the stated traffic.

Which initial provisioning plan should the team choose? Select ONE.

Options:

• A. Provision Standard at 1 eCKU, then migrate to Enterprise at 2 eCKUs for production.

• B. Provision Freight at experiment capacity, then raise it to the quoted production capacity before launch.

• C. Provision multi-zone Dedicated at production capacity immediately and retain it through production.

• D. Provision Enterprise at 1 eCKU, then raise the same cluster to 2 eCKUs for production.

Best answer: D

Explanation: Cluster selection should account for both the experiment and the likely production state. Enterprise supports the required private connectivity and idempotent producers. Starting at 1 eCKU satisfies the experimental demand, while raising the configured minimum and maximum to 2 eCKUs before production satisfies the stated capacity assessment and the minimum elastic-capacity prerequisite for 99.99% SLA eligibility.

Its total quoted cost is \(3 \times \$900 + 9 \times \$1,800 = \$18,900\). Starting with Standard appears cheaper initially, but production requires a private-network offering, so the supplied migration cost makes that path more expensive. Dedicated is technically suitable but unnecessary at the quoted demand and cost. Freight is cheaper, but its lack of idempotent producer support is a substantive incompatibility.

Why each option fits or fails:

A. This path meets production requirements after migration but costs $26,500, including the $8,500 migration estimate.

B. Freight meets the traffic and private-connectivity needs but does not support the required idempotent producers.

C. This configuration meets the technical requirements, but its quoted 12-month cost of $66,000 exceeds the qualifying Enterprise path.

D. This path meets private networking, idempotence, capacity, and SLA prerequisites for $18,900 without a cluster migration.

Question 3

Topic: Confluent Cloud Core Concepts

An operations team is transitioning an event pipeline to archive raw events and provide an enriched stream.

Current state:

• A running Kafka cluster contains raw-events with seven-day retention.
• Schema Registry contains the required raw-events-value schema.
• An object-storage sink connector is PAUSED. Its start position is earliest, and its Kafka permissions, schema access, storage credentials, and outbound connectivity have been validated.
• A Flink compute pool is available. The intended runtime service account can read raw-events and write enriched-events, but the deployer lacks permission to assign that service account.
• Downstream consumers may move to enriched-events only after records are present and processing lag is stable.
• Retention on raw-events may be reduced only after archive completion is verified.

The team may perform one transition step without changing permissions or configuration. Which step is operationally ready now? Select ONE.

Options:

• A. Move downstream consumers from raw-events to enriched-events.

• B. Resume the managed sink connector to begin archiving retained records.

• C. Reduce raw-events retention because its schema is registered.

• D. Submit the Flink statement using the intended runtime service account.

Best answer: B

Explanation: Kafka supplies durable event storage according to topic retention. Schema Registry manages schema subjects and versions, but it does not store the event records themselves. A managed sink connector performs integration by reading Kafka records and writing them to an external system; all dependencies for that connector are already satisfied. Flink provides stream processing through statements running in a compute pool, but deployment authority is separate from the runtime account’s Kafka permissions. Because the deployer cannot assign the intended service account, processing cannot begin. Consumer cutover and retention reduction also depend on evidence from later stages, so resuming the connector is the only ready transition.

Why each option fits or fails:

A. The required enriched records and stable processing-lag evidence do not yet exist because processing has not started.

B. The connector has all required Kafka, schema, external-system, and network dependencies, so it can begin its integration task.

C. Schema registration does not archive Kafka records, and the required archive-completion verification has not occurred.

D. The runtime account has data access, but the deployer cannot assign it for statement execution.

Question 4

Topic: Confluent Cloud Core Concepts

A company is reorganizing its Confluent Cloud resources.

Operating requirements:

• Developers own development Kafka clusters, connectors, schemas, and Flink statements and may change them at any time.
• The production SRE team owns production resources and deploys only during approved weekly windows.
• Company policy requires separate inventory and change-management boundaries for resources with different owners and schedules.
• Production workloads must not depend on resources that developers can change.
• Developers must not administer production resources or access production Kafka data or schemas.
• Production applications must use an approved private network path.

Which TWO measures satisfy these requirements?

Options:

• A. Create separate environments but grant both teams broad administration in each environment, using approval tickets to control production changes.

• B. Place both stages in one environment and distinguish their resources through names, labels, and separate deployment calendars.

• C. Create separate development and production environments, placing each stage’s Kafka, Schema Registry, connectors, and Flink pools in its corresponding environment.

• D. Separate the Kafka clusters but use the development environment’s Schema Registry for both stages to centralize compatibility management.

• E. Apply production-specific role bindings, data-plane grants, service accounts, and private network controls that exclude development principals and network paths.

Correct answers: C and E

Explanation: Confluent Cloud environments are logical groupings for resources within an organization. Separate environments are appropriate when development and production have different owners, deployment schedules, and dependency lifecycles. Each stage should contain the managed resources it depends on, including its environment’s Schema Registry, so production does not rely on development-controlled services.

An environment boundary is not a complete security boundary. Access must still be enforced through appropriately scoped role bindings, Kafka and Schema Registry permissions, and workload service accounts. Network reachability is also separate from authorization, so production’s private connectivity, routing, DNS, and endpoints must be configured to exclude unapproved development paths. Change procedures complement these controls but cannot replace them.

Why each option fits or fails:

A. Shared broad administration would allow developers to modify production resources despite the approval process.

B. Names, labels, and calendars do not provide the required separate inventory and change-management boundaries.

C. Separate environments provide logical resource groupings aligned with each team’s ownership, deployment schedule, and runtime dependencies.

D. A development-owned Schema Registry would create a production dependency that developers can change outside the production schedule.

E. Environment placement alone does not enforce authorization or connectivity, so production requires explicit identity, resource-access, and network controls.

Question 5

Topic: Kafka Operations

A consumer in one group is assigned both partitions of a Confluent Cloud topic. Its record-processing log shows:

1: key=acct-17 partition=0 offset=310 event=Submitted
2: key=acct-42 partition=1 offset=905 event=Submitted
3: key=acct-42 partition=1 offset=906 event=Approved
4: key=acct-17 partition=0 offset=311 event=Approved

The team is evaluating only Kafka’s ordering guarantee, not business timestamps or concurrent application processing.

Which conclusion is supported? Select ONE.

Options:

• A. The sequence violates ordering because offset 311 must be processed before offset 905, regardless of partition.

• B. The sequence is valid because offsets increase within each partition, while records from different partitions may be interleaved.

• C. The sequence violates ordering because records from partition 0 must remain contiguous until that partition is caught up.

• D. The sequence is valid and its exact interleaving must be reproduced by every consumer group reading the topic.

Best answer: B

Explanation: Kafka provides ordering within each partition, not across an entire topic. For partition 0, offset 310 precedes offset 311. For partition 1, offset 905 precedes offset 906. The combined log may interleave records from these partitions without violating Kafka’s guarantee.

Offset numbers are partition-local positions. Comparing offset 311 from partition 0 with offset 905 from partition 1 does not reveal which record has a globally earlier position. Likewise, consumer groups track progress independently, so a particular merged processing sequence is not a topic-wide ordering that every group must reproduce.

Why each option fits or fails:

A. Offsets identify positions only within their own partitions, so offset values from different partitions cannot establish a topic-wide order.

B. Partition 0 preserves 310 before 311, and partition 1 preserves 905 before 906; Kafka does not impose an order between those partitions.

C. Per-partition ordering does not require consecutive records from one partition to appear contiguously in a log that combines multiple partitions.

D. Independent consumer groups preserve partition order but may observe or process different cross-partition interleavings.

Question 6

Topic: Kafka Operations

A topic using cleanup.policy=delete must preserve a 60-hour replay window. Its configured size capacity must include 20% headroom above each partition’s estimated 60-hour data volume.

Effective settings:

• retention.ms: 259,200,000 (72 hours)
• retention.bytes: 300 GiB
• segment.bytes: 1 GiB

Steady retained-log growth:

Assume these rates remain steady and ignore storage overhead. The oldest record that must remain replayable is 60 hours old.

Which is the smallest configuration change that satisfies the policy and accurately describes cleanup behavior? Select ONE.

Options:

• A. Set retention.bytes to 864 GiB and leave retention.ms unchanged; the size limit applies to the combined topic log, with removal occurring when that total crosses the limit.

• B. Set retention.bytes to 432 GiB and leave retention.ms unchanged; either limit can make old segments eligible, but removal does not occur at an exact crossing time.

• C. Set retention.bytes to 360 GiB and leave retention.ms unchanged; the 72-hour setting supplies the remaining headroom, with removal occurring when the earlier limit is crossed.

• D. Leave retention.bytes at 300 GiB and set retention.ms to 311,040,000; enlarging the time window prevents the size condition from shortening the replay window.

Best answer: B

Explanation: Kafka delete retention is governed independently by time and size. Data can become eligible for cleanup when either applicable limit is exceeded. Because retention.bytes applies per partition, the busiest partition determines the required size setting:

At the current 300 GiB setting, that partition holds only about 50 hours of data at the stated rate, so the 72-hour time setting cannot guarantee the required replay window. Setting the size limit to at least 432 GiB provides the specified capacity headroom while the existing 72-hour limit covers the required age.

Crossing a retention threshold establishes cleanup eligibility rather than an exact deletion timestamp. Cleanup operates asynchronously on log segments, and the active segment is not immediately removed. Segment boundaries and cleanup scheduling therefore affect when eligible records actually disappear.

Why each option fits or fails:

A. The 864 GiB calculation incorrectly combines all partition rates because retention.bytes is enforced per partition, not as one topic-wide byte pool.

B. The busiest partition needs \(6 \times 60 \times 1.20 = 432\) GiB, and segment-based asynchronous cleanup prevents an exact deletion-time prediction.

C. A 360 GiB limit covers only the busiest partition’s estimated 60-hour volume and does not provide the required 20% size headroom.

D. Increasing time retention cannot prevent the 300 GiB per-partition size limit from making the busiest partition’s older segments eligible first.

Question 7

Topic: Kafka Operations

An operator investigates why two applications consuming the orders topic do not each receive every new record. The topic has four partitions.

Requirement: After the next planned restart, each application deployment must independently process every new record. Replicas within the indexer deployment should continue sharing its work. Historical replay is not required.

Observations:

• No authentication, authorization, or network errors are reported.
• All consumers are configured with group.id=orders-live.
• Consumer group inspection shows:

• Together, the three consumers account for all accepted records, but each application sees only records from its assigned partitions.

Which configuration response should the operator make? Select ONE.

Options:

• A. Keep the shared group.id, but assign each application a distinct client.id, then validate record counts through client-level metrics.

• B. Give the indexer replicas one shared group.id and the fraud monitor a different group.id, then validate assignments and lag for both groups.

• C. Keep the shared group.id, but issue each application a distinct Kafka API key, then validate each principal’s authorization and traffic.

• D. Keep the shared group.id, but assign every consumer a unique group.instance.id, then validate that assignments remain stable after restart.

Best answer: B

Explanation: A conventional consumer group load-shares topic partitions among its active consumers. Each partition is assigned to at most one active member of that group, so the indexer and fraud monitor cannot both consume every record while sharing orders-live.

The applications need different group IDs. The two indexer replicas should retain a common indexer group ID so they divide the four partitions between themselves. The fraud monitor should use another group ID, giving it an independent assignment across the topic and its own committed next-read positions. Because only future records are required, the new groups can begin according to the coordinated restart configuration without recovering shared historical progress.

Client IDs, static member IDs, and API keys serve identification, membership stability, and authentication respectively. None changes the fundamental load-sharing boundary established by group.id.

Why each option fits or fails:

A. A distinct client ID improves identification and metrics but does not separate consumer group assignments or offset progress.

B. Different group IDs provide independent partition assignments and offset progress, while the indexer replicas still share work within their own group.

C. Separate credentials distinguish authentication and authorization, but they do not create independent consumer group progress.

D. Static member IDs can reduce assignment disruption, but all members still divide partitions within the same consumer group.

Question 8

Topic: Kafka Operations

A replacement consumer must resume work for consumer group invoice-writer on partition invoices-0 without omitting unfinished records or unnecessarily replaying completed work.

Current state:

• The previous consumer is stopped and no other group member is active.
• Records at offsets 418 through 421 were delivered before shutdown.
• Processing completed successfully through offset 419.
• Offset 420 was interrupted, and offset 421 was fetched but not processed.
• The group coordinator reports committed offset 420 for invoices-0.
• Topic retention still includes all listed records.

Which step is ready to perform? Select ONE.

Options:

• A. Start the replacement in a new consumer group and expect it to inherit offset 420 from invoice-writer.

• B. Reset invoice-writer to offset 421 and then start the replacement because offset 420 was already delivered.

• C. Start the replacement in invoice-writer without an offset reset and expect reading to resume at offset 420.

• D. Reset invoice-writer to offset 419 and then start the replacement to resume after the last completed record.

Best answer: C

Explanation: A committed consumer offset identifies the next record that a particular consumer group should read from a particular partition. It is not the offset of the last completed record. Here, the committed value of 420 means the replacement consumer in invoice-writer will resume at offset 420.

Delivery and processing completion are separate observations. Although offsets 420 and 421 were delivered, neither completed successfully, so reading them again is appropriate. No offset reset is needed because the existing commit already represents the required restart position. The records also remain available under topic retention.

Consumer progress is group-specific and does not alter topic storage. A newly named group would have no inherited commit and would determine its initial position from an explicit reset or its auto.offset.reset behavior.

Why each option fits or fails:

A. Committed offsets belong to a specific consumer group, so a new group does not inherit invoice-writer progress.

B. Delivery does not establish processing completion, and starting at 421 would omit the unfinished record at offset 420.

C. The committed offset is the next-read position, so the inactive group can resume at offset 420 and reprocess the unfinished records.

D. Resetting to 419 would read the already completed record again because the restart position, not the last completed offset, should be 420.

Question 9

Topic: Confluent Cloud Static Operations

An operator must provide private connectivity from application clients to a Confluent Cloud Dedicated Kafka cluster.

Network facts:

• The Confluent Cloud network is in AWS us-east-1 with CIDR 10.20.0.0/16.
• vpc-app is in AWS us-east-1 with CIDR 10.40.0.0/16. Its client subnets use route table rt-app.
• vpc-hub is already peered with both networks through separate peering connections.
• vpc-legacy, an alternative workload location, uses CIDR 10.20.128.0/17.

Supported behavior:

• Confluent Cloud peering requires nonoverlapping CIDRs in the same supported cloud region.
• VPC peering is not transitive.
• For an accepted direct peer, Confluent manages the return route to the declared customer CIDR; the customer must configure its subnet route tables.
• DNS resolution and security rules for the Kafka endpoints have already been validated.

Which two measures establish a supported network path from the clients in vpc-app to the cluster? Select TWO.

Options:

• A. Add a 10.20.0.0/16 route to rt-app that targets the direct peering connection.

• B. Establish a direct peering connection between vpc-app and the Confluent Cloud network.

• C. Place the clients in vpc-legacy and establish a direct peer using its more-specific CIDR.

• D. Route 10.20.0.0/16 from rt-app to the existing peering connection with vpc-hub.

• E. Add a default route from rt-app to a NAT gateway for the private Kafka endpoints.

Correct answers: A and B

Explanation: A supported private path requires both a valid direct network relationship and explicit routing from the client subnets. vpc-app and the Confluent Cloud network are eligible for direct peering because they use the same cloud region and their CIDRs do not overlap. The route table associated with the application subnets must then send traffic for 10.20.0.0/16 through that direct peer.

The existing hub cannot provide the path because VPC peering does not support transitive forwarding between separate peering connections. The legacy VPC is also unsuitable because 10.20.128.0/17 overlaps the cluster network’s 10.20.0.0/16. Finally, private broker addresses are not made reachable by an internet or NAT route. Authentication and Kafka authorization remain separate from network reachability.

Why each option fits or fails:

A. The application subnet route table must direct traffic for the Confluent network CIDR through the new peer.

B. The networks are in the same region and have nonoverlapping CIDRs, while direct peering avoids the unsupported transit path through vpc-hub.

C. The legacy CIDR lies within the Confluent network CIDR, and a more-specific route does not make overlapping peered address spaces valid.

D. VPC peering is non-transitive, so vpc-hub cannot forward application traffic through its separate Confluent Cloud peer.

E. A NAT gateway does not create reachability to private broker addresses in the Confluent Cloud network.

Question 10

Topic: Confluent Cloud Static Operations

An operator must configure invoice-reader to consume from Kafka cluster lkc-west-22 as service account sa-invoice. The client must read topic payments and commit offsets for consumer group invoice-reader.

Credential inventory:

Target configuration and access:

• Bootstrap endpoint: pkc-west.example.confluent.cloud:9092 for lkc-west-22
• sa-invoice: READ on topic payments
• sa-invoice: READ on group invoice-reader
• No applicable deny ACLs exist.

The client currently targets the west bootstrap endpoint using KAFKA_A and receives an authentication failure.

Which change should the operator make? Select ONE.

Options:

• A. Create a Kafka API key scoped to lkc-west-22 and owned by sa-invoice, then retain the west endpoint and existing ACLs.

• B. Use KAFKA_B with the west endpoint and grant sa-reporting the same topic and group permissions.

• C. Keep KAFKA_A and recreate the same sa-invoice topic and group ACLs on lkc-west-22.

• D. Use CLOUD_C with the west endpoint because its owner already has the required Kafka ACLs.

Best answer: A

Explanation: A resource-scoped Kafka API key identifies both its owning principal and the Kafka cluster against which it can authenticate. KAFKA_A represents sa-invoice, but it is scoped to lkc-east-11; using its secret against the west cluster does not transfer or extend that scope.

Authentication and authorization are separate checks. The client first needs a Kafka key for lkc-west-22 owned by the required principal, sa-invoice. After authentication, the west cluster evaluates that principal’s permissions. The supplied READ grants cover both the payments topic and the invoice-reader consumer group, and no deny ACL overrides them. Therefore, the ACLs need not be recreated. A key owned by another service account would cause the client to operate as that other principal, while a Cloud management key is not the appropriate Kafka data-plane credential.

Why each option fits or fails:

A. The new key authenticates sa-invoice to the intended cluster, where that principal already has the required topic and group permissions.

B. This would use the correct cluster scope but authenticate the workload as sa-reporting, contrary to the required service identity.

C. Additional ACLs cannot make a Kafka API key scoped to lkc-east-11 authenticate against lkc-west-22.

D. A Cloud resource-management key is intended for management APIs and is not a resource-scoped Kafka credential for data-plane access.

Question 11

Topic: Confluent Cloud Static Operations

A team uses a deployment pipeline to provision Confluent Cloud resources and a production client to write to a Standard Kafka cluster. Both stop working shortly after the engineer who created them transfers to another department.

Diagnostic observations:

• The pipeline receives 401 Unauthorized from Cloud management APIs.
• The producer receives SASL authentication failures.
• Cluster health, DNS, routing and quotas are normal.
• Offboarding records confirm that the engineer’s user credentials were disabled.
• The pipeline’s Cloud API key and the producer’s Kafka API key are both owned by that engineer.

The team requires individual accountability for interactive administration, least-privilege workload access and independent credential rotation for the two workloads.

Which identity design and recovery action should the operator implement? Select ONE.

Options:

• A. Create one service account for both workloads, grant it Cloud management and Kafka write permissions and replace both disabled credentials.

• B. Re-enable the engineer, rotate both human-owned keys and document a process for transferring the credentials during future staffing changes.

• C. Create a shared SSO user for the operations team, exclude it from routine offboarding and issue separate Cloud and Kafka keys to that user.

• D. Create separate service accounts for deployment and production, issue appropriately scoped keys, grant each required permissions and retain named SSO identities for administrators.

Best answer: D

Explanation: Unattended automation and production clients should use service accounts rather than credentials owned by individual employees. API keys inherit the permissions of their owning principal, so keys tied to a disabled human identity create an operational continuity risk.

The deployment pipeline and producer also serve different purposes. The deployment service account should receive only the Cloud resource-management permissions and credentials required for provisioning. The producer service account should receive a Kafka-cluster-scoped key and only the necessary topic permissions, such as an applicable WRITE ACL. Separate identities allow independent rotation and limit the effect of a compromised credential.

People should continue using individually attributable SSO identities with suitable administrative roles. Shared human accounts weaken auditability and should not be used to provide workload continuity.

Why each option fits or fails:

A. A single combined identity restores continuity but unnecessarily couples administrative automation and production data access, increasing credential scope and blast radius.

B. Workloads would remain dependent on a person’s identity, so another role change or offboarding event could interrupt both services again.

C. A shared human identity obscures individual accountability and still treats unattended workloads as a human user rather than as service identities.

D. Separate workload identities provide continuity and independent least-privilege access, while named SSO users preserve accountability for human administration.

Question 12

Topic: Confluent Cloud Dynamic Operations

A Confluent Cloud Kafka cluster is reviewed over a 15-minute operating interval.

Workload expectation:

• Producer traffic: 20 MiB/s and 10,000 records/s
• Two independent consumer groups read the full stream
• Acceptable combined egress: 38-42 MiB/s
• Alert when cluster-wide produce requests exceed 900 requests/s in any second

Observed telemetry:

Which interpretation is supported by these measurements? Select ONE.

Options:

• A. The egress measurement exceeds the expected workload because total egress should approximately equal ingress even when independent consumer groups read the stream.

• B. Each consumer group consumed exactly 19.5 MiB/s and remained caught up because their combined egress was 39 MiB/s.

• C. The aggregate byte and request measurements meet the stated expectations, but group-level telemetry is needed to confirm each consumer group is caught up.

• D. The produce-request alert should fire because the record rate of 10,000 records/s exceeds the threshold of 900 requests/s.

Best answer: C

Explanation: Byte throughput, record rate, and request rate measure different aspects of a Kafka workload. A produce request can contain multiple records, so 10,000 records/s does not imply 10,000 requests/s. The measured maximum was 820 requests/s, below the 900 requests/s alert threshold.

Ingress and egress also need not match. Independent consumer groups maintain separate progress and can each read the same records. Consequently, two groups reading a 20 MiB/s input stream can produce combined egress near 40 MiB/s. The observed 39 MiB/s falls within the specified 38-42 MiB/s range.

However, cluster-wide egress is an aggregate. It cannot prove that both groups received equal traffic or remained caught up. Consumer-group lag or group-scoped consumption measurements are required for that determination.

Why each option fits or fails:

A. Independent consumer groups can each read the same records, so combined egress may be approximately twice the ingress rate.

B. Cluster-wide egress does not show how traffic was distributed between groups or whether either group accumulated lag.

C. Ingress, combined egress, and maximum request rate are within their stated ranges, while cluster-wide egress does not establish each group’s progress.

D. Record rate and request rate are different measurements, and the observed maximum request rate was only 820 requests/s.

Question 13

Topic: Confluent Cloud Dynamic Operations

A production order processor has three deployed instances, and all three are required to sustain current demand. An operator is rotating its Kafka cluster API key. The tested rollout starts and validates a replacement before stopping each old instance, preserving at least three processing instances throughout.

Credential inventory:

• Both keys are owned by service account sa-orders-prod and scoped to cluster lkc-prod.
• Secret version v42 contains K-old; version v43 contains K-new.
• Confluent Cloud reports both keys as ACTIVE.

Rolling deployment evidence:

The Ready check confirms only process liveness. Which procedure should the operator use to complete the rotation while preserving availability? Select ONE.

Options:

• A. Deploy v43 to worker-3, verify authentication and offset progress across all instances, and then delete K-old.

• B. Deploy v43 to worker-3, delete K-old when the instance reports Ready, and then verify its offset progress.

• C. Delete K-old, deploy v43 to worker-3, and verify authentication and offset progress after the instance reconnects.

• D. Deploy v43 to worker-3, verify all instances remain healthy, and retain K-old indefinitely as a rollback credential.

Best answer: A

Explanation: A safe API-key rotation overlaps the old and replacement credentials only during migration. The replacement must have the correct owner and resource scope, then be distributed through the workload’s actual secret locations. Here, worker-1 and worker-2 demonstrate that K-new supports authentication and record processing, but worker-3 still depends on K-old.

The operator should roll worker-3 to secret version v43 and confirm data-plane evidence such as successful authentication and advancing offsets. A successful key-creation response or process readiness alone does not establish that the workload is operating with the new credential. Once every instance has migrated and processing is verified, K-old can be deleted without interrupting the required capacity.

Why each option fits or fails:

A. Migrating and validating the final old-key consumer ensures no required instance depends on K-old before it is retired.

B. Process readiness does not prove that worker-3 authenticated with the replacement key or resumed record processing before revocation.

C. Deleting K-old first disconnects worker-3 while it still uses that key, reducing the capacity required for current demand.

D. Keeping the superseded credential active leaves unnecessary access available and does not complete the key rotation.

Question 14

Topic: Confluent Cloud Dynamic Operations

A Dedicated Kafka cluster shows rising producer p95 latency during a recurring three-hour peak.

Operating evidence:

• Current capacity: 4 CKUs
• Sustained accepted load during the peak: 3.2 CKU equivalents
• Forecast workload growth: 25%
• Capacity policy: forecast load must not exceed 75% of installed capacity
• Supported target sizes: 6 or 8 CKUs
• Approved budget: sufficient for 6 CKUs, but not 8 CKUs
• Cluster status: RUNNING, with no active service incident
• Principal ingress quota utilization: 62%, with no throttling errors

Which response is most appropriate? Select ONE.

Options:

• A. Keep the cluster at 4 CKUs, raise the principal ingress quota, then verify latency and accepted ingress.

• B. Resize the cluster to 8 CKUs, monitor the resize operation and resource status, then verify latency and utilization.

• C. Resize the cluster to 6 CKUs, monitor the resize operation and resource status, then verify latency and utilization.

• D. Keep the cluster at 4 CKUs, monitor the forecast period, and resize only if accepted load exceeds 4 CKU equivalents.

Best answer: C

Explanation: Forecast load is the sustained recent load increased by the expected growth: 3.2 x 1.25 = 4.0 CKU equivalents. The policy limits forecast load to 75% of installed capacity, so required capacity is 4.0 / 0.75 = 5.33 CKUs. The next supported size meeting that requirement is 6 CKUs, where forecast utilization would be about 66.7%.

Dedicated clusters require an explicit CKU resize; they do not automatically add CKUs in response to sustained demand. Confluent Cloud manages the underlying infrastructure changes and rebalance, so the operator should monitor the resize operation and cluster resource status rather than add broker hosts or manually reassign replicas. After completion, latency and utilization metrics should confirm that the expansion resolved the symptom. The absence of quota throttling also distinguishes cluster capacity pressure from a principal-level ingress limit.

Why each option fits or fails:

A. The principal is not approaching its ingress quota and has no throttling errors, so increasing that quota does not address cluster load.

B. Eight CKUs would provide sufficient capacity, but it exceeds the stated budget when 6 CKUs already meet the capacity policy.

C. Forecast load is 4.0 CKU equivalents, and 6 CKUs provide the required headroom while remaining within the approved budget.

D. Although 4 CKUs could equal forecast demand, it would provide no unused capacity and would violate the 25% headroom policy.

Question 15

Topic: Confluent Cloud Dynamic Operations

An operator receives this production change request:

Rewind consumer group billing-export by 30 minutes to replay failed records. No customer may be billed twice. Make no production mutation until the target and scope are verified.

Resource inventory:

• Production: environment Payments (env-p7), cluster core (lkc-p91)
• Test: environment Payments (env-t2), cluster core (lkc-t44)
• Both clusters contain a consumer group named billing-export.
• The change tool supports a read-only plan showing current and proposed offsets by partition.
• The consumer calls a non-idempotent billing API. Some calls timed out after submission, and their billing outcomes have not been reconciled.
• Kafka retention includes the entire proposed replay interval.

Which TWO measures are required before approving the production change?

Options:

• A. Accept successful authentication through the CLI profile named prod as sufficient confirmation of the target cluster.

• B. Block approval until billing provides replay-safe deduplication or idempotency for every record in the reset interval.

• C. Review a read-only plan pinned to env-p7 and lkc-p91 that reports the group and per-partition offset changes.

• D. Execute the reset against env-t2 and lkc-t44, then reuse the name-based operation in production if the test succeeds.

• E. Save the committed offsets and restore them after replay to prevent duplicate billing effects.

Correct answers: B and C

Explanation: Controlled changes require both target verification and dependency validation. Display names are ambiguous because both environments use the same environment, cluster, and consumer-group names. A read-only plan scoped by immutable environment and cluster IDs confirms the actual target and exposes the per-partition offset mutation before execution.

An offset reset changes where the consumer reads next; it does not undo external effects. Because some billing requests may already have succeeded and the billing API lacks replay protection, rewinding could charge customers twice. Kafka retention confirms that records remain available, but it does not make replay safe. Approval must therefore wait for billing reconciliation combined with an effective idempotency or deduplication mechanism.

Why each option fits or fails:

A. A local profile label and successful authentication do not independently verify the environment, cluster ID, group, or proposed offset scope.

B. Records with uncertain billing outcomes could be processed again, so the current operation cannot satisfy the prohibition against duplicate charges.

C. The immutable environment and cluster IDs disambiguate identical names, while the plan confirms the exact group and proposed mutation scope.

D. Testing the mechanics on another cluster does not verify the production resource IDs or resolve the production billing dependency.

E. Committed offsets control the next Kafka read position; restoring them cannot reverse or suppress external charges already completed during replay.

Question 16

Topic: Confluent Cloud Streaming Pipelines

An operations team is preparing a fully managed sink connector for an AWS Enterprise Kafka cluster.

Current state:

• The environment and cluster are in AWS us-east-1.
• An application in a customer VPC reaches Kafka through an inbound PrivateLink connection.
• The connector service account can read the source topic.
• The external sink exposes a private AWS endpoint service in us-east-1 at orders-db.internal.example.
• Connector logs show that resolution of orders-db.internal.example fails before any TCP connection or sink authentication attempt.
• The network inventory contains no connector egress gateway or endpoint access point.

Desired state: Hand off the connector from connectivity setup to record-delivery validation while keeping the sink private.

Which dependency must be completed before this handoff can occur?

Options:

• A. Replace the connector service account credentials and recreate its topic-level read authorization on the Enterprise cluster.

• B. Provision an Egress PrivateLink gateway and endpoint access point, then add the gateway DNS record for the sink domain.

• C. Extend the application’s inbound PrivateLink endpoint and Kafka bootstrap DNS configuration to the managed connector workers.

• D. Configure Dedicated network Private Link Access for the external endpoint service and authorize the connector service account.

Best answer: B

Explanation: Inbound Kafka connectivity and managed connector egress are independent paths. The application’s successful private connection proves that its VPC can reach Kafka, but it provides no network route or DNS configuration for Confluent-managed connector workers to reach an external sink.

For AWS Enterprise connector egress through PrivateLink, the environment needs an Egress PrivateLink gateway, an endpoint access point associated with the external endpoint service, and a gateway DNS record for the external domain. After these components are provisioned, operators should validate DNS resolution and TCP connectivity before moving to sink authentication and record-delivery checks.

Dedicated network Private Link Access serves a different connectivity model and should not be substituted for the Enterprise connector egress gateway and access-point workflow.

Why each option fits or fails:

A. Kafka authorization is already working, while the observed failure occurs during external sink DNS resolution before authentication.

B. AWS Enterprise connector egress requires the gateway, access point, and DNS mapping before the managed connector can privately resolve and reach the sink.

C. The application endpoint supports inbound client access to Kafka, not outbound connectivity from managed connector workers to an external service.

D. Dedicated network Private Link Access is not the AWS Enterprise connector-egress mechanism and does not create the connector’s outbound path.

Question 17

Topic: Confluent Cloud Streaming Pipelines

An operator investigates a Flink SQL statement that has remained PENDING for 18 minutes.

Normalized operations snapshot:

• The statement reports Waiting for compute capacity and requests 4 CFUs.
• Its compute pool is PROVISIONED with 10 current CFUs and a configured maximum of 10 CFUs.
• Two other statements in the pool are RUNNING and together consume all 10 CFUs.
• The scaling status reports AT_LIMIT; no authentication, authorization, or task failures appear.
• The organization quota and an approved change permit raising the pool maximum to 14 CFUs.
• The running statements must not be interrupted.

Which action should the operator take next? Select ONE.

Options:

• A. Continue waiting for the existing pool to scale beyond 10 CFUs and monitor the statement lifecycle.

• B. Submit an identical statement to the same pool and monitor which instance reaches RUNNING first.

• C. Raise the pool maximum to 14 CFUs and monitor the pending statement and pool usage for progress.

• D. Provision another compute pool in the environment and wait for the pending statement to migrate automatically.

Best answer: C

Explanation: A PENDING statement can reflect normal startup, but prolonged pending status combined with AT_LIMIT, full CFU consumption, and an explicit capacity-wait message indicates blocked resource allocation. A Flink compute pool scales only within its configured maximum; it cannot automatically exceed that ceiling.

The pool currently uses 10 of 10 CFUs, while the new statement requests 4 CFUs. Raising the approved maximum to 14 CFUs creates the required headroom while preserving the running statements. After the change, the operator should verify that pool allocation increases and that the same statement transitions toward RUNNING. Repeated submissions do not solve capacity exhaustion and can make diagnosis or workload management more difficult.

Why each option fits or fails:

A. Autoscaling cannot exceed the configured 10-CFU maximum, so waiting alone cannot satisfy the additional capacity request.

B. A duplicate competes for the same exhausted capacity and can add demand without resolving the configured ceiling.

C. The pool is at its configured ceiling, and four additional CFUs provide the capacity requested by the pending statement without interrupting running work.

D. A statement does not automatically migrate from its assigned compute pool merely because another pool has available capacity.

Question 18

Topic: Confluent Cloud Streaming Pipelines

A team must export all new records from Kafka topic orders to an Amazon S3 bucket. The solution must use private connectivity and the approved AWS key pair, without a custom application.

Resource inventory:

• Kafka cluster: Enterprise, AWS us-east-2, private networking
• Connector service account: granted read access to orders and its consumer group
• S3 credential: permitted to list and write objects in the target bucket
• Egress PrivateLink gateway, S3 access point, and gateway DNS record: READY

Approved connector matrix:

Which action should the operator take to satisfy and validate the requirement? Select ONE.

Options:

• A. Deploy the Amazon S3 Source through the configured egress access point; verify its tasks are running and S3 objects produce records in orders.

• B. Deploy the HTTP Sink against the S3 HTTPS endpoint using the AWS key pair; verify its tasks are running and successful HTTP responses increase.

• C. Deploy the Amazon S3 Sink through the configured egress access point; verify its tasks are running and new records appear in S3 after flushing.

• D. Replace the egress path with Dedicated Private Link Access before deploying the Amazon S3 Sink; verify its tasks are running and objects appear in S3.

Best answer: C

Explanation: A source connector imports data from an external system into Kafka, while a sink connector exports Kafka records to an external system. Because the requirement is to move records from orders to Amazon S3, the Amazon S3 Sink has the correct direction.

The matrix confirms that this connector is available and supports both the approved AWS key pair and Egress PrivateLink. The inventory also shows that its principal can read the topic, the external credential can write to the bucket, and the required gateway, access point, and DNS record are ready.

Validation should not rely only on the connector’s overall state. The operator should confirm that its tasks are running and that consumed records produce the expected S3 objects after the configured flush behavior.

Why each option fits or fails:

A. An S3 Source imports objects into Kafka, which reverses the required export direction.

B. The approved HTTP Sink configuration requires OAuth 2.0, so the supplied AWS key pair does not satisfy its authentication requirement.

C. The S3 Sink has the required Kafka-to-S3 direction, matches the approved authentication and private path, and can be validated at task and output levels.

D. Dedicated Private Link Access concerns Dedicated cluster connectivity and does not replace the ready Enterprise connector egress path shown in the inventory.

Question 19

Topic: Confluent Cloud Data Governance

A team plans to deploy a new version of the orders.enriched-value schema. The version has passed the configured Schema Registry compatibility check, but deployment also requires the EnrichOrders Flink statement to emit records using the new version.

Current lineage:

Resource owners:

The lineage view covers registered schemas, Kafka topics, managed connectors, Flink statements, and declared application consumers. It shows the external warehouse endpoint but does not inventory warehouse jobs or field-level usage inside applications.

Which initial coordination plan is best supported by this lineage evidence? Select ONE.

Options:

• A. Coordinate Data Ingest, Stream Processing, and Risk Apps to validate the upstream path and fraud reader; defer sink validation while its task remains running.

• B. Coordinate every listed owner to validate every shown resource; treat the lineage view as complete evidence of all downstream warehouse effects.

• C. Coordinate Risk Apps and Analytics Integration to validate both downstream readers; omit Stream Processing because Schema Registry accepted the new version.

• D. Coordinate Stream Processing, Risk Apps, and Analytics Integration to validate the revised output and both direct read paths; obtain separate evidence for warehouse jobs.

Best answer: D

Explanation: Lineage supports impact analysis by tracing visible producers and consumers around the resource being changed. Here, EnrichOrders produces records for orders.enriched, while FraudScorer and orders-sink consume them. Their owners are therefore the initial validation contacts for output generation, application consumption, and sink processing.

Passing a Schema Registry compatibility check addresses schema evolution rules, not successful production, application behavior, connector mapping, or external-system processing. Likewise, a connector’s running state does not prove that it can process the revised records. The lineage coverage ends at the warehouse endpoint, so warehouse jobs and field-level application usage require additional evidence from system owners, configuration reviews, or testing.

Why each option fits or fails:

A. A running task does not establish compatibility, and this plan omits the sink that directly reads records governed by the changed schema.

B. The upstream source is not a direct dependency of the changed output schema, and the stated coverage cannot establish every external warehouse effect.

C. Schema compatibility acceptance does not prove that the Flink statement can correctly emit records using the new schema version.

D. These owners cover the producer and both direct consumers of the changed schema, while warehouse-job effects remain outside the stated lineage coverage.

Question 20

Topic: Confluent Cloud Data Governance

A team is preparing version 4 of the orders-value subject for release.

Current state:

• Schema Registry default: BACKWARD_TRANSITIVE
• Subject override for orders-value: FULL_TRANSITIVE
• The approved version 4 schema passed the subject-wide compatibility test under the configured policy.
• release-sa can register versions for orders-value but cannot update compatibility settings.
• governance-admin can update compatibility settings.

Desired state: Register version 4 under the current subject policy, then remove the override so later versions inherit the registry default.

Which transition step is ready now and preserves the desired policy change?

Options:

• A. Remove the subject override with release-sa, then register version 4 under BACKWARD_TRANSITIVE.

• B. Delay registration until release-sa also receives permission to update compatibility settings.

• C. Change the registry default to FULL_TRANSITIVE, remove the subject override, then register version 4.

• D. Register version 4 with release-sa, then have governance-admin remove the subject override.

Best answer: D

Explanation: A subject-specific compatibility setting overrides the Schema Registry default for that subject. Therefore, version 4 is currently governed by FULL_TRANSITIVE, not BACKWARD_TRANSITIVE. Because the approved schema passed the configured subject-wide check, release-sa can register it using its existing schema-write permission.

Compatibility testing does not itself register the schema. After registration, an authorized administrator can remove the subject override. Once removed, later registrations for orders-value inherit the registry-level BACKWARD_TRANSITIVE policy. The effective scope of a compatibility setting is distinct from authorization: permission to register a schema version does not imply permission to update compatibility configuration, and one principal need not possess both permissions for the transition to proceed.

Why each option fits or fails:

A. release-sa lacks permission to change compatibility settings, and removing the override first would evaluate registration under the registry default.

B. Registration can proceed with the existing schema-write permission; the later configuration change can be performed by the authorized administrator.

C. The existing subject override already supplies FULL_TRANSITIVE, while changing the registry default would alter policy for other subjects that inherit it.

D. The subject override currently enforces FULL_TRANSITIVE, the schema passed that policy, and registration permission is separate from permission to remove the override.

Question 21

Topic: Confluent Cloud Data Governance

An operator must satisfy these requirements:

• Morgan may maintain catalog tags and business metadata only in env-prod.
• Morgan is also approved to maintain schema subjects and compatibility within env-prod; Kafka record access and access to other environments are not approved.
• Audit events must be retained in an approved immutable archive for 90 days.

Available grants:

The service account sa-audit-export already has AuditLogViewer. An approved collector can write to the archive after authenticating to the audit-log resource. Confluent Cloud retains audit logs natively for seven days.

Which two measures satisfy the requirements with the required scope? Select TWO.

Options:

• A. Issue sa-audit-export an audit-log-scoped API key and run the collector to retain events for 90 days.

• B. Grant Morgan DataDiscovery in the env-prod environment.

• C. Grant Morgan DataSteward in the env-prod environment.

• D. Grant Morgan DataSteward at the organization scope.

• E. Issue sa-audit-export a Cloud resource-management API key and run the collector to retain events for 90 days.

Correct answers: A and C

Explanation: Governance permissions should be assigned at the narrowest scope that covers the operating task. DataSteward at env-prod allows Morgan to maintain catalog tags and business metadata without granting organization-wide authority or unrelated Kafka message access. DataSteward also permits schema creation, evolution, deletion, and compatibility changes in its scope; those powers are explicitly approved here. DataDiscovery is read-only for the relevant governance activities.

Audit-log authorization and authentication are separate requirements. sa-audit-export already has AuditLogViewer, but the collector also needs an API key scoped to the audit-log resource. Because native audit-log retention is only seven days, the collector must place events in the approved external archive to meet the 90-day requirement. A Cloud resource-management key is intended for management APIs and does not authenticate audit-log consumption.

Why each option fits or fails:

A. The existing AuditLogViewer authorization and an audit-log-scoped credential allow the collector to preserve events beyond native retention.

B. DataDiscovery supports inspection but does not provide the required permission to maintain tags and business metadata.

C. Environment-scoped DataSteward permits the required metadata maintenance without extending governance authority to other environments.

D. Organization-scoped DataSteward exceeds the stated boundary by granting governance authority outside env-prod.

E. A Cloud resource-management key cannot substitute for the audit-log-scoped key required to consume audit events.

Question 22

Topic: Confluent Cloud Resilience

An operations team is preparing to hand off an AWS workload that uses a private, multi-zone Confluent Cloud Dedicated cluster.

Current state:

• Application instances and PrivateLink endpoint network interfaces are present in AZ-a and AZ-b.
• Both application tiers use two customer-managed DNS forwarders, but both forwarders run in AZ-a.
• A dependent database has tested multi-zone failover.

Transition evidence: During an AZ-a isolation test, the cluster remains healthy and an existing consumer in AZ-b continues processing. Replacement instances in AZ-b cannot start Kafka sessions because broker hostname lookups time out.

Desired handoff: The service must support fresh client starts and reconnections after either availability zone fails.

Which dependency must the team address before the handoff can proceed?

Options:

• A. Deploy DNS resolver capacity in AZ-b, then isolate AZ-a and verify fresh clients can resolve and reconnect to bootstrap and discovered broker endpoints.

• B. Deploy a third DNS resolver in AZ-a, then isolate one resolver and verify fresh clients can reconnect through either remaining resolver.

• C. Deploy a linked Kafka cluster in another region, then isolate AZ-a and verify its mirror topics remain caught up during the test.

• D. Deploy additional application instances in AZ-b, then isolate AZ-a and verify existing consumers rebalance across the remaining instances.

Best answer: A

Explanation: A multi-zone Confluent Cloud cluster protects the managed Kafka service from a zone failure, but it does not make customer-managed client dependencies resilient. Here, both DNS forwarders share AZ-a, so losing that zone removes name resolution for replacement or reconnecting clients in AZ-b. Existing Kafka connections can temporarily hide this failure because they may continue without another DNS lookup.

Resolver capacity must exist outside the failed zone. Validation should isolate AZ-a, start fresh clients in AZ-b, and confirm that they can resolve the bootstrap hostname, reach discovered broker endpoints, authenticate, and resume processing. This tests the complete client path rather than relying only on cluster health or an existing session.

Why each option fits or fails:

A. Resolver capacity outside AZ-a removes the remaining zonal dependency, while fresh connections validate DNS and reachability to all required Kafka endpoints.

B. Additional resolver instances in AZ-a remain unavailable when that entire zone fails, so they do not provide zonal resilience.

C. Cluster Linking addresses regional recovery rather than the customer-managed DNS dependency preventing clients from using the healthy multi-zone cluster.

D. Additional instances cannot establish Kafka sessions while their only DNS forwarding capacity remains in the failed zone.

Question 23

Topic: Confluent Cloud Resilience

A company uses Cluster Linking for an active-passive regional recovery design. At 14:20, the source region is declared unavailable.

Observations:

• The source cluster API and bootstrap endpoints are unreachable.
• At 14:18, the last successful observation showed the mirror topic trailing by about 75 seconds and 8,500 records.
• The destination cluster is healthy, and destination networking, credentials, and client configurations were previously validated.
• The destination mirror topic remains read-only.
• The recovery policy prioritizes restoring writes within 15 minutes and accepts an RPO of up to 5 minutes.
• The incident commander has authorized unplanned regional recovery.

Which action should the operator take? Select ONE.

Options:

• A. Reset destination consumer offsets to the latest synchronized positions and redirect producers and consumers to the mirror topic.

• B. Keep the mirror read-only, redirect consumers, and queue new writes until the source returns and promotion can complete.

• C. Promote the mirror topic, redirect clients to the destination, and treat the observed 75-second lag as fully synchronized.

• D. Fail over the mirror topic, redirect clients to the destination, and record that unreplicated source records may be unavailable.

Best answer: D

Explanation: Forced failover is the appropriate Cluster Linking recovery operation when the source is unreachable and service restoration takes priority over waiting for complete synchronization. It makes the destination mirror topic writable without the reachable-source and caught-up-state checks required for planned promotion.

The last observation showed replication lag, and telemetry stopped before recovery began. Therefore, the operator cannot promise zero data loss. Records not replicated before source loss may be unavailable at the destination, even though the observed lag was within the stated RPO. After failover, clients can use the already validated destination path. Recovery records should preserve the last-known lag evidence, and the runbook should prevent the returning source from creating conflicting writes until reconciliation is completed.

Why each option fits or fails:

A. Offset changes affect consumer reading positions but do not convert a read-only mirror topic into a writable topic.

B. Waiting for planned promotion conflicts with the authorized 15-minute write-recovery priority despite reducing data-loss risk.

C. Planned promotion requires a reachable source and caught-up replication and synchronization state, neither of which can be confirmed.

D. Failover makes the mirror writable without source catch-up checks and appropriately acknowledges exposure from the last-known replication lag.

Question 24

Topic: Confluent Cloud Resilience

Cluster East was the original active cluster. During a regional outage, its mirror topic on Cluster West was failed over and Cluster West became active.

Current state:

• Cluster West contains 85,000 records written since failover.
• Cluster East accepted 420 divergent records during isolation that never reached Cluster West.
• East-to-West and West-to-East cluster links are configured, but topic replication is stopped.
• The supported West-to-East truncate-and-restore workflow truncates and restores the East topic to the West lineage, discarding East-only records.
• Operations must retain every West write and preserve the divergent East records for later reconciliation.
• Producers can be paused during the final cutover.

Which failback plan should the operator use? Select ONE.

Options:

• A. Export East-only records, start West-to-East truncate-and-restore, pause West producers, verify final catch-up, promote East, then redirect clients and reconcile the export.

• B. Export the East-only records, resume East-to-West replication, verify West has zero link lag, pause West producers, promote East, and then redirect clients and reconcile the export.

• C. Start West-to-East truncate-and-restore, wait for zero record lag, export the East-only records, pause West producers, promote East, and then redirect clients and reconcile both histories.

• D. Export the East-only records, start West-to-East truncate-and-restore, pause West producers when the link reports running, promote East before record lag reaches zero, and then redirect clients.

Best answer: A

Explanation: Failback is a controlled migration from the new active cluster, not merely a restart of the recovered endpoint. Cluster West became the authoritative source for the shared topic lineage and all records written after failover.

Because truncate-and-restore truncates and restores the East topic, the divergent East-only records must first be exported or otherwise preserved. Replication should then run from West to East. Pause West producers and confirm the replication direction and final zero record lag before planned promotion. Synchronize final consumer positions and stop the old consumers before moving the group. This prevents a pre-pause lag observation from overlooking later writes. Clients can then be redirected to East, and the preserved divergent records can be reconciled according to business requirements. A later reverse-and-start operation is a distinct planned role reversal on the restored mirror; it is not the operation that removes divergent history.

Why each option fits or fails:

A. Export precedes truncation; stopping writes before the final catch-up check ensures that all West records are mirrored before planned cutover.

B. East-to-West replication uses the recovered stale cluster as the source rather than rebuilding it from the active West cluster.

C. The truncate-and-restore operation discards East-only records, so they cannot be exported afterward for reconciliation.

D. A running link does not establish that all West records have replicated, so early promotion can violate the requirement to retain every West write.

Continue in the web app

Use IT Mastery for interactive Confluent CCAC practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Confluent CCAC on Web

Recall operating boundaries · Official resources · Report a question issue