The lock-lab app managed identity only needs to read one secret from Key Vault. Which assignment follows least privilege?
Select an answer to reveal the explanation.
Short Explanation
The app just needs to read a secret—hand it Key Vault Secrets User, not the Contributor badge that rewires the vault. Keep management keys away from the workload identity.
Full Explanation
Least privilege for a lock-lab app managed identity that only reads one secret is a data-plane role such as Key Vault Secrets User at vault or, better, secret scope. That role authorizes secret Get/List without granting control-plane rights to change networking, firewall, or the permission model. Workload identities should hold the minimum data-plane permission required for runtime reads.
Key Vault Contributor on the vault fails by concept because Contributor is a management role that can alter vault configuration, not a least-privilege secret-read grant. Owner on the resource group fails even more broadly: it authorizes nearly all resource actions in the group, far beyond reading one secret. User Access Administrator on the subscription fails because it enables creating arbitrary role assignments estate-wide—privilege to escalate rather than to read a secret.
Exam caveat: AZ-500 distinguishes Key Vault data-plane roles (Secrets User, Crypto User, etc.) from control-plane roles (Contributor, Key Vault Contributor). Operational check: assign Key Vault Secrets User to the managed identity at the secret or vault scope, remove Contributor/Owner if present on that identity, restart the app, confirm secret Get succeeds, and confirm the identity cannot update vault network settings.