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

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

この記事では、5つの出題ドメインの配点比率と頻出トピック、 実際の出題パターンに基づくサンプル問題、そして2ヶ月で合格するための学習ロードマップを解説します。

試験概要

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

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

5つの出題ドメインと配点比率

試験は5つのドメインから構成され、配点比率が公式に公開されています。 比率を把握することで、どのドメインに学習時間を重点配分すべきかが明確になります。

ドメイン2（ELT）とドメイン1（Lakehouse Platform）だけで全体の53%を占めます。 この2ドメインを確実に得点源にすることが合格への最短ルートです。 逆にドメイン5（Data Governance）は9%（約4問）なので、深追いより基本事項の確認に留めるのが効率的です。

ドメイン1: Databricks Lakehouse Platform（24%）

Lakehouseアーキテクチャの基礎概念と、Databricksプラットフォームの操作に関するドメインです。 「Data WarehouseとData Lakeの違い」「Lakehouseがそれらをどう統合するか」という概念問題から、 クラスタ・ノートブック・Reposの操作に関する実務問題まで幅広く出題されます。

主要トピックと出題傾向

• クラスタの種類: All-Purpose ClusterとJob Clusterの違いは鉄板の出題ポイントです。 「対話的な開発にはAll-Purpose、本番ジョブにはJob Cluster」という使い分けに加え、 Job Clusterはジョブ終了時に自動削除される点、コスト面でJob Clusterの方が安い点が問われます。
• ノートブックの機能: マジックコマンド（%sql, %python, %md）、 ウィジェット（dbutils.widgets）、%runによるノートブック間の変数共有、 ノートブックのバージョン履歴管理が出題範囲です。
• Databricks Repos: Git連携の仕組み、ブランチの切り替え、 Pull Request経由のコードレビューフロー、Reposで管理できるファイルの種類（ノートブック・Pythonファイル・設定ファイル）が問われます。
• Delta Lakeの基本: ACIDトランザクション、タイムトラベル（DESCRIBE HISTORY / RESTORE）、 スキーマ進化（mergeSchema）、OPTIMIZE / VACUUM の違いは必ず出ます。

ドメイン2: ELT with Spark SQL and Python（29%）

最大の配点比率を持つドメインで、Spark SQLとPySparkによるELT処理の実践力が問われます。 コードの読み書きが直接出題されるため、座学だけでは対応が難しく、ハンズオン経験の差がスコアに直結します。

主要トピックと出題傾向

• Spark SQLの基本構文: SELECT / JOIN / GROUP BY / HAVING / WINDOW関数（ROW_NUMBER, RANK, LAG, LEAD） を使ったデータ変換。特にCTAS（CREATE TABLE AS SELECT）でDeltaテーブルを作成するパターンが頻出です。
• MERGE INTO: 「既存レコードがあればUPDATE、なければINSERT」するUPSERT処理。 WHEN MATCHED THEN UPDATE / WHEN NOT MATCHED THEN INSERTの構文を正確に書けるかが問われます。 CDCデータの取り込みシナリオと組み合わせた問題が多いです。
• 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）が出題範囲です。
• 半構造化データ: JSONのネスト構造をSpark SQLで展開する方法（「:」記法、explode関数、 from_json、schema_of_json）が問われます。

ドメイン3: Incremental Data Processing（22%）

バッチ一括処理ではなく、新規・変更データだけを効率的に処理するインクリメンタル処理のドメインです。 Auto Loader・Structured Streaming・CDCの3トピックが中心で、 「どの場面でどの手法を使うか」の判断力が試されます。

主要トピックと出題傾向

• Auto Loader（cloudFiles）: クラウドストレージに到着する新規ファイルを自動検知して取り込む仕組み。 Directory Listing モードと File Notification モードの違い、 スキーマ推論（cloudFiles.inferColumnTypes）とスキーマ進化（cloudFiles.schemaEvolutionMode）の設定が出ます。 「COPY INTOとAuto Loaderの使い分け」は鉄板の出題テーマです。 少数ファイルならCOPY INTO、大量ファイルの継続的取り込みならAuto Loaderが正解になります。
• Structured Streaming: spark.readStream / writeStreamの基本構文、 出力モード（append / complete / update）の違い、トリガー設定（Trigger.availableNow, processingTime）、 チェックポイントの役割が問われます。「Trigger.availableNowとTrigger.onceの違い」も頻出です。
• CDC（Change Data Capture）: ソースDBからのINSERT/UPDATE/DELETEイベントを DeltaテーブルにMERGE INTOで反映するパターン。DLTのAPPLY CHANGES INTO構文も出題範囲です。

ドメイン4: Production Pipelines（16%）

開発したパイプラインを本番運用に乗せるためのドメインです。 Databricks Workflows（旧Jobs）とDelta Live Tables（DLT）が中心トピックです。

主要トピックと出題傾向

• Databricks Workflows: ジョブの作成・スケジュール設定、タスク間の依存関係（DAG構造）、 リトライポリシー、アラート通知（メール / Webhook）の設定が問われます。 マルチタスクジョブで「タスクAが成功したらタスクBを実行」のような依存定義も出ます。
• Delta Live Tables（DLT）: @dlt.table / @dlt.view デコレータの使い方、 Medallionアーキテクチャ（Bronze → Silver → Gold）との対応、 Expectationsによるデータ品質制約（@dlt.expect / @dlt.expect_or_drop / @dlt.expect_or_fail）の3段階の違いが頻出。 「不正データをドロップしたい」→ expect_or_drop、「パイプラインを止めたい」→ expect_or_fail です。
• エラーハンドリング: パイプライン失敗時のリトライ戦略、 DLTのイベントログによるエラー診断、ストリーミングジョブのチェックポイントリセット判断が出題範囲です。

ドメイン5: Data Governance（9%）

配点比率は最小ですが、Unity Catalogの基礎知識は確実に問われます。 4問程度と少ないため、深い実装知識より「何ができるか」の概念理解が重要です。

主要トピックと出題傾向

• Unity Catalogの3レベル名前空間: catalog.schema.table の階層構造、 デフォルトカタログの設定、USE CATALOG / USE SCHEMA の使い方が基本です。
• GRANT / REVOKE: テーブルやスキーマへの権限付与の構文 （GRANT SELECT ON TABLE catalog.schema.table TO group_name）が出ます。 USAGE権限がないと下位オブジェクトにアクセスできない点も頻出です。
• データリネージ: Unity Catalogが自動的にテーブル間のリネージを記録する仕組み、 リネージグラフの用途（影響分析・コンプライアンス）が問われます。
• 動的ビュー: CURRENT_USER() や IS_MEMBER() を使った行レベル・列レベルのアクセス制御が出題範囲です。

2ヶ月合格ロードマップ

以下は、平日1〜2時間・休日3〜4時間の学習ペースを想定した8週間のロードマップです。 Sparkやデータエンジニアリングの基礎知識がある前提で設計しています。

学習リソースとしては、Databricks Academy（無料のLearning Path）、 公式Practice Exam（受験登録後にWebassessorからアクセス可能）、 そしてCommunity Edition上でのハンズオン演習の3つを軸に進めてください。 座学→ハンズオン→問題演習のサイクルを各トピックで回すのが最も定着率が高い学習法です。

合格者が語る出題傾向

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

• 「最も適切なものを選べ」系が7割以上: 明らかな間違いではなく「どれも部分的に正しいが、最適解はどれか」を問う問題が多いです。 2択まで絞れるが最後の1問で迷うパターンが頻発するため、各機能の「目的・制約・ベストプラクティス」を正確に区別する力が必要です。
• コード問題は「読める」レベルで十分: コードを一から書かせる問題はなく、 提示されたSQLやPySparkコードの出力・挙動・エラー原因を問う形式です。 ただしMERGE INTO・Auto Loader・DLTの構文は穴埋め形式で出る可能性があるため、構文の骨格は覚えておきましょう。
• Delta Lake関連は全ドメインに横断: Delta Lakeはドメイン1（概念）・ドメイン2（MERGE INTO）・ドメイン3（CDC） すべてに関わるため、事実上最も出題頻度が高いトピックです。 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ヶ月以内に次の試験を受けるペースが推奨されます。

問題で確認

よくある質問