Databricks Data Engineer Associate完全解説｜出題範囲・問題例・合格戦略

Databricks Certified Data Engineer Associateは、Lakehouse上でのデータエンジニアリングスキルを証明する認定試験です。 Spark SQL・Python・Delta Lake・Lakeflow Spark Declarative Pipelines・Unity Catalogの実践的理解が問われ、 Databricks認定の中で最も受験者数が多い試験でもあります。

この記事は2026年5月4日改訂の現行Exam Guideに準拠し、7つの出題セクションの配点比率と頻出トピック、 実際の出題パターンに基づくサンプル問題、そして2ヶ月で合格するための学習ロードマップを解説します。

試験概要

まず試験の基本情報を整理します。受験前に確認すべき項目をすべてまとめました。

1点だけ強調しておきます。合格ラインは公表されていません。Databricks公式FAQには「合格スコアは統計的分析によって設定され、試験に新しい問題が追加されると変更されることがある」と記載されています。 「70%」「45問中32問」といった数字が広く出回っていますが、いずれもDatabricks発の情報ではありません。 具体的なボーダーを断言している記事は、根拠のない推測だと考えてください。

45問を90分で解くため、1問あたり平均2分です。 「最も適切なものを選べ」形式が大半で、明らかに間違いの選択肢を消去法で外し、 残り2択まで絞る判断力が求められます。 時間配分としては、確信のある問題は60秒以内で通過し、迷う問題にフラグを付けて最後に見直すのが定石です。

7つの出題セクションと配点比率（2026年5月4日版）

2026年5月4日に改訂された現行Exam Guideでは、出題範囲が7セクション構成になり、配点比率が公式に公開されています。 旧版の5ドメイン構成（Lakehouse Platform / ELT with Spark SQL and Python / Incremental Data Processing / Production Pipelines / Data Governance） とはセクション名も配点も異なるため、古い記事や教材の配点表をそのまま使わないでください。

Data Ingestion and Loading（21%）とData Transformation and Modeling（22%）だけで全体の43%を占めます。 この2セクションを確実に得点源にすることが合格への最短ルートです。 次に大きいのがWorking with Lakeflow Jobs（16%）とGovernance and Security（15%）です。 特にガバナンス系は改訂のたびに比重が上がっており、9%（2024年6月版）→ 11%（2025年11月版）→ 15%（現行）と推移しています。 旧版の学習計画のように「配点が低いので流し読みでよいドメイン」として扱うのは、もはや不利な戦略です。 逆にDatabricks Intelligence Platformは6%（約3問）しかないため、深追いする意味はありません。

もう1つ押さえるべき変更点があります。Delta SharingとLakehouse Federationは出題範囲から削除されました。旧版準拠の教材やブログ記事にはこの2つが試験トピックとして残っていることが多いので、学習時間を割かないでください。

セクション1: Databricks Intelligence Platform（6%）

Lakehouseアーキテクチャの基礎概念と、Databricksプラットフォームの操作に関するセクションです。 「Data WarehouseとData Lakeの違い」「Lakehouseがそれらをどう統合するか」という概念問題に加え、 コンピュートの種類やノートブックの操作が問われます。 配点に注意してください。旧版のDatabricks Lakehouse Platformは24%でしたが、現行セクションは6%（約3問）です。 深追いする場所ではなく、後続セクションを読むための語彙を揃える位置づけと考えてください。

主要トピックと出題傾向

• コンピュートの種類: All-Purpose ComputeとJob Computeの違いは鉄板の出題ポイントです。 「対話的な開発にはAll-Purpose、本番ジョブにはJob Compute」という使い分けに加え、 Job Computeはジョブ終了時に自動削除される点、コスト面でJob Computeの方が安い点が問われます。 SQL Warehouseやサーバーレスコンピュートの位置づけも押さえておくと有利です。
• ノートブックの機能: マジックコマンド（%sql, %python, %md）、 ウィジェット（dbutils.widgets）、%runによるノートブック間の変数共有、 ノートブックのバージョン履歴管理が出題範囲です。
• 何がどこに属するか: アカウント・ワークスペース・Unity Catalogの階層関係、 マネージドテーブルと外部テーブルの違いは、取り込みセクションとガバナンスセクションが前提としている語彙です。

セクション2: Data Ingestion and Loading（21%）

データをLakehouseに取り込む工程のセクションで、配点は全体の2番目です。 Auto Loader・COPY INTO・Structured Streamingが中心トピックで、 「どの場面でどの取り込み方式を使うか」の判断力が試されます。 旧版のIncremental Data Processingドメインは、実質的にこのセクションと次のセクションに分割されました。

主要トピックと出題傾向

• Auto Loader（cloudFiles）: クラウドストレージに到着する新規ファイルを自動検知して取り込む仕組み。 Directory Listing モードと File Notification モードの違い、 スキーマ推論（cloudFiles.inferColumnTypes）とスキーマ進化（cloudFiles.schemaEvolutionMode）の設定が出ます。 「COPY INTOとAuto Loaderの使い分け」は鉄板の出題テーマです。 少数ファイルならCOPY INTO、大量ファイルの継続的取り込みならAuto Loaderが正解になります。
• COPY INTOとread_files: COPY INTOは取り込み済みファイルをスキップする冪等な処理である点、 FORMAT_OPTIONS / COPY_OPTIONS（mergeSchema、force）の指定、ファイルからCTASでDeltaテーブルを作るパターンが問われます。 SQLから直接ファイルを読むread_files関数も押さえておきましょう。
• Structured Streaming: spark.readStream / writeStreamの基本構文、 出力モード（append / complete / update）の違い、トリガー設定（Trigger.availableNow, processingTime）、 チェックポイントの役割が問われます。「Trigger.availableNowとTrigger.onceの違い」も頻出です。
• 半構造化データ: JSONのネスト構造をSpark SQLで展開する方法（「:」記法、explode関数、 from_json、schema_of_json）が問われます。 生ペイロードが1つの文字列カラムで届く取り込み直後の処理として頻出です。

セクション3: Data Transformation and Modeling（22%）

最大の配点比率を持つセクションで、Spark SQLとPySparkによる変換処理の実践力に加え、 メダリオンアーキテクチャを前提としたモデリングの判断力が問われます。 コードの読み書きが直接出題されるため、座学だけでは対応が難しく、ハンズオン経験の差がスコアに直結します。

主要トピックと出題傾向

• Spark SQLの基本構文: SELECT / JOIN / GROUP BY / HAVING / WINDOW関数（ROW_NUMBER, RANK, LAG, LEAD） を使ったデータ変換。特にCTAS（CREATE TABLE AS SELECT）でDeltaテーブルを作成するパターンが頻出です。
• MERGE INTOとCDC: 「既存レコードがあればUPDATE、なければINSERT」するUPSERT処理。 WHEN MATCHED THEN UPDATE / WHEN NOT MATCHED THEN INSERTの構文を正確に書けるかが問われます。 ソースDBのINSERT/UPDATE/DELETEイベントをDeltaテーブルに反映するCDCシナリオ、SCDタイプ1/2と組み合わせた問題が多く、 宣言的パイプライン側の等価な仕組み（APPLY CHANGES INTO / apply_changes）も出題範囲です。
• PySpark DataFrame API: select / filter / withColumn / groupBy / agg の基本操作に加え、 DataFrame APIとSpark SQLの等価な書き方を問う問題が出ます。 spark.sql()でSQL文を実行するパターンも含まれます。
• UDF（User Defined Function）: Python UDFとSpark SQLのビルトイン関数のパフォーマンス差 （Python UDFはSerialization/Deserialization のオーバーヘッドがある）、 SQL UDFの作成構文（CREATE FUNCTION）が出題範囲です。
• メダリオン設計と宣言的パイプライン: Bronze → Silver → Gold が実際のテーブルにどう対応するか、 Lakeflow Spark Declarative Pipelinesの @dlt.table / @dlt.view デコレータの使い方、 ストリーミングテーブルとマテリアライズドビューの違い、 Expectationsによるデータ品質制約（@dlt.expect / @dlt.expect_or_drop / @dlt.expect_or_fail）の3段階の違いが頻出です。 「不正データをドロップしたい」→ expect_or_drop、「パイプラインを止めたい」→ expect_or_fail です。

セクション4: Working with Lakeflow Jobs（16%）

作った処理を1つのジョブに束ね、スケジュールで動かすオーケストレーションのセクションです。 名称に注意してください。旧称のDatabricks Workflowsは現在Lakeflow Jobsであり、 現行Exam Guideもこの名称で統一されています。

主要トピックと出題傾向

• タスクと依存関係: 1つのジョブに束ねられるタスク種別（ノートブック・SQL・パイプライン・Pythonスクリプトなど）、 depends_on によるDAGの組み方が問われます。 「タスクAが成功したらタスクBを実行」のような依存定義に加え、失敗時の分岐を扱う Run if 条件も出ます。
• トリガーとスケジュール: cronスケジュールに加え、ファイル到着トリガー・テーブル更新トリガー・ 継続実行モードが出題範囲です。「この要件ならどのトリガーか」という形で問われます。
• 失敗時の扱いと通知: リトライポリシー、タイムアウト、失敗タスクだけを再実行するRepair run、 開始・成功・失敗・実行時間超過に対するアラート通知（メール / Webhook）の設定が問われます。
• 値の受け渡し: ジョブ・タスクのパラメータ、それを受け取るウィジェット、 タスク間で値を渡すtaskValuesの使い方が出題範囲です。

セクション5: Implementing CI/CD（10%）

旧版には独立したドメインとして存在しなかったセクションで、ノートブックで書いたコードを安全に本番へ届ける工程です。 出題のほとんどはDatabricks Git FoldersとDeclarative Automation Bundlesの2製品でカバーできます。

主要トピックと出題傾向

• Databricks Git Folders（旧 Databricks Repos）: Git連携の仕組み、ブランチの切り替え、 Pull Request経由のコードレビューフロー、管理できるファイルの種類（ノートブック・Pythonファイル・設定ファイル）が問われます。 Pullするとノートブックの実行結果が消える点は典型的な引っかけです。
• Declarative Automation Bundles（旧 Databricks Asset Bundles）: databricks.yml でジョブやパイプラインをコードとして宣言し、 targets で dev / staging / prod を切り分け、variables でパラメータ化する仕組みが問われます。 開発モードと本番モードの違いは頻出です。
• デプロイの自動化: Databricks CLIでバンドルをデプロイし、CIパイプライン（GitHub Actionsなど）に組み込む流れ。 「この処理はどの環境で動かすべきか」「デプロイされたジョブの所有者は誰か」といった形で出題されます。

セクション6: Troubleshooting, Monitoring, and Optimization（10%）

すでに動いているものを対象に、どこで壊れたかを突き止め、コストを監視し、速くするセクションです。 Deltaテーブルの保守コマンドもここに含まれます。旧版でLakehouse Platformドメインにあった OPTIMIZE / VACUUM の知識は、このセクションに移りました。

主要トピックと出題傾向

• Deltaテーブルの保守: ACIDトランザクション、タイムトラベル（DESCRIBE HISTORY / RESTORE）、 スキーマ進化（mergeSchema）、OPTIMIZE / VACUUM の違いは必ず出ます。 OPTIMIZEは小ファイルの圧縮、VACUUMは参照されなくなったファイルの削除で、この2つの取り違えが定番の誤答です。
• レイアウトとパフォーマンス: data skipping、パーティショニングの落とし穴（小さいテーブルの過剰分割）、 ZORDER、スモールファイル問題が出ます。ビルトイン関数とPython UDFの性能差もこの文脈で問われます。
• エラーハンドリングと切り分け: パイプライン失敗時のリトライ戦略、 Lakeflow Spark Declarative Pipelinesのイベントログとジョブの実行履歴によるエラー診断、 ストリーミングジョブのチェックポイントリセット判断が出題範囲です。 イベントログ・ドライバログ・Query Historyのどれを見るべきかを選べるかが問われます。

セクション7: Governance and Security（15%）

最も比重が上がったセクションです。ガバナンス系は2024年6月版で9%、2025年11月版で11%でしたが、 現行では15%（約7問）となり、Lakeflow Jobsと並ぶ規模になりました。 旧版準拠の学習計画は「流し読みでよいドメイン」として扱っていますが、その助言はもう古いものです。 セクション全体の背骨はUnity Catalogです。

主要トピックと出題傾向

• Unity Catalogの3レベル名前空間: catalog.schema.table の階層構造、 デフォルトカタログの設定、USE CATALOG / USE SCHEMA の使い方が基本です。
• GRANT / REVOKE: テーブルやスキーマへの権限付与の構文 （GRANT SELECT ON TABLE catalog.schema.table TO group_name）が出ます。 上位のカタログ・スキーマに USE CATALOG / USE SCHEMA がなければテーブル権限だけでは何もできない点、 そもそも権限を付与できるのは所有者である点も頻出です。
• データリネージと監査: Unity Catalogが自動的にテーブル間のリネージを記録する仕組み、 リネージグラフの用途（影響分析・コンプライアンス）に加え、 system テーブルや INFORMATION_SCHEMA から「誰が何をしたか」を辿る方法が問われます。
• きめ細かいアクセス制御: CURRENT_USER() やグループ判定関数を使った動的ビュー、 行フィルタと列マスクによる行レベル・列レベルの制御が出題範囲です。 「部門ごとに自部門の行だけ見せる」「特定グループ以外には列をマスクする」という形で問われます。
• 資格情報の扱い: トークンやパスワードをノートブックに直書きせずSecret Scopeに置き、 dbutils.secrets 経由で参照する。ソースコードに資格情報が書かれている選択肢が出たら、これが正解の型です。

このセクションに関する注意点が1つあります。Delta SharingとLakehouse Federationは出題範囲外です。どちらもかつてはガバナンス領域のトピックで、旧版準拠の教材では今も演習に含まれていますが、現行版では削除されました。

2ヶ月合格ロードマップ

以下は、平日1〜2時間・休日3〜4時間の学習ペースを想定した8週間のロードマップです。 Sparkやデータエンジニアリングの基礎知識がある前提で、7セクションを順番に、配点比率に応じた時間配分で進める構成にしています。

学習リソースとしては、Databricks Academy（無料のLearning Path）、 公式Practice Exam（受験登録後にWebassessorからアクセス可能）、 そしてCommunity Edition上でのハンズオン演習の3つを軸に進めてください。 座学→ハンズオン→問題演習のサイクルを各トピックで回すのが最も定着率が高い学習法です。 合格ラインが非公表である以上、「Practice Examで何%取れば安全」という基準は存在しません。 1つの数字ではなく、全セクションで安定して正答できるかどうかで判断してください。

合格者が語る出題傾向

実際に試験を受けた合格者のフィードバックから、試験の傾向を整理します。

• 「最も適切なものを選べ」系が7割以上: 明らかな間違いではなく「どれも部分的に正しいが、最適解はどれか」を問う問題が多いです。 2択まで絞れるが最後の1問で迷うパターンが頻発するため、各機能の「目的・制約・ベストプラクティス」を正確に区別する力が必要です。
• コード問題は「読める」レベルで十分: コードを一から書かせる問題はなく、 提示されたSQLやPySparkコードの出力・挙動・エラー原因を問う形式です。 ただしMERGE INTO・Auto Loader・Lakeflow Spark Declarative Pipelinesの構文は穴埋め形式で出る可能性があるため、構文の骨格は覚えておきましょう。
• Delta Lake関連は全セクションに横断: Delta Lakeはセクション2（取り込み先）・ セクション3（MERGE INTOとメダリオン設計）・セクション6（OPTIMIZE / VACUUM / タイムトラベル） すべてに関わるため、事実上最も出題頻度が高いトピックです。 OPTIMIZE・VACUUM・Z-ORDER・タイムトラベル・スキーマ進化は必ず押さえてください。
• 消去法が有効: 4択のうち1〜2個は明らかに関係ない機能（例: MLflowが正解の文脈でUnity Catalogが選択肢にある）が含まれるため、 消去法で2択に絞ってから判断するのが効率的です。

関連資格へのステップアップ

Data Engineer Associateに合格したら、次のステップとして2つの資格が有力です。

DEA → DEP のパスはデータエンジニアとしての深化、DEA → MLA のパスはMLエンジニアへのキャリア拡張を意味します。 どちらもDEAで学んだDelta Lake・Spark・Unity Catalogの知識がそのまま基盤になるため、 DEAの学習内容を忘れないうちに次の試験に進むのが効率的です。 目安として、DEA合格後2〜3ヶ月以内に次の試験を受けるペースが推奨されます。

問題で確認

よくある質問