Databricks 認定学習資料

テーマ切替

確認問題｜Professional ⑧ データガバナンス（配点 7%） ​

教材 08-governance.md の内容に基づく確認問題です（全10問）。 まず問題を解き、下の「解答・解説」で答え合わせをしてください。

問題 ​

Q1.（シナリオ）テーブル所有者が次を実行したが、analysts グループのユーザーはまだテーブルを読めない。原因と、この仕様が持つ意味として正しいものはどれか。

sql
GRANT SELECT ON TABLE prod_catalog.sales.orders TO `analysts`;
  • A. SELECT は読み取り専用なので、書き込み権限の MODIFY も併せて付与する必要がある
  • B. USE CATALOG（親カタログ）と USE SCHEMA（親スキーマ）が不足している。これらはデータへのアクセスそのものは許可しない前提条件であり、SELECT を持っていても欠けているとアクセスできない。USE CATALOG を付与できるのはカタログ所有者／MANAGE 保有者だけなので、この仕組みによってカタログ／スキーマ所有者が、下位オブジェクト所有者の付与に関わらずアクセス境界を制御できる
  • C. テーブルレベルの GRANT は無効で、必ずスキーマレベルで付与しなければならない
  • D. Unity Catalog では GRANT の反映に最大 24 時間かかるため、待つ必要がある

Q2. Unity Catalog の権限継承について、正しい説明はどれか。

  • A. カタログ／スキーマに付与した権限は、その中の現在および将来のすべての子オブジェクトに自動適用される（例: カタログに SELECT を付与すればカタログ内の任意テーブルを読める）。ただし重要な例外として、メタストアレベルで付与した特権は子オブジェクトに継承されない（CREATE CATALOG はメタストアにカタログを作成する操作を許可するだけで、カタログ内データへのアクセスは付与しない）
  • B. スキーマに付与した権限は、付与時点で存在するオブジェクトにのみ適用され、将来作成されるオブジェクトには適用されない
  • C. メタストアレベルの権限も含めて、すべてのレベルの権限が子に継承される
  • D. 権限継承は特権モデル バージョン 2.0 以降でのみ有効になる

Q3. 所有権と MANAGE 特権の違いについて、正しい説明はどれか。

  • A. MANAGE を付与すると、そのオブジェクトのすべての特権（SELECT / MODIFY 等）が自動的に付与される
  • B. ALL PRIVILEGES には MANAGE が含まれるため、ALL PRIVILEGES を付与すれば所有権の譲渡もできる
  • C. 所有権は 1 オブジェクトに複数設定でき、MANAGE は 1 つだけ設定できる
  • D. 所有者はオブジェクトの全権限＋権限付与＋所有権譲渡の権利を持ち、作成者が初期所有者になる。MANAGE は所有者でなくても権限管理・所有権譲渡・名前変更・削除を可能にする特権だが、MANAGE を持つだけでは全特権が自動付与されない（各特権は個別付与が必要で、MANAGE 保有者はそれらを明示的に付与できる）。コンテナに MANAGE を付与すると全子オブジェクトにも及ぶ。ALL PRIVILEGES には MANAGE・EXTERNAL USE LOCATION・EXTERNAL USE SCHEMA は含まれない。運用オブジェクトの所有権は個人ではなくグループに割り当てる

Q4. BROWSE 特権とデータ検出について、正しい説明はどれか。

  • A. BROWSE はテーブルのデータを読み取る特権であり、SELECT の下位互換である
  • B. BROWSE を付与するには先に USE CATALOG と USE SCHEMA が必要である
  • C. BROWSE は USE CATALOG / USE SCHEMA なしにオブジェクトの存在確認・名前／説明／タグの表示・アクセス要求を可能にする特権（データそのものにはアクセスしない）。Databricks はカタログレベルで All account users グループに BROWSE を付与して組織全体でデータを検出できるようにすることを推奨する。アクセス要求の送信先（メール / Slack / Teams / PagerDuty / webhook 等）を構成すると、検出後にセルフサービスでアクセスを要求できる
  • D. BROWSE はスキーマレベルにのみ付与でき、カタログレベルには付与できない

Q5. データリネージ（系列）の仕組みと表示権限について、正しい説明はどれか。

  • A. リネージはテーブルレベルまでしかキャプチャされず、列レベルの追跡には別途設定が必要である
  • B. Unity Catalog は Databricks で実行されるクエリの系列を列レベルまで自動的にキャプチャし、メタストアにアタッチされた全ワークスペースにわたって集約する。表示にはテーブル／ビューの親カタログに対して最低 BROWSE（または対象への SELECT）が必要で、系列グラフは Unity Catalog と同じアクセス許可モデルを共有する。アクセス権のないダウンストリームは masked ノードとして表示され展開できない。確認方法は Catalog Explorer の［系列］タブ、Genie Code（/getTableLineages）、システムテーブル（system.access.table_lineage / system.access.column_lineage）
  • C. 系列を見るにはメタストア管理者である必要がある
  • D. 系列は各ワークスペースごとに独立して記録され、他ワークスペースでキャプチャされた系列は一切見えない

Q6. データリネージの制限事項として、正しい説明はどれか。

  • A. 名前を変更したテーブルの系列も、旧名から新名へ自動的に引き継がれる
  • B. 列レベル系列は、ソース／ターゲットをパスで参照した場合（例: select * from delta."s3://.../path"）でもサポートされる
  • C. Catalog Explorer の系列データはローリング 1 年、系列システムテーブルは無期限保持である
  • D. 名前を変更したカタログ・スキーマ・テーブル・ビュー・列の系列は保持されない。列レベル系列は両方がテーブル名で参照される場合のみサポートされ、パス参照では不可。UDF はソース列とターゲット列のマッピングを隠す場合がある。RDD とグローバル一時ビューは系列にキャプチャされない。Spark SQL データセットのチェックポイント使用時もキャプチャしない。2024 年 9 月 1 日より前の系列データは利用不可で、Catalog Explorer の表示は無期限保持だが系列システムテーブルはローリング 1 年間のウィンドウ。トランザクションはロールバックされても系列イベントは保持される

Q7. system.access.audit を使った監査について、正しい説明はどれか。

  • A. 主要列は event_time（UTC のタイムスタンプ）/ event_date / user_identity（email 等）/ service_name（例 unityCatalog）/ action_name（例 getTable）/ request_params（要求パラメータのマップ）/ response（statusCode / errorMessage / result）/ audit_level（WORKSPACE_LEVEL / ACCOUNT_LEVEL）など。クエリは event_date より event_time でフィルタするとパフォーマンスが向上する。アカウントレベルイベントは workspace_id = 0 で記録され、ほとんどの監査ログはワークスペースのリージョンでのみ利用可能
  • B. event_time はローカルタイムゾーンで記録されるため、event_date でフィルタするほうが正確である
  • C. アカウントレベルイベントは workspace_id が NULL で記録される
  • D. system.access.audit は書き込み可能なので、不要なイベントを削除して保持容量を節約できる

Q8. カタログ設計とメタストアについて、正しい説明はどれか。

  • A. メタストアがデータ分離の主要単位であり、環境ごとにメタストアを作るのが推奨である
  • B. カタログはリージョンをまたいで共有できるため、複数リージョンのワークスペースから同じカタログを直接参照するのが推奨である
  • C. カタログがデータ分離の主要単位（primary unit of data isolation） であり、データアクセスの論理カテゴリを表す。設計は環境スコープ（dev / staging / prod）・チーム・部署、またはその組み合わせに対応させる。メタストアはアカウント内でリージョンごとに 1 つで、同リージョンの全ワークスペースが共有するためカタログは本質的にリージョンごとに分離される。メタストアはリージョン分離を提供するがデータ分離の既定単位ではない（分離は通常カタログから開始）。リージョン／クラウドをまたぐ共有は OpenSharing（Delta Sharing） を使い、頻繁アクセスのテーブルを複数メタストアに外部テーブル登録するのは避ける（整合性問題・エグレス料金）
  • D. カタログのマネージドストレージはメタストアレベルに置くのがベストプラクティスで、カタログレベルには置かない

Q9. タグについて、正しい説明はどれか。

  • A. タグキーは大文字小文字を区別しないため、Sales と sales は同一のタグとして扱われる
  • B. タグは 1 オブジェクト（テーブル／列）あたり最大 50 タグ、1 テーブルの全列合計で最大 1,000 列タグ、キー／値の最大長は各 256 文字。キーに . , - = / : は使えず、先頭／末尾のスペースも不可。タグキーは大文字小文字を区別し、タグ検索は正確な単語一致が必要。タグデータはプレーンテキストで格納されグローバルにレプリケートされる場合があるため個人情報・機密情報を使わない。管理タグ（governed tag） は許可キー／値と割り当て可能なユーザーを制御し ASSIGN 特権が必要。システムタグは Databricks 事前定義でキー／値は変更不可。ABAC ポリシー評価時のみ上位レベルのタグが配下の全オブジェクトに暗黙継承される（ただし列レベルには継承されない）
  • C. タグの付与に必要な権限は SELECT のみである
  • D. 1 つの ALTER TABLE で複数列に同時にタグを割り当てられる

Q10. マネージドテーブル／外部テーブルの使い分けと OpenSharing の制限について、正しい説明はどれか。

  • A. 外部テーブルが推奨形式であり、マネージドテーブルは既存データがある場合にのみ使う
  • B. マネージドテーブルは DROP してもデータファイルが残り、外部テーブルは即座に削除される
  • C. マネージドテーブルが推奨（自動最適化・予測的最適化・メタデータキャッシュ等の恩恵を受けられる）で、外部は既存データ・DR・外部リーダー／ライター要件があるときに使う。外部テーブルへの外部アクセスは UC の制御・監査・系列をバイパスするため制限すべきで、UC マネージドテーブル／ボリュームへのストレージレベルの直接アクセスを Unity Catalog 以外の ID に付与してはならない。リージョン／クラウド／組織をまたぐ共有には OpenSharing を使うが、系列とアクセス制御はメタストア境界を越えない点に注意する
  • D. マネージド／外部の区別はテーブル・ボリュームだけでなく、ビュー・関数・モデルにも適用される

解答・解説 ​

Q1. 正解: B テーブルを読むには「テーブルへの SELECT」＋「親スキーマへの USE SCHEMA」＋「親カタログへの USE CATALOG」の 3 点セットが必要。USE CATALOG / USE SCHEMA は使用特権（前提条件） であり、それ自体はデータへのアクセスを許可しないが、これらがないと SELECT を持っていてもアクセスできない。USE CATALOG を付与できるのはカタログ所有者／MANAGE 保有者だけなので、この仕組みがアクセス境界として働き、カタログ／スキーマ所有者が下位オブジェクト所有者の付与に関わらず全体を制御できる。A の MODIFY は書き込み特権なので読み取りには不要、C はテーブルレベルの GRANT も有効なので誤り、D のような反映遅延の仕様はない。

Q2. 正解: A カタログ／スキーマに付与した権限は、その中の現在および将来のすべての子オブジェクトに自動適用される（特権モデル v1.0。B・D が誤り）。例えばカタログに SELECT を付与すればカタログ内の任意テーブルを読め（適切な USE CATALOG / USE SCHEMA が前提）、CREATE TABLE を付与すればカタログ内の任意スキーマにテーブルを作成できる。重要な例外はメタストアレベルで付与した特権が子オブジェクトに継承されないこと（CREATE CATALOG はメタストアにカタログを作成する操作を許可するだけで、カタログ内データへのアクセスは付与しない）ため C は誤り。継承のためカタログ／スキーマレベルの特権は広範になるので、最小特権の原則に従い CREATE TABLE / CREATE VOLUME 等はスキーマレベルで付与するのが推奨。

Q3. 正解: D すべてのセキュリティ保護可能オブジェクトには所有者が 1 つ存在し、作成者が初期所有者になる。所有者はそのオブジェクトの全権限（他者への権限付与を含む）と所有権譲渡の権利を持つ。MANAGE は所有者でなくても権限管理・所有権譲渡・名前変更・削除を可能にする特権だが、MANAGE を持つだけでは全特権が自動付与されない（A が誤り）。コンテナに MANAGE を付与すると全子オブジェクトにも MANAGE が及ぶ。ALL PRIVILEGES には MANAGE・EXTERNAL USE LOCATION・EXTERNAL USE SCHEMA は含まれない（意図しないデータ流出・特権エスカレーション防止のため）ので B も誤り。C は所有者が 1 つである点に反する。運用オブジェクトの所有権は誤操作や退職時のリスクを避けるため個人ではなくグループに割り当てる。

Q4. 正解: CBROWSE は USE CATALOG / USE SCHEMA なしに、データにアクセスせずオブジェクトの存在確認・名前／説明／タグの表示・アクセス要求を可能にする特権（A・B が誤り）。Databricks はカタログレベルで All account users グループに BROWSE を付与して組織全体でデータを検出できるようにすることを推奨している（D が誤り）。加えてアクセス要求の送信先を構成すると、ユーザーがオブジェクトを検出した後にセルフサービスでアクセスを要求でき、既定のメール送信先を有効にしておけば要求はカタログ所有者／オブジェクト所有者に届く。なおリネージ表示に必要な最低権限もこの BROWSE である。

Q5. 正解: B Unity Catalog は Databricks で実行されるクエリの系列を列レベルまで自動的にキャプチャし、メタストアにアタッチされた全ワークスペースにわたって集約する（A・D が誤り。適切な権限があれば別ワークスペースでキャプチャされた系列も見えるが、他ワークスペースのノートブック／ダッシュボード等の詳細はマスクされる）。系列グラフは Unity Catalog と同じアクセス許可モデルを共有し、表示には対象カタログへの最低 BROWSE（または対象への SELECT）が必要で、メタストア管理者である必要はない（C が誤り）。アクセス権のないダウンストリームは masked ノードとして表示され展開できない。キャプチャ要件はテーブルが UC に登録され、クエリが Spark DataFrame または Databricks SQL インターフェイスを使うこと。ストリーミングの系列追跡は DBR 11.3 LTS 以降、Lakeflow パイプラインの列系列は DBR 13.3 LTS 以降。

Q6. 正解: D 系列の制限は頻出。名前を変更したカタログ・スキーマ・テーブル・ビュー・列の系列は保持されない（A が誤り）。列レベル系列は両方がテーブル名で参照される場合のみサポートされ、パス参照（select * from delta."s3://.../path"）では不可（B が誤り）。UDF はソース列とターゲット列のマッピングを隠す場合がある。RDD・グローバル一時ビュー・Spark SQL データセットのチェックポイント使用時はキャプチャされない。system.information_schema 配下のテーブルも記録されない。ジョブ API の runs submit や spark submit タスクは系列ビューで使えない（テーブル／列レベル系列はキャプチャされるがジョブ実行へのリンクは不可）。Lakeflow パイプラインの PRIVATE テーブル使用時はカバレッジが不完全。2024 年 9 月 1 日より前の系列データは利用不可。保持期間は Catalog Explorer の表示が無期限、系列システムテーブルがローリング 1 年間なので C は逆。

Q7. 正解: Asystem.access.audit（パブリックプレビュー、無料保持 365 日）は「誰がいつ何にアクセス・操作したか」を記録するガバナンスの中核テーブル。主要列は A の通りで、event_time は UTC（+00:00） のタイムスタンプであり、公式は「クエリは event_date より event_time でフィルタするとパフォーマンスが向上する」と明記している（B が逆）。アカウントレベルイベントは workspace_id = 0（C が誤り）。システムテーブルは読み取り専用で変更できない（D が誤り）。response.statusCode <> 200 で権限拒否などの失敗操作を抽出したり、service_name = 'unityCatalog' かつ action_name IN ('getTable', 'generateTemporaryTableCredential') でテーブルアクセスを追跡したりするのが典型的な使い方。

Q8. 正解: Cカタログがデータ分離の主要単位であり、設計は組織単位や SDLC スコープ（運用データ用 vs 開発データ用、非顧客データ用 vs 機密顧客データ用など）を反映することが多い。メタストアはアカウント内でリージョンごとに 1 つで、同リージョンの全ワークスペースが共有するためカタログは本質的にリージョンごとに分離される。メタストアはリージョン分離を提供するがデータ分離の既定単位ではない（A が誤り）。カタログはリージョンをまたいで直接共有するものではなく、リージョン／クラウド／組織をまたぐ共有は OpenSharing を使い、頻繁アクセスのテーブルを複数メタストアに外部テーブル登録するのは整合性問題・エグレス料金の観点で避ける（B が誤り）。ストレージのベストプラクティスはカタログレベルのストレージを優先（初期の UC ではメタストアレベルが必要だったが現在は不要）で、メタストアレベルを作る場合は専用コンテナを使い、UC 外からアクセスできるコンテナや DBFS ルートのコンテナは使わない（D が逆）。

Q9. 正解: B タグの制約はまとめて覚える。1 オブジェクト（テーブル／列）あたり最大 50 タグ、1 テーブルの全列合計で最大 1,000 列タグ、キー／値の最大長は各 256 文字、キーに使えない文字は . , - = / : で先頭／末尾のスペースも不可、タグキーは大文字小文字を区別（Sales と sales は別。A が誤り）、タグ検索は正確な単語一致が必要、1 つの ALTER TABLE で複数列に同時割り当ては不可（列ごとに個別実行。D が誤り）。必要な権限はオブジェクトの所有者であるか、対象オブジェクトの APPLY TAG ＋ 親スキーマの USE SCHEMA ＋ 親カタログの USE CATALOG（管理タグならさらに ASSIGN）なので C も誤り。警告としてタグデータはプレーンテキストで格納されグローバルにレプリケートされる場合があるため、個人情報・機密情報をタグ名／値／記述子に使わない。**ABAC ポリシー評価時のみ上位レベルのタグが配下の全オブジェクトに暗黙継承される（列レベルには継承されない）**点も重要。

Q10. 正解: Cマネージドテーブル／ボリュームが推奨で、Unity Catalog がガバナンス（アクセス制御・監査・系列）と基盤ファイルストレージのライフサイクル（最適化・整理・削除）の両方を管理する（A が逆）。外部は既存データ・DR・外部リーダー／ライター要件があるときに使うが、外部テーブルへの外部アクセスは UC の制御・監査・系列をバイパスするため制限すべき。特に「Unity Catalog 以外の ID に、UC マネージドテーブル／ボリュームへのストレージレベルの直接アクセスを付与してはならない」は重要な警告（UC マネージドテーブルは直接ストレージアクセスをサポートしない）。ドロップ時の挙動はマネージド＝保持期間後にデータファイルも完全削除、外部＝メタデータのみ削除でデータファイルは残るなので B は逆。マネージド／外部の区別はテーブルとボリュームにのみ適用され、ビュー・モデル・関数には適用されない（D が誤り）。リージョン／クラウド／組織をまたぐ共有には OpenSharing を使うが、系列とアクセス制御はメタストア境界を越えない。