AZ-900 — Azure の管理とガバナンス：練習問題56問

Step 1: 概念の整理 - Azure の管理階層は一般に、管理グループ > サブスクリプション > リソース グループ > リソースという階層構造をとります。管理グループは複数のサブスクリプションをまとめてガバナンス（Policy、RBAC の継承など）を適用するための単位です。サブスクリプションは課金、クォータ、境界を提供し、その中に複数のリソース グループを持ちます。リソース グループは論理的なコンテナで、同一サブスクリプション内でリソースをグルーピングします。

Step 2: 正しい選択肢の理由付け - 「管理グループは複数のサブスクリプションを階層的にまとめて一括で管理ポリシーを適用できる」はそのまま管理グループの主目的です。これにより上位で定義したポリシーやロールが下位（サブスクリプション、リソース グループ、リソース）に継承されます。次に「サブスクリプションはリソース グループおよびその中にあるリソースを所有し、請求やクォータの境界になる」は、請求単位やクォータ管理がサブスクリプションで行われることを示しており正しいです。

Step 3: 誤答の検討と実務的影響 - 「リソース グループは複数のサブスクリプションを含めることができる」は誤りです。リソース グループはサブスクリプションのスコープ内でのみ作成され、別のサブスクリプションを包含することはできません。もしサブスクリプション間でリソースを整理したい場合は、管理グループやタグ、ポリシーを活用します。また「リソース グループは必ず単一のリージョンにのみリソースを配置しなければならない」も誤りです。リソース グループ自体にリージョンの制約はなく、グループ内のリソースは異なるリージョンに存在して構いません（ただし個々のリソースの移行・冗長構成にはリージョンや依存関係の影響がある点に注意）。Trap: よくある誤解として、リソース グループを物理的なリージョン境界だと考えたり、サブスクリプションとリソース グループの役割を混同することがあります。管理グループはあくまでサブスクリプションをまとめるための「管理上の」階層であり、課金単位やクォータはサブスクリプションが担います。Why each wrong answer fails: 2番（リソース グループは複数のサブスクリプションを含める）は、スコープの誤認で、リソース グループはその作成されたサブスクリプションに属する単一のスコープであり他のサブスクリプションを跨ぐことはできません。4番（リソース グループは単一リージョン制約）は、リソース グループは論理的コンテナであり、内部のリソースが複数リージョンにまたがることが可能であるという点で誤りです。以上の点から正解は 1 と 3 です。

Step 1: 要件確認 — 質問は「Windows 環境で既存の PowerShell スクリプトを使用して Azure リソースの自動化を行いたい」というシナリオです。ここでは PowerShell 環境との互換性と Azure 操作が重要です。

Step 2: ツールの特性分析 — Azure PowerShell は PowerShell 環境向けに提供されるモジュール群（Az モジュール）で、PowerShell コマンドレット（Cmdlet）を使って Azure リソースを作成、構成、管理できます。既存のスクリプト（関数、エラーハンドリング、パイプライン処理）を活かしやすく、Windows 管理者が最も移行しやすい選択肢です。Azure ポータルは GUI で手動操作が中心、ARM テンプレートは宣言的定義でスクリプトとは性質が異なる、Azure ポリシーは準拠性の強制と監査に使うもので自動化スクリプト実行のツールではありません。

Step 3: 結論と運用上の利点 — 既存の PowerShell コード資産を最小限の変更で再利用し、認証（サービスプリンシパルやマネージドID）を組み込んで自動化ジョブに組み込むなら Azure PowerShell が有利です。CI/CD パイプラインやスケジュールされたタスク（Azure Automation など）と連携できます。 Trap: よくある誤解は「ARM テンプレートが自動化の唯一の方法」というものですが、ARM は宣言的なデプロイに適しており、既存の手続き的 PowerShell スクリプトを直接実行するものではありません。 Why each wrong answer fails: - Azure ポータル: GUI ベースで手動操作には向くが、既存の PowerShell スクリプトの自動実行や統合には不向きです。自動化やバージョン管理が難しくなります。 - ARM テンプレート（JSON）: ARM テンプレートはリソースを宣言的に記述してデプロイする IaC（Infrastructure as Code）ツールであり、PowerShell の既存スクリプトのロジック（条件分岐や複雑な処理）をそのまま実行するには適していません。テンプレートは効果的だが用途が異なります。 - Azure ポリシー: Azure ポリシーはガバナンスと準拠性を管理するためのもので、リソースの強制ルールや監査に使いますが、PowerShell スクリプトによる自動化の実行基盤や API を提供するものではありません。

Step 1: 要件把握 — 要求は「複数サブスクリプションにまたがるガバナンスの一元管理」。複数サブスクリプション全体に対して共通のポリシーや RBAC ルールを適用したいというシナリオです。

Step 2: スコープの整理 — マネージメント グループはサブスクリプションを階層的にまとめるための上位スコープで、組織全体のガバナンスを効率良く行うために設計されています。マネージメント グループにポリシーやアクセス権を割り当てれば、その下にあるすべてのサブスクリプションとその配下のリソースに継承されます。サブスクリプションは請求やクォータの単位で、単一サブスクリプション内での管理には有効ですが、複数サブスクリプションにまたがる一括管理には手間がかかります。リソース グループはより粒度の細かいリソース管理の単位です。

Step 3: 結論 — 複数サブスクリプションにまたがるガバナンスを一元的に適用するにはマネージメント グループが最適です。これにより、ポリシー、Blueprint、RBAC の割当てを上位で行い、組織全体で一貫したガバナンスを実現できます。 Trap: よくある誤解は「ポリシーはサブスクリプション単位で問題ないだろう」という考えです。小規模な環境ではそれで済むこともありますが、組織が成長するとサブスクリプションごとに同じポリシーを手作業で適用・維持するのはミスや不整合を招きます。マネージメント グループはスケールと一貫性のための重要な概念です。 Why each wrong answer fails: - リソース グループ（Resource Group）: 誤り。リソース グループはサブスクリプション内のリソースをまとめる単位であり、複数サブスクリプションにまたがるガバナンスを一度に適用するためのスコープではありません。 - サブスクリプション（Subscription）: 誤り。サブスクリプションは請求・クォータ単位でのスコープであり、個別にポリシーを適用することは可能ですが、複数サブスクリプション間で一元管理するためにはマネージメント グループの方が適しています。 - リソース（個別の Resource）: 誤り。個別リソースに直接アクセス制御やポリシーを設定することはできますが、スケールや管理性の観点で非効率です。複数サブスクリプションにまたがる一元管理には不向きです。

Step 1: 要点の整理 Azure Resource Manager（ARM）は、宣言的にリソースの「望ましい状態」を定義する仕組みを提供します。ARM テンプレートは JSON（または Bicep にトランスパイル可能）でリソースの構成を記述し、テンプレートを適用することで Azure にリソースが作成・更新されます。

Step 2: 冪等性と動作の理解 ARM のデプロイは冪等で設計されており、同じテンプレートを繰り返し適用しても、既に望ましい状態にあるリソースを再作成せず最終的に同じ状態になります。これにより、何度デプロイしても環境が予測可能に保たれるという利点があります。

Step 3: 具体的適用と誤解の回避 ARM は手続き的順序のみをサポートするというのは誤りです（テンプレート内で依存関係を宣言することで依存順序は解決されるが、ユーザーが逐次的に一つずつ操作する必要はない）。また、ARM は OS に依存せず、Windows だけでなく Linux や PaaS サービス、ネットワーク等幅広く管理できます。 Trap: よくある誤解 「テンプレートを繰り返すと不都合が起きる」「ARM はスクリプトと同じ扱いで順序通りにしか実行されない」という誤解。ARM は宣言的かつ冪等であるため、デプロイ方法はスクリプト（手続き型）とは概念的に異なります。 Why each wrong answer fails: 1) 宣言型テンプレートでインフラをコード化できる — 正しい。ARM テンプレートによりリソースの望ましい状態を定義できる。 2) ARM は手続き的で冪等性を保証しない — 誤り。ARM は宣言的モデルで、同じテンプレートを何度実行しても最終状態が同じになるよう冪等性を提供する。内部でデプロイ順序を解決するため、ユーザーが逐一順序を管理する必要はない。 3) ARM デプロイは冪等である — 正しい。これにより再実行が安全で、構成の一貫性が保たれる。 4) ARM は Windows のみ対応 — 誤り。ARM は OS 非依存であり、Linux VM、PaaS、ネットワークなど多様なリソースを管理可能。 総括：ARM は宣言的・冪等なデプロイを行うため、インフラをコード化して繰り返し安全にデプロイするユースケースに適している。

Step 1: 要件の整理—質問は「複数のサブスクリプションに対して統一したポリシーやガバナンスを適用」するための『最も上位に位置する概念』を問うています。つまり、サブスクリプションよりも上位でまとめて制御できるスコープが必要です。

Step 2: スコープの階層確認—Azure の管理階層は一般に、ルート(テナント)、管理グループ、サブスクリプション、リソース グループ、リソースという構成です。管理グループは複数のサブスクリプションをまとめるためのネイティブな階層要素であり、上位で Azure Policy や RBAC を適用すると、その下にぶら下がる全てのサブスクリプションに継承されます。

Step 3: 結論—複数サブスクリプションに統一ポリシーを適用したい場合は「管理グループ」を使用してポリシーやアクセス制御を上位で定義・適用します。 Trap: よくある誤解は「サブスクリプションが最上位である」と思い込むことです。サブスクリプションは課金やリソースの境界にはなりますが、複数サブスクリプションを横断してガバナンスを一括適用するには管理グループが必要です。 Why each wrong answer fails: - サブスクリプション: サブスクリプションは課金単位やリソース境界を表しますが、別々のサブスクリプションにわたる統一ポリシーの適用を直接行う上位のスコープではありません。管理グループを使わない場合、各サブスクリプションに個別にポリシーを適用する必要があり、運用負荷が高くなります。 - リソース グループ: リソース グループは同一ライフサイクルやアクセス制御を目的にリソースをグルーピングしますが、サブスクリプションより下位に位置するため、複数サブスクリプションに跨るポリシー適用のスコープにはなりません。 - タグ: タグはリソースにメタデータを付与して分類や請求の集計を容易にする仕組みですが、ポリシーや権限を直接的に上位で一括管理するスコープとは異なります。 まとめると、複数サブスクリプションを横断してポリシーやガバナンスを上位で管理するには管理グループが正解です。

Step 1: ARM テンプレートの本質 ARM テンプレートは JSON/YAML ベースでリソース構成を宣言する仕組みで、どのリソースをどのように作成するかを記述します。宣言型のため「あるべき状態」を定義すると、ARM がその状態になるように必要な操作を実行します。これにより、同一の構成を何度でも再現できます。

Step 2: 適用領域と利点 ARM テンプレートは複数リソース（仮想マシン、ストレージ、ネットワーク、データベース等）をまとめて扱い、依存関係を解決しつつ一貫したデプロイが可能です。バージョン管理、CI/CD との連携、自動化されたテストやレビューを通じて、インフラの信頼性と展開速度が向上します。

Step 3: 実務的なユースケース 例えばステージング環境や本番環境を同じ構成で複数作成する、または災害復旧時に同一構成を迅速に再構築する場合に有効です。テンプレートはパラメーター化して環境ごとの差分を吸収できるため、運用効率が高まります。 Trap: よくある誤解 ARM テンプレートをモニタリングや課金レポートのためのツールだと捉える誤解がありますが、それらは別のサービス（Monitor、Cost Management）が担当します。ARM テンプレートはあくまでリソースの定義とデプロイに特化しています。 Why each wrong answer fails: - 単発の GUI 操作でのみ作成される一時的なリソース: GUI 操作で一度だけ設定する一時的なリソースにはテンプレートの導入コストが割に合わないことがあります。ARM テンプレートは再現性や自動化を重視する場合に有効なので、このケースは不適切です。 - ネットワーク経路のリアルタイム監視: これは Azure Monitor や Network Watcher の役割であり、ARM テンプレートは監視やリアルタイム分析を行いません。 - 課金レポートの自動生成: 課金情報の集計やレポート作成は Cost Management や Billing API の領域で、ARM テンプレートはインフラ定義のためのツールであるため適していません。 - 複数のリソースを宣言的に定義して再現可能にデプロイするインフラストラクチャ: 正解です。ARM テンプレートはこの用途に最も適しており、IaC（Infrastructure as Code）を実現する標準的な手段です。

Step 1: 要件の洗い出し — 要件は「複数サブスクリプションに跨る共通アクセスの委任」と「一部サブスクリプションでの例外的な異なる権限付与」を同時に満たすことです。これは中央での一括管理と部分的な例外管理の両立が必要になります。

Step 2: 管理グループと RBAC の適用モデル — 管理グループは複数サブスクリプションをまとめ、RBAC（Azure のロールベースアクセス制御）やポリシーを上位スコープで適用できます。管理グループに付与されたロールはその下位に継承されますが、下位スコープ（サブスクリプションやリソース グループ、個別リソース）で明示的に異なるロールを割り当てれば上位の割り当てを“上書き”ないし調整することができます。これにより一元管理と例外対応が両立します。

Step 3: 実装の流れと注意点 — まず管理グループ階層を設計し、共通のアクセス権を管理グループに割り当てます。次に例外とするサブスクリプションに移動して、そのサブスクリプションで必要な補足または限定的なロールを割り当てます。注意点として、RBAC の継承と上書きの挙動（最も具体的なスコープの割り当てが優先される点）を理解しておくこと、そして不要な昇格（余計な広範な権限付与）が起きないように最小権限の原則を徹底することが重要です。 Trap: よくある誤解は「テナントレベルで割り当てればすべて解決する」という考えや「上位で割り当てたら下位では絶対に変更できない」と思うことです。テナント（Azure AD）自体はディレクトリのアイデンティティ管理をする場所であり、リソースへの直接的な RBAC 適用のスコープとは異なります。また、RBAC はより具体的なスコープでの割り当てが優先されるため、下位での調整は可能です。 Why each wrong answer fails: - 選択肢1（テナントレベルで直接割り当て）: テナント（Azure AD）レベルはディレクトリの管理単位であり、リソース側の RBAC は通常管理グループやサブスクリプション等のスコープで行います。テナントでの割り当ては一部の Azure AD 管理操作には有効ですが、リソースへのアクセス管理をテナント単位で一括制御するのは誤ったアプローチです。 - 選択肢3（各リソース グループに手動で割り当て）: 要件を満たすことは可能ですが、運用コストが高く人的ミスが増えます。大量のサブスクリプションやリソース グループがある組織では非効率的です。 - 選択肢4（各リソースに個別割り当て）: 最も細かい粒度の制御ですが、管理負荷が極めて高く、スケーラブルではありません。共通のアクセス権を一括で管理できないため大規模環境には向きません。 総括すると、管理グループで共通の RBAC を割り当て、例外だけサブスクリプションで上書きする設計が最も実務的かつ拡張性のある方法です。

Step 1: 基本的な機能差の把握 Azure CLI はコマンド名とフラグを持つシェルスタイルのインターフェースで、Bash やシェルスクリプトに組み込みやすく、コンテナや CI/CD パイプラインで広く利用されます。対して Azure PowerShell は PowerShell のコマンドレット（Cmdlet）を用い、.NET オブジェクトを返すことでパイプライン処理やオブジェクト操作が得意です。

Step 2: 利用者とユースケース 一般に Linux/コンテナ/DevOps 環境では Azure CLI の方が自然に感じられることが多く、Windows 管理者や既存の PowerShell スクリプト資産を活かしたい場合は Azure PowerShell が適しています。ただし近年はどちらもクロスプラットフォームに対応しており、好みや既存環境で選ばれます。

Step 3: 運用上の判断 組織では両方をサポートするポリシーを持ち、用途に応じて使い分けるのが現実的です。自動化パイプラインの標準化、スクリプトの保守性、チームスキルを考慮して選択してください。 Trap: 多くの人が「CLI は Linux 専用」「PowerShell は Windows 専用」と誤解しますが、現在どちらもクロスプラットフォームで動作します。真の違いはコマンド体系と出力形式です。 Why each wrong answer fails: 1) Azure CLI は主に Linux や macOS のシェルスタイル（Bash）に馴染むコマンド構文を持ち、コンテナや DevOps 環境でよく使われる — 正しい。CLI の設計思想とユースケースを正確に表しています。 2) Azure PowerShell は PowerShell のコマンドレットを利用し、オブジェクト指向の出力（.NET オブジェクト）を扱うことで Windows 管理者に馴染みやすい — 正しい。PowerShell の出力はオブジェクトであり、より複雑なデータ処理に向きます。 3) Azure CLI は GUI を提供し、Azure ポータルと同等の視覚的ダッシュボードを構築できる — 誤り。CLI はコマンドラインツールであり GUI を提供しません。ダッシュボードはポータルや別の可視化ツールで作成します。 4) Azure PowerShell は Windows 以外では一切動作せず、macOS や Linux では使用できない — 誤り。PowerShell Core はクロスプラットフォームであり、macOS や Linux でも動作します。

Step 1: Azure Policy は特定のリソースタイプやプロパティ（たとえば許可されるリージョン、SKU、タグの有無など）を強制するための機能で、ポリシーは階層的なスコープに割り当てることができます。割り当て可能なスコープは管理グループ、サブスクリプション、リソース グループ、あるいは個々のリソースです。スコープが上位であるほど、その下位にある項目すべてへポリシーが継承されます。

Step 2: 組織内の「すべてのサブスクリプション」に対して一括で同じ制約（たとえば特定リージョンでの展開禁止）を適用したい場合、最上位の管理グループ（あるいは適切な上位管理グループ）にポリシーを割り当てるのが効率的です。これにより、管理グループ配下の全サブスクリプションおよびその配下のリソース グループ、リソースに対してポリシーが自動的に継承されます。

Step 3: 実運用では、管理グループを用いて組織の組織構造や責任分担に応じたポリシーの適用を行います。たとえば、本番サブスクリプション群には厳格なポリシーを、開発サブスクリプション群には別のポリシーを適用する、といった具合です。管理グループ設計とポリシー設計を連携させ、例外管理を委譲可能にしておくとガバナンス運用が容易になります。 Trap: よくある誤解は「サブスクリプション単位でポリシーを割り当てれば十分だろう」という点です。サブスクリプションごとに個別で同じポリシーを設定することは可能ですが、大規模組織では煩雑になり、設定漏れや管理工数増加のリスクを招きます。管理グループを使って上位で統一的に制御することが推奨されます。 Why each wrong answer fails: - リソース単位（個々のリソース）にポリシーを割り当てる（誤り）: 個々のリソースにポリシーを割り当てると粒度は高いものの、組織内の全サブスクリプションに対して一貫した制御を行うには非現実的であり、管理コストが非常に高くなります。 - リソース グループ単位にポリシーを割り当てる（誤り）: リソース グループ単位だとサブスクリプション間での横断的な一括制御ができません。各サブスクリプション内の多くのリソース グループに対して個別に設定する必要が生じます。 - サブスクリプション単位にポリシーを割り当てる（誤り）: サブスクリプション単位で割り当てることは可能ですが、組織にサブスクリプションが多数ある場合、すべてに同じポリシーを割り当てる作業が必要になり、運用面でのミスや負荷が増えます。管理グループを利用すると一度の割り当てで下位すべてに適用できます。 - 管理グループにポリシーを割り当てる（正解）: 管理グループは複数サブスクリプションをまとめるスコープであり、ここにポリシーを割り当てることで配下のサブスクリプション全体に一貫した制御を適用できます。 このため、複数サブスクリプションにまたがるガバナンス要件（たとえばリージョン制限）を実現する際は、管理グループと Azure Policy を組み合わせることがベストプラクティスです。

Step 1: 要件の明確化 — 要求は「複数リソースをまとめてライフサイクル（デプロイ・更新・削除）を一括管理」すること。つまり、同じライフサイクルを共有するリソース群を論理的に結びつけたい場面を想定します。

Step 2: 各スコープの役割確認 — リソース グループは同じライフサイクルを持つリソースをまとめるための基本的な論理コンテナーで、ARM を通じて一括デプロイや一括削除が可能です。サブスクリプションは課金とクォータのスコープであり、複数のリソース グループを包含します。マネージメント グループは複数サブスクリプションを階層的にまとめ、ポリシーやガバナンスを上位で適用するためのスコープです。タグはリソースにメタデータを付与して整理・検索する目的で、ライフサイクル管理のコンテナーではありません。

Step 3: 結論 — ライフサイクルを揃えて一括管理するにはリソース グループが最適です。ARM テンプレートやポータル、CLI/PowerShell を用いてリソース グループ単位でデプロイや削除、ロール割当てができます。 Trap: よくある間違いは「サブスクリプションやマネージメント グループで一括管理すれば良い」と考えることです。サブスクリプション／マネージメント グループはガバナンスや請求のスコープ管理には有効ですが、リソースのライフサイクル単位での細やかなデプロイや削除操作のためにはリソース グループが適切です。 Why each wrong answer fails: - サブスクリプション（Subscription）: 誤り。サブスクリプションは請求、課金、クォータのスコープを定義するための単位で、複数のリソース グループを包含します。ライフサイクルを揃えた細粒度のデプロイ/削除には向いていません。 - マネージメント グループ（Management Group）: 誤り。マネージメント グループは複数サブスクリプションをまとめてポリシーやガバナンスを一括適用するための上位スコープです。個別リソースのライフサイクル（デプロイ/削除）管理のためのコンテナーではありません。 - タグ（Tag）: 誤り。タグはリソースにキー/バリューのメタデータを付与して分類や検索を行う機能であり、リソースのライフサイクルをまとめて管理するコンテナーとしての機能は持ちません。タグ付けは補助的な整理手段です。

Step 1: Azure Resource Manager（ARM）はリソースとリソース グループを階層的に管理します。リソース グループは論理的なコンテナーであり、その中に仮想マシン、ストレージ アカウント、ネットワークなどのリソースが属します。ARM が提供する操作の一つに「リソース グループの削除」があり、これはそのコンテナーとコンテナー内の全リソースのライフサイクルをまとめて管理するための操作です。

Step 2: リソース グループの削除を実行すると、Azure はそのグループに含まれる各リソースに対して削除操作を順次実行し、最終的にリソース グループそのものを削除します。これにより、関連するすべてのリソースが完全に削除され、一貫した状態が保たれます。テンプレートやスクリプトでリソース グループに含まれるものを一括でクリーンアップしたい場合、この動作が有用です。

Step 3: 実務上の注意点として、削除は取り消せない場合が多く、特に課金やデータ保管に影響します。必要なバックアップやエクスポートを事前に行う運用手順を作成すること、また誤削除防止のために管理者向けのアクセス制御（RBAC）や管理用プロセス（例：承認フロー）を整備することが重要です。 Trap: よくある誤解として「リソースはグループだけ削除され、リソース自体は残るだろう」と考えるケースがあります。しかし実際にはリソース グループの削除はその中のすべてのリソースの削除を伴います。特にストレージや DB のデータが失われる点を見落としがちです。 Why each wrong answer fails: - リソース グループ内のすべてのリソースは削除される（正解）: ARM の設計どおり、グループとその中のリソースがまとめて削除されます。 - リソースはそのまま残り、グループから切り離される（誤り）: リソースはグループの論理的なコンテナーに紐づいており、グループ削除時に残存するようには設計されていません。残す場合は個別に別のグループへ移動する操作を事前に行う必要があります。 - リソースは別の既存のリソース グループに自動的に移動される（誤り）: 自動移動は行われません。移動を行うには明示的に move 操作（移動 API やポータル操作）を実行する必要があります。また、リソースの種類や状態によっては移動が制限されることもあります。 - リソースは一時的にアーカイブされ、後で復元できる（誤り）: Azure はリソース グループ削除時に自動アーカイブは行いません。復元が必要ならば、事前にスナップショットやバックアップ、エクスポートを取っておく必要があります。 このため、リソース グループを削除する際はデータ損失と課金停止の影響を十分に評価し、必要な保護措置を講じることがベストプラクティスです。

Step 1: 要件を分解すると「タグを必須にすること」と「許可されていないリージョンでのリソース作成を拒否すること」の2つがある。これらはリソースの構成や作成ルールに関するポリシー的な制御であり、リアルタイムのガバナンスと準拠性を提供する機能が必要。

Step 2: Azure Policyはリソースの作成・更新時にルールを適用して、準拠していない操作を拒否（deny）したり、準拠させるために自動的に修正（deployIfNotExistsやmodify）を行ったり、単に監査（audit）することができる。タグの必須化や許容リージョンのホワイトリスト化はPolicyの典型的なユースケースであり、ポリシー定義で「effect」をdenyに設定すれば非準拠な作成をブロックできる。

Step 3: 実運用では、ポリシーを管理グループやサブスクリプションレベルに割り当てて一元管理し、定期的に準拠性レポートを確認することでガバナンスを維持する。必要に応じてAzure Blueprintsを使って複数のポリシーやRBACなどをテンプレート化できるが、個々のルール実行はPolicyが担当する。 Trap: よくある誤解は「RBACでタグやリージョンの制限もできる」と考えること。RBACは誰が何を実行できるか（Who, What）を制御するが、リソースの中身（タグやリージョンなどの構成）を検査・強制する機能は持たない。従ってガバナンス目的の構成制約にはAzure Policyを使うのが正しい。 Why each wrong answer fails: - Azure RBAC（選択肢1）: RBACはアクセス許可（例: 仮想マシンの起動や停止）を管理するための仕組みで、リソース作成時の属性（タグの有無やリージョン）を拒否・強制する機能は提供しない。したがって今回の「タグ必須化」「特定リージョンの拒否」といった構成制約を実現できない。 - Azure Blueprints（選択肢3）: Blueprintsはポリシー、RBAC、ARMテンプレート等をまとめて再利用可能なデプロイメントパッケージとして提供するツールで、組織全体のセットアップを迅速に行える。しかしBluePrint自体はルールを直接適用してリソース作成を拒否するエンジンではなく、内部でAzure Policyを割り当てることが多いため、直接の実行主体はAzure Policyである。 - 管理グループ（選択肢4）: 管理グループは複数サブスクリプションを階層的に整理し、そこに対してポリシーやRBACを一括で適用できるスコープを提供するための概念的なコンテナに過ぎない。ポリシーを適用するスコープを提供する点では関連するが、実際の「タグの必須化」「リージョン制限」を実行するのはAzure Policyである。 結論：タグ必須化とリージョン拒否を自動的に行いたい場合、Azure Policyを使用してポリシー定義を作成・割り当てし、必要に応じてdeny効果を設定するのが正解である。