WEB問題集
解説
【正解: A】の理由
Azure Policy はリソースに対するルールベースのガバナンス制御サービスで、Definition / Effects (Deny / Audit / Modify / DeployIfNotExists) / Initiative / Assignment / Compliance Dashboard を提供します。組み込み Policy 200+ で PCI DSS / HIPAA / ISO 27001 等の規制対応を Management Group から継承適用できます。
【他選択肢が違う理由】
- B. 物理ハードウェア管理: Policy はクラウド ガバナンスのソフトウェア機能で物理機器は管理しません
- C. パスワード ポリシーのみ: パスワード ポリシーは Microsoft Entra ID の領域で別サービスです
- D. 廃止された機能: 現役の主力ガバナンス機能で継続的に拡張されています
解説
【正解: A】の理由
Initiative (Policy Set) は複数の Policy を 1 つのコレクションにまとめてガバナンス フレームワーク全体を一括管理する仕組みです。PCI DSS / HIPAA / ISO 27001 / NIST 800-53 / Microsoft Cloud Security Benchmark 等が組み込み Initiative として 50+ 提供され、Initiative 単位でコンプライアンス スコアが算出されます。
【他選択肢が違う理由】
- B. Policy を置き換える代替: Initiative は Policy を束ねる仕組みで個別 Policy を置換するものではありません
- C. 物理サーバ起動シーケンス: 物理機器制御ではなくクラウド ガバナンスの機能です
- D. 廃止された機能: 現役の主力機能で組み込み Initiative も継続追加されています
解説
【正解: A】の理由
Resource Locks は本番リソースの誤削除 / 誤変更を防ぐガバナンス機能です。CanNotDelete は削除のみブロック、ReadOnly は読み取り以外をすべてブロックします。Subscription / RG / 個別リソース単位で適用でき、Owner 権限保持者でも手動でロック解除が必要なため RBAC とは独立した保護レイヤーとして機能します。
【他選択肢が違う理由】
- B. 暗号化キー管理: それは Azure Key Vault の領域で Locks とは別機能です
- C. RBAC の代替: 補完関係にあり RBAC とは別レイヤーのガバナンス機能です
- D. 廃止された機能: 現役の主要機能で本番ガバナンスに必須です
解説
【判定: はい】の理由
Azure Policy の Deny 効果は組み込み Policy「Require a tag on resources」をカスタマイズし、CostCenter / Owner Tag がないリソース作成を ARM レベルで拒否できます。Management Group に割り当てれば配下サブスクリプションに自動継承され、組織全体に一貫したガバナンスが適用されるため要件 1 を完璧に満たします。
【「いいえ」が違う理由】
既存リソースは Modify / DeployIfNotExists 効果で自動修正できビジネス継続性も保たれます。Tag 付与漏れを防ぐことで Cost Management のチャージバックや棚卸し作業が効率化されます。要件 2 / 3 は別 Policy / Lock が必要ですが本解決策は要件 1 を解決し CAF でも最優先の取り組みです。
解説
【判定: はい】の理由
組み込み Policy「Allowed locations」を Japan East / Japan West のみに設定し Management Group / Subscription に割り当てると、他リージョンでのリソース作成は ARM レベルで拒否されます。データ レジデンシー要件 (GDPR / 国内データ法等) や規制対応で特定リージョン配置を強制する典型シナリオで、要件 2 を完璧に満たします。
【「いいえ」が違う理由】
Allowed Locations は組み込み Policy のため設定が簡単で、Initiative に組み込み他要件と一括適用するのが標準です。「Allowed locations for resource groups」も併用するのがベスト プラクティスで、グローバル サービスは除外される点に注意します。要件 3 は別ソリューションが必要ですが本解決策は要件 2 を解決します。
解説
【判定: はい】の理由
Resource Locks の CanNotDelete を Production の重要リソース (SQL DB / Storage / Key Vault / App Gateway 等) に適用すると、読み取り / 変更は通常通り可能でも削除アクションのみが完全にブロックされます。Owner 権限保持者でも「ロック解除 → 削除」の 2 段階が必要で、要件 3 を完璧に満たします。
【「いいえ」が違う理由】
Lock は RBAC と独立した保護レイヤーで、本番 DB / Storage 誤削除事故を防いだ実績があります。より厳格な ReadOnly も適用可能で、Azure Policy の deployIfNotExists で「特定 Tag のリソースに自動 Lock 付与」を実装すればガバナンスを完全自動化できます。3 ソリューションで要件 1-3 を完全カバーします。
解説
【正解: A】の理由
Management Groups は組織のサブスクリプションを最大 6 階層で管理するトップ レベル ガバナンス スコープです。上位に適用した Policy / RBAC / Tag が配下サブスクリプションに自動継承され、Subscription 移動 / Cost Management 集計 / CAF Landing Zone 構築の基盤として機能します。
【他選択肢が違う理由】
- B. 物理サーバ管理: 物理機器ではなくクラウドのサブスクリプション階層を管理します
- C. 個別 VM 管理のみ: VM 単位ではなくサブスクリプション階層を管理する機能です
- D. 廃止された機能: 現役の主力機能で CAF Landing Zone の基盤として必須です
解説
【正解: A, B, C】の理由
Azure ガバナンスの 3 大機能は Azure Policy / Resource Locks / Management Groups です。A はコンプライアンス ルールを Deny / Audit / Modify / DeployIfNotExists 等で強制します。B は CanNotDelete / ReadOnly で本番リソースの誤削除を防ぎ Owner でも手動解除が必要です。C はサブスクリプションを階層化し上位のガバナンスを配下に継承適用します。
【他選択肢が違う理由】
- D. Microsoft Excel: 表計算ソフトで Azure ガバナンス機能ではありません
- E. Microsoft Word: 文書作成ソフトで Azure ガバナンス機能ではありません
次の各ステートメントについて、Azure ガバナンスに関する記述として正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
Azure Policy の Deny 効果は、条件に合致しないリソース作成リクエストを Azure Resource Manager レベルで拒否する。 正しい記述です。Deny は最も強い効果で、Policy 条件に違反するリソース作成 / 更新リクエストを Azure Resource Manager レベルで即時拒否します。監査のみの Audit と異なり、ノンコンプライアンスなリソース作成を未然に防げます。 | ||
Resource Locks の CanNotDelete は Owner ロール権限保持者でも、ロックを解除しなければリソース削除ができない。 正しい記述です。CanNotDelete は RBAC とは独立した保護レイヤーとして機能し、Owner 権限保持者でも「ロック解除 → 削除」の 2 段階が必要です。本番リソースの誤削除事故を防ぐ重要な機能です。 | ||
Azure Management Groups で上位スコープに割り当てた Policy は、配下サブスクリプションには継承されない。 誤った記述です。Management Group に割り当てた Policy / RBAC は配下のすべてのサブスクリプション / リソース グループ / リソースに自動継承されます。これにより組織全体に一貫したガバナンスを実現できます。 |
解説
【正解: A】の理由
RBAC は Azure リソースへの最小権限アクセスを実現する中核セキュリティ機能です。Microsoft Entra ID のユーザー / グループ / SP / マネージド ID に組み込み 100+ またはカスタム ロールを割り当て、MG / Subscription / RG / リソースの 4 階層スコープで制御します。ABAC や PIM と連携し JIT 権限昇格も実現できます。
【他選択肢が違う理由】
- B. 物理サーバ アクセス制御: クラウド リソースへのアクセス制御機能で物理サーバは対象外です
- C. パスワード ポリシー: それは Microsoft Entra ID の領域で RBAC とは別機能です
- D. 廃止された機能: 現役の中核セキュリティ機能で継続的に拡張されています