A subscription Contributor opened the lock-lab Key Vault and added themselves Get, List, and Set through an access policy. Why does Microsoft recommend Azure RBAC over access policies for this risk, and what is the mitigation direction?
Select an answer to reveal the explanation.
Short Explanation
With access policies, vault write is basically “make yourself a keyholder.” That’s why Microsoft steers you to Azure RBAC and skinny control-plane roles—so Contributor can’t quietly mint Get/List/Set for themselves.
Full Explanation
Under the access-policy permission model, a principal with Microsoft.KeyVault/vaults/write can update the vault resource—including access policies—and grant themselves Get, List, and Set on secrets. That control-plane-to-data-plane self-elevation is why Microsoft recommends Azure RBAC for Key Vault with tightly scoped control-plane roles: data-plane rights become separate role assignments that Contributor alone should not mint by rewriting vault policies. Prefer migrating the lock-lab vault to Azure RBAC and minimizing who holds vault write.
Claiming access policies cannot be changed by anyone with vault write fails by concept—that write permission is exactly how the contractor self-granted. Claiming only Security Copilot can detect Contributor self-grants fails because detection tooling is not the documented primary mitigation; permission-model and RBAC design are. Moving secrets into App Configuration fails because App Configuration is not a drop-in replacement for Key Vault secret authorization controls and does not eliminate the need for proper secret RBAC.
Exam caveat: subscription Contributor often includes vault write—do not equate “not Key Vault Admin” with inability to edit access policies. Operational check: review activity logs for vault write and access-policy changes, migrate the vault to Azure RBAC, remove broad self-serve policy edit paths, assign Key Vault Secrets User (or tighter) only where needed, and confirm Contributor can no longer add themselves via access policies.