Help desk needs Get on only the Key Vault secret named lock-operator-pin. Which approach provides that object-level scope?
Select an answer to reveal the explanation.
Short Explanation
Access policies are whole-vault guest lists. If help desk should touch only lock-operator-pin, use Azure RBAC scoped to that one secret object and leave the rest alone.
Full Explanation
Vault access policies authorize principals across secret permissions at vault scope; they cannot scope Get to a single named secret such as lock-operator-pin. Object-level least privilege for help desk therefore requires Azure RBAC data-plane roles assigned at the individual secret resource scope. That is the supported way to let help desk retrieve one PIN secret without listing every other canal secret in the vault.
Adding a vault access policy that lists every secret name help desk might need fails by concept: access policies do not provide per-secret ACL entries in that manner—they grant secret permissions for the vault’s secrets broadly. Assigning Key Vault Contributor at the subscription fails because it is a wide control-plane role across vaults, not object-scoped Get. Storing the PIN in a publicly readable blob fails confidentiality and bypasses Key Vault auditing and authorization.
Exam caveat: per-secret RBAC requires the Azure RBAC permission model on the vault—access-policy mode cannot express that scope. Operational check: switch or confirm Azure RBAC permission model, assign Key Vault Secrets User (or equivalent) on the lock-operator-pin secret only, verify help desk Get succeeds on that secret and fails on a sibling secret, and remove any vault-wide secret grants for that group.