ある企業が本番環境のリソースグループに対してリソースロックを適用しようとしている。重要なデータベースサーバーを誰も誤って削除できないようにしたいが、構成の読み取りや更新（設定変更）は引き続き許可したい。最も適切なリソースロックの種類はどれか。
- A. CanNotDelete ポリシーを Azure Policy で作成して割り当てる
- B. ReadOnly ロックを適用する：読み取りのみ許可し、すべての書き込み操作を拒否する
- C. Delete ロックを適用する：削除操作のみを拒否し、読み取りや更新は引き続き許可する
- D. ロックは不要で、RBAC の「共同作成者」ロールから削除権限だけを除外したカスタムロールを作成する
解答と解説を見る
正解: C
Azure リソースロックには「Delete（CanNotDelete）」と「ReadOnly」の 2 種類がある。Delete ロックはリソースの削除のみを禁止し、読み取りや設定変更（書き込み）は引き続き許可する。要件は「削除禁止かつ更新は許可」であるため Delete ロックが正解。選択肢Bの ReadOnly ロックは読み取りのみ許可し、更新・削除の両方の書き込み操作をブロックするため、設定変更も禁止されてしまい要件を満たさない。選択肢Aの「CanNotDelete ポリシー」という Azure Policy 組み込み定義は存在せず、リソースロックは Policy とは別の仕組みである。選択肢DはカスタムRBACロールでも削除権限を除外できるが、リソースオーナーは既存の Owner ロールで削除できてしまうため、ロックの方が確実に上書きされた制御となる。リソースロックは RBAC よりも優先されるため、オーナーであっても削除できなくなる。