Databricks Certified Data Engineer Professional（DEP）は、Databricksの上級データエンジニアリング認定試験です。 Associate試験（DEA）が「各機能を理解しているか」を問うのに対し、DEPは「複雑な要件を満たすパイプラインを設計・実装・運用できるか」を問います。 公式の試験ガイドのサンプル問題10問は、すべて実務の状況を想定した問題です。Delta Lake・Structured Streaming・Unity Catalog・Lakeflow Jobsの深い理解に加え、 本番環境でのトラブルシュート・セキュリティ設計・CI/CDまでカバーする必要があります。
この記事では、2026年10月9日に切り替わった新しいDEPの試験仕様・9つの出題セクションの詳細・DEAとの違い・各セクションの高難易度トピック・DEA合格後の学習ロードマップ・シナリオ問題の攻略法を体系的に解説します。
DEPの試験仕様は以下の通りです（2026年10月9日からの新しい試験。公式の試験ガイドより）。DEA（45問・90分）と比較して問題数は60問に増え、制限時間も120分に拡大されており、1問あたり2分の計算です。採点されない問題が含まれることがあり、その分の時間は120分に含まれています。2026年10月8日までの旧版は、採点対象59問・10セクションでした。
| 項目 | 内容 |
|---|---|
| 問題数 | 採点対象60問（ほかに採点されない問題が含まれることがある） |
| 制限時間 | 120分（採点されない問題の分の時間を含む） |
| 合格ライン | 非公表（統計的分析で設定され、変更されうる） |
| 受験料 | $200（税別） |
| 言語 | 英語のみ（2026年10月9日からの新試験。試験ガイドより） |
| 出題形式 | 多肢選択式（Multiple choice）。公式のサンプル問題は10問とも状況の説明から始まる |
| コード | 主にPythonとSQL |
| 前提資格 | なし（DEA合格は不要だが知識は前提） |
| 推奨される経験 | 試験範囲のデータエンジニアリング業務の実務経験1年 |
| 有効期限 | 2年間（更新するには、その時点の試験に合格する） |
| 受験形式 | オンライン監督付き / テストセンター |
DEAとDEPは同じ「Data Engineer」ラインの試験ですが、求められるスキルレベルが根本的に異なります。 DEAは「各機能が何をするか知っている」レベル、DEPは「複数の機能を組み合わせて要件を満たす設計判断ができる」レベルです。
| 比較項目 | DEA（Associate） | DEP（Professional） |
|---|---|---|
| 問題数 | 45問 | 60問 |
| 制限時間 | 90分 | 120分 |
| 合格ライン | 非公表 | 非公表 |
| 受験料 | $200 | $200 |
| 受験言語 | 英語・日本語・ポルトガル語（ブラジル）・韓国語 | 英語のみ |
| 難易度 | 基礎〜中級 | 中級〜上級 |
| 試験ガイドの説明 | Databricksで基礎的なデータエンジニアリング作業を行う力 | 本番運用に耐えるデータエンジニアリングの仕組みを構築・最適化・保守する高度なスキル |
| 想定経験 | Databricks 6ヶ月以上の利用経験 | 試験範囲の業務の実務経験1年（推奨） |
| コード読解 | PySpark/SQLの基本構文を読める程度 | foreachBatch・Lakeflow Pipelines（旧Delta Live Tables）・Jobs API等の実装コードを読んで正誤を判断 |
新しいDEPは9つのセクションから出題されます。最も大きいのは「Developing Code for Data Processing using Python and SQL」の23%で、「Cost & Performance Optimization」（15%）、「Data Ingestion & Acquisition」と「Data Manipulation」（各12%）が続きます。「Data Governance」と「Data Modeling」は各5%と小さいものの、60問中3問ほどが出る計算になるため、手を抜けません。
| セクション | 配点 | 出題数（概算） |
|---|---|---|
| 1. Developing Code for Data Processing using Python and SQL | 23% | 約14問 |
| 2. Data Ingestion & Acquisition | 12% | 約7問 |
| 3. Data Manipulation | 12% | 約7問 |
| 4. Monitoring and Alerting | 10% | 約6問 |
| 5. Cost & Performance Optimization | 15% | 約9問 |
| 6. Ensuring Data Security and Compliance | 8% | 約5問 |
| 7. Data Governance | 5% | 約3問 |
| 8. Debugging and Deploying | 10% | 約6問 |
| 9. Data Modeling | 5% | 約3問 |
2026年10月8日までの旧版は10セクション（採点対象59問）で、公式ページの配点はDeveloping Code for Data Processing using Python and SQL 22%、Data Ingestion & Acquisition 7%、Data Transformation, Cleansing, and Quality 10%、Data Sharing and Federation 5%、Monitoring and Alerting 10%、Cost & Performance Optimisation 13%、Ensuring Data Security and Compliance 10%、Data Governance 7%、Debugging and Deploying 10%、Data Modelling 6%でした。新しい試験では「Data Sharing and Federation」というセクションがなくなり、「Data Ingestion & Acquisition」にOpenSharing（旧Delta Sharing）・Clean Rooms・Lakehouse Federationの項目があります。「Data Transformation, Cleansing, and Quality」は「Data Manipulation」になり、VARIANT型やai_queryなどのAI関数が明記されました。
なお、NicheeLabのDEP問題集は旧版（10セクション）の出題範囲で作成したもので、新しい試験ガイドに明記されたClean Rooms・ai_query・Metric Viewsなどを問う問題はまだありません。新しい範囲は、公式の試験ガイドとドキュメントで補ってください。
配点が最も大きく、出題項目も12個と最多のセクションです。Lakeflow PipelinesとAuto Loaderでのストリーミングパイプライン、UI・API・CLIでのLakeflow Jobs、AUTO CDC API、Structured Streamingのステートフル処理、UDF（Unity Catalogの関数を含む）、サーバーレスコンピュートの構成、テストまでが範囲です。ストリーミングテーブルとマテリアライズドビューの使い分けも問われ、公式のサンプル問題では、過去の日付に遅れて届いた更新も反映した集計が必要な場面で、マテリアライズドビューを選ばせています。
ストリーミングデータをDeltaテーブルにupsertする場合、foreachBatchでマイクロバッチごとにMERGE INTOを実行するのが標準パターンです。試験ガイドは、ウォーターマーク・出力モード・foreachBatch・チェックポイントを使ったステートフル処理と、障害後にexactly-onceで状態を復旧させることを出題項目に挙げています。バッチIDを使った重複排除、MERGEのWHEN MATCHED / WHEN NOT MATCHED条件、遅れて届くイベントで状態が増え続けないようにするウォーターマークの役割を説明できるようにしてください。
Lakeflow PipelinesのAUTO CDC API（旧APPLY CHANGES API）は、CDCフィードからSCD Type 1とType 2のテーブルを作ります。どちらにするかはstored_as_scd_typeで指定します。AUTO CDC APIはAPPLY CHANGES APIと同じ構文で、APPLY CHANGES APIも引き続き使えますが、DatabricksはAUTO CDC APIを推奨しています。MERGE文で書く場合は、WHEN MATCHED AND s.value <> t.value THEN UPDATE SET t.end_date = s.effective_date, t.is_current = falseのように既存レコードを閉じてから新しいレコードをINSERTする2段階の処理になるため、両方の書き方を読めるようにしておきましょう。
Lakeflow Jobs（旧Databricks Workflows）でのETLの作成と自動化は、UI・API・CLIのどれについても問われます。複数タスクの依存関係、失敗時のリトライ（max_retries、retry_on_timeout）、タスク間の値の受け渡し（dbutils.jobs.taskValues.set()とdbutils.jobs.taskValues.get()）に加え、新しい試験ガイドはIf/Else条件やFor Eachループといった制御フローも出題項目に挙げています。
テストでは、assertDataFrameEqual・assertSchemaEqual・DataFrame.transformとテストフレームワークを使ったユニットテストと統合テストが出題項目に入っています。サーバーレスコンピュートの環境・依存ライブラリの管理・パフォーマンスモードの選び方や、PyPI・ローカルのwheel・ソースアーカイブから入れたライブラリの依存関係の衝突やインストール失敗の切り分けも問われます。
Kafka・Kinesis・Pub/Subなどのメッセージバスやクラウドストレージから、Delta Lake・Parquet・JSON・Iceberg・CSV・バイナリのデータを取り込む方法が問われます。旧版で独立していたデータ共有とフェデレーションの項目も、このセクションに入っています。
Auto Loaderには2つのファイル検出モードがあります。Directory Listingはクラウドストレージのディレクトリを一覧して新規ファイルを検出し、File Notificationはクラウドのイベント通知でファイルの到着を受け取ります。数百万ファイルが蓄積されたディレクトリで検出が遅くなった場合は、File Notificationへの切り替えを検討します。現在のドキュメントで推奨されているのはファイルイベント（cloudFiles.useManagedFileEvents）を使う方法です。従来の方法（cloudFiles.useNotifications = true）ではAuto LoaderがAWS SQSなどの通知用のリソースを自動で作るため、そのためのクラウド側の権限が必要です。2つのモードはいつでも切り替えられ、exactly-onceの処理は保たれます。
SQL Server・MySQL・PostgreSQLなどのリレーショナルデータベースから、Lakeflow Connectで変更データ（CDC）を取り込む設定が新しく明記されました。公式のサンプル問題では、PostgreSQLの挿入・更新・削除を最小限のコードで継続的に取り込む方法として、Lakeflow Connectのマネージドコネクタを選ばせています。Lakeflow PipelinesでのCDCの取り込み先として、DeltaとIcebergの両方が挙がっています。
OpenSharing（旧Delta Sharing。D2DとDatabricks-to-Open）とClean Roomsによるプライバシーを守った共同作業、Unity Catalogの権限と接続ごとの資格情報を使ったLakehouse Federationの設定が問われます。
旧版の「Data Transformation, Cleansing, and Quality」にあたるセクションです。Spark SQLとPySparkでのウィンドウ関数・結合・集計に加え、半構造化データとAI関数が明記されました。
形の決まっていないJSONは、parse_jsonでVARIANT型の列にして、variant_getやコロン記法で値を取り出します。公式のサンプル問題でも、固定のスキーマを決めずに効率よく保存し、速く取り出す方法として出ています。また、ai_queryなどのAI関数を使い、パイプラインの中でモデルの推論を行ってデータの付加や分類をする項目もあります。
Lakeflow PipelinesのExpectations（データ品質の制約）で、不正なレコードを隔離（quarantine）するか、削除（drop）するか、処理を失敗（fail）させるかを選ぶ項目です。
システムテーブル、REST API・CLI・SDK、パイプラインのイベントログ、Lakehouse alerts、Lakeflow JobsのUIとJobs APIを使った監視が問われます。
Databricksのsystem.billing.usage・system.access.audit・system.compute.clustersやLakeflowのシステムテーブル（system.lakeflow）は、コスト分析・監査・ワークロードの監視に使います。公式のサンプル問題では、先月のDBU消費をジョブやSQLウェアハウスごとに割り当てる方法として、system.billing.usageをcomputeとpricingのシステムテーブルと結合する方法を選ばせています。
Unity Catalogの監査ログはsystem.access.auditテーブルに記録されます。アクション種別（action_name）、対象リソース（request_params）、実行ユーザー（user_identity）を組み合わせて、「誰がいつどのテーブルにアクセスしたか」をクエリで追跡できるようにしてください。新しい試験ガイドは、Databricks Lakehouse alertsで業務指標・データ品質の異常・利用量とコスト・SQLウェアハウスやクエリの状態・監査とセキュリティのイベントなどを監視する項目も挙げています。
Unity Catalogのマネージドテーブル・予測最適化（Predictive Optimization）・Liquid Clusteringが運用の手間をどう減らすかと、テーブルの使われ方に合った最適化の選び方が問われます。
公式ドキュメントは、Liquid Clusteringを「テーブルのパーティショニングとZORDERに代わる」データレイアウトの最適化と説明しています。試験ガイドにも、テーブルの大きさとクエリのパターンからLiquid Clusteringとパーティショニング・ZORDERを比べる項目と、CLUSTER BY AUTOを選ぶ項目があります。小さなMERGEで行の更新や削除が頻繁に起きるテーブルでは、削除ベクトルを有効にすると、変更のたびにファイル全体を書き直さずに済みます（公式のサンプル問題より）。
Delta TableのChange Data Feedを有効にすると、INSERT/UPDATE/DELETEの変更履歴を下流で読み取れます。table_changes() 関数またはSpark DataFrameの readStream.option("readChangeFeed", "true") で変更データを取得し、 下流のテーブルに反映するパイプライン設計が問われます。CDFのレコードには _change_type（insert / update_preimage / update_postimage / delete） と _commit_version、_commit_timestamp が付与される点を正確に覚えてください。
クエリプロファイルでデータスキップの効き具合・結合の戦略・シャッフルを確かめてボトルネックを見つける項目と、Deltaキャッシュで同じデータの繰り返しの読み込みを速くする項目があります。
最小権限のアクセス制御、ABAC、匿名化と仮名化、PIIの検出とマスキング、データの保持と削除の方針への対応が問われます。配点は8%ですが、実務で設定ミスが許されない領域です。
行フィルタはALTER TABLE ... SET ROW FILTERで関数を指定し、ユーザーの属性に基づいて行の可視性を制御します。列マスクはALTER TABLE ... ALTER COLUMN ... SET MASKで列の値をマスクします。新しい試験ガイドは、ガバナンスタグを使ったABAC（属性ベースのアクセス制御）のポリシーで、行フィルタと列マスクを大規模にまとめて適用する項目を挙げています。公式のサンプル問題では、数百のテーブルで「pii」タグの付いた列を、これから作られるテーブルも含めてまとめてマスクする方法として、テーブルごとのSET MASKやDynamic Views（current_user()やis_account_group_member()で条件を書くビュー）ではなく、ABACポリシーを選ばせています。
ハッシュ化・トークン化・抑制・一般化といった匿名化と仮名化の方法、バッチとストリーミングの両方でPIIを検出してマスクするパイプライン、GDPRの消去権（忘れられる権利）に沿ってDelta LakeとUnity Catalogの機能でデータを削除する方法が問われます。
Unity Catalogのタグとコメントでオブジェクトにメタデータを付けて探しやすくする方法と、カタログ→スキーマ→オブジェクトへの権限の継承が問われます。公式のサンプル問題では、カタログにSELECTを付与すると、あとから作られたスキーマやテーブルにも権限が引き継がれることを確かめています。
Spark UI・クラスタのログ・システムテーブル・クエリプロファイルからエラーの原因を探し、失敗したジョブをジョブの修復（repair）とパラメータの上書きで直す項目と、デプロイの項目があります。DEAにもCI/CDのセクション（10%）がありますが、DEPではエラーの調査やジョブの修復も同じセクションに入っています。
Declarative Automation Bundlesは、ジョブ・パイプライン・ノートブック・設定ファイルをdatabricks.ymlなどのYAMLで定義し、databricks bundle deployコマンドでワークスペースにデプロイする仕組みです。公式のサンプル問題では、dev・staging・prodに同じジョブとパイプラインを環境ごとの設定つきでデプロイする方法として、ターゲットごとのオーバーライドを定義してdatabricks bundle deploy -t <target>でデプロイする方法を選ばせています。
Databricks Git folders（旧Repos）を使ったGitベースのCI/CDで、ノートブックとコードをデプロイする項目です。GitHub Actions・Azure DevOps・GitLab CIなどのCI/CDツールと組み合わせた典型的な流れは「PRマージ → CIでユニットテスト実行 → Declarative Automation Bundlesでステージングにデプロイ → 統合テスト → 本番デプロイ」です。
大規模なDelta/Icebergテーブルのレイアウト設計（データの粒度に合わせたパーティショニング、アクセスパターンに合わせたクラスタリング、コンパクションによるファイルサイズの調整）と、分析用のディメンショナルモデルの設計が問われます。
スター・スキーマなどのディメンショナルモデルでは、集計の事前計算にマテリアライズドビューを、指標の定義を一か所で管理して使い回すにはUnity CatalogのMetric Viewsを使います。公式のサンプル問題では、ダッシュボードごとに「純売上」の計算がばらばらで表示も遅いという場面で、Metric Viewsで指標を一度だけ定義し、マテリアライズドビューで事前に集計する方法を選ばせています。
DEAに合格済みのエンジニアがDEPを目指す場合、3〜4ヶ月の計画的な学習を推奨します。 DEAの知識をベースにしつつ、DEP固有の深い実装知識を積み上げていくアプローチです。
DEPの公式のサンプル問題は、状況を説明したうえで「どれを選ぶべきか」を問うシナリオ形式が中心です（試験ガイドの10問中9問がこの形式です）。状況の説明から「本当に問われていること」と制約を読み取る必要があります。以下の4ステップで効率的に解答できます。
シナリオの末尾にある「Which of the following ...」「What should the engineer do ...」を最初に読みます。 何が問われているかを先に把握してからシナリオを読むと、不要な情報をスキップでき、読解時間を短縮できます。
シナリオ中の「must」「should not」「minimum cost」「without downtime」「exactly-once」のようなキーワードが正答選択の決め手になります。こうした制約を一つずつ確かめながら読み進めてください。多くの場合、正答と次点の選択肢は「この制約を満たすか否か」の一点で区別されます。
4つの選択肢のうち、通常2つは明確に不正解です（存在しないAPI、正反対の動作説明など）。 残り2つを制約条件と照合して最終判断します。DEPでは「どちらも動くが、要件を最も効率的に満たすのはどちらか」 という比較判断が多いため、コスト・パフォーマンス・運用性の3軸で評価する習慣をつけてください。
120分で60問ということは、1問2分が目安です。2分半考えても確信が持てない問題はフラグ（マーク）して次に進んでください。 全問に一通り答えたら、フラグを付けた問題に戻って見直します。 残り時間をフラグ付き問題に集中投下する戦略が、1点でも多く積み上げるうえで効果的です（合格ラインは公表されていないため、狙うべき固定のボーダーはありません）。
Data Ingestion & Acquisition
問題 1
データエンジニアが、クラウドストレージに到着するCSVファイルをAuto Loaderでリアルタイム取り込みするストリーミングパイプラインを運用している。ファイル数は1日あたり約50万件で増加傾向にあり、最近になってAuto Loaderの起動時に数分間の遅延が発生するようになった。取り込み遅延を最小化しつつ、既存のチェックポイントを維持したい。最も適切な対策はどれか。
正解: A
ファイル数が大量（50万件/日かつ増加傾向）の場合、Directory Listingモードではストレージのファイル一覧の取得に時間がかかり、起動時の遅延が発生します。File Notificationモードに切り替えると、クラウドのイベント通知でファイルの到着を受け取るため、ディレクトリ全体を一覧する必要がなくなり、遅延が解消されます。現在のドキュメントで推奨されているのはファイルイベント（cloudFiles.useManagedFileEvents）を使う方法で、従来の方法ではcloudFiles.useNotifications = trueを設定します。2つのモードはいつでも切り替えられ、exactly-onceの処理は保たれるため、既存のチェックポイントのまま続けられます。Bは要件の「リアルタイム取り込み」に反します。Cはファイル処理数を絞るだけで根本原因（ファイル検出の遅延）は解消しません。Dはチェックポイント維持の要件に違反し、全ファイル再処理は不要なコストとダウンタイムを生みます。
DEA（Associate）に合格していなくてもDEP（Professional）を受験できますか？
受験可能です。DatabricksはProfessional試験にAssociate合格を前提条件としていません。ただし、DEPはDEAの知識を前提とした上位試験であり、Delta Lake・Structured Streaming・Unity Catalogの基本概念が身についていないと問題文の意味を取るだけで時間を消費します。実質的にはDEAレベルの知識は必須と考えてください。
DEPの問題は全て長文シナリオ形式ですか？短い知識問題も出ますか？
短い知識問題が出るかどうかも含め、Databricksは問題形式ごとの割合を公表していません。公式の試験ガイドに載っているサンプル問題10問は、どれも数行の状況説明のあとに問いが続く形式で、そのうち9問は「どれを選ぶべきか」を問うものです。シナリオの中の要件と制約（コスト、レイテンシ、運用の手間など）を読み取り、選択肢をそれに照らして比べる力が合否を分けます。
DEPの学習に実際のDatabricks環境は必要ですか？Free Editionで足りますか？
公式の試験ガイドは、AI Prep Guideで作るハンズオン課題について「どれもDatabricks Free Editionで完了できる規模」としており、手を動かす練習にはFree Edition（2025年末で終了したCommunity Editionの後継）が使えます。ただしFree Editionはサーバーレスコンピュートのみで、コンピュートの構成を自分で決めることはできず、Clean Roomsにも対応していません。ジョブのタスクの同時実行は5つまで、アクティブなパイプラインは種類ごとに1つまでといった制限もあります。クラスタの構成など、Free Editionでは試せない機能まで確かめるには、所属企業のワークスペースや2週間の無料トライアルを利用してください。
出題範囲を体系的に扱う教科書があります。全 16 章、登録なしで全部読めます。
第 0 部・無料
クラウド自体がはじめての方へ
サーバー・ネットワーク・データベースの前提知識なしで読める 8 章。登録不要・無料。
無料
DEA 直前仕上げ
出題範囲の総ざらい
無料
Databricks とレイクハウスの全体像
なぜこの製品が要るのか、何がどこに属するか
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
Databricks資格一覧｜全8試験・難易度・勉強法
Databricks認定資格（全8試験）の一覧・出題範囲・合格ライン・難易度を徹底解説。2026年10月時点の公式情報に...
Databricks試験の難易度ランキング｜7資格を徹底比較
Databricks認定試験のうち7資格の難易度をランキング形式で徹底比較。合格率・学習時間・出題傾向から難易度を分析。...
Databricks資格の勉強方法｜最短合格ルートと学習時間の目安
Databricks認定資格に最短で合格するための勉強方法を完全ガイド。公式リソース・問題集・学習スケジュールを徹底解説...
Databricks Data Engineer Associate完全解説｜出題範囲・問題例・合格戦略
Databricks Certified Data Engineer Associate試験を徹底解説。2026年5月版...
Databricks ML Associate完全解説｜MLflow・AutoML対策
Databricks Certified Machine Learning Associate試験を徹底解説。4つの出題...