An engineer flips the lock-lab Key Vault permission model to Azure role-based access control and every application immediately loses secret access. What order should the security engineer have followed?
Select an answer to reveal the explanation.
Short Explanation
Seat the RBAC roles first, then flip the permission model—don’t cut over cold. After apps can still Get secrets, sweep the leftover access policies off the vault.
Full Explanation
Changing a Key Vault permission model from access policies to Azure RBAC immediately stops access-policy evaluation for the data plane. The correct cutover order is to assign the required data-plane Azure RBAC roles to every application and operator identity first, flip the permission model, validate secret Get, then remove leftover access policies. Seating RBAC before the flip avoids a cold cutover where every lock-lab app loses access at once.
Changing the permission model first and then inventing custom access policies that stack on RBAC fails by concept: after the flip, access policies no longer authorize the data plane and do not stack. Disabling Microsoft Entra ID tenant-wide so apps fall back to access keys in code fails identity architecture and is not a Key Vault migration step. Deleting the vault and recreating it as Standard SKU without assigning roles fails availability and still leaves apps unauthorized under RBAC.
Exam caveat: the permission-model change is instantaneous for authorization behavior—treat it like a breaking config change with a pre-staged role inventory. Operational check: export current access-policy principals and permissions, map them to Azure RBAC data-plane roles, assign those roles, flip the model in a maintenance window, verify each canal app, then delete obsolete access policies.