This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Secure secrets and keys by using Azure Key Vault
      --> Configure access to Key Vault

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Azure Key Vault is a foundational security service for protecting secrets, cryptographic keys, and certificates used by cloud applications, infrastructure, and AI workloads. For the SC-500 exam, it is important to understand not only who can access Key Vault, but also how authentication works, how authorization is configured, the difference between the control plane and data plane, and how Azure RBAC compares with legacy access policies.

Important current-state note: Azure RBAC is now the recommended authorization model for Key Vault data-plane access. Microsoft documentation states that, beginning with API version 2026-02-01, Azure RBAC is the default access-control model for newly created Key Vaults. Legacy Key Vault access policies remain relevant because you may encounter existing vaults configured with them.

1. What Does “Configure Access to Key Vault” Mean?

Configuring access to Azure Key Vault involves controlling which identities can perform which operations against:

• Secrets
• Keys
• Certificates

It also involves controlling who can administer the Key Vault resource itself.

A key concept for the SC-500 exam is that Key Vault has two distinct security planes:

Both planes use Microsoft Entra ID for authentication, but authorization is handled differently depending on the plane and Key Vault’s configured permission model.

Exam Tip

Think of the distinction this way:

Control plane = manage the vault.
Data plane = use what is inside the vault.

A user having permission to manage a Key Vault does not automatically mean that the user should be able to read its secrets.

2. Authentication vs. Authorization

These two concepts are frequently tested together.

Authentication

Authentication answers:

Who are you?

Azure Key Vault uses Microsoft Entra ID to authenticate users, applications, service principals, and managed identities.

Examples include:

• User authentication
• Service principals
• Managed identities
• Other supported Microsoft Entra authentication methods

Authorization

Authorization answers:

What are you allowed to do?

After the caller is authenticated, Azure determines whether that identity has permission to perform the requested operation.

For example:

Application
    │
    │ Authenticate
    ▼
Microsoft Entra ID
    │
    │ Access token
    ▼
Azure Key Vault
    │
    │ Authorize
    ▼
Can the identity perform this operation?

The distinction is critical.

An application can successfully authenticate to Microsoft Entra ID and still receive an authorization failure from Key Vault because it does not have the required permissions.

3. Use Managed Identities Whenever Possible

For Azure-hosted applications, managed identities are one of the preferred ways to authenticate to Key Vault.

Instead of storing a client secret or password in application configuration, an Azure resource can obtain a Microsoft Entra token using its managed identity.

For example:

Azure App Service
      │
      │ Managed Identity
      ▼
Microsoft Entra ID
      │
      │ Token
      ▼
Azure Key Vault
      │
      ▼
Secret

This eliminates the need for developers to store credentials for the Key Vault connection.

Microsoft’s current Key Vault security guidance recommends using managed identities for application and service connections where appropriate.

Why This Is More Secure

Hard-coded credentials introduce several risks:

• Credentials can accidentally be committed to source control.
• Secrets can appear in configuration files.
• Credentials need to be rotated.
• Developers may copy credentials between environments.
• Compromised credentials can be reused elsewhere.

Managed identities reduce these risks because Azure manages the identity’s credentials.

4. Azure RBAC for Key Vault

Azure role-based access control (Azure RBAC) is the recommended authorization model for Key Vault.

RBAC uses three fundamental components:

1. Security principal
2. Role definition
3. Scope

For example:

Security Principal:
Application Managed Identity
        +
Role:
Key Vault Secrets User
        +
Scope:
Specific Key Vault

The resulting role assignment determines what the identity can do.

Azure RBAC can be applied at different scopes, including:

• Management group
• Subscription
• Resource group
• Individual Key Vault
• In supported scenarios, individual keys, secrets, or certificates

5. Important Key Vault RBAC Roles

Several built-in roles are particularly important for SC-500.

Key Vault Administrator

The Key Vault Administrator role can perform all data-plane operations on the Key Vault’s keys, secrets, and certificates.

However, it does not manage the Key Vault resource itself or manage Azure RBAC role assignments.

This distinction is important.

Key Vault Administrator ≠ Azure subscription/resource administrator.

Key Vault Reader

The Key Vault Reader role can read metadata about:

• Key Vaults
• Keys
• Secrets
• Certificates

It does not provide access to sensitive values such as secret contents or key material.

Therefore, if an administrator needs to inspect Key Vault configuration and object metadata but should not retrieve secrets, Key Vault Reader may be appropriate.

Key Vault Secrets User

The Key Vault Secrets User role provides the ability to read secret contents.

This is an important role for applications that need to retrieve secrets but don’t need to manage them.

Example

An application needs to retrieve:

DatabaseConnectionString

but should not be able to:

• Create secrets
• Delete secrets
• Change secrets
• Manage Key Vault permissions

A Key Vault Secrets User assignment is much closer to the principle of least privilege than granting Key Vault Administrator.

Key Vault Secrets Officer

The Key Vault Secrets Officer role can perform actions on secrets, except managing permissions.

This is appropriate for identities that need to manage secrets rather than merely consume them.

For example, a deployment automation identity may need to:

• Create secrets
• Update secrets
• Delete secrets
• Recover secrets

without being allowed to manage the Key Vault’s RBAC assignments.

Key Vault Crypto User

The Key Vault Crypto User role allows cryptographic operations using keys.

This is different from granting an identity permission to retrieve secret values.

For example, an application may need to use a key to perform cryptographic operations without being given broad administrative permissions over the Key Vault.

Key Vault Crypto Officer

The Key Vault Crypto Officer role can perform actions on keys, except managing permissions.

This is intended for identities responsible for managing cryptographic keys.

Key Vault Certificates Officer

The Key Vault Certificates Officer role can perform actions on certificates, except managing permissions.

This is useful when an identity needs to manage certificate objects but should not receive broad access to secrets or keys.

6. Key Vault Contributor vs. Key Vault Administrator

This is a particularly useful distinction for exam questions.

Key Vault Contributor

Key Vault Contributor can manage the Key Vault resource itself.

However, the role does not provide access to:

• Secret values
• Key material
• Certificate contents

It also does not allow the user to assign Azure RBAC roles.

Key Vault Administrator

Key Vault Administrator provides extensive data-plane access to the contents of the vault, including keys, secrets, and certificates.

It does not manage the Azure resource or role assignments.

Remember

This is exactly the type of distinction that can appear in scenario-based questions.

7. Azure RBAC vs. Key Vault Access Policies

Historically, Key Vault used its own access policy model.

Access policies allow administrators to assign permissions for:

• Keys
• Secrets
• Certificates

to security principals.

For example:

Application A
    └── Secret: Get
    └── Secret: List
Application B
    └── Key: Encrypt
    └── Key: Decrypt
Administrator
    └── Certificate: Manage

However, access policies are now considered a legacy model.

Microsoft recommends Azure RBAC instead because RBAC provides centralized authorization and better separation between resource administration and data access.

8. Why Legacy Access Policies Can Create a Security Problem

One of the most important security issues with the legacy access-policy model involves the Contributor permission.

Under the access-policy model, a principal with permissions that allow modification of the Key Vault resource can potentially modify access policies and grant itself data-plane access.

For example:

User
 │
 ├── Contributor on Key Vault
 │
 ▼
Modify Key Vault access policy
 │
 ▼
Grant self "Secret Get"
 │
 ▼
Read secrets

This can undermine separation of duties.

Microsoft specifically warns that users with Contributor, Key Vault Contributor, or other permissions that include the ability to modify Key Vault configuration can potentially grant themselves data-plane access when the access-policy model is used.

Why RBAC Helps

With RBAC, assigning access is controlled through Azure role assignments.

The ability to create or remove role assignments is associated with privileged authorization permissions such as those provided by Owner, User Access Administrator, or appropriately scoped data-access administration roles.

This creates a better separation:

Resource Administrator
       │
       ├── Manage Key Vault resource
       │
       X
       │
       └── Cannot automatically grant themselves data access
Security Administrator
       │
       └── Manage access assignments

9. Principle of Least Privilege

When configuring Key Vault access, always apply the principle of least privilege.

Give an identity only the permissions it needs.

Poor Design

An application needs to retrieve one secret.

You assign:

Key Vault Administrator

This gives the application far more access than necessary.

Better Design

Assign:

Key Vault Secrets User

at the narrowest practical scope.

The application can retrieve secret values but doesn’t receive unnecessary administrative capabilities.

10. Control Plane Access

The control plane is used to manage the Key Vault resource.

Examples include:

• Create a Key Vault
• Delete a Key Vault
• Update Key Vault properties
• Configure certain Key Vault settings
• Manage resource-level configuration

Azure RBAC is used to authorize control-plane operations.

A user who needs to manage the Key Vault resource may therefore require a role such as:

Key Vault Contributor

But that does not mean the user can automatically read secret values.

11. Data Plane Access

The data plane deals with the objects stored in Key Vault.

Examples include:

Secrets

• Get
• List
• Set
• Delete
• Recover
• Backup
• Restore
• Purge

Keys

Operations include:

• Encrypt
• Decrypt
• Sign
• Verify
• Wrap
• Unwrap
• Create
• Update
• Delete

Certificates

Operations include:

• Get
• List
• Create
• Import
• Update
• Delete
• Recover
• Backup
• Restore

For exam purposes, remember:

Data-plane authorization determines what you can do with the objects inside Key Vault.

12. Network Access Is Separate From Authorization

A common exam trap is confusing network access with identity authorization.

Suppose an application has:

Key Vault Secrets User

But the Key Vault firewall blocks the application’s network location.

The application can still fail to retrieve the secret.

Why?

Because two independent security questions must be satisfied:

Can the application reach Key Vault?
             +
Is the application authorized?
             =
Successful access

Network security can be configured using mechanisms such as:

• Key Vault firewall
• IP restrictions
• Virtual network/service endpoint configurations where applicable
• Private endpoints
• Public network access controls

Therefore:

RBAC answers “Are you allowed?”
Network controls help answer “Can you reach it?”

13. Private Endpoints and Key Vault Access

A private endpoint provides private connectivity to Key Vault through an Azure virtual network.

This can help eliminate exposure through the public network.

A common secure architecture is:

Application
     │
     ▼
Azure VNet
     │
     ▼
Private Endpoint
     │
     ▼
Azure Key Vault

Organizations can also use Azure Policy to require security configurations such as:

• RBAC
• Disabled public network access
• Private Link
• Private DNS
• Firewall protection

14. Key Vault Firewall

The Key Vault firewall can restrict network access.

For example, you might allow access only from approved network locations.

However, remember:

A firewall does not replace authentication or authorization.

A request still needs an appropriate Microsoft Entra identity and appropriate Key Vault permissions.

15. Authorization and Managed Identities: A Common Scenario

Consider an Azure App Service that needs a database password stored in Key Vault.

A secure design would be:

             Microsoft Entra ID
                    ▲
                    │
              Managed Identity
                    │
                    ▼
              Azure App Service
                    │
                    │ Authorized request
                    ▼
               Azure Key Vault
                    │
                    ▼
          Database connection secret

The application:

1. Uses its managed identity.
2. Obtains a Microsoft Entra token.
3. Sends the request to Key Vault.
4. Key Vault validates the identity and authorization.
5. Key Vault returns the secret if access is permitted.

No Key Vault password needs to be embedded in application code.

16. Role Assignment Scope

Azure RBAC supports hierarchical scopes.

For example:

Management Group
      │
   Subscription
      │
 Resource Group
      │
   Key Vault

A role assigned at a higher level can potentially apply to resources beneath that scope.

For least privilege, prefer the smallest scope that satisfies the requirement.

For example, if an application only needs secrets from:

ProductionKeyVault

don’t unnecessarily assign its role at the subscription level.

17. Separating Administrative and Application Access

A mature Key Vault architecture often separates responsibilities.

For example:

The goal is to prevent an application from receiving administrative privileges simply because it needs to consume a secret.

18. Key Vault Access and the Principle of Separation of Duties

A strong security architecture separates:

• Resource administration
• Data access
• Permission administration
• Application consumption

This limits the damage caused by compromised accounts or applications.

For example:

Application
   │
   └── Read secrets
Key Vault administrator
   │
   └── Manage vault data
Resource administrator
   │
   └── Manage Key Vault resource
Access administrator
   │
   └── Manage role assignments

This is preferable to giving one identity unrestricted control over everything.

19. Common SC-500 Exam Traps

Trap 1: “Key Vault Contributor can read secrets.”

False.

Key Vault Contributor manages the Key Vault resource but does not automatically provide access to secrets, keys, or certificates.

Trap 2: “Authentication means the application can access the secret.”

False.

Authentication establishes identity. Authorization determines whether the identity has permission.

Trap 3: “Key Vault Administrator can manage Azure RBAC.”

False.

Key Vault Administrator provides broad Key Vault data-plane permissions but doesn’t manage Azure role assignments.

Trap 4: “The Key Vault firewall grants access.”

False.

Network controls determine whether traffic can reach the service. Authorization still determines whether the identity can perform the requested operation.

Trap 5: “Access policies are the preferred model for new deployments.”

False.

Azure RBAC is the recommended model, and current Microsoft documentation identifies access policies as legacy.

Trap 6: “Key Vault Reader can read secret values.”

False.

Key Vault Reader can read metadata but not sensitive values such as secret contents.

20. Key Concepts to Remember

For the SC-500 exam, make sure you can quickly distinguish these concepts:

Practice Exam Questions

Question 1

An Azure App Service must retrieve the value of a secret stored in Azure Key Vault. The application should not be able to create, modify, or delete secrets.

Which approach provides the most appropriate authorization?

A. Assign the Key Vault Contributor role to the App Service managed identity.

B. Assign the Key Vault Administrator role to the App Service managed identity.

C. Assign the Key Vault Secrets User role to the App Service managed identity.

D. Assign the Key Vault Reader role to the App Service managed identity.

Answer: C

Explanation:
The Key Vault Secrets User role allows an identity to read secret contents without granting broad administrative permissions over the vault or allowing it to manage secrets. Key Vault Contributor manages the vault resource but doesn’t provide secret access, while Key Vault Reader provides metadata access rather than secret contents.

Question 2

A security administrator needs to allow an application to perform encryption and decryption operations using a specific Key Vault key. The application should not be able to manage the key or access secrets.

Which role is most appropriate?

A. Key Vault Crypto User

B. Key Vault Secrets User

C. Key Vault Reader

D. Key Vault Administrator

Answer: A

Explanation:
Key Vault Crypto User is designed for identities that need to perform cryptographic operations using keys. It provides substantially less access than Key Vault Administrator and doesn’t grant secret-management permissions.

Question 3

An administrator has the Key Vault Contributor role on a Key Vault. The administrator attempts to retrieve a secret’s value and receives an authorization failure.

What is the most likely explanation?

A. Key Vault Contributor only works with certificates.

B. Key Vault Contributor provides resource-management permissions but does not provide data-plane access to secret values.

C. Key Vault Contributor can only access Key Vault through a private endpoint.

D. Key Vault Contributor requires the Key Vault Reader role to access the Azure portal.

Answer: B

Explanation:
Key Vault Contributor is a control-plane role. It allows management of the Key Vault resource but doesn’t grant access to secrets, keys, or certificates in the data plane.

Question 4

An organization wants an Azure-hosted application to authenticate to Key Vault without storing a client secret in application configuration.

Which solution should the security engineer recommend?

A. Store a Key Vault access policy in the application’s configuration file.

B. Store a service principal password in Azure App Configuration.

C. Create a shared administrator account for the application.

D. Enable a managed identity for the Azure resource and grant that identity the required Key Vault permissions.

Answer: D

Explanation:
A managed identity allows an Azure resource to authenticate to Microsoft Entra ID without requiring developers to store application credentials. The managed identity can then be assigned the minimum Key Vault RBAC role required by the application.

Question 5

A company is deploying a new Key Vault. The security team wants centralized authorization, strong separation of duties, and integration with Azure RBAC and Privileged Identity Management.

Which authorization model should be selected?

A. Azure RBAC

B. Key Vault access policies

C. Shared access signatures

D. Storage account keys

Answer: A

Explanation:
Azure RBAC is the recommended Key Vault authorization model. It provides centralized role assignments and better separation between resource administration and data access. It also integrates with capabilities such as Privileged Identity Management.

Question 6

A user has the Key Vault Reader role assigned to a Key Vault. The user needs to view the names and metadata of secrets but must not be able to retrieve their values.

Which statement is correct?

A. The user must be assigned Key Vault Administrator.

B. Key Vault Reader provides metadata access but does not provide sensitive secret contents.

C. The user must be assigned Key Vault Secrets Officer.

D. Key Vault Reader automatically provides the Get Secret permission.

Answer: B

Explanation:
Key Vault Reader allows reading Key Vault and object metadata but does not provide access to sensitive values such as secret contents or key material.

Question 7

A Key Vault uses the legacy access-policy authorization model. A user has sufficient permissions to modify the Key Vault resource and discovers that they can modify the access policy. Why is this configuration considered a security concern?

A. Access policies prevent administrators from accessing secrets.

B. Access policies require a private endpoint before they can be changed.

C. The user may be able to modify the access policy and grant themselves data-plane access.

D. Access policies automatically disable Microsoft Entra authentication.

Answer: C

Explanation:
One of the security weaknesses of the legacy access-policy model is that identities with sufficient Key Vault resource-management permissions may be able to modify access policies and grant themselves access to Key Vault data. Azure RBAC provides stronger separation of permission administration.

Question 8

An application has been assigned the Key Vault Secrets User role, but requests to Key Vault continue to fail because the application is connecting from an unauthorized network location.

What additional control should the security engineer investigate?

A. Azure Key Vault network access controls

B. Key Vault Certificates Officer

C. Key Vault Reader

D. Microsoft Entra password writeback

Answer: A

Explanation:
RBAC determines whether an identity is authorized to perform an operation, but network controls determine whether the application can reach Key Vault. The security engineer should investigate the Key Vault firewall, public network access configuration, private endpoint configuration, and related networking controls.

Question 9

A security engineer needs to give an operations team permission to manage secrets in a Key Vault. The team must not be able to manage Azure RBAC role assignments.

Which role is most appropriate?

A. Key Vault Reader

B. Key Vault Secrets Officer

C. Key Vault Contributor

D. Key Vault Crypto User

Answer: B

Explanation:
Key Vault Secrets Officer provides extensive management capabilities for secrets while excluding permission management. Key Vault Contributor manages the Key Vault resource rather than the secret data, and Key Vault Crypto User is intended for cryptographic operations using keys.

Question 10

A security engineer is designing access for a production application that only needs to read secrets from one Key Vault. The organization follows the principle of least privilege.

Which configuration is the best choice?

A. Assign Key Vault Administrator at the subscription scope.

B. Assign Key Vault Contributor at the resource-group scope.

C. Assign Key Vault Secrets Officer at the Key Vault scope.

D. Assign Key Vault Secrets User at the narrowest practical scope.

Answer: D

Explanation:
The application only needs to read secret values, so Key Vault Secrets User is more appropriate than Secrets Officer or Administrator. Assigning the role at the narrowest practical scope further supports least privilege and limits the potential impact of a compromised application identity.

Final Exam Takeaway

For “Configure access to Key Vault,” the most important mental model is:

Microsoft Entra ID authenticates the identity → Azure RBAC authorizes access → network controls determine connectivity → least privilege determines how much access to grant.

And remember the critical distinction:

Key Vault Contributor manages the vault. Key Vault Secrets User reads secrets. Key Vault Secrets Officer manages secrets. Key Vault Administrator broadly manages Key Vault data.

Those distinctions are especially valuable when SC-500 questions present several roles that sound similar but provide very different permissions.

Go to the SC-500 Exam Prep Hub main page