Confluent CCDAK 30-, 60-, and 90-day study plan with topic order, review loops, and final-week priorities.
This page answers the real prep question for CCDAK: how do I organize Kafka developer study so partitioning, producer guarantees, consumer offsets, and schema choices keep making sense together?
Use the plan that matches your available time, then follow the loop: official scope -> drills -> miss review -> mixed sets -> timed runs.
Typical ranges based on background:
| Your starting point | Typical total study time | Best-fit timeline |
|---|---|---|
| You’ve built production Kafka producers/consumers | 30–50 hours | 30–60 days |
| You’ve used Kafka lightly (basic pub/sub) | 50–80 hours | 60–90 days |
| You’re new to Kafka client development | 80–120+ hours | 90 days |
Choose a plan based on hours per week:
| Time you can commit | Recommended plan | What it feels like |
|---|---|---|
| 10–12 hrs/week | 30‑day intensive | Fast learning + lots of reps |
| 6–8 hrs/week | 60‑day balanced | Steady progress + review time |
| 3–5 hrs/week | 90‑day part‑time | Slow-and-solid with repetition |
If you want one rule: spend ~60% learning + 40% practice early, then invert it to ~30% learning + 70% practice in the final 1–2 weeks.
Confluent does not publish a public weighted domain table for CCDAK, so use this review order:
Target pace: ~10–12 hours/week. Goal: cover the blueprint quickly, then harden instincts through drills and mixed sets.
| Week | Focus | What to do | Links |
|---|---|---|---|
| 1 | Kafka fundamentals + partitioning | Learn topics, partitions, ordering, keys, replication awareness, and consumer-group scaling limits. | Resources • Cheat Sheet |
| 2 | Producer behavior | Drill acks, retries, batching, idempotence, and in-flight ordering trade-offs. |
Cheat Sheet • Glossary |
| 3 | Consumer groups + offsets | Master poll loops, commit strategies, offset reset, rebalances, liveness, and lag interpretation. | Resources • Glossary |
| 4 | Transactions + schemas + troubleshooting | Add transactions, read_committed, compatibility modes, and client-failure diagnosis. Finish with mixed timed runs. |
FAQ • Glossary |
Target pace: ~6–8 hours/week. Goal: learn steadily with more time to review and build repetition.
| Weeks | Focus | What to do |
|---|---|---|
| 1–2 | Fundamentals + partitioning | Read core concepts, then run a mini lab with keyed vs unkeyed records and consumer-group scaling. |
| 3–4 | Producer reliability + performance | Batching vs latency, retries, idempotence, in-flight limits, and safer throughput tuning. |
| 5–6 | Consumer groups + offsets | Rebalances, commit strategies, auto.offset.reset, and failure-handling or poison-message choices. |
| 7–8 | Transactions + schemas + review | Transactions, read_committed, Schema Registry awareness, compatibility mindset, then mixed sets and remediation. |
Target pace: ~3–5 hours/week. Goal: slow-and-solid reps with spaced repetition.
| Month | Focus | What to do |
|---|---|---|
| 1 | Fundamentals | Learn topics, partitions, offsets, consumer groups, and ordering boundaries; run small lab experiments. |
| 2 | Producers + consumers | Alternate weeks between producer guarantees and consumer correctness. |
| 3 | Semantics + polish | Transactions, schema evolution, troubleshooting, and final mixed review. |
flowchart LR
A["Read one lesson"] --> B["Run one small Kafka client drill"]
B --> C["Write 3 behavior rules"]
C --> D["Do one short scenario set"]
D --> E["Log misses by producer, consumer, schema, or troubleshooting lane"]
Strong developer rules look like this:
ordering is per partition, not per topicat-least-once means duplicates are possibleidempotence helps retries, but transactions solve a different scope