第4章 · セキュリティ運用の管理·v2.0.0·更新 2026/6/28·読了目安 約9分
変更要約: AZ-500 第4章を深掘り（図ja化・比較表/シナリオ/FAQ/ひっかけ/深掘り段落を全節に追加）
4.3ガバナンスとコンプライアンス
この節の要点
組織のルールを技術的に強制する Azure Policy、設定の雛形をまとめて適用する Azure Blueprints（※非推奨で 2026 年 7 月に廃止予定。後継は Azure Deployment Stacks＋Azure Policy）、規制基準への適合を可視化する Defender for Cloud の 規制コンプライアンス を理解します。大規模環境を一貫して安全に保ちます。
大規模な環境では「人手のチェック」では一貫性を保てません。Azure Policy でルールを技術的に強制し、コンプライアンス状態を継続的に評価します。
4.3.1ガバナンスの仕組み
- Azure Policy：ルールを定義しスコープに割り当て、準拠/非準拠を継続評価する。
- effect：deny（非準拠の作成を拒否）・audit（記録のみ）・deployIfNotExists（自動修復）など。
- イニシアチブ：複数ポリシーを束ねた集合。基準（例: ISO/PCI）への対応をまとめて割り当てる。
- Blueprints / 規制コンプライアンス：設定の雛形をまとめて展開し、Defender for Cloud で基準への適合を可視化する。
試験ポイント
「ルールを技術的に強制＝Azure Policy」「非準拠の作成を拒否＝deny effect」「記録のみ＝audit」「自動修復＝deployIfNotExists」「複数ポリシーの束＝イニシアチブ」「基準への適合を可視化＝Defender for Cloud の規制コンプライアンス」 は AZ-500 で頻出です。RBAC が「誰が何を」なら、Policy は「リソースがどうあるべきか」を強制します。