WEB問題集
Microsoft Fabric で、特定の 1 つのレポートだけを外部ユーザーに共有し、ワークスペース全体へのアクセスは与えたくありません。最小権限の原則に最も適した方法はどれですか?
解説
【正解: C】の理由
アイテムレベルの直接共有 (Share) は、ワークスペース全体ではなく特定のレポートやセマンティックモデルといった個々のアイテム単位で読み取り (Read) 権限を付与する機能です。共有相手には対象アイテムと、そのレポートが依存する基のセマンティックモデルへの必要最小限のアクセスだけが与えられ、ワークスペース内の他のアイテムは一切見えません。これにより「必要な人に必要なものだけ」を渡す最小権限の原則に最も忠実に沿った共有ができ、外部ユーザーへ単一レポートだけを渡すように範囲を厳密に限定したいケースに最適です。ワークスペースロールは付与するとワークスペース内の全アイテムへ一律に効いてしまうため、この要件には過剰となります。
【他選択肢が違う理由】
- A: Viewer ロールはワークスペース内のすべてのアイテムを閲覧可能にするため、単一レポートだけを渡したい要件に対して付与範囲が広すぎ、最小権限に反します。
- B: Member ロールは閲覧に加えアイテムの共有や再配布まで許可するため、外部ユーザーに与える権限としては過大で最小権限の原則に反します。
- D: テナント管理者ロールは組織全体の設定を管理する最上位権限であり、レポート 1 つの共有手段としてはまったく不適切な重大な過剰付与です。
【参考】
各セキュリティ機能が制御する対象を選択してください。
| ステートメント | 選択 |
|---|---|
|
行レベルセキュリティ (RLS)
|
|
|
オブジェクトレベルセキュリティ (OLS)
|
|
|
列レベルセキュリティ (CLS / 列権限)
|
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| 行レベルセキュリティ (RLS) | 行 |
| オブジェクトレベルセキュリティ (OLS) | テーブル/列の存在 |
| 列レベルセキュリティ (CLS / 列権限) | 列のアクセス |
【ポイント】
「行レベルセキュリティ (RLS)」→ 行: RLS はロールの DAX フィルターでテーブルの行を動的に制限します。「オブジェクトレベルセキュリティ (OLS)」→ テーブル/列の存在: OLS はテーブルや列の存在自体を隠し、メタデータも見せません。「列レベルセキュリティ (CLS / 列権限)」→ 列のアクセス: CLS は GRANT/DENY 等で特定列へのアクセスを制限します。
【参考】
Microsoft Fabric のデータ保護/セキュリティ機能と、その制御対象の対応として正しいものを 3 つ選択してください。
解説
【正解: C / A / D】の理由
RLS = 行のフィルター、OLS = テーブル/列の存在を隠す (メタデータも非表示)、CLS/列権限 = 特定列へのアクセス制限、の 3 つが正しい対応です。感度ラベルはデータ分類/保護ラベルであり行を削除しません。Endorsement は推奨バッジでデータ暗号化機能ではありません。
【他選択肢が違う理由】
- E: 感度ラベルはデータ分類ラベルで、行の自動削除はしません。
- B: Endorsement は推奨/認定バッジで、暗号化機能ではありません。
【参考】
各機能を該当カテゴリにマッチさせてください。
- 情報保護
- OneLake ショートカット
- Workspace Identity
- 感度ラベル
解説
【正解マッチング】
| 項目 | 正しいカテゴリー |
|---|---|
| 感度ラベル | データ保護/分類 |
| Workspace Identity | 外部認証 ID |
| OneLake ショートカット | データ参照 |
| 情報保護 | データ保護/分類 |
【ポイント】
感度ラベル/情報保護=データ保護/分類、Workspace Identity=外部認証 ID、OneLake ショートカット=データ参照です。
【参考】
容量のパフォーマンス問題に対応する一般的な手順を順序通りに並べてください。
- Capacity Metrics アプリで CU 消費/スロットリングを分析
- 必要に応じて SKU スケールアップ/オートスケールを構成
- 最適化 (スケジュール分散/クエリ改善) を実施
- 原因アイテム/操作 (高消費の更新やクエリ) を特定
解説
【正しい順序】
- Capacity Metrics アプリで CU 消費/スロットリングを分析
- 原因アイテム/操作 (高消費の更新やクエリ) を特定
- 最適化 (スケジュール分散/クエリ改善) を実施
- 必要に応じて SKU スケールアップ/オートスケールを構成
【ポイント】
- ステップ 1 Capacity Metrics アプリで CU 消費/スロットリングを分析: まず実態を Metrics アプリで把握します。
- ステップ 2 原因アイテム/操作 (高消費の更新やクエリ) を特定: どのアイテム/操作が消費しているか特定します。
- ステップ 3 最適化 (スケジュール分散/クエリ改善) を実施: 負荷平準化やクエリ改善でまず効率化します。
- ステップ 4 必要に応じて SKU スケールアップ/オートスケールを構成: 最適化後も不足なら容量を拡張します。
【誤った順序の問題点】
- 分析せずいきなり最大 SKU 購入: 原因分析と最適化を経ずのスケールはコスト過大です。
- 原因特定を省略: 原因不明のままでは適切な対処ができません。
