Databricks Certified Data Engineer Associate 教科書

模擬試験 セット3(45問・90分・合格目安70%)

模擬試験 セット3 — 全45問 残り 90:00

模擬試験 セット3(新シラバス重点編)

本試験と同じ45問・90分・4択形式です。ページを開いた時点からタイマーが動いています。すべて解答したら最下部の「採点する」を押してください(時間切れで自動採点されます)。

このセットは、2026年5月改訂の試験ガイドで新設・強化された領域(Lakeflow Connect、Lakeflow Jobs の新トリガーと制御フロー、CI/CD、Liquid Clustering、Predictive Optimization、ABAC)と新旧名称の対応を多めに含む、やや難しめの構成です。似た機能を混同させる選択肢に注意して解いてください。

最終確認:2026年8月

Databricks Intelligence Platform(問1〜3)

問1. 2026年5月改訂の試験では製品の新名称が使われるが、社内の既存教材や過去のドキュメントには旧名称が残っている。旧名称と新名称の対応として正しいものはどれか。

解説:正しい対応は「Repos → Git Folders」です。全体の対応表は、Workflows → Lakeflow Jobs、Delta Live Tables → Lakeflow Spark Declarative Pipelines、Repos → Git Folders、Databricks Asset Bundles(DABs)→ Declarative Automation Bundles です。AはWorkflowsの新名称をパイプライン製品と取り違えており、CはETLパイプライン(DLT)と取り込みコネクタ(Lakeflow Connect)の混同、Dはデプロイの仕組み(バンドル)とジョブ実行基盤の混同です。試験では旧名称のまま出題される可能性もあるため、両方向で対応を覚えてください。参照:1-2節

問2. メダリオンアーキテクチャにおけるシルバー層の役割の説明として最も適切なものはどれか。

解説:シルバー層は、ブロンズ層の生データにクレンジング・重複排除・正規化・結合などを施した「検証済みで再利用可能な」データを保持する層です。Aはブロンズ層、Bはゴールド層の説明です。Dのような「ガバナンス対象外の置き場」はメダリオンアーキテクチャのどの層にも該当せず、すべての層がUnity Catalogの管理下に置かれるべきです。参照:1-3節

問3. Databricksのサーバーレスコンピュートに関する説明として最も適切なものはどれか。

解説:サーバーレスコンピュートでは、計算資源がDatabricks側のアカウントで管理・プールされ、ユーザーはインスタンスタイプの選定やクラスタ管理から解放され、起動待ちも大幅に短縮されます。Bは「サーバーレス=無料」という誤解で、実際は使用量に応じて課金されます。Cはクラシック(顧客アカウント内)コンピュートの説明であり逆です。Dは誤りで、SQLウェアハウスだけでなくジョブ・ノートブック・パイプラインにもサーバーレスの選択肢があります。参照:1-1節

データ取り込みとロード(問4〜12)

問4. あるチームが、社外のSaaS型CRMアプリケーションのデータを毎日Delta表へ取り込みたい。APIのポーリング、認証管理、増分取得の管理といったコードを自前で書かずに済ませたい。最も適切な機能はどれか。

解説:SaaSアプリケーションやデータベースからのフルマネージドな取り込みは、Lakeflow Connectのマネージドコネクタの役割です。認証・API呼び出し・増分管理をDatabricks側が管理するため、取り込みコードを自前で書く必要がありません。AのAuto LoaderとBのCOPY INTOはクラウドオブジェクトストレージ上の「ファイル」を読む機能であり、SaaSのAPIには接続できません。CのDelta Sharingは相手側が共有を設定して初めて成立するデータ共有の仕組みで、こちらから任意のSaaSデータを取り込む機能ではありません。参照:2-6節

問5. Lakeflow Connectにおける「標準コネクタ」と「マネージドコネクタ」の違いの説明として最も適切なものはどれか。

解説:Lakeflow Connectでは、クラウドオブジェクトストレージなどからユーザー自身が構成して取り込む仕組み(Auto Loader、COPY INTOなど)が標準コネクタ、SaaSアプリケーションやデータベースを対象にDatabricksが接続・増分取得を管理するものがマネージドコネクタです。Aは対応関係が逆です。Cは誤りで、両者は対象ソースと管理レベルが異なる別の仕組みです。Dも誤りで、マネージドコネクタの取り込み先はUnity Catalog配下のテーブルです。参照:2-6節

問6. クラウドストレージのディレクトリに継続的に到着する大量のJSONファイルを、到着した分だけ増分でDelta表に取り込みたい。どのファイルを処理済みかの管理も自動化したい。最も適切な方法はどれか。

解説:継続到着するファイルの増分取り込みはAuto Loaderの中核ユースケースです。format("cloudFiles")で読み、チェックポイントに処理済みファイルの状態が記録されるため、再実行しても同じファイルが二重処理されません。Bはデータ量に比例して毎回のコストが増え続け、増分処理になっていません。Cは大量ファイルに対して非現実的です。DはAuto Loaderが自動で行うことを手作りするアンチパターンで、バグや漏れの温床になります。参照:2-2節

問7. COPY INTOとAuto Loaderの使い分けに関する説明として最も適切なものはどれか。

解説:COPY INTOは取り込み済みファイルをスキップする冪等なSQLコマンドで、ファイル数が比較的少ないバッチロードに手軽です。Auto Loaderはファイル検知がスケーラブルで、数百万ファイル規模や継続到着への増分取り込みに適します。Aは逆で、COPY INTOは再実行しても既取り込み分をスキップします。Bは逆で、大規模になるほどAuto Loaderが有利です。DはCOPY INTOがバッチのSQLコマンドである点と矛盾します。参照:2-3節

問8. 外部ベンダーから一度だけ受領したCSVファイル群がUnity CatalogのVolumeに置かれている。スキーマ推論込みで、これらから新しいDelta表を最短の手順で作りたい。最も適切な方法はどれか。

解説:1回限りのロードでは、read_files(またはCSVリーダー)で読み取った結果をそのままCTASでDelta表化するのが最短です。スキーマは読み取り時に推論されます。Aは手作業が多く推論の利点を捨てています。Cの常駐ストリームは「一度だけ」の要件に対して過剰で、コストも無駄です。DはDeltaのトランザクションや最適化の恩恵を受けられず、以降の利用に不利です。参照:2-1節

問9. 業務システムのリレーショナルデータベースのテーブルを、挿入・更新・削除の変更分を継続的にDelta表へ反映する形で取り込みたい。Lakeflow Connectのマネージドコネクタに関する説明として最も適切なものはどれか。

解説:データベース向けのマネージドコネクタは、ソース側の変更ログを利用したCDCベースの増分取り込みを構成でき、挿入・更新・削除をターゲットへ反映します。Aのフルダンプ限定は誤りで、CDCによる増分反映が主眼です。Bの「削除は不可」も誤りです。Cは誤りで、「マネージド」の名の通り接続・取得・反映のパイプライン自体をDatabricksが管理し、ユーザーがJDBCコードを書く必要はありません。参照:2-6節

問10. Auto LoaderでJSONファイルを取り込んでいるが、ソース側の仕様変更で想定外の新フィールドや型が一致しない値が混ざる可能性がある。データを失わずに取り込みを継続する仕組みとして最も適切なものはどれか。

解説:Auto Loaderはスキーマ推論・進化に対応しており、現在のスキーマに合致しなかった値を_rescued_data列に退避してデータ損失なく取り込めます。新しい列が検出された場合はスキーマを進化させて処理を継続できます。Bはデータを黙って失うため後から原因調査ができません。Cは運用が回らず、Dは型情報を全て捨てており分析利用が困難になります。参照:2-4節

問11. 毎日受領する顧客マスタの差分ファイルをDelta表に反映したい。既存の顧客IDの行は最新情報で更新し、新規の顧客IDの行は挿入したい。最も適切なSQLはどれか。

解説:「既存キーは更新、新規キーは挿入」というアップサート要件はMERGE INTOの典型ユースケースです。Aは差分ファイルにない既存顧客の行が消えてしまいます。Bは同一顧客IDの行が重複していきます。Dは全量の受領が前提になるうえ、毎回の全削除・全挿入は非効率で、差分反映という要件にも合いません。参照:2-5節

問12. SQLだけを使って、クラウドストレージに継続的に到着するファイルを増分で取り込むテーブルをDatabricks SQL上に定義したい。最も適切な構文はどれか。

解説:ストリーミングテーブル(CREATE STREAMING TABLE)は、SQLだけでファイルの増分取り込みを定義できる仕組みで、STREAM read_files(...)により到着分のみが処理されます。Aのビューは実体を持たず、参照のたびに全ファイルを読み直します。Cのマテリアライズドビューは変換・集計結果を最新に保つ用途であり、追記ソースの増分「取り込み」にはストリーミングテーブルが適します。Dはファイルをその場で参照する定義であり、Delta表への増分ロードにはなりません。参照:2-3節

データ変換とモデリング(問13〜22)

問13. Lakeflow Spark Declarative Pipelines(旧称 Delta Live Tables)における、ストリーミングテーブルとマテリアライズドビューの使い分けとして最も適切なものはどれか。

解説:ストリーミングテーブルは各入力行を一度だけ処理する増分処理向けで、取り込みや追記ソースの変換に適します。マテリアライズドビューは定義クエリの結果を最新に保つオブジェクトで、集計・結合など「結果全体の正しさ」が求められる変換に適します(更新は可能な範囲で増分化されます)。AとBは役割が逆または限定しすぎです。Dは誤りで、更新セマンティクスが異なります。なお、この製品は旧名称の「Delta Live Tables(DLT)」で出題される可能性があります。参照:3-1節

問14. パイプラインで、主キー列がNULLの行は品質基準違反としてターゲットに入れず、違反件数はメトリクスとして記録したい。期待(expectation)の指定として最も適切なものはどれか。

解説:ON VIOLATION DROP ROWは違反行をターゲットから除外しつつ、違反件数をパイプラインの品質メトリクスとして記録します。BのFAIL UPDATEは違反発生時に更新自体を失敗させるため「入れずに処理は続ける」という要件に合いません。CのON VIOLATION句なしは警告として記録するだけで、違反行もターゲットに入ってしまいます。DのWHERE句は行を除外できますが品質メトリクスとして記録されず、データ品質の可視化という期待の利点を失います。参照:3-3節

問15. CDCフィードを入力として、顧客住所の変更履歴をすべて保持する形(各行に有効期間を持つ履歴表)でターゲット表を維持したい。Lakeflow Spark Declarative Pipelinesでの実現方法として最も適切なものはどれか。

解説:変更履歴を有効期間付きで保持するのはSCD Type 2であり、AUTO CDC(旧名称 APPLY CHANGES INTO。旧名称で出題される可能性があります)でSTORED AS SCD TYPE 2を指定すれば、順序制御・履歴行の開始/終了管理を宣言的に任せられます。CのSCD TYPE 1は最新値で上書きするため履歴が残りません。Aは実装可能ですが、順序の乱れや遅延到着の処理を自前で作り込むことになり最適ではありません。Bは生イベントの山ができるだけで「現在有効な行」も「有効期間」も直接得られません。参照:3-4節

問16. イベント表に、同一イベントIDの行が複数回の取り込みにより重複して存在する。各イベントIDについてタイムスタンプが最新の1行だけを残した結果を得るSQLとして最も適切なものはどれか。

解説:「キーごとに最新の1行」はウィンドウ関数ROW_NUMBERの典型パターンです。PARTITION BY event_id ORDER BY ts DESCで各IDの行に順位を付け、1位のみを残します。AのDISTINCTは全列が完全一致する行しか除去できず、タイムスタンプ等が異なる重複には無力です。Cは集約関数なしに非グループ化列をSELECTしておりエラーになります。Dは表全体で1行しか返しません。参照:3-2節

問17. 文字列型の列payloadにJSON文書が格納されており、その中の配列フィールドitemsの各要素を1行ずつに展開して分析したい。最も適切な処理の組み合わせはどれか。

解説:正しい順序は「from_jsonで文字列→構造体に変換し、その中の配列にexplodeを適用」です。Bは順序が逆で、文字列のままではexplodeできません(explodeの入力は配列またはマップ)。Aの正規表現によるJSON解析は入れ子や順序の揺れに脆弱でアンチパターンです。DのようなSTRINGからARRAYへの直接CASTはできません。参照:3-2節

問18. 上流ソースに新しい列が追加された。既存のDelta表への日次書き込みを、既存データを壊さずに新列も取り込みながら継続したい。最も適切な対応はどれか。

解説:Deltaはデフォルトでスキーマを強制し、スキーマの異なる書き込みを拒否します。新列を取り込むには、mergeSchemaオプションなどでスキーマ進化を明示的に有効化し、既存データを保ったままテーブルスキーマに列を追加させます。Bはスキーマ「強制」と「進化」の混同で、自動追加はされません。Cは履歴・権限・下流参照をすべて壊します。Dはモデルを不必要に複雑化させます。参照:3-5節

問19. 誤ったUPDATE文を本番のDelta表に実行してしまい、多数の行が不正な値になった。実行前の状態に戻す方法として最も適切なものはどれか。

解説:Deltaはトランザクションログにより過去バージョンを保持しており、DESCRIBE HISTORYで操作履歴とバージョン番号を確認し、RESTORE TABLEで指定バージョンへ巻き戻せます(タイムトラベル)。Aは逆効果で、VACUUMは保持期間を過ぎた旧バージョンのファイルを物理削除するコマンドであり、実行すると巻き戻し先を失う可能性があります。Bのファイル再編成は値を戻しません。Cは誤りで、手動バックアップがなくてもログから復元できます。参照:3-5節

問20. 複雑なJOINと絞り込みのロジックを複数の利用者・複数のセッションから再利用したい。データの実体は持たせず、参照のたびに元表の最新データを反映させたい。最も適切なオブジェクトはどれか。

解説:永続ビューはクエリ定義だけをカタログに保存し、参照のたびに元表の最新データに対して評価されます。複数の利用者・セッションから名前で再利用でき、要件に合致します。Aの一時ビューは作成したセッション内でしか見えません。CのCTASは作成時点のスナップショットの実体を持ち、元表の更新を反映しません。Dのグローバル一時ビューもクラスタ(コンピュート)の生存期間に縛られ、恒久的な共有には使えません。参照:3-6節

問21. 「税抜価格と税率から税込価格を計算する」ロジックを、SQLの複数のクエリから同じ名前で呼び出せる形で共有したい。ガバナンス(権限管理)の対象にもしたい。最も適切な方法はどれか。

解説:CREATE FUNCTIONで定義するSQL UDFはUnity Catalog配下のオブジェクトとして登録され、名前での再利用と権限管理(EXECUTEの付与)が可能です。Aは誤りで、単純な計算ロジックはSQL UDFで十分であり、SQL UDFはPython UDFよりオプティマイザとの親和性も高い選択です。Bは変更時に全クエリの修正が必要になり保守性が最悪です。Dは全テーブルのスキーマ変更と再計算を伴い、税率変更のたびに破綻します。参照:3-6節

問22. Lakeflow Spark Declarative Pipelinesの実行モードに関する説明として最も適切なものはどれか。

解説:トリガーモードは起動のたびに「その時点で処理可能なデータ」を処理して停止するためコスト効率が良く、連続モードは常時稼働と引き換えに低レイテンシを実現します。Bは逆で、常時稼働する連続モードのほうがコンピュートコストは高くなりがちです。Cは誤りで、トリガーモードでもストリーミングテーブルはチェックポイントに基づき増分処理されます。Dも誤りで、モードは設定で変更できます。参照:3-1節

Lakeflow Jobs(問23〜29)

問23. 取引先からのデータファイルが不定期にUnity CatalogのVolumeへ置かれる。ファイルが到着したときだけ処理ジョブを実行し、cronスケジュールによる空振り実行と検知遅延を避けたい。最も適切なものはどれか。

解説:2026年5月改訂で重要度が上がった論点です。Lakeflow Jobsのトリガーにはscheduled/file arrival/table updateがあり、「ファイルが置かれたら実行」はfile arrivalトリガーの役割そのものです。監視対象にはUC Volumeや外部ロケーションのパスを指定します。Aは空振り起動のコストと最大5分の遅延が残ります。Cは常時稼働コストがかかり過剰です。Dのtable updateトリガーの監視対象は「テーブル」であり、ファイルパスは指定できません。参照:4-2節

問24. 上流チームが管理するUnity Catalog上のDelta表が更新されたら、それを入力とする自チームの集計ジョブを自動実行したい。上流チームのジョブ定義には変更を加えられない。最も適切なものはどれか。

解説:table updateトリガーは、指定したUnity Catalog上のテーブルが更新されたことを契機にジョブを起動します。上流のジョブ定義に手を入れずに「テーブルの更新」だけを契機にでき、要件に合致します。Aは前提(上流に変更を加えられない)に反します。Bのfile arrivalトリガーの監視対象はストレージのパスであり、テーブル名は指定できません(問23と対で覚えてください)。Cは高頻度の空振り起動が発生し非効率です。参照:4-2節

問25. 日次ジョブで、前段タスクが算出した「当日データ件数」が閾値を超えた場合のみ本処理タスクを実行し、超えない場合は担当者への通知タスクへ分岐させたい。Lakeflow Jobsでの実現方法として最も適切なものはどれか。

解説:If/else conditionタスクはジョブ内の制御フロー機能で、タスク値やジョブパラメータを条件式で評価し、true/falseそれぞれの経路に後続タスクを分岐させられます。前段タスクからはtask valueで値を引き渡すのが定石です。BのFor eachは同一処理の反復用で条件分岐の機能ではありません。Cは無駄な実行が発生し、実行履歴も分かりにくくなります。Dは誤りで、ノートブック内のif文でも書けはしますが、タスク単位の分岐・可視化・再実行制御ができるIf/elseタスクが用意されています。参照:4-3節

問26. 同一のノートブック処理を、10か国分の国コードをそれぞれパラメータとして与えて繰り返し実行したい。同時に実行する数(並列度)も制御したい。Lakeflow Jobsでの実現方法として最も適切なものはどれか。

解説:For eachタスクは、リストなどの入力値ごとに内側のタスクをパラメータ付きで反復実行する制御フロー機能で、同時実行数(concurrency)の設定により並列度も制御できます。国が増えてもリストに追加するだけで済みます。AとDは定義の重複が増え、11か国目の追加やロジック変更のたびに全コピーの修正が必要になります。BのIf/elseは条件分岐であり反復の機能ではありません(問25と対で覚えてください)。参照:4-3節

問27. 20個のタスクを持つジョブが、途中の1タスクの失敗により停止した。成功済みタスクを再実行することなく、失敗した箇所から効率よく復旧する方法として最も適切なものはどれか。

解説:repair run(修復実行)は、失敗したラン自体に対して失敗・スキップされたタスク(とその下流)だけを再実行する機能で、成功済みタスクの結果を活かして同一ランとして完了させられます。AとCは成功済みタスクの分まで再計算コストがかかります。Dは処理としては流せても、実行履歴が失敗のまま残り、下流タスクの依存関係も解決されないため運用上不適切です。参照:4-1節

問28. 本番の定期バッチジョブ(旧称 Workflows、現 Lakeflow Jobs)の実行に使うコンピュートに関する説明として最も適切なものはどれか。

解説:ジョブ専用クラスタ(job cluster)は実行のたびに起動・終了するため待機コストがなく、単価もall-purposeクラスタより低く設定されており、定期バッチの標準的な選択です。サーバーレスのジョブコンピュートを使えばクラスタ管理自体も不要になります。Aは待機時間分の課金が発生し高コストです。Bは誤りで、ジョブはサーバーレスでも実行できます。Cは逆で、対話的開発に向くのはall-purposeクラスタです。なお「Workflows」という旧名称で出題される可能性があります。参照:4-1節

問29. 深夜に実行されるバッチジョブについて、失敗に翌朝まで気づかない事態を防ぎ、かつネットワークの瞬断のような一時的なエラーでは人手をかけずに自動復旧させたい。設定の組み合わせとして最も適切なものはどれか。

解説:一時的な障害には上限付きのタスクリトライで自動復旧し、リトライしても失敗した場合は失敗時通知で即座に検知する、という組み合わせが定石です。Bは検知が翌朝まで遅れる属人的な運用です。Cの無制限リトライは、コードのバグのような恒久的な失敗でリソースを浪費し続けます。Dの「通知が来ない=失敗」という判断は、通知システム自体の障害と区別できず信頼性がありません。参照:4-4節

CI/CD(問30〜33)

問30. 複数人のチームでノートブック開発のバージョン管理を行いたい。Databricksワークスペース内でリモートGitリポジトリをクローンし、ブランチの切替・コミット・プッシュなどのGit操作を行える機能はどれか。

解説:Git Foldersは、ワークスペース内にリモートGitリポジトリをクローンし、ブランチ操作・コミット・プッシュ・プルをUIから行える機能です。旧名称の「Repos」で出題される可能性があるため対応を覚えてください。AのDeclarative Automation Bundlesはリソース定義をYAMLで宣言してデプロイする仕組みで、Git操作の機能ではありません(開発中の版管理はGit Folders、環境への配備はバンドル、と役割が異なります)。BのUnity Catalogはデータガバナンス、DのLakeflow Connectはデータ取り込みの機能です。参照:5-1節

問31. Declarative Automation Bundles(旧称 Databricks Asset Bundles、DABs)の説明として最も適切なものはどれか。

解説:バンドルは、プロジェクトのルートに置くdatabricks.ymlにリソース(ジョブ、パイプライン等)とtargets(dev/test/prodなどの環境)を宣言し、CLIで検証・配備・実行するInfrastructure-as-Code的な仕組みです。コードと設定を一体でソース管理でき、CI/CDの中核になります。旧名称の「Databricks Asset Bundles(DABs)」で出題される可能性があります。AのエクスポートやCのオートスケーリングは無関係で、DはDelta Sharingの説明です。参照:5-2節

問32. 同じバンドルをdevとprodに配備する際、ターゲットごとに使用するカタログ名やコンピュートの設定を切り替えたい。最も適切な方法はどれか。

解説:バンドルのvariablesは環境差分を吸収するための仕組みで、リソース定義側は変数を参照し、targetsセクションでターゲットごとに値を上書きします。定義は1つのまま複数環境に配備できます。Bは複製間の乖離(ドリフト)が必ず発生します。Cは配備後の手動変更で、次回のdeployで上書きされるうえIaCの利点を失います。Dはコード変更なしに環境を切り替えるというCI/CDの原則に反します。参照:5-2節

問33. Lakeflow JobsとパイプラインのCI/CDフローの設計として最も適切なものはどれか。

解説:「開発はGit Foldersのブランチ+プルリクエスト、検証とデプロイはCIからバンドルのCLIで自動実行」が標準的なCI/CDフローです。人手のGUI操作を挟まないことで再現性と監査性が確保されます。Aは個人の作業中ブランチが本番を直接動かす構成で、レビュー前の変更が本番に影響します。Bは手作業のため再現性がなく設定ミスの温床です。Dは誤りで、validateは検証のみを行い、配備にはdeployの実行が必要です。参照:5-3節

トラブルシューティング・監視・最適化(問34〜38)

問34. 高カーディナリティの列(顧客IDなど)での絞り込みが多い大規模Delta表のデータレイアウトを最適化したい。将来、クエリパターンが変わる可能性もある。最も適切なものはどれか。

解説:Liquid Clusteringは、Hiveスタイルのパーティション分割やZORDERに代わる現行推奨のレイアウト最適化です。高カーディナリティ列もキーにでき、キーの変更にテーブル全体の書き直しが不要で、CLUSTER BY AUTOなら利用パターンに応じた自動選定も可能です。Aは高カーディナリティ列でのパーティション分割になり、極端に多いパーティションと小ファイルを生む典型的なアンチパターンです。Cは誤りで、両者は排他であり併用しません。Dは自作不要で、コストも過大です。参照:6-3節

問35. 数百のUnity CatalogマネージドテーブルへのOPTIMIZEやVACUUMの実行スケジュールを個別に管理する負担が大きい。運用負荷を最小化する方法として最も適切なものはどれか。

解説:Predictive Optimizationは、Unity Catalogのマネージドテーブルを対象に、テーブルの利用パターンに基づいてOPTIMIZEやVACUUMなどのメンテナンスを自動的に実行する機能です。個別のメンテナンスジョブのスケジュール管理が不要になります(対象がUCマネージドテーブルである点も覚えてください)。Aはほとんど更新のない表にも無駄なコストをかけます。BとCは誤りで、旧バージョンのファイル削除(VACUUM)や小ファイルの集約(OPTIMIZE)というメンテナンス自体は必要であり、「不要」なのは手動管理のほうです。参照:6-3節

問36. Lakeflow Jobsの本番ジョブが今朝の実行で失敗した。原因調査の最初の一歩として最も適切なものはどれか。

解説:トラブルシューティングの起点は失敗したランの詳細です。実行履歴から該当ランを開けば、どのタスクがどのエラーで失敗したかを特定でき、必要に応じてSpark UIやログへ掘り下げられます。原因特定後はrepair runで失敗タスクのみ再実行できます。Bは原因不明のままリソースを増やす対症療法で、コードのバグや権限エラーには無力です。Cは実行履歴という調査材料を失います。DのVACUUMは失敗調査と無関係で、むしろタイムトラベルの復元先を減らすリスクがあります。参照:6-1節

問37. ストリーミングで細かい追記が続くDelta表(外部テーブルのためPredictive Optimizationの対象外)の読み取りが徐々に遅くなった。調査の結果、原因は大量の小さなデータファイルだと分かった。最も適切な対処はどれか。

解説:小ファイル問題への対処はOPTIMIZEによるコンパクションです。多数の小ファイルを読み取り効率の良い大きなファイルへ集約し、スキャン時のオーバーヘッドを減らします。AのVACUUMは「現在のバージョンから参照されなくなった」古いファイルを削除するコマンドであり、現役の小ファイルはそもそも削除対象になりません(OPTIMIZEとVACUUMの役割の混同は定番のひっかけです)。BはDeltaのトランザクションや統計の利点を失い本末転倒です。Dはデータ自体を過去に巻き戻してしまいます。参照:6-2節

問38. 複数のワークスペースにまたがるジョブの実行履歴の傾向(失敗率、実行時間)と、コンピュートの利用量・コストをSQLで横断的に分析したい。最も適切なデータソースはどれか。

解説:システムテーブルは、アカウント内の運用データ(ジョブ実行履歴のsystem.lakeflow配下、利用量・課金のsystem.billing.usageなど)をUnity Catalog経由でSQL照会できる仕組みで、複数ワークスペースを横断した分析に適します。Aのprint出力は構造化されておらず横断集計に耐えません。Cの手動ダウンロードとDの目視巡回は、規模に対してスケールせず継続的な監視になりません。参照:6-4節

ガバナンスとセキュリティ(問39〜45)

問39. 数百のテーブルに散在する個人情報列へのマスキングを、テーブルごとの個別設定ではなく、全社共通のポリシーとして一元的に適用したい。最も適切なUnity Catalogの機能はどれか。

解説:ABAC(属性ベースアクセス制御)は、2026年5月改訂で追加された重要トピックです。ガバナンス付きタグを列やテーブルに付与し、「このタグが付いた列はマスクする」というポリシーを上位スコープで定義することで、行フィルタ・カラムマスクを多数のテーブルへ一元適用できます。AとBはテーブル数に比例して設定と保守の負担が増え、漏れが生じやすい個別管理です。Dはデータの利用価値そのものを失わせ、マスキングという要件に合いません。参照:7-3節

問40. 地域列の値に基づく行レベルのアクセス制御を、カタログ内の対象テーブル群に適用したい。今後新しく作成されるテーブルにも、個別の設定作業なしで同じ制御が効くようにしたい。最も適切なものはどれか。

解説:ABACポリシーは上位スコープ(カタログやスキーマ)で定義でき、条件となるガバナンス付きタグが付いたオブジェクトに自動的に適用されます。タグ付けの運用さえ守られれば、新規テーブルにも個別作業なしで制御が及ぶ点が、テーブル単位の手動設定に対する本質的な利点です。Bは新規テーブルへの適用漏れという、まさに避けたいリスクが残ります。Cはガバナンスをデータ基盤の外に出してしまい、経路によって制御が効かなくなります。Dはテーブル数の爆発と結合の複雑化を招きます。参照:7-3節

問41. アナリストのグループに catalog1.schema1.table1 への読み取りだけを許可したい。Unity Catalogで必要となる最小権限の組み合わせとして最も適切なものはどれか。

解説:Unity Catalogでテーブルにアクセスするには、テーブル自体のSELECTに加えて、その経路にあたるカタログのUSE CATALOGとスキーマのUSE SCHEMAが必要です(3層の名前空間を「通過」する権限)。AはSELECT単独では経路の権限が足りずアクセスできません。BのALL PRIVILEGESは書き込みや作成まで許してしまい最小権限に反します。Cの管理者ロールは論外の過剰権限です。参照:7-1節

問42. 本番のLakeflow Jobsが特定の社員の個人ユーザーとして実行されており、その社員の異動・退職でジョブが失敗するリスクが指摘された。最も適切な対策はどれか。

解説:本番の自動処理は、特定個人に紐づかないサービスプリンシパルをrun as(実行ユーザー)に設定するのが原則です。人の異動・退職の影響を受けず、付与権限もジョブに必要な範囲へ最小化できます。Aは問題の先送りにすぎません。Cは全ジョブが過剰権限で動くことになり、1つのジョブの不具合や侵害が全データに及びます。Dのような権限チェックの無効化という仕組みはなく、あったとしてもガバナンスの放棄です。参照:7-2節

問43. ゴールド層のある表の値に異常が見つかった。この表が上流のどの表からどう作られたかを遡って特定し、逆にこの表を参照している下流への影響範囲も調べたい。最も適切な方法はどれか。

解説:Unity Catalogのリネージは、UC経由で実行されたワークロードからテーブル間・カラム間の依存関係を自動収集しており、上流への遡りと下流への影響分析の両方に使えます。Bは動的にテーブル名を組み立てるコードを追えず、網羅性も保証されません。Cは誤りで、リネージ収集は自動です(手動登録は不要)。DのDESCRIBE DETAILが返すのはファイル数や場所といった物理メタデータで、依存関係の情報は含まれません。参照:7-4節

問44. 顧客テーブル(Unity Catalog管理)の電話番号列を、個人情報管理グループ pii_admins のメンバーにはそのまま、それ以外の利用者には伏字で表示したい。このテーブルは多数のダッシュボードやノートブックから直接参照されている。最も適切な方法はどれか。

解説:カラムマスクは、グループ判定で値をそのまま返すか伏字を返すかを分岐する SQL UDF を SET MASK でテーブル本体の列に適用します。テーブルを直接参照するすべての経路で一貫して効くため、参照元の変更が不要です。Aはコピーの拡散と鮮度・同期の問題を生みます。Bは全参照元の書き換えが必要で、切り替え漏れがそのまま漏えいリスクになります。Cは誤りで、Unity Catalog の GRANT はテーブル単位であり列単位の SELECT 制御はできません(列単位の制御にはカラムマスクや列を絞ったビューを使います)。参照:7-3節

問45. 外部テーブルとして運用してきたDelta表を、Predictive Optimizationなどマネージドテーブル向けの機能を活用するためにマネージドテーブルへ移行したい。テーブル名・付与済みの権限・テーブル履歴を維持したまま移行する方法として最も適切なものはどれか。

解説:ALTER TABLE ... SET MANAGEDは、Unity Catalogの外部テーブルをマネージドテーブルへ変換するコマンドです。テーブル名・付与済みの権限・テーブル履歴(タイムトラベル)・ビューなどの参照を保持したまま変換でき、変換後は一定期間内であればALTER TABLE ... UNSET MANAGEDで外部テーブルに戻すこともできます。AのDEEP CLONEは独立した別テーブルを作る操作で、権限は引き継がれず履歴も複製先では新規に始まるため要件を満たしません。CのDROPして作り直す方法は、権限と履歴が失われます。Dは誤りで、変換手段は提供されています。参照:7-1節