CCDAK 試験ガイド：出題範囲・配点・申込み・対策

CCDAK は、Kafka アプリケーション開発（Producer/Consumer、Schema Registry、Kafka Streams、Kafka Connect、セキュリティ/可観測性）に焦点を当てた認定です。単なる用語暗記ではなく、設計判断（配信保証・スキーマ進化・並列度・運用上のトレードオフ）を問われます。

本ガイドは、公式ドキュメントの安定仕様を前提に、試験で頻出の観点を実務の手触りで解説します。最新の試験仕様は必ず Confluent 認定ページで最終確認してください。

CCDAKの概要と現場での価値

CCDAK は Kafka ベースのアプリ開発者向け認定で、データ設計と API 利用の正確性、可用性・耐障害性・整合性に関する判断を評価します。主な対象は、Producer/Consumer の実装、Schema Registry を用いたスキーマ管理、Kafka Streams でのストリーム処理、Kafka Connect によるデータ連携です。

試験はベンダー中立の Kafka コア概念（トピック/パーティション、複製、ISR、リーダー選出、コンシューマグループ）、配信保証（at-most/at-least/exactly-once）、セキュリティ（TLS/SSL、SASL 概念）、監視（主要ブローカ/クライアントメトリクス）を中心に、Confluent プラットフォームの実務的利用（Schema Registry、Connect、Streams）までをカバーします。

• 想定ロール: アプリ開発者、データエンジニア、ストリーミング基盤のテックリード
• 扱うタスク: Producer/Consumer 実装、セロ・ワン・マルチの配信保証設計、スキーマ進化と互換性、Streams トポロジ設計、Connect のシンク/ソース連携
• 重視される力: 正しい構成の選択理由を説明できること（acks、idempotence、再試行、オフセット管理、処理順序の保証範囲）

出題範囲と配点の目安

正確な配点は試験バージョンで調整されます。以下は公式領域に基づく目安レンジです。設問は単一領域に閉じない（例: Producer の再送制御とブローカの min.insync.replicas の組合せ）ため、領域横断の因果を説明できる知識が必要です。

Streams と Schema Registry/SerDes は設計レベルの理解（状態管理、再パーティショニング、互換性戦略）が問われます。操作コマンドや運用は開発者視点の範囲（コンシューマグループの確認、レイテンシやスロットル指標の読み方）が中心です。

• Kafka 基礎（トピック/パーティション/複製/ISR/リーダー）: 約15–20%
• Producer/Consumer（acks・再試行・idempotence・トランザクション・オフセット管理）: 約25–30%
• Schema Registry と SerDes（Avro/JSON Schema/Protobuf、互換性モード、進化）: 約10–15%
• Kafka Streams（状態ストア、再パーティショニング、処理保証、ジョイン/集約）: 約20–25%
• Kafka Connect（ソース/シンク、分散実行、エラーハンドリング/DLQ、変換）: 約10–15%
• セキュリティ/監視（SSL/SASLの概念、主要メトリクス、クライアント・ブローカ設定）: 約10–15%

申込み・受験方式・当日の流れ

申し込みは Confluent の認定ページから行います。アカウント作成後、試験カタログで CCDAK を選択し、受験方式（オンライン監督またはテストセンター）と日時を予約します。受験環境要件（カメラ、マイク、安定回線、身分証）とシステムチェックは事前に完了させてください。

試験時間・問題数・合格基準はバージョンにより調整されます。言語は主に英語です。再受験ポリシーやキャンセル/日程変更、受験有効期限、受験料・バウチャーの扱いは必ず公式規約を確認してください。

• 公式認定ページから予約、本人確認書類が必須
• オンライン監督時は静かな個室・クリアデスク・常時カメラ/マイク
• システムチェック（回線、ブラウザ、セキュリティ設定）を事前実施
• 再受験や日程変更のルールはバージョン/地域で異なるため公式を参照

合格ロードマップ（4週間プラン例）

短期集中で基礎→API→処理基盤の順に積み上げます。各週で必ず演習（ローカルやコンテナでの実行、壊してから直す）を入れ、設定値と観測結果を結びつけます。

暗記よりも、設定を変えたときの振る舞い（重複、順序、遅延、再均等化、スループット/耐障害性のトレードオフ）を説明できる状態を目指します。

• Week1: コア概念（パーティション/複製/ISR、コンシューマグループ、リバランス）と主要 CLI
• Week2: Producer/Consumer API（acks、retries、delivery.timeout.ms、idempotence、オフセットコミット）
• Week3: Schema Registry（互換性モード/進化）、Kafka Streams（状態・再パーティショニング・EOS）
• Week4: Kafka Connect（分散モード、DLQ/リトライ）、セキュリティ概念、模擬試験と弱点潰し
• 実務連動演習: Avro でスキーマ進化、Streams で集計、Connect で RDB→Kafka→オブジェクトストレージ

重要トピック深掘り：配信保証とExactly-Once

Producer の配信保証は acks、retries、enable.idempotence、max.in.flight.requests.per.connection、delivery.timeout.ms の相互作用で決まります。idempotent producer とトランザクション（transactional.id）を組み合わせると、Kafka 内部では重複なくコミット単位の原子性を実現できます。コンシューマ側では isolation.level=read_committed を設定し、コミット済みレコードのみを読むことで EOS を完結させます。

Kafka Streams では processing.guarantee=exactly_once_v2 を利用します。これは内部のプロデューサ/コンシューマ設定（トランザクション・idempotence）を適切に束ね、状態ストアと出力トピック間の整合性を担保します。外部システムまで含めた完全な EOS はシステム依存であり、Kafka 外のシンクが冪等・トランザクション対応でない場合は少なくとも at-least-once を前提に設計します。

• acks=all は min.insync.replicas と組にする。ISR がしきい値未満なら書き込みは失敗し安全側に倒れる
• idempotence 有効時は max.in.flight を 5 以下（順序厳密なら 1）に制限。retries は高めでも重複を生まない
• Transactional producer には一意の transactional.id が必要。コンシューマは read_committed を設定
• Streams では exactly_once_v2 を推奨。旧設定は互換性はあるが新規は v2 が安定

データフローと消費グループの並列度

設定例：Idempotent Producer と Kafka Streams EOS

// Java Producer (idempotence + transactions)
Properties p = new Properties();
p.put("bootstrap.servers", "localhost:9092");
p.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("acks", "all");
p.put("enable.idempotence", "true");
p.put("retries", Integer.toString(Integer.MAX_VALUE));
// 厳密な順序が必要なら 1、スループット優先なら <=5
p.put("max.in.flight.requests.per.connection", "1");
p.put("transactional.id", "orders-txn-001");
KafkaProducer<String, String> producer = new KafkaProducer<>(p);
producer.initTransactions();
try {
  producer.beginTransaction();
  producer.send(new ProducerRecord<>("orders", "k1", "v1"));
  // 複数レコードを1トランザクションに束ねる
  producer.commitTransaction();
} catch (Exception e) {
  producer.abortTransaction();
}
producer.close();

// Java Consumer (read committed)
Properties c = new Properties();
c.put("bootstrap.servers", "localhost:9092");
c.put("group.id", "orders-app");
c.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
c.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
c.put("isolation.level", "read_committed");

// Kafka Streams (EOS v2)
Properties s = new Properties();
s.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
s.put(StreamsConfig.APPLICATION_ID_CONFIG, "payments-streams");
s.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, StreamsConfig.EXACTLY_ONCE_V2);
StreamsBuilder b = new StreamsBuilder();
KStream<String, String> in = b.stream("payments");
in.groupByKey().count(Materialized.as("cnt")).toStream()
  .to("payments-agg", Produced.with(Serdes.String(), Serdes.Long()));
KafkaStreams app = new KafkaStreams(b.build(), s);
app.start();

模擬演習の作り方と本番テクニック

設問は“この要件で最も適切な設定はどれか”が多いです。選択肢を読む順番を固定（まず非現実的なものを除外）し、残る2択で要件に最短距離の設定を選びます。数値やタイムアウトは相互作用（delivery.timeout.ms と retries×linger×batch.size など）を意識します。

自作模擬は、要件→設定→観測の三点セットで作ると効果的。例えば「重複禁止」「順序必須」「高スループット」の3条件で Producer 設定を比較し、ブローカの min.insync.replicas を変えた時の失敗モードを観測します。CLI では consumer-groups の lag 確認、トピックのパーティション数と割当の整合をチェックできるようにしておきます。

• 不正解の典型: acks=1 で安全を謳う、idempotence なしで EOS を主張、read_uncommitted のまま消費
• Streams の再パーティショニングが必要かを見抜く（keyBy/groupBy 後の並列度とシャッフル）
• Schema 互換性は“追加の安全/危険”を問う設問に強い（BACKWARD/FORWARD/FULL の使い分け）
• 時間配分: 1周目で易問を先に確保、難問はマークして2周目で精査

問題で確認

よくある質問