Databricks Certified Data Engineer Associate 教科書

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

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

模擬試験 セット1

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

最終確認:2026年8月

Databricks Intelligence Platform(問1〜3)

問1. ある小売企業では、BI用のデータウェアハウスと機械学習用のデータレイクを別システムで運用しており、同じデータの二重管理と鮮度のずれに悩んでいる。データエンジニアが経営層に「レイクハウスアーキテクチャ」を提案する際の説明として最も適切なものはどれか。

解説:レイクハウスは「データレイクの柔軟性・低コスト」と「データウェアハウスの信頼性・管理機能」を1つの基盤に統合するアーキテクチャで、Delta LakeによるACIDトランザクションとUnity Catalogによるガバナンスがその中核です。Aは従来の二重管理そのものでレイクハウスの否定です。Cはデータレイクの利点(多様なデータ形式)を捨てており、Dはレイクハウスが構造化・非構造化の両方を単一基盤で扱える点と矛盾します。参照:1-1節

問2. あるECサイトの運用担当者が、誤ったWHERE句のUPDATE文でDeltaテーブルの大量の行を書き換えてしまった。実行前の状態を確認し、テーブルを元に戻したい。対応として最も適切なものはどれか。

解説:Delta Lakeはすべての変更をトランザクションログにバージョンとして記録するため、タイムトラベルで過去の状態をクエリでき、RESTOREでテーブルを過去バージョンへ巻き戻せます。Aは誤りで、Deltaならログが保持されている限り復元可能です。Bは逆で、VACUUMは古いファイルを物理削除するためむしろタイムトラベル可能な範囲を狭めます。Cのログの手動編集はテーブル破損を招く危険な操作で、サポートされる手順ではありません。参照:1-2節

問3. あるメーカーの分析チームでは、アナリスト数名が日中に不定期でSQLのアドホッククエリやBIダッシュボードの参照を行う。管理負荷を抑えつつ、使っていない時間のコストも最小化したい。コンピュートの選択として最も適切なものはどれか。

解説:SQL中心のBI・アドホック分析にはSQLウェアハウスが適しており、特にサーバーレスは起動が速く、アイドル時に自動停止するため不定期利用のコスト効率と管理負荷の両面で優れます。Bは使っていない時間も課金され続けます。CのJobコンピュートは自動化ジョブ向けであり、対話的なSQL分析の用途に合いません。Dはガバナンスもスケーラビリティも失われます。参照:1-3節

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

問4. ある物流企業では、取引先からクラウドストレージの特定フォルダに毎日CSVファイルが数件届く。SQLベースの日次バッチでDeltaテーブルへ増分ロードしたいが、ジョブを再実行してもロード済みファイルが二重に取り込まれないようにしたい。方法として最も適切なものはどれか。

解説:COPY INTOはロード済みファイルを内部で追跡し、既に取り込んだファイルを自動でスキップする冪等なSQLコマンドで、「少数のファイルが定期的に届くSQLバッチの増分ロード」の典型解です。AとDは全件再ロードで増分の要件に反し、データ量の増加とともにコストが膨らみます。Bは手動管理でありミスの温床になるうえ自動化できません。参照:2-2節

問5. あるモバイルアプリ企業がAuto Loaderでイベント JSONを継続的に取り込んでいる。アプリの更新に伴いイベントに新しいフィールドが追加されることがあり、その際もパイプラインを止めずにデータを失わず取り込みたい。設計として最も適切なものはどれか。

解説:Auto Loaderはスキーマ推論とスキーマ進化をサポートし、addNewColumnsモードでは新しい列を検出するとスキーマを更新して取り込みを継続できます(検出時に一度ストリームが停止するため、ジョブの自動再起動と組み合わせます)。さらに_rescued_data列により、スキーマに合わないデータも失わず保全できます。Aはデータ欠損を生み、Bは運用コストが非現実的です。Dは下流での型付け・検証をすべて先送りするだけで、スキーマ進化への対処になっていません。参照:2-3節

問6. ある広告配信企業では、クラウドストレージに1時間あたり数十万個の小さなログファイルが到着する。Auto Loaderで取り込んでいるが、新着ファイルの検出に時間がかかり、リスト操作のコストも増大している。改善策として最も適切なものはどれか。

解説:Auto Loaderの検出モードのうち、既定のディレクトリリスティングはフォルダを繰り返しリストするため、ファイル数が極端に多いと遅延とAPIコストが増えます。ファイル通知モードはストレージのイベント通知サービスで新着を検出するため、大量ファイルの継続到着に対しスケーラブルです。Aはリスト回数が増えてコストがさらに悪化します。Cも同様にスキャンコストの問題を解決しません。Dはビジネス要件側を止める本末転倒な対応です。参照:2-3節

問7. ある人材サービス企業が、利用中のSaaS型CRMの顧客データをDatabricksに日次で取り込みたい。開発チームは小規模で、APIのページネーションや増分抽出のコードを自前で保守したくない。アプローチとして最も適切なものはどれか。

解説:Lakeflow ConnectはSalesforceのようなSaaSアプリケーションやデータベース向けのマネージドコネクタを提供し、認証・増分取り込み・スケジュールを設定ベースで構成できるため、コード保守を最小化したい要件に合致します。Aは保守負荷が高く車輪の再発明です。Bは手作業で自動化・信頼性の要件を満たしません。CはSaaSの内部DBへの直接接続であり、通常は提供されず、提供されてもベンダーのサポート外の危険な構成です。参照:2-4節

問8. ある製造企業の基幹システムはオンプレミスのPostgreSQLで稼働している。夜間バッチでいくつかのテーブルをDatabricksに読み込み、Deltaテーブルとして保存したい。Spark標準の仕組みで実現する方法として最も適切なものはどれか。

解説:リレーショナルデータベースからの読み取りには、SparkのJDBCデータソース(spark.read.format("jdbc"))で接続URL・テーブル・認証情報を指定するのが標準的な方法です。読み取ったDataFrameはそのままDeltaに書き込めます。BのDBデータファイルはPostgreSQL固有の内部形式でありSparkでは解釈できません。CとDは自動化・信頼性・現実性のいずれの観点でも成立しません。参照:2-5節

問9. あるエネルギー企業が、外部プロバイダの気象情報REST APIから1時間ごとにデータを取得し、Deltaテーブルに蓄積したい。APIはJSONを返し、専用コネクタは提供されていない。実装として最も適切なものはどれか。

解説:専用コネクタのないREST APIからの取り込みは、PythonのHTTPクライアントでレスポンスを取得し、JSONをDataFrame化してDeltaへ書き込むカスタム実装が標準的なパターンで、Lakeflow Jobsのスケジュールで定期実行できます。Aは誤りで、外部APIの呼び出しは通常のPythonコードで可能です。BのDeltaリーダーはストレージ上のDeltaテーブル用であり、APIエンドポイントは読めません。Cは自動化の要件を満たしません。参照:2-5節

問10. あるゲーム会社では、クラウドストレージにプレイログのファイルが毎分継続的に到着し、累計ファイル数は数百万に達している。ニアリアルタイムで増分を取り込み続けたい。取り込み方式の選択として最も適切なものはどれか。

解説:方式の使い分けの典型論点です。累計ファイル数が数百万規模で継続到着する場合はAuto Loaderが適します。チェックポイントによる状態管理とファイル通知モードにより、ファイル数が増えても検出コストが破綻しません。AのCOPY INTOは数千ファイル規模の定期バッチには便利ですが、超大量ファイルの高頻度実行ではリストのオーバーヘッドが問題になります。Cは全件再作成で増分・鮮度の要件に反します。DのJDBCはデータベース接続用であり、ストレージのファイル検出には使いません。参照:2-6節

問11. ある保険会社が、過去システムから出力された約200個のParquetファイルを新しいDeltaテーブルへ一度だけ移行したい。担当者はSQLに慣れており、ストリーミングの常時稼働は不要である。方法として最も適切なものはどれか。

解説:「少数ファイル・1回限り(または低頻度)・SQL中心」という条件はCOPY INTOやCTASが適する典型です。冪等性があるため追加ファイルが後から届いても再実行できます。Aのストリーミング常時稼働は要件に対して過剰でコストの無駄です。Bは一括移行のためだけにメッセージ基盤を新設する過剰設計です。Dは件数的に非現実的でエラーも混入しやすくなります。参照:2-6節

問12. あるSNS分析企業のブロンズテーブルには、イベントがJSON文字列のままraw_payload列に格納されている。この中のuser.address.cityのようなネストされたフィールドを抽出してシルバーテーブルの列にしたい。方法として最も適切なものはどれか。

解説:JSON文字列列に対しては、コロン(:)構文でパスを指定してフィールドを直接参照できるほか、from_jsonでSTRUCT型に変換すればドット記法でネストにアクセスできます。Bは不要な変換であり、CSVはネスト構造の表現に不向きです。Cの正規表現によるJSON解析は壊れやすくエスケープ等で誤抽出を起こします。Dは誤りで、Spark/Databricksはネスト構造をネイティブに扱えます。参照:2-6節

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

問13. ブロンズテーブルの注文データをシルバーに変換する際、主キーにあたるorder_idがnullの行は分析に使えないため除外し、割引額discountのnullは「割引なし」を意味するため0で補完したい。処理として最も適切なものはどれか。

解説:nullクリーニングは「列ごとに意味を考えて、除外と補完を使い分ける」のが基本です。subsetを指定したdropで必須キー欠損行のみ除外し、意味的に0とみなせる列はfillnaで補完します。Aは discountがnullなだけの有効な注文まで削除してしまいます。Cは数値列に文字列を入れることになり型が壊れます。Dはシルバー層でクリーニングを行うメダリオンアーキテクチャの役割分担に反し、下流の全消費者に負担を転嫁します。参照:3-1節

問14. 顧客マスタ(全顧客)と注文テーブルを結合し、「注文が1件もない顧客も含めた」顧客ごとの注文集計レポートを作りたい。顧客マスタを左側とした場合の結合として最も適切なものはどれか。

解説:「左側(顧客マスタ)の行をすべて残し、右側(注文)は一致した行だけ付与、一致しなければnull」という要件はleft outer joinそのものです。Aのinner joinは注文のない顧客が結果から消えてしまいます。Bのcross joinは全組み合わせを生成する別物で、意図しない行数爆発を招きます。Cのunionは行の連結であり、キーで突き合わせる結合の代わりにはなりません。参照:3-2節

問15. 数十億行の売上ファクトテーブルと、数千行の店舗マスタを結合するクエリが遅い。実行計画を見ると両テーブルのシャッフルを伴う結合になっていた。改善策として最も適切なものはどれか。

解説:片方が十分小さい結合では、小テーブルを全エグゼキュータに配布するbroadcast joinにより高コストなシャッフルを回避できます(broadcast()ヒントやspark.sql.autoBroadcastJoinThresholdで制御)。Bは逆で、巨大テーブルのブロードキャストはメモリ不足を引き起こします。Cは保守不能な運用です。Dのcross join後フィルタは中間結果が爆発し、性能はむしろ悪化します。参照:3-2節

問16. ECサイトの注文テーブルに、1注文に含まれる商品IDの配列を保持するitems列(ARRAY型)がある。商品ID単位の売れ筋分析のため、配列の要素ごとに1行ずつ持つテーブルに変換したい。使用する関数として最も適切なものはどれか。

解説:配列の要素を行方向に展開する(1要素=1行)のはexplodeの役割で、「注文×商品」の粒度に変換する本問の要件に合致します。Aのconcatは文字列連結、Bのcollect_listはむしろ逆方向(行→配列)の集約です。DのdropDuplicatesは重複行の排除で、配列の展開とは無関係です。参照:3-3節

問17. 顧客テーブルのfull_name列に「姓 名」がスペース区切りの1つの文字列で入っている。姓と名を別々の列に分けたい。最初に適用する処理として最も適切なものはどれか。

解説:文字列の分割はsplit(col, " ")で配列化し、getItem(0)/getItem(1)(SQLでは添字アクセス)でそれぞれをwithColumnの新列にするのが定石です。Bのexplodeは配列を「行」に展開する関数で、同一人物が複数行になってしまい目的と異なります。Cの集約は分割と無関係です。Dは誤りで、Sparkの標準関数で完結できます。参照:3-3節

問18. 上流システムの再送により、注文イベントテーブルに同じorder_idの行が複数回記録されることがある。金額などの他列は同一で、order_idを基準に1行だけ残したい。処理として最も適切なものはどれか。

解説:特定のキー列を基準にした重複排除はdropDuplicates(サブセット指定)が直接の解です。全列一致の重複ならdistinct()でも除去できますが、キー列基準の指定ができるdropDuplicatesが柔軟です。Aは手順として意味がなく危険です。Bは観測するだけで問題を解決しません。Cはnull除外でありデータ重複には効きません。参照:3-4節

問19. 数百億行のアクセスログから日次のユニークユーザー数をダッシュボードに表示したい。厳密な値は不要で数%の誤差は許容できるが、COUNT(DISTINCT user_id)の実行時間とメモリ消費が問題になっている。対応として最も適切なものはどれか。

解説:「誤差許容・大規模・高速化したい」というカーディナリティ集計にはapprox_count_distinct(HyperLogLogベース)が適します。相対誤差も引数で指定できます。Aはコスト増で解決する力技であり、誤差を許容できる要件に対して不経済です。Cはドライバのメモリを確実に枯渇させます。Dのサンプリングからの外挿はユニーク数の推定としては統計的に誤った方法で、大きく外れます。参照:3-4節

問20. あるETLジョブで、集計後のデータ量は小さいのにシャッフル後のステージで大量の極小タスクが発生し、オーバーヘッドで遅くなっている。原因はシャッフルパーティション数がデータ量に対して過大なことだった。対応として最も適切なものはどれか。

解説:シャッフル後のパーティション数はspark.sql.shuffle.partitionsで決まり、データ量に対して過大だと極小タスクのオーバーヘッドが支配的になります。値の適正化、またはAQEによる小パーティションの自動結合(coalesce)が正攻法です。Aは逆方向で悪化します。Bはメモリ不足の対処であり本問の症状と無関係です。Dは結合戦略の設定で、シャッフルパーティション数の問題には効きません。参照:3-5節

問21. ゴールド層に、日次で更新されれば十分な売上集計を用意したい。BIから頻繁に参照されるため結果は事前計算しておき、更新時はエンジンに増分計算を任せたい。作成するオブジェクトとして最も適切なものはどれか。

解説:「参照頻度が高い集計を事前計算し、定期リフレッシュで増分更新したい」はマテリアライズドビューの典型ユースケースです。Aの通常ビューは毎回計算が走るため参照が多いと非効率です。Bのストリーミングテーブルは継続到着データの増分「取り込み」に適したオブジェクトで、日次で十分な集計に常時稼働を使うのは過剰です。Cの一時ビューはセッションを越えて共有できず、BI用途に使えません。参照:3-6節

問22. Lakeflow Spark Declarative Pipelines(旧 Delta Live Tables)のパイプラインで、シルバーテーブルに「amount列は0以上」という品質ルールを設け、違反した行だけをテーブルに入れず、パイプライン自体は継続させたい。設定として最も適切なものはどれか。

解説:エクスペクテーション(期待)は違反時の動作を選べます。記録のみ(警告)・違反行を除外(DROP ROW)・更新を失敗させる(FAIL UPDATE)の3種で、「違反行だけ入れず処理は継続」はDROP ROWに該当します。BのFAIL UPDATEはパイプラインが止まるため要件に反します。Cは品質問題を放置し下流全体に影響します。Dは手動運用でパイプラインの自動化と両立しません。参照:3-6節

Lakeflow Jobs(問23〜29)

問23. あるデータチームは「宣言的パイプラインの更新 → 完了後にSQLで集計テーブルを更新 → 最後にダッシュボードをリフレッシュ」という一連の処理を毎朝自動実行したい。Lakeflow Jobs(旧 Workflows)での実現方法として最も適切なものはどれか。

解説:Lakeflow Jobsはノートブック・パイプライン・SQL・ダッシュボードなど複数のタスクタイプを1つのジョブに混在させ、依存関係でつなげられます。異種処理の連鎖は「1ジョブ・複数タスク+依存関係」が基本形です。Aの時刻ずらしは前段の遅延や失敗を検知できず壊れやすい設計です。Bはパイプラインやダッシュボード更新をノートブックに押し込む不自然な作りで、失敗箇所の特定やリトライの粒度も失われます。Dは自動化の要件を満たしません。参照:4-1節

問24. あるジョブでは、タスクA(売上取り込み)とタスクB(在庫取り込み)が並列に走り、両方が成功した後にのみタスクC(統合レポート作成)を実行したい。設定として最も適切なものはどれか。

解説:ジョブのタスクはDAG(有向非巡回グラフ)を構成し、1つのタスクに複数の依存先を指定すると、既定ではすべての依存タスクが成功した後に実行されます(ファンイン)。本問はCの依存にAとBを指定するだけで実現できます。Aは順序が逆です。Cの時間待ちは前段の遅延で壊れる典型的なアンチパターンです。Dでは取り込み完了前にレポートが作られる恐れがあります。参照:4-1節

問25. 外部APIを呼び出すタスクが、先方の一時的な接続エラーで月に数回失敗する。エラーは数分後の再実行でほぼ解消する。運用担当の手を煩わせない対策として最も適切なものはどれか。

解説:一過性(transient)の失敗にはタスクレベルのリトライ設定が直接の解で、回数と間隔を指定すれば自動で再試行されます。Bは自動化の放棄です。Cはエラーの隠蔽であり、本当に失敗したときもデータ欠損に気づけなくなります。Dは成功時にも多重実行されて無駄なコストと二重処理のリスクを生みます。参照:4-2節

問26. 日次ジョブで、品質チェックタスクの結果(合格/不合格)に応じて「合格なら本番テーブルへ反映するタスク」「不合格なら担当者へ通知するタスク」のどちらかだけを実行したい。実現方法として最も適切なものはどれか。

解説:Lakeflow JobsのIf/else条件タスクは、タスク値やジョブパラメータを条件式で評価し、真偽に応じて実行経路を分岐できます。「結果に応じてどちらかだけ実行」はその典型ユースケースです。Aは不合格でも本番反映されてしまい品質チェックの意味がありません。Bは自動化の要件に反します。CのFor eachは同じ処理をパラメータを変えて繰り返すループ用で、分岐には使いません。参照:4-2節

問27. 30個の国別テーブルすべてに同一の変換ノートブックを適用したい。国コードをパラメータとして渡す以外、処理内容は共通である。ジョブの設計として最も適切なものはどれか。

解説:「同一処理×パラメータ違いの反復」はFor eachタスクの典型ユースケースです。入力リストの各要素でネストしたタスクを実行でき、並列度(concurrency)も指定できます。AとDは国が増えるたびに手作業が増え、変更時に30箇所の修正が必要になります。CのIf/elseは分岐のための機能であり、反復の道具ではありません。参照:4-2節

問28. 取引先ごとにファイルが届く時刻がバラバラで、事前に予測できない。クラウドストレージの指定パスにファイルが置かれたら、できるだけ早くロードジョブを開始したい。トリガーの選択として最も適切なものはどれか。

解説:「到着時刻が不定・到着したら速やかに処理」という要件にはファイル到着トリガーが合致します。指定した外部ロケーションのパスを監視し、新規ファイルを検出するとジョブを起動します。Aでは最大24時間の遅延が発生します。Bの連続実行でも実現はできますが、ファイルが届かない時間帯もコンピュートが動き続けるためコスト効率が劣ります。Dは論外の手動運用です。参照:4-3節

問29. 経理部門向けの日次売上レポートは「毎朝7時までに前日分が確定していること」だけが要件で、上流データは毎日深夜2時までに確実に揃う。トリガー設計の判断として最も適切なものはどれか。

解説:トリガーは要件で選びます。「締め時刻が明確」「上流の完了時刻が保証されている」「日次で十分」という条件では、時間ベースのスケジュールが最もシンプルで運用しやすい選択です。データ駆動(ファイル到着など)が有利なのは到着タイミングが不定で鮮度要件が厳しい場合です。B・Cの「常に〜が優れている」という判断は要件を無視しており、Dは日次要件に対して過剰投資です。参照:4-4節

CI/CD(問30〜33)

問30. あるチームはDatabricks Git Folders(旧 Repos)でGitリポジトリと連携して開発している。本番運用中のノートブックに新機能を追加する際、mainブランチのコードに影響を与えずに開発とレビューを進める手順として最も適切なものはどれか。

解説:Git Foldersではブランチの作成・切り替え・コミット・プッシュ・プルがUIから行えます。本番コードを守る標準の流れは「フィーチャーブランチで開発 → プッシュ → プルリクエスト → レビュー → マージ」です。Aは未検証コードが本番ブランチを直接汚染するリスクがあります。Bのファイル名によるバージョン管理は変更履歴もレビューも担保できない典型的なアンチパターンです。Cはバージョン管理の放棄です。参照:5-1節

問31. あるチームがDeclarative Automation Bundles(旧 Databricks Asset Bundles)でジョブとパイプラインを管理している。同じ資産一式を「開発ワークスペースには開発設定で、本番ワークスペースには本番設定で」デプロイし分けたい。バンドルの構成として最も適切なものはどれか。

解説:バンドルのdatabricks.ymlにはtargetsセクションで複数の環境(ワークスペースURL、モード、環境別の設定)を定義でき、「-t dev」「-t prod」の指定だけで同一コードを環境別にデプロイし分けられます。Aはコードの乖離を招く二重管理です。Cの手書き換えはミスが本番事故に直結します。Dは手動作業でCI/CDの目的(再現性・自動化)に反します。参照:5-2節

問32. CI/CDパイプラインで、バンドルの設定ファイルの構文誤りや参照切れを、実際のワークスペースへ資産を配置する前の段階で検出したい。CIの検証ステップで実行すべきコマンドとして最も適切なものはどれか。

解説:databricks bundle validateはバンドル定義の構文・スキーマ・設定の妥当性をデプロイ前に検証するコマンドで、CIのプルリクエスト段階に組み込む代表的なステップです。Bのdestroyはデプロイ済み資産の削除で逆効果です。Cは「配置前に検出したい」という要件に反し、壊れた定義が環境に反映されるリスクがあります。Dのrunは配置済みのジョブ実行であり、検証の代わりに本物の処理を走らせるのは順序が誤っています。参照:5-3節

問33. 検証を通過したバンドルを、CIランナーから本番ターゲット(prod)のワークスペースへ配置し、続けて特定のジョブを実行したい。Databricks CLIのコマンドの組み合わせとして最も適切なものはどれか。

解説:バンドルの配置はdatabricks bundle deploy、配置済みジョブ・パイプラインの実行はdatabricks bundle runで行い、-tオプションでターゲット環境を指定します。CI/CDからはこの2コマンドの組み合わせが基本形です。Aのinitは新規バンドルの雛形作成、destroyは削除で目的と無関係です。Bは自動化に反します。Cは誤解で、validateは検証のみを行い資産の配置は行いません。参照:5-3節

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

問34. 「日次ジョブがここ1か月でだんだん遅くなっている気がする」という報告を受けた。まだSLA違反には至っていない。傾向を客観的に確認するための最初の行動として最も適切なものはどれか。

解説:Lakeflow Jobsの実行履歴には各実行の所要時間・ステータスが残り、時系列の推移(トレンド)と、DAG上のどのタスクで時間が伸びているかを確認できます。診断は「計測 → 特定 → 対処」の順が原則です。Aは問題がSLA違反として顕在化するまで放置する後手の対応です。Bは原因不明のままのコスト増で、データ量起因なら再発します。Dは履歴という重要な手掛かりを消す悪手です。参照:6-1節

問35. あるジョブのステージが終わらないためSpark UIを確認すると、200個のタスクのうち199個は数秒で完了しているが、1個だけが数十分実行し続けており、そのタスクのシャッフル読み取り量だけが突出して大きい。最も可能性の高い原因はどれか。

解説:「大多数のタスクは速いのに一部だけ極端に遅く、そのタスクのシャッフル読み取り量が突出している」はデータスキューの典型的な兆候です。特定のキー値(null や人気商品IDなど)に行が集中すると、そのキーを担当するパーティションだけ肥大化します。Aのノード不足なら全タスクが均等に遅くなります。Cのドライバ問題はタスク単位の偏りとして現れません。Dも「一様に遅い」症状であり、本問の偏った症状と一致しません。参照:6-2節

問36. 数TBのDeltaテーブルは、クエリのフィルタ条件が時期によってregion列だったりstore_id列だったりと変化する。従来の固定的なパーティショニングでは追従が難しい。データレイアウト戦略として最も適切なものはどれか。

解説:Liquid Clusteringは従来のパーティショニングやZORDERに代わる柔軟なレイアウト手法で、クラスタリングキーをALTER TABLEで後から変更でき、データの書き換えなしにクエリパターンの変化へ追従できます。Aの高カーディナリティ列での物理パーティションは小ファイルを大量に生む代表的なアンチパターンです。Bは大規模テーブルで性能とコストを浪費します。Cはストレージと同期保守のコストが非現実的です。参照:6-3節

問37. 運用チームは、多数のUnity Catalogマネージドテーブルに対するOPTIMIZEやVACUUMの実行スケジュールを個別に管理しており、負担が大きい。メンテナンスを自動化する機能として最も適切なものはどれか。

解説:Predictive Optimizationは、Unity Catalogのマネージドテーブルに対してOPTIMIZEやVACUUMなどのメンテナンス操作を、テーブルの利用状況に基づいて自動的に実行する機能です。スケジュール管理の負担をなくし、効果が見込めるテーブルに絞って実行されます。Bは効果のないテーブルにもコストをかけ続けます。Cの保持期間0時間はタイムトラベルを破壊し、実行中クエリの破損リスクもある危険な設定です。Dは小ファイル堆積などで性能が劣化していきます。参照:6-3節

問38. あるノートブックが「ドライバのメモリ不足(OOM)」でクラッシュを繰り返す。コードを確認すると、数億行のDataFrameに対してcollect()を呼び、全行をドライバに取得してPythonのループで処理していた。対処として最も適切なものはどれか。

解説:ドライバOOMの代表的な原因が、大規模データのcollect()による全件取得です。根本対策は処理ロジックを分散処理(DataFrame API/SQL)に書き換え、ドライバへ持ち込むのは集計後の小さな結果やdisplayでの一部確認に限定することです。Aはドライバ側のOOMに対してエグゼキュータの増強では解決しません。Bも最終的に全行がドライバに載る点は変わりません。Dは観測しやすくなるだけで問題は残ります。参照:6-4節

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

問39. クラウドストレージ上の既存のDeltaデータを、Databricks以外の外部ツールからも直接読み続けながらUnity Catalogにテーブルとして登録したい。また、将来テーブル定義を削除してもストレージ上のデータファイルは残したい。テーブルの種類として最も適切なものはどれか。

解説:「ストレージの場所を自分で管理する」「外部システムとファイルを共有する」「DROPしてもデータを残す」はいずれも外部テーブルを選ぶ典型的なシグナルです。Aは説明自体が誤りで、マネージドテーブルはライフサイクルをDatabricksが管理し、DROPするとデータも削除対象になります(新規作成ではマネージドが推奨ですが、本問の要件には合いません)。Cはデータの登録ではなく一時的なクエリ定義です。Dは集計結果の事前計算用オブジェクトで、既存データの登録手段ではありません。参照:7-1節

問40. 分析チームのグループ`analysts`に、テーブルmain.sales.ordersをSELECTさせたい。GRANT SELECT ON TABLE main.sales.orders TO `analysts` を実行したが、メンバーは「アクセスできない」というエラーになる。原因として最も可能性が高いものはどれか。

解説:Unity Catalogでテーブルを読むには「USE CATALOG+USE SCHEMA+SELECT」の3点セットが必要です。テーブルへのSELECTだけあっても、上位のカタログ・スキーマを使う権限がなければ到達できません。Aは誤りで、GRANTはユーザー・グループ・サービスプリンシパルのいずれにも発行でき、運用上はむしろグループへの付与が推奨されます。Bは誤りで、所有者以外にも付与できます。Cのような遅延仕様はありません。参照:7-2節

問41. Unity Catalog上の給与テーブルmain.hr.salariesを、グループ`interns`には読み取らせないようにしたい。方法として最も適切なものはどれか。

解説:Unity CatalogではDENYはサポートされていません(DENYが使えるのはレガシーのhive_metastoreのテーブルACLのみ)。UCの既定は拒否であり、権限が無指定ならアクセスできないため、読ませたくない相手にはSELECTをGRANTしない(付与済みならREVOKEする)のが正しい対応です。あわせて、許可はグループ単位・最小権限で設計します。AのDENY文はUCでは実行できず誤りです。なお公式試験ガイドにはGRANT/REVOKE/DENYと記載がありますが、UCで使えるのはGRANT/REVOKEだけという表記差に注意してください。Cは最小権限の原則に反し、統制にもなっていません。Dは他の正当な利用者まで巻き添えにします。参照:7-2節

問42. 新設する分析用スキーマanalytics配下には今後100個以上のテーブルが追加されていく。分析グループには「配下の既存・将来のテーブルすべての読み取り」を、テーブル追加のたびの作業なしで許可したい。設計として最も適切なものはどれか。

解説:Unity Catalogの権限は階層(カタログ→スキーマ→テーブル)に沿って継承されるため、スキーマレベルのGRANT SELECTで配下の将来のテーブルにも自動的に読み取りが及びます。「オブジェクト追加のたびに作業ゼロ」の要件は上位階層への付与で満たすのが定石です。Bは追加のたびに作業と漏れのリスクが発生します。CとDは読み取りだけの要件に対して過剰な権限(管理・変更・削除まで可能)を与え、最小権限の原則に反します。参照:7-2節

問43. 顧客テーブルのemail列について、人事グループにはそのままの値を、それ以外の利用者には「***」にマスクした値を表示したい。テーブルの複製や別ビューの乱立は避けたい。実現方法として最も適切なものはどれか。

解説:列レベルマスキングは、呼び出し側の所属(is_account_group_member)に応じて元の値かマスク値を返すSQL UDFを定義し、対象列にカラムマスクとして設定する方式です。テーブルは1つのまま、利用者に応じて表示だけが変わります。Aは複製の同期という新たな運用問題を生みます。Cは正当な利用者(人事)まで使えなくなります。Dは技術的統制がなく、監査にも耐えません。参照:7-3節

問44. 全社のカタログには数百のテーブルに個人情報(PII)列が散在している。テーブルごとに個別のマスク関数を設定する運用が限界に達しており、「PIIとしてタグ付けされた列には共通のマスクポリシーを一括適用する」という集中管理に移行したい。利用する機能として最も適切なものはどれか。

解説:ABACは「タグ(属性)」と「ポリシー」を分離し、pii等のタグが付いた列に対するマスク・行フィルタのポリシーをカタログやスキーマ単位で一括定義できる集中管理の仕組みです。新しいテーブルもタグを付けるだけでポリシーが適用され、数百テーブル規模のスケール課題に対応できます。Aはまさに限界に達している現行運用です。Bは物理隔離であり、正当な利用も妨げ管理も分断されます。Cは分析に必要なデータまで失う過剰対応です。参照:7-4節

問45. Unity Catalogのマネージドテーブルに対してDROP TABLEを実行した場合の挙動として最も適切なものはどれか。

解説:マネージドテーブルはメタデータとデータの両方のライフサイクルをUnity Catalogが管理するため、DROP TABLEを実行するとテーブル定義とデータの双方が削除対象になります。ただし削除は即時の物理消去ではなく、一定の保持期間内であればUNDROP TABLEで復元できます。Aは外部テーブルの挙動で、外部テーブルのDROPでは定義のみが削除されストレージ上のファイルは残ります。Bは誤りで、保持期間内の復元手段が用意されています。Dのような制約は存在せず、マネージドテーブルもDROP TABLEで削除できます。参照:7-1節