Using Confluent Cloud's Free Tier: Learning Cluster Setup and Hands-On Practice (CCDAK/CCAAK)

Confluent Cloud takes Kafka operations off your hands with a managed service, which makes it ideal for hands-on practice with low learning cost and risk. This article lays out a procedure to confirm the CCDAK / CCAAK essentials by actually working through them, all within the free tier / trial credit.

Prices and perks change with promotions. Always defer to the official documentation and the console display for figures and limits, and we keep cost-heavy features (Connectors, ksqlDB, etc.) to the bare minimum in this article.

Free Tier Assumptions and Study Plan (Basics for Safe Operation)

Confluent Cloud's free tier / trial typically deducts usage-based charges from the credit. Amounts and validity periods change, so rather than memorizing numbers, understand structurally where costs grow.

For learning, start with one Basic-equivalent Kafka cluster with the minimum number of topics and partitions, and walk through the full flow of Schema Registry, API keys, and ACL / RBAC. CCDAK emphasizes practical producer / consumer work, partition design, and schema evolution. CCAAK emphasizes access control, permission boundaries, and the basics of monitoring and operations.

• Common cost drivers are cluster uptime, partition count, retention period, throughput, and add-on services (Connectors, ksqlDB, etc.). Start small.
• On Confluent Cloud, the number of brokers and replication factors are largely managed appropriately by the service, so exam study can focus on topic design and client behavior.
• For exam preparation, lock in stable concepts: ordering guarantees (per key), reprocessing (retention / compaction), consumer group rebalancing, and security (SASL_SSL, ACL, RBAC).

Pre-study safety checklist (excerpt)

- Topics minimum (e.g. 1-2 topics, 1-3 partitions each)
- Start with short retention (e.g. 1-24 hours)
- Keep Connectors / ksqlDB disabled at start
- After use, always delete API keys, environment, cluster, and topics
- Check credit balance / billing detail before and after work

Learning Cluster Design (Topics, Partitions, Schemas)

On the free tier, the rule is the smallest configuration that still lets you experiment with reads and writes. Start with 1 topic and 1-3 partitions, then confirm key-based ordering guarantees and consumer group scalability by actually working with them. Defer to the managed side's defaults for replication factor and broker configuration to lower the learning cost.

Use Schema Registry for schemas and experiment with backward-compatible schema evolution. Start with a change that reduces required fields (preserving backward compatibility), then deliberately introduce an incompatible change to observe the error and feel out what the compatibility setting actually means.

• Partition count is a tradeoff between parallelism and ordering guarantees. To guarantee per-key order, fix the key; to raise parallelism, increase partitions — but do so cautiously on the free tier.
• Learn retention strategy in two flavors: time-based retention (retention.ms) and compaction (cleanup.policy=compact). Use one or the other depending on reprocessing requirements.
• Schema Registry compatibility can be set to backward / forward / full, etc. For learning, starting with backward compatibility is the safe choice.

Minimal topic creation example (CLI, with shortened retention)

confluent login --save
confluent environment create learn-env
confluent environment use <ENV_ID>
confluent kafka cluster create learn-basic --type basic --cloud aws --region ap-northeast-1
confluent kafka cluster use <CLUSTER_ID>
# APIキー発行（後でクライアントで使用）
confluent api-key create --resource <CLUSTER_ID> --description learn-key
# トピック（1パーティション、保持1時間の例）
confluent kafka topic create orders --partitions 1 --config retention.ms=3600000

Free-Tier Setup Steps (UI + CLI, Fastest Route)

On the first pass, prepare the environment and Kafka cluster in the Web UI, then create API keys, topics, and ACLs via the CLI — that order has the least confusion. Credit is consumed mainly by cluster uptime and data transfer / storage. The basic move is: create quickly, verify quickly, clean up promptly.

Enabling Schema Registry in the same environment makes downstream schema exercises smoother. Region and cloud provider choices rarely create a big availability difference for learning, so pick what is close and low-latency.

• Always confirm the CLI context points to the right environment and cluster
• Separate API keys for humans (interactive use) from those for service accounts (applications)
• Check the credit / billing dashboard between tasks to detect cost anomalies early

Minimal architecture for learning (free-tier-friendly)

 [Producer App] --(SASL_SSL)--> [Confluent Cloud Kafka] --(group subscribe)--> [Consumer App]
                           \                                          /
                            \-- Schema (Registry) --------------------/

Notes:
- Producer / Consumer connect from the same region to suppress external egress fees
- Use Schema Registry alongside to practice backward-compatible schema evolution
- RBAC / ACL grant least privilege at the cluster level

Shortest CLI command sequence from environment to API key issuance (example)

confluent login --save
confluent environment create learn-env && confluent environment use <ENV_ID>
confluent kafka cluster create learn-basic --type basic --cloud aws --region ap-northeast-1 && confluent kafka cluster use <CLUSTER_ID>
confluent schema-registry cluster enable --cloud aws --geo ap-southeast-1  # 例: リージョンはUIの案内に合わせる
confluent iam service-account create sa-app --description "for app"
confluent api-key create --resource <CLUSTER_ID> --service-account <SA_ID> --description app-key

Hands-On Practice (For Developers: The Heart of CCDAK)

Experience producer / consumer basics, key-based ordering guarantees, and reprocessing. Start with synchronous send to make error handling visible, then watch the throughput difference with asynchronous send and callbacks. On the consumer side, confirm the difference between auto-commit and manual commit, and observe rebalance behavior at low parallelism.

Start with minimal fields in your schema and add fields while preserving backward compatibility. Deliberately try a compatibility-breaking change and confirm that the produce call is rejected — the exam theory clicks into place.

• Confirm same-key ordering guarantees with keyed records
• Experience at-least-once reprocessing with manual commit, accepting a small amount of duplication
• Toggle schema evolution compatibility modes and learn to explain failure reasons from the logs

Python Producer (confluent-kafka, SASL_SSL, minimal example)

from confluent_kafka import Producer
import json

conf = {
    'bootstrap.servers': '<BOOTSTRAP_SERVERS>',
    'security.protocol': 'SASL_SSL',
    'sasl.mechanisms': 'PLAIN',
    'sasl.username': '<API_KEY>',
    'sasl.password': '<API_SECRET>'
}

p = Producer(conf)

def delivery(err, msg):
    if err:
        print(f'Delivery failed: {err}')
    else:
        print(f'Delivered to {msg.topic()} [{msg.partition()}] @ {msg.offset()}')

for order_id in range(1, 6):
    key = f"order-{order_id % 2}"  # 同一キーの順序を確認
    val = json.dumps({'id': order_id, 'amount': 100 + order_id})
    p.produce('orders', key=key, value=val, callback=delivery)
    p.poll(0)

p.flush()
# コンシューマ側では group.id を設定し、auto.offset.reset=earliest で再処理の挙動を確認

Hands-On Practice (For Administrators: CCAAK Essentials)

Confluent Cloud abstracts away most of the broker operations, so for learning, concentrate on access control, permission boundaries, monitoring, and security settings. In particular, clearly separate the roles of ACL and RBAC, and practice least privilege at the service account level.

Check metrics from the console and via CLI / API, and lock in the basic readings of latency, throughput, and error rate. On the free tier, avoid long load tests — keep observation short and clean up rigorously.

• Separate cluster-admin and developer roles via RBAC
• Limit Read / Write on specific topics via ACL
• Make key / secret rotation procedures reproducible by scripting them

Minimal ACL and RBAC example (CLI)

# RBAC: Kafka開発者にDeveloperRead/Writeを付与（リソースはKafkaクラスタ）
confluent iam rbac role-binding create \
  --principal User:<SA_ID> \
  --role DeveloperWrite \
  --cloud-cluster <CLUSTER_ID>

confluent iam rbac role-binding create \
  --principal User:<SA_ID> \
  --role DeveloperRead \
  --cloud-cluster <CLUSTER_ID>

# ACL: 特定トピックordersへの許可（より細粒度）。
confluent kafka acl create \
  --allow \
  --service-account <SA_ID> \
  --operation READ \
  --topic orders

confluent kafka acl create \
  --allow \
  --service-account <SA_ID> \
  --operation WRITE \
  --topic orders

Cost Management and Cleanup (Operating to Protect the Free Tier)

Cost optimization is all about pre-start design and post-task deletion done reliably. Batch your experiments, run them back-to-back, and build the habit of never leaving the environment open. Always revisit retention period and partition count, and delete unnecessary topics immediately.

Confluent Cloud has a solid billing dashboard and usage metrics. Keeping screenshots or CLI logs per experiment also helps later with exam review and team sharing.

• Shorter retention, low partition count, and same-region connectivity hold down network costs
• Enable Connectors / ksqlDB only when there is a clear purpose, and only for short windows
• On shutdown, delete in the order API key → topic → cluster → environment to prevent leftovers

Standard cleanup procedure (CLI)

# コンシューマ/プロデューサ停止後に実施
confluent kafka topic delete orders
confluent api-key delete <API_KEY_ID>
confluent kafka cluster delete <CLUSTER_ID>
confluent environment delete <ENV_ID>
# 削除前に請求ダッシュボードで当日分の増分を確認

Check with a Question

Frequently Asked Questions