Confluent Cloud Overview: Managed Kafka Features and Exam Prep

Confluent Cloud delivers Apache Kafka as a fully managed service, with scaling, upgrades, repairs, and monitoring handled on the service side. Developers can focus on producers/consumers, schemas, connectivity, and security boundaries.

This article summarizes cluster types and scaling, security and networking, schema management and development flow, observability, and exam-relevant points, all based on stable official specifications.

What Is Confluent Cloud: Provided Components and Responsibility Boundaries

Confluent Cloud provides as a service: Kafka brokers, ZooKeeper/KRaft-equivalent cluster management, upgrades, disaster recovery, data encryption, and multi-AZ deployment (varies by plan). In addition, you can use ecosystem features such as Schema Registry, ksqlDB, Kafka Connect (managed connectors), and Cluster Linking in an integrated way.

Users focus on application-boundary choices such as topic design (partition count, retention, compression, cleanup policy), authentication/authorization (API keys, ACL/RBAC), network connectivity, schema compatibility, and error handling policy. Most broker settings are managed by the service and not changed directly by users (on the exam, the ability to discern which settings are modifiable is important).

• Provided elements: Kafka clusters, Schema Registry, ksqlDB, managed connectors, Cluster Linking, governance features
• Responsibility boundary: broker operations are the service's responsibility; the user owns the application and data modeling
• Connectivity: public endpoints, VPC peering, PrivateLink/Private Service Connect, and more (cloud- and region-dependent)

Confluent Cloud logical architecture (overview)

Cluster Types and Scaling Design

Confluent Cloud clusters are generally offered in Basic / Standard / Dedicated tiers. Basic is for small-scale and testing, Standard offers higher availability (multi-AZ in many regions) and stable throughput, and Dedicated provides dedicated capacity, private connectivity, and incremental scaling (e.g., CKU-based). Specific values and limits change by region and time, so always check the latest official documentation.

Think about scaling together with topic design: partition count, replication factor (generally the service default), retention, and compression. On the exam, do not jump to the conclusion that insufficient throughput equals insufficient partitions; you are tested on the ability to consider it holistically, including producer batching, acks=all, compression, key distribution, and connector task parallelism.

• Basic: cost-focused, for testing and small-scale workloads
• Standard: production-grade availability and throughput. Multi-AZ in most cases
• Dedicated: predictable dedicated capacity, incremental scaling, supports private networking

Security and Networking: Authentication, Authorization, Connectivity

Authentication uses an API Key/Secret (SASL/PLAIN over TLS). Issue them per service account rather than per person, and configure ACLs or RBAC following the principle of least privilege. Traffic is encrypted with TLS, and encryption at rest is also handled service-side.

Connectivity options include public endpoints plus, depending on the cloud, VPC/VNet peering, PrivateLink/Private Service Connect, and IP allowlists. When compliance requirements are strict, it is common to combine a Dedicated cluster with private connectivity.

From an exam perspective, it is important to accurately understand the role differences between ACLs and RBAC (resource-based ACLs vs. role-based RBAC), separation of producer/consumer identities, key rotation procedures, and network isolation options.

• API keys are per environment/cluster. Grant with least privilege
• Use ACLs (topic/group/cluster) and RBAC (permission sets) together
• Private connectivity options vary in availability by cloud/region

Developer Experience and Governance: Schemas, Compatibility, Validation

Schema Registry supports Avro/Protobuf/JSON Schema and lets you set compatibility modes (BACKWARD, FORWARD, FULL, TRANSITIVE, etc.). Subject naming strategy (TopicNameStrategy, RecordNameStrategy, etc.) is chosen on the client side. In Confluent Cloud, you can enable per-topic schema validation to prevent incorrect schema writes early.

For delivery guarantees, leverage idempotence and transactions (EOS v2). For producers, use enable.idempotence=true, acks=all, and in.flight settings consistent with idempotence, and for stream processing set a transactional ID to achieve exactly-once. The exam frequently asks about interdependencies of settings and failure behavior (resend, ordering).

• As a rule, base compatibility on BACKWARD and adjust for downstream requirements
• Decide on an organizational standard for subject naming to prevent deviations
• Use schema validation to protect production topics

Java producer (minimal configuration example for Confluent Cloud)

Properties props = new Properties();
props.put("bootstrap.servers", "<broker-endpoint>:9092");
props.put("security.protocol", "SASL_SSL");
props.put("sasl.mechanism", "PLAIN");
props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username='\u003cAPI_KEY\u003e' password='\u003cAPI_SECRET\u003e';");
// 配信保証（冪等）
props.put("enable.idempotence", "true");
props.put("acks", "all");
props.put("max.in.flight.requests.per.connection", "5"); // idempotence と整合
props.put("compression.type", "lz4");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

KafkaProducer<String, String> p = new KafkaProducer<>(props);
p.send(new ProducerRecord<>("orders", "k1", "v1"), (md, ex) -> { /* handle */ });
p.flush();
p.close();

Operations and Observability: Metrics, Limits, Modifiable Settings

Because Confluent Cloud is managed, many broker settings are fixed/private. What users can operate on is primarily topic settings (retention, increasing partition count, compression, cleanup.policy=delete/compact, etc.) and access control. Design with the assumption that core settings such as the replication factor, set by service defaults, cannot be changed.

Monitoring is done via the console, alerts, and the Cloud Metrics API. Integrate producer/consumer latency, throughput, error rate, consumer lag, and so on with external monitoring, and define SLOs. Log forwarding and alert integrations vary in available features by cloud/region and plan, so verify before adoption.

Considerations when changing settings: partition count can be increased but not decreased. After increasing, verify that key distribution is not skewed and understand the ordering boundary (guaranteed only within a partition). Changes to retention or compaction settings affect downstream systems (replay/recovery strategy).

• Leverage the Cloud Metrics API to integrate visualization with external APM
• Define SLO/SLI per topic (latency, errors, lag)
• Make changes incrementally. Validate production with a canary

Exam Prep Essentials (CCDAK / CCAAK)

CCDAK emphasizes data modeling, delivery guarantees, and client configuration; CCAAK emphasizes operations, security, and scaling. Questions assuming Confluent Cloud tend to ask about the range of parameters tunable in a managed environment, network isolation, schema validation, migration/DR via Cluster Linking, and parallelism and error handling for managed connectors.

On practice exams, watch out for traps such as: private connectivity available only on Dedicated, whether the replication factor can be changed, client tuning before broker settings, choosing schema compatibility modes, enabling per-topic schema validation, and the fact that increasing partitions does not guarantee global ordering.

• Memorize the line between what is possible and what is not (especially network and broker settings)
• First, remove bottlenecks via client-side tuning
• Make schema compatibility and validation mandatory on production topics

Check Your Understanding

Frequently Asked Questions