Databricks Certified Data Engineer Associate 教科書

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

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

模擬試験 セット2(応用シナリオ編)

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

セット2は応用シナリオとトラブルシューティング中心です。「症状から原因を診断して対策を選ぶ」「Spark UI のメトリクスを読み解く」「パイプラインや CI/CD の正しい並び順を選ぶ」タイプの問題を多く含みます。難易度は標準〜やや難です。

最終確認:2026年8月

Databricks Intelligence Platform(問1〜3)

問1. (応用シナリオ)あるデータチームには「アナリストが日中に対話的に使う SQL ダッシュボード」と「毎晩2時に起動する ETL バッチ」の2つのワークロードがある。現在は両方を1つの All-purpose クラスタで実行しており、アイドル時間も含めてコストが高い。コンピュート構成の見直しとして最も適切なものはどれか。

解説:SQL 分析にはそれに最適化された SQL ウェアハウス、スケジュール実行のバッチには実行時のみ課金される Job compute、という使い分けがコストと性能の両面で標準です。Aはアイドルコストが最大化する逆方向の変更です。Cは割り当てが逆で、対話的な利用はジョブ用コンピュートに適しません。Dはワークロードの規模を無視しており、性能要件を満たせません。参照:1-3節

問2. (トラブルシューティング)不要になったテーブルを DROP TABLE で削除したのに、クラウドストレージ上のデータファイルがそのまま残っていることに気づいた。原因として最も適切なものはどれか。

解説:外部テーブルはデータの所有・管理がユーザー側にあり、DROP はメタデータ(テーブル定義)のみを取り除きます。データも一緒に管理・削除させたい場合はマネージドテーブルを使います。Aのような仕様は外部テーブルにはありません。Bの VACUUM は履歴上の不要ファイルを物理削除する操作で、DROP の挙動とは別の話です。Dは誤りで、タイムトラベルは削除を禁止する機能ではありません。参照:1-1節

問3. (トラブルシューティング)昨日、誤った条件の UPDATE を本番の Delta テーブルに実行してしまった。このテーブルには保持期間7日で VACUUM を毎週実行する運用がある。復旧方針として最も適切なものはどれか。

解説:Delta Lake はトランザクションログにより過去バージョンへの RESTORE が可能ですが、到達できるのは VACUUM でまだ削除されていないバージョンまでです。保持期間がある運用では復旧の時間的猶予に限りがあります。Aは誤りで、RESTORE により書き戻せます。Bはトランザクションログとの整合性を壊す危険な操作です。Cは保持期間の存在を無視しており誤りです。参照:1-2節

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

問4. (トラブルシューティング)Auto Loader で JSON ファイルを取り込むストリーミング処理が、ソースに新しい列が追加された日に UnknownFieldException で停止した。以後も列追加は時々発生する見込みである。運用として最も適切なものはどれか。

解説:Auto Loader は schemaLocation でスキーマを追跡し、既定の addNewColumns モードでは新列の検出時にストリームを停止させ、再起動後に進化したスキーマで処理を続けます。したがって再起動(リトライ)を自動化するのが標準運用です。Bは不要な全再処理でコスト過大です。Cは誤りで、スキーマ進化はまさにこのための仕組みです。Dはスキーマ推論・進化の基盤を失わせる逆方向の変更です。参照:2-2節

問5. (応用シナリオ)Auto Loader の入力ディレクトリには累計数千万ファイルが蓄積しており、デフォルトのディレクトリ一覧(directory listing)モードでは新規ファイルの検出に時間がかかるようになった。改善策として最も適切なものはどれか。

解説:巨大なディレクトリでは一覧取得のコストが支配的になるため、ストレージのイベント通知で新着だけを知る file notification モードが適します。Aは取り込み済みファイルの管理情報を失い、重複取り込みの原因になります。Bは最もコストが高い方向への逆行です。Dは高コストな一覧処理の頻度を上げるだけで、症状を悪化させます。参照:2-2節

問6. (トラブルシューティング)Auto Loader で CSV を Delta テーブルに取り込んだところ、一部の行では数値型の列に「N/A」という文字列が入っていたことが分かった。ジョブは失敗しておらず、その値がどこへ行ったのかを確認して補正したい。最も適切な説明はどれか。

解説:Auto Loader はスキーマに合わないデータを既定で _rescued_data 列へ JSON として退避し、データを失わずに後から検査・補正できるようにします。Aは既定動作の誤解で、不一致は即失敗ではなく退避されます。Cのような自動変換は行われません。Dのような隔離テーブルは既定では作られず、必要なら自分で構成するものです。参照:2-3節

問7. (応用シナリオ)営業支援 SaaS のデータを毎日レイクハウスへ取り込むために、REST API を呼び出す自前の Python スクリプトを保守しているが、API の仕様変更のたびに壊れ、増分取得やスキーマ変更への対応も自前実装で負荷が大きい。改善策として最も適切なものはどれか。

解説:Lakeflow Connect は SaaS アプリケーションやデータベースからのマネージド取り込みコネクタを提供し、増分処理・変更対応などの保守負荷を大きく減らせます。これがまさに自前コネクタ保守の代替です。Aは言語を替えるだけで本質が変わりません。Bは自動化に逆行し、抜け漏れの原因になります。Cは転送量と処理コストを増やすだけで、壊れやすさは残ります。参照:2-1節

問8. (トラブルシューティング)変更データを毎時 MERGE INTO でターゲットへ upsert しているジョブが、「同一のターゲット行に複数のソース行がマッチした」という趣旨のエラーで失敗した。対応として最も適切なものはどれか。

解説:MERGE は1つのターゲット行に複数のソース行が一致すると、どちらを適用すべきか決められず失敗します。CDC データでは「キーごとに最新の変更だけを残してから MERGE する」前処理が定石です。Bは一致条件を壊す無意味な変更です。Cは動作はしても増分処理の利点を捨てるコスト過大な回避です。Dのような設定はなく、あったとしても整合性を壊します。参照:2-5節

問9. (応用シナリオ)クラウドストレージに置かれたファイルを日次バッチの INSERT INTO で追記しているが、ジョブが途中失敗して再実行されると、同じファイルの内容が二重に登録されてしまう。取り込みを冪等にする改善として最も適切なものはどれか。

解説:COPY INTO と Auto Loader はロード済みファイルを追跡する冪等な取り込みで、失敗後のリトライや再実行に安全です。Aは運用負荷が高くミスの温床です。Bは障害からの復旧手段を失わせます。Dは復旧を少し楽にするだけで、重複の発生自体は防げません。参照:2-4節

問10. (トラブルシューティング)ストリーミング取り込みジョブの挙動が不審だったため、チェックポイントディレクトリを削除して再起動したところ、過去の全ファイルが再取り込みされ、下流テーブルに大量の重複が発生した。チェックポイントの理解として正しいものはどれか。

解説:構造化ストリーミングはチェックポイントに進捗(オフセット)と状態を永続化することで、障害後も続きから正しく再開できます。削除は「どこまで処理したかの記憶」を消す操作であり、ソースの再処理と下流の重複を招きます。Aはキャッシュとの混同です。Cのような自動修復はありません。Dは誤りで、チェックポイントは耐障害性のために永続ストレージへ書かれます。参照:2-6節

問11. (並び順)クラウドストレージへ継続的に到着する注文データ(JSON)を分析可能な状態にするまでの取り込み・整備の流れとして、最も適切な並び順はどれか。

解説:取り込みは「生データの確保(bronze)→ 品質を整えた silver → ビジネス集計の gold」という依存関係の順に進めます。bronze に生データを残すことで、後からのロジック変更時の再計算や監査が可能になります。AとBは依存関係が逆転しており成立しません。Cは生データ層を飛ばしており、障害調査や再処理の基盤を失います。参照:2-1節

問12. (トラブルシューティング)日次バッチで Delta テーブルへ追記する処理が、上流の正式な仕様変更で追加された新列 discount_rate を含む DataFrame の書き込み時に、スキーマ不一致の AnalysisException で失敗した。対応として最も適切なものはどれか。

解説:スキーマ強制(enforcement)は意図しない変更からテーブルを守る仕組みであり、正式な変更は mergeSchema による明示的なスキーマ進化で反映するのが正しい使い方です。既存データを保ったまま新列が追加されます。Bは型変更などの上書きが必要な場面向けで、日次追記には過剰かつ危険です。Cは仕様変更の反映という要件に反します。Dのような全体無効化はできず、仮にできても品質統制を失います。参照:2-3節

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

問13. (応用シナリオ)現在は BI 用テーブルへソースの生データを直接ロードし、クレンジングと集計をすべてレポートごとの巨大な SQL で行っている。レポート間でロジックが重複し、修正漏れによる数値の食い違いが多発している。メダリオンアーキテクチャに沿った改善として最も適切なものはどれか。

解説:メダリオンアーキテクチャの狙いは品質段階の分離と変換ロジックの一元化です。silver で一度だけデータを整えれば、下流のロジック重複と修正漏れが解消します。Aは単一クエリの巨大化で保守性がさらに悪化します。Bはクレンジング前のデータを各レポートが個別に処理する現状の問題をそのまま残します。Dは重複を組織的に拡大する逆方向の変更です。参照:3-1節

問14. (応用シナリオ)Lakeflow Spark Declarative Pipelines(旧 Delta Live Tables)の silver テーブルに対し、「order_id が NULL の行は取り込まない。ただし何件除外したかは品質メトリクスとして追跡したい。パイプライン全体は停止させたくない」という要件がある。expectation の設定として最も適切なものはどれか。

解説:「違反行を落とす+件数は追跡+パイプラインは継続」という3つの要件の組み合わせを満たすのは expect_or_drop です。Aは違反行が silver に混入してしまいます。Cは全体停止となり「止めたくない」という要件に反します。Dは品質管理を各レポートへ押し付け、除外件数の追跡もできません。参照:3-4節

問15. (応用シナリオ)Lakeflow Spark Declarative Pipelines で、(a)クラウドストレージへ継続到着するイベントを追記で取り込むテーブルと、(b)silver 全体を集計した日次サマリーの2つを定義する。宣言方法の組み合わせとして最も適切なものはどれか。

解説:streaming table は追記され続けるソースの増分取り込みに適し、materialized view は集計・結合の結果を宣言的に最新化する用途に適します。集計側を streaming table にすると全体の再集計を増分で表現しにくく、追記ソース側を materialized view にすると増分処理の利点を失います。A・B・Cはこの適材適所のいずれかが崩れています。参照:3-4節

問16. (応用シナリオ)本番の大規模 Delta テーブルに対する変換ロジックの変更を、本番と同等のデータで検証したい。ストレージコストを抑えつつ、本番テーブルへ一切影響を与えない方法として最も適切なものはどれか。

解説:shallow clone は元テーブルのデータファイルを参照する軽量コピーで、独立した書き込みができるため検証用途に適します。Bは本番の履歴を汚し、検証中に他の利用者へ影響します。Cは目的は果たせますが「コストを抑える」という要件に反します。Dは統制の崩壊であり、本番影響ゼロという要件と正反対です。参照:3-2節

問17. (トラブルシューティング)CDC イベントを Lakeflow Spark Declarative Pipelines の AUTO CDC(旧 APPLY CHANGES INTO)でターゲットへ適用しているが、ネットワーク遅延でイベントが順不同に届いた日に、古い住所が最新の住所を上書きしてしまった。見直すべき設定として最も適切なものはどれか。

解説:AUTO CDC は SEQUENCE BY の順序キーによって「どちらが新しい変更か」を判定します。順不同到着で古い値が勝ってしまうのは、順序キーが未指定または到着順など不適切な列になっている場合の典型症状です。AとBは性能に関する設定で、適用順序の正しさには影響しません。Dはデータ品質制約の話で、順序判定とは無関係です。参照:3-5節

問18. (応用シナリオ)20億行の売上ファクトテーブルと約200行の店舗ディメンションテーブルの join が、大きなシャッフルを伴い遅い。最も効果的な改善はどれか。

解説:片側が十分小さい join では、小さい側を各ワーカーへ配布するブロードキャスト join により、大テーブル側のシャッフルを丸ごと回避できます。Aは並列性を破壊し、大幅に悪化します。Cは結合という要件そのものの放棄です。Dは読み込みの再利用には役立つ場面があっても、join のシャッフル自体はなくなりません。参照:3-6節

問19. (応用シナリオ)bronze の注文データには items という配列列(1注文に複数商品)が含まれる。商品単位の分析のために「1商品=1行」の silver テーブルを作りたい。使うべき変換として最も適切なものはどれか。

解説:配列の要素を行へ展開するのは explode の役割で、「1注文複数商品」を「1商品1行」へ正規化する定番の変換です。Aの pivot は行から列への変換で、商品数が可変の配列には不適です。Bは逆方向(行→配列)の操作です。Cは文字列化してしまい、商品単位の集計・結合ができなくなります。参照:3-3節

問20. (トラブルシューティング)gold 層の materialized view が「昨日の売上を含んでいない」と報告された。調査すると、基盤となる silver テーブルは最新である。対応として最も適切なものはどれか。

解説:materialized view は事前計算された結果を保持し、鮮度は refresh の実行タイミングで決まります。上流が最新なのに結果が古いのは、refresh がまだ実行されていない典型症状です。Bは通常のビュー(毎回計算)との混同です。Cは最新と確認済みの上流を壊すだけです。Dは切り分けをせずに他の層へ原因を押し付けています。参照:3-4節

問21. (トラブルシューティング)ある変換ノートブックがドライバーの OutOfMemory で失敗する。コードを確認すると、約5億行の DataFrame に collect() を実行して全行を Python のリストへ取得し、ループで加工してから書き戻していた。修正として最も適切なものはどれか。

解説:collect() は全データをドライバー1台へ集める操作で、大規模データにおけるドライバー OOM の代表的な原因です。変換は分散処理のまま表現し、結果も分散のまま書き込むのが正しい設計です。Aは5億行に対しては根本対策になりません。Bも全件をドライバーへ集める点は同じで、同じ障害を起こします。Dは総メモリ使用量を変えません。参照:3-6節

問22. (応用シナリオ)1行ずつ文字列を整形する Python UDF を多用した変換ジョブが、同程度のデータ量の他ジョブと比べて数倍遅い。最も効果的な改善はどれか。

解説:Python UDF は行ごとのシリアライズと Python プロセスとの往復コストが大きく、オプティマイザの最適化も適用されません。まず組み込み関数への置換、それが無理ならベクトル化 UDF、という順で検討するのが定石です。Aは計測にもなっておらず、さらに遅くなります。Cは往復が増えて悪化し得ます。Dはコストを10倍にして非効率を温存するだけです。参照:3-6節

Lakeflow Jobs(問23〜29)

問23. (トラブルシューティング)Lakeflow Jobs(旧 Workflows)で運用している夜間バッチが、月初の数日だけ所要時間が通常の4倍になる。原因調査の最初の一歩として最も適切なものはどれか。

解説:まず実行履歴の比較で「どのタスクが・どれだけ」遅いのかを絞り込み、該当実行のメトリクスで原因(月初の締め処理によるデータ量増加や特定キーへの偏りなど)を確認するのが調査の手順です。Aは原因不明のままコストを4倍にし、スキューが原因なら効果も薄い判断です。Bは問題を人手へ移すだけです。Cは根拠のない変更です。参照:4-4節

問24. (応用シナリオ)「取り込み → 変換 → データ品質チェック → BI 用テーブルの公開」の4処理を毎晩実行したい。品質チェックが失敗した場合は公開を実行せず、担当チームへ通知する必要がある。Lakeflow Jobs の構成として最も適切なものはどれか。

解説:タスクの依存関係により「上流が成功したときだけ下流を実行」を保証し、失敗時は通知する、というのが Lakeflow Jobs の基本設計です。Bは時刻頼みの連携で、処理が遅延した日に破綻します。Cは失敗の隠蔽であり、品質チェックの目的と正反対です。Dは順序が逆で、チェックの意味がなくなります。参照:4-2節

問25. (トラブルシューティング)夜間ジョブが、外部 API の一時的なタイムアウトが原因で月に数回失敗し、毎朝担当者が手動で再実行している。処理は再実行すれば成功し、冪等であることも確認済みである。改善として最も適切なものはどれか。

解説:冪等な処理の一時的エラーには自動リトライの設定が定石で、人手対応を減らしつつ復旧も早くなります。通知は「リトライで直らなかったものだけ」に絞ることで運用ノイズも減ります。Aは業務要件の放棄です。Bは自動化への逆行で持続しません。Dは原因への対処になっておらず、再現条件も特定できません。参照:4-3節

問26. (応用シナリオ)1つのジョブに5つのタスクがあり、タスクごとに個別の Job クラスタが起動するため、クラスタ起動のオーバーヘッドが累積して所要時間もコストも大きい。タスクは同じライブラリ構成で動作する。改善として最も適切なものはどれか。

解説:同一ジョブ内の複数タスクはクラスタ定義を共有でき、起動オーバーヘッドを1回に集約しつつ、タスク分割による可観測性と部分再実行のしやすさを保てます。Aは実行していない時間帯も課金され、コスト面で逆効果です。Cはタスク単位の監視・再実行という利点を失います。Dは何も解決しません。参照:4-1節

問27. (応用シナリオ)取引先からのデータファイルは不定期(週に数回、時刻もばらばら)にクラウドストレージへ置かれる。現在は15分ごとの cron スケジュールでジョブを起動しており、大半の実行は「新着ファイルなし」のまま終わるが、クラスタ起動コストは毎回発生している。改善として最も適切なものはどれか。

解説:不定期な到着に対しては、到着イベントを起点にジョブを起動するファイル到着トリガーが適しており、空実行のコストと処理開始までの遅延を同時に解消できます。Aは空実行をさらに増やす逆方向です。Bは相手の運用に依存し、現実的な統制になりません。Cは自動化の放棄で、検知漏れと遅延を招きます。参照:4-3節

問28. (応用シナリオ)パイプラインの最後に「一時テーブルの削除と実行結果の通知」を行うクリーンアップタスクを置いている。上流タスクが失敗した日であっても、クリーンアップだけは必ず実行したい。設定として最も適切なものはどれか。

解説:タスクの Run if 条件を使うと、依存タスクの成否に関わらず完了後に必ず実行(All done)といった制御ができます。Bは上流が失敗した日に実行されず、要件を満たしません。Cは削除すべき一時テーブルがまだ存在しない時点で走ることになり無意味です。Dは実行タイミングの保証がなく、無駄なコストも発生します。参照:4-2節

問29. (トラブルシューティング)30タスクで構成される夜間ジョブが、28番目のタスクだけ失敗して停止した。上流27タスクの処理結果は正しいことを確認済みである。再実行の方法として最も適切なものはどれか。

解説:Repair run は失敗した実行に対して、失敗タスク以降だけを同じパラメータ・同じ実行コンテキストで再実行でき、成功済みの27タスク分の時間とコストを節約できます。Aは大きな無駄です。Cは元の実行とパラメータや依存関係がずれるリスクがあります。Dは当日のデータ欠損を業務側へ放置する判断で不適切です。参照:4-4節

CI/CD(問30〜33)

問30. (トラブルシューティング)Declarative Automation Bundles(旧 DABs)で本番環境へデプロイしたところ、ジョブが開発用の小さいクラスタ設定と dev スキーマ名のまま動いていた。bundle 構成の見直しとして最も適切なものはどれか。

解説:bundle では共通のリソース定義に対し、targets で環境ごとの上書き(variables による値の差し替え)を宣言的に分離するのが基本形です。デプロイ時のターゲット指定により dev 設定の prod 混入を仕組みで防げます。Aは再現性と自動化を失います。Bはコードの重複で乖離が進行します。Dは環境分離の放棄であり本末転倒です。参照:5-2節

問31. (並び順)データパイプラインの変更を安全に本番へ届ける CI/CD の流れとして、最も適切な並び順はどれか。

解説:「開発 → レビュー → 自動テスト → マージ → 段階的デプロイ(staging → prod)」の順序は、テスト・レビュー・検証環境という防御線をすべて本番の手前に配置する構成です。BとCは本番を実験場にする運用で、障害がそのまま利用者へ届きます。Dは全体が逆順で成立しません。参照:5-3節

問32. (トラブルシューティング)bundle でデプロイした本番ジョブが、デプロイ作業をした開発者個人のアカウント権限で実行されており、「その開発者の退職や権限変更でジョブが停止するリスクがある」とセキュリティレビューで指摘された。対応として最も適切なものはどれか。

解説:本番の自動処理は個人アカウントではなくサービスプリンシパルとして実行するのが原則で、人の異動・退職と本番運用を切り離せます。bundle では run_as で実行主体を指定できます。Aは問題の先送りにすぎません。Cは最小権限の原則に反し、リスクをむしろ拡大します。Dは表示の問題ではなく、実行主体の問題です。参照:5-2節

問33. (応用シナリオ)ノートブックに埋め込まれた数百行の変換ロジックにバグが混入しがちだが、検証にはノートブック全体を実データで実行するしかなく、テストに時間がかかっている。テスト容易性の改善として最も適切なものはどれか。

解説:ロジックの関数化・モジュール化により、小さなテストデータで高速に検証できるユニットテストが書け、CI での自動実行(マージ前の回帰検出)が可能になります。AとBは回帰の自動検出をあきらめており、発見が本番障害の後になります。Dは構造を変えておらず、テスト容易性は改善しません。参照:5-3節

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

問34. (トラブルシューティング)あるステージの200タスクのうち199タスクは30秒以内に完了するが、1タスクだけが10分かかっている。Spark UI のステージメトリクスでは Shuffle Read Size が Min 12MB / Median 15MB / Max 9.8GB であった。診断と対策として最も適切なものはどれか。

解説:タスクの大半が速く1つだけ極端に遅い、かつシャッフル読み取りの Max が Median の数百倍という組み合わせは、特定キーにデータが集中するスキューの典型パターンです。全体増強(A)は偏った1タスクのボトルネックには効きません。Bは同じキー分布で毎回再現するため説明になりません。Cは Max の突出という最重要のシグナルを読み落としています。参照:6-2節

問35. (トラブルシューティング)よく参照される Delta テーブルへのクエリが数か月かけて徐々に遅くなった。調査すると、ストリーミング書き込みの積み重ねによりテーブルが数百万個の小さなファイルで構成されていた。対策として最も適切なものはどれか。

解説:小ファイル問題は、ファイルオープンとメタデータ処理のオーバーヘッドが読み取り性能を劣化させる現象で、OPTIMIZE によるコンパクションが直接の対策です。継続的な維持は自動化(予測的最適化など)に任せるのが定石です。Bは ACID・データスキップなど Delta の利点をすべて失います。Cは対策ではありません。Dは原因(ファイルサイズ管理)ではなく要件を切り下げる誤った方向です。参照:6-3節

問36. (応用シナリオ)監査チームのクエリはほぼ常に特定の日付範囲(event_date)で絞り込むが、10TB のテーブルに対してどのクエリもほぼ全ファイルをスキャンしている。読み取り量を減らす対策として最も適切なものはどれか。

解説:フィルタによく使う列でデータを物理的にまとめると、各ファイルの統計(最小値・最大値)により関係ないファイルの読み飛ばし(データスキップ)が効き、スキャン量が大きく減ります。現在の推奨手法は liquid clustering です。Aは同期・管理が破綻する複製の乱造です。Cは返す行数を絞るだけで、スキャン量が減るとは限りません。Dはスキップの単位も並列性も失う逆効果の変更です。参照:6-3節

問37. (トラブルシューティング)ワークスペースの月額コストが3か月で2倍になったが、どのチームのどのジョブが増加要因なのか分からない。調査方法として最も適切なものはどれか。

解説:課金・使用状況はシステムテーブルに記録されており、期間別・リソース別・タグ別の集計によって増加要因を定量的に特定できます。タグ付けの整備はチーム別按分と再発時の早期検知の基盤になります。Aは業務影響が大きいうえ不正確です。Bは合計しか分からず内訳の特定になりません。Dは主観の申告であり計測になりません。参照:6-4節

問38. (トラブルシューティング)大きなテーブル同士を結合する夜間ジョブが、Executor の OutOfMemory とディスクへの大量の spill で不安定になっている。Spark UI を確認すると、1つのシャッフルパーティションあたりのデータ量が数 GB に達していた。対策として最も適切なものはどれか。

解説:Executor の OOM と大量 spill の一因は、1パーティションあたりのデータが処理メモリに対して過大なことです。AQE はシャッフルの実測統計に基づきパーティションを実行時に調整でき、手動ならパーティション数の増加で粒度を下げられます。Aは障害箇所(Executor)の取り違えです。Bは行数が積算で爆発し、悪化どころか破綻します。Cのような設定はなく、spill はむしろ OOM を回避するための安全弁です。参照:6-2節

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

問39. (トラブルシューティング)新任アナリストに sales カタログ配下の sales.gold.orders テーブルへの SELECT を GRANT したのに、本人のクエリは権限エラー(PERMISSION_DENIED)で失敗する。Unity Catalog の権限モデルとして最初に確認すべきことはどれか。

解説:Unity Catalog の権限は「カタログ → スキーマ → オブジェクト」の3層で評価され、テーブルの SELECT だけでは親階層の USE 権限がないとアクセスできません。これがテーブル権限付与後の権限エラーの典型原因です。Bはプラットフォームの権限と無関係です。Cは所有者変更という過剰な操作で原則に反します。Dは最小権限に反するうえ、親階層の問題は解決しません。参照:7-1節

問40. (応用シナリオ)顧客テーブルの email 列を、一般のアナリストにはマスクした値で、privacy_admins グループには実際の値で見せたい。テーブルの複製は作りたくない。最も適切な機能はどれか。

解説:列マスクは単一のテーブルのまま、参照するユーザーの属性に応じて列の表示内容を動的に切り替えられる機能で、「複製なし・グループ別の見え方」という要件に合致します。Aは複製の同期・管理負荷が大きく要件にも反します。Cは技術的統制がなく、監査にも耐えません。Dは正当な利用まで止めてしまいます。参照:7-2節

問41. (応用シナリオ)監査部門から「この顧客テーブルに過去90日間で実際にアクセスした人の一覧(誰が・いつ・どんな操作か)を提出せよ」と要求された。対応として最も適切なものはどれか。

解説:「実際に誰がアクセスしたか」は監査ログの照会で答えるのが正しい対応で、Unity Catalog 環境では操作の記録がシステムテーブルとして参照できます。Aは権限の一覧であり実アクセスの証跡ではないため、要求に答えていません。Bは正確性も網羅性もありません。Dは誤りで、記録は残っています。参照:7-4節

問42. (応用シナリオ)silver 層の顧客テーブルの列定義を変更したいが、変更の前に「どの下流テーブル・ビュー・ダッシュボードが影響を受けるか」を把握したい。最も適切な方法はどれか。

解説:Unity Catalog は実際のクエリ実行からテーブル・列レベルのリネージを自動収集しており、下流依存の把握という影響調査にそのまま使えます。AとBは自己申告や目視に頼るため漏れが避けられません。Cは本番障害を計画に織り込む発想であり論外です。参照:7-3節

問43. (応用シナリオ)全社共通の受注テーブル(Unity Catalog管理)について、各地域のメンバーには自分の地域の行だけを見せたい。地域は今後も増える予定で、地域ごとにビューを量産する運用は避けたい。最も適切な方法はどれか。

解説:行レベルセキュリティは、グループ判定を行う SQL UDF を ALTER TABLE ... SET ROW FILTER でテーブル本体に適用するのが定石です。すべての参照経路(ノートブック・BI・SQL)で一貫して効き、地域が増えてもフィルタ関数側の対応だけで済みます。Bは要件で避けたいとされたビューの量産で、管理負荷と付与漏れのリスクがあります。Cの DENY は Unity Catalog では非対応(レガシーの hive_metastore のみ)であり、仮に使えても行単位の制御はできません。Dのカラムマスクは「列の値を隠す」機能で、行そのものを見えなくすることはできません。参照:7-3節

問44. (トラブルシューティング)セキュリティレビューで「複数のノートブックにクラウドストレージのアクセスキーが平文で書かれている」と指摘された。Unity Catalog 環境での是正として最も適切なものはどれか。

解説:Unity Catalog の storage credential と external location はクラウド資格情報を一元管理し、利用者にキーを配布せずに権限制御と監査を実現します。コード上の秘密情報はシークレット管理へ移すのが原則です。AのBase64は符号化にすぎず誰でも復元できます。Cはエクスポートや履歴など漏えい経路が残ります。Dはローテーションと平文管理は別問題で、露出期間が短くなるだけです。参照:7-1節

問45. (トラブルシューティング)あるアナリストは gold スキーマの売上サマリービューを問題なく SELECT できるが、そのビューが参照している silver スキーマの元テーブルを直接 SELECT すると PERMISSION_DENIED になる。Unity Catalog の動作の説明として最も適切なものはどれか。

解説:Unity Catalog のビューは、元テーブルへのアクセスをビューの所有者の権限で行います。このため利用者に元データへの直接権限を与えることなく、加工・制限された結果だけを公開できます。これはビューをアクセス制御の層として使う基本パターンであり、症状は正常な動作です。Aは誤りで、ビューと元テーブルの権限は独立しており破損ではありません。Bは誤りで、DENY は Unity Catalog では非対応(hive_metastore のレガシー権限モデルの概念)であり、原因の説明として成立しません。Cは誤りで、権限がビューから元テーブルへ自動伝播することはありません。参照:7-2節