Browse Exams — Mock Exams & Practice Tests

CCAC Cheatsheet — Confluent Cloud Ops: Networking, RBAC, Governance, Connectors & Linking

Comprehensive CCAC quick reference: Confluent Cloud resource model, private networking options, service accounts + API keys + RBAC, Stream Governance and schema discipline, managed connectors operations, Cluster Linking patterns, and troubleshooting signals.

On this page

Use this for last‑mile review. Pair it with the Syllabus for coverage and Practice to harden instincts.

1) Confluent Cloud resource model (the hierarchy you must know)

    flowchart TD
	  ORG["Organization"] --> ENV["Environment"]
	  ENV --> CL["Kafka Cluster"]
	  ENV --> SR["Schema Registry"]
	  ENV --> SG["Stream Governance (Catalog)"]
	  ENV --> SA["Service Accounts"]
	  SA --> KEY["API Keys"]
	  ENV --> CONN["Connectors"]

High-yield rules

  • Treat environments as your blast-radius boundary (dev/test/prod isolation).
  • API keys belong to service accounts; rotate keys and avoid shared “human” keys.
  • Governance (catalog/schemas) is easiest when standardized at the environment level.

2) Access control: service accounts, API keys, RBAC

Authentication vs authorization

  • Authentication: “Who is calling?” (API key / identity)
  • Authorization: “What can they do?” (RBAC role bindings and scopes)

Operational key lifecycle (minimal safe baseline)

Step What to do Why
Create service account Use per-app identities Audit + least privilege
Grant RBAC role Scope to env/cluster/resources Reduce blast radius
Create API key Store in secret manager Avoid leaking credentials
Rotate regularly Dual keys during rotation Zero downtime changes
Revoke on exit/incident Remove bindings + delete keys Close access quickly

3) Networking in Confluent Cloud (public vs private)

Connectivity options (mental model)

Option What it is When it’s used What to remember
Public endpoint Access over internet Default, fast to start Use allowlists where possible
PrivateLink / private service access Private connectivity into your VPC/VNet Compliance + no public exposure DNS/routing planning matters
VPC/VNet peering Private network peering Controlled private routing IP overlap pitfalls

DNS gotcha: private connectivity often requires private DNS or custom resolution so clients resolve brokers to private endpoints.

4) Kafka cluster knobs (operator level)

Topic basics: partitions and parallelism

You want… Do this Why
More consumer parallelism Increase partitions One consumer per partition per group
Preserve ordering for an entity Use a stable key Ordering is per partition
Reduce duplicate risk Use idempotent producer patterns Retries happen

Retention vs compaction (remember intent)

Policy Best for Mental model
Retention (delete) Event logs / audit streams Keep full history for N days
Compaction Changelogs / latest state per key Keep last value per key

5) Stream Governance + schemas (operator mindset)

Schema compatibility (why it shows up)

Compatibility answers: “Who can read what after change?”

Mode Safe for… Simple rule
BACKWARD New consumers reading old data Add fields with defaults
FORWARD Old consumers reading new data Be careful with removals
FULL Both directions Strictest; safest at scale

Operator rule: choose guardrails that prevent breaking changes in shared topics.

6) Managed connectors (what “managed” does and doesn’t do)

Connector ops checklist

Question Why it matters
Is the connector authorized to read/write? RBAC + API key scope issues are common
Is the destination reachable privately? Networking and DNS routing issues
Is schema/serialization compatible? Deserialization failures can halt tasks
Is throughput bounded? Quotas/limits can cause backpressure

Failure patterns (high-yield)

  • Task failures due to auth (invalid key, missing permissions)
  • Failures due to network (private endpoint misconfigured, DNS mismatch)
  • Failures due to data (schema incompatibility, bad payload)

7) Cluster Linking (multi-cluster replication patterns)

Why Cluster Linking exists

Cluster Linking supports replicating data across clusters for:

  • multi-region reads
  • disaster recovery
  • multi-cloud topologies
    flowchart LR
	  SRC["Source cluster"] --> LINK["Cluster Link"]
	  LINK --> DEST["Destination cluster"]
	  DEST --> APPS["Consumers (region B)"]

Operational cues

  • Treat linking as a platform primitive (monitor lag/health like you would consumer groups).
  • Design for failover: know which cluster is the source of truth and how clients switch.

8) Monitoring + troubleshooting pickers

  • Clients can’t connect: advertised endpoints/DNS/private networking mismatch; allowlists; TLS/SASL config mismatch.
  • Auth errors: API key belongs to wrong service account; missing RBAC binding; wrong scope (env vs cluster).
  • Lag / backlog: insufficient partitions, slow consumers, connector throughput caps, or quota throttling.
  • Connector failing: auth/network/data; inspect task error first, then validate destination and serialization.

Mini-glossary

Environment (blast radius) • Service account (identity) • API key (credential) • RBAC (authorization) • Private connectivity (no public path) • Cluster Linking (multi-cluster replication) • Schema compatibility (safe evolution rules).

Syllabus
Practice