ある企業が本番環境のリソースグループに ReadOnly リソースロックを適用している。運用チームが、このリソースグループ内のストレージアカウントのアクセスキーをローテーションしようとしたところ、操作が失敗した。失敗の原因として最も適切な説明はどれか。
- A. ReadOnly ロックはリソースグループへの新規リソース追加のみをブロックし、既存リソースへの操作は影響しない
- B. ReadOnly ロックはリソースの読み取りのみを許可するためキーローテーション（書き込み操作）が拒否された
- C. ストレージアカウントのキーローテーション操作は Azure Key Vault を経由しないと実行できない
- D. アクセスキーのローテーションはロックとは独立した操作のため、RBAC 権限不足が原因である
解答と解説を見る
正解: B
Azure ReadOnly ロックを適用すると、スコープ内のリソースに対してすべての書き込み操作（PUT, PATCH, DELETE）が拒否される。ストレージアカウントのアクセスキーローテーション（regenerateKey アクション）はPOST リクエストを含む書き込み操作として扱われるため、ReadOnly ロックによって拒否される。これは RBAC 権限が十分にある場合でも同様で、ロックは RBAC の上位に位置する制御機構であり、オーナーロールを持っていても ReadOnly ロック下での書き込みはできない。選択肢Aは誤りで、ReadOnly ロックは新規追加だけでなく既存リソースへの書き込み操作もブロックする。選択肢Dは RBAC ではなくロックが原因であるため誤り。選択肢Cは Key Vault 経由の要件は存在せず、キーローテーションは直接可能だがロックが妨げている。