Which Key Vault RBAC role grants get, list, wrap, and unwrap?
You have an Azure subscription that contains a managed identity named Identity1 and the Azure key vaults shown in the following table.
KeyVault1 contains an access policy that grants Identity1 the following key permissions:
• Get
• List
• Wrap
• Unwrap
You need to provide Identity1 with the same permissions for KeyVault2. The solution must use the principle of least privilege.
Which role should you assign to Identity1?
Community Insight
It tests translating Key Vault vault access-policy permissions into Azure RBAC data actions; the trap is assuming List is missing from the keys/read action or choosing Crypto Officer to cover all four operations.
This SC-500 question maps Key Vault access-policy key permissions (Get, List, Wrap, Unwrap) to the least-privileged Azure RBAC role for a managed identity on a second key vault. The correct role is Key Vault Crypto Service Encryption User (C), which grants key read (get/list) plus wrap and unwrap without broader crypto or management rights.
Most candidates pick Key Vault Crypto User or Crypto Officer because they assume the specialized Crypto Service Encryption User role lacks List; in Key Vault RBAC, keys/read covers both Get and List, so the specialized role is least privilege.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Key Vault Crypto Service Encryption User contains the data actions Microsoft.KeyVault/vaults/keys/read, Microsoft.KeyVault/vaults/keys/wrap/action, and Microsoft.KeyVault/vaults/keys/unwrap/action. In the Key Vault RBAC model, keys/read represents both Get and List key metadata, while wrap and unwrap are the exact cryptographic operations required. This role therefore reproduces the four access-policy permissions on KeyVault2 without adding update, delete, sign, encrypt, decrypt, or permission-management capabilities. That makes it the least-privileged built-in role among the choices.Why the Other Options Are Wrong
Key Vault Reader can read metadata but does not grant wrap or unwrap, so it cannot satisfy the cryptographic requirement. Key Vault Crypto User does include the required operations, but it also grants extra crypto actions such as encrypt, decrypt, sign, and verify plus update, backup/restore, and purge, making it broader than necessary. Key Vault Crypto Officer is even broader because it allows full key management, including create, import, delete, and update operations. Craigg's comment that "Only Officer can do all 4 takes" is a common misreading of how keys/read maps to both Get and List.Community Comment Notes
The single supplied comment, from Craigg, argues for Key Vault Crypto Officer and says the encryption role "does not grant list permissions." That overlooks the RBAC mapping: Microsoft.KeyVault/vaults/keys/read covers both get and list in Key Vault. Craigg's point that Crypto Service Encryption User is a specialized role does not change its permission set; the question asks for equivalent key permissions, not a human operator role.Official Reference
Exam Strategy
When an access policy lists Get and List, remember that RBAC's keys/read data action covers both; do not look for a separate List action. Choose the narrowest built-in role whose data actions are a superset of the required operations, and reject roles that add cryptographic or management actions.
Frequently Asked Questions
Why is Key Vault Crypto User not the least-privileged choice?
It also grants encrypt, decrypt, sign, verify, update, backup/restore, and purge key actions, which exceed the Get, List, Wrap, Unwrap set.
Does Key Vault Crypto Service Encryption User include the List permission?
Yes. The Microsoft.KeyVault/vaults/keys/read data action covers both Get and List key metadata in the Key Vault RBAC model.
Related Analysis
Practice All SC-500 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SC-500 Practice Test →