A lock-lab Key Vault still shows vault access policies, and an engineer also assigned Key Vault Secrets Officer through Azure RBAC. How should the security engineer treat the permission models?
Select an answer to reveal the explanation.
Short Explanation
Pick a lane: access policies or Azure RBAC for the data plane—not both at once. Flip the vault’s permission model to the one you want and stop mixing the dials.
Full Explanation
A Key Vault data plane is authorized with either the vault access-policy model or Azure RBAC for Key Vault, controlled by the vault’s permission model setting. The models do not stack: enabling Azure RBAC means access policies are no longer the authorization path for data-plane operations, and vice versa. If the lock-lab vault still shows access policies while someone also assigned Key Vault Secrets Officer, the security engineer must pick one model, switch the vault accordingly, and stop mixing expectations.
Keeping both models enabled so permissions always add together fails by concept—Microsoft documents mutual exclusivity for the data-plane permission model. Deleting Azure RBAC entirely because access policies are “the only supported model” fails because Azure RBAC for Key Vault is a first-class, recommended model on current vaults. Assigning only subscription Reader and assuming either model will authorize secret Get fails because Reader lacks Key Vault data-plane secret permissions under RBAC and is not an access-policy grant.
Exam caveat: after switching models, existing callers break until the matching grants exist—model flip is a cutover event. Operational check: inventory required Get/List/Unwrap principals, assign the matching Azure RBAC data-plane roles (or access policies if staying on that model), change the permission model once, then verify each canal app still retrieves secrets and that the unused model is not relied upon.