AZ-900：Microsoft Azure Fundamentals Azure の管理とガバナンス 問3
Azure の管理とガバナンス／ガバナンスとコンプライアンス開発チームには引き続きリソースの作成・更新権限を残したまま、サブスクリプション内で許可されていないSKUのストレージアカウントが新規に作成されようとした場合には、そのデプロイ自体を拒否したい。実現方法として適切なものはどれか。
当サイトのオリジナル問題（AZ-900：Microsoft Azure Fundamentalsの出題範囲「Azure の管理とガバナンス」に対応。実際の試験問題ではありません）
- A許可されたSKUのみを許可する定義を作成し、Deny効果でサブスクリプションにAzure Policyとして割り当てる。
- B開発チームに割り当てているロールをContributorからReaderに変更する。
- C対象のサブスクリプションにReadOnlyのリソースロックを設定する。
- D対象のリソースグループにCanNotDeleteのリソースロックを設定する。
正解：A
解説
特定の条件（許可されたSKU以外など）を満たさないリソースのデプロイそのものを拒否するには、該当する条件を定義したAzure Policyをdeny効果で割り当てます。RBACのロール変更はユーザーの操作権限全体を制御するもので、Readerに変更すると作成・更新自体ができなくなり「権限は残したまま」という要件に反します。リソースロックは既存リソースの削除や変更を防ぐ仕組みであり、新規作成時の条件（SKUの種類など）を制御するものではありません。
選択肢ごとの解説
- A正しい。許可されたSKU以外を拒否する条件をAzure PolicyのDeny効果として割り当てることで、権限を残したまま条件に合わないデプロイを拒否できます。
- B誤り。Readerロールに変更すると作成・更新自体ができなくなり、開発チームに作成権限を残すという要件に反します。
- C誤り。ReadOnlyロックはそのスコープ内の新規リソース作成（コントロールプレーン操作）もブロックするため、SKUなど条件に基づくデプロイ制御ができないだけでなく、許可されたSKUであっても作成自体ができなくなり、開発チームに作成権限を残すという要件にも反します。
- D誤り。CanNotDeleteロックは削除を防ぐだけの仕組みで、新規作成されるリソースのSKU条件を制御するものではありません。