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

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 firewall settings on 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.

Overview

Azure Key Vault is designed to securely store and manage sensitive information such as:

• Secrets
• Cryptographic keys
• Certificates

However, protecting the contents of a Key Vault requires more than identity and access controls. You should also control where network connections to the Key Vault are allowed to originate.

Azure Key Vault provides network security controls that can restrict access based on:

• Public IPv4 addresses and address ranges
• Azure virtual networks and subnets
• Trusted Microsoft services
• Private endpoints
• Public network access settings
• Network Security Perimeter configurations

For the SC-500 exam, an important concept is that network restrictions and identity permissions work together. A request generally needs to satisfy both the network boundary and the appropriate authorization requirements.

Exam mindset: Think of Key Vault security as multiple layers. A user or workload may have permission to read a secret, but that does not necessarily mean the request is allowed to reach the Key Vault.

1. Understanding the Key Vault Firewall

The Key Vault firewall provides a network-level boundary around a vault.

Without restrictive network rules, a Key Vault can potentially accept requests from a broad range of network locations. You can instead configure the vault so that only explicitly permitted network sources can access the data plane.

The firewall’s network rule set includes concepts such as:

• Default action
• IP network rules
• Virtual network rules
• Trusted service bypass

A common secure configuration is:

Default action = Deny

Then explicitly allow the networks and services that need access.

This follows the principle of least privilege at the network level.

2. Default Network Access Behavior

The Key Vault network rule set has a default action that determines what happens when a request doesn’t match an applicable network rule.

The two important values are:

• Allow
• Deny

DefaultAction = Allow

Requests that aren’t specifically blocked by network rules can access the vault, subject to other security controls.

This provides less network restriction.

DefaultAction = Deny

Requests that don’t match an allowed network rule are blocked.

This is the preferred configuration when you want to establish a restricted network boundary.

Exam Tip

If a question says:

“Only specific networks should be permitted to access the Key Vault.”

The expected configuration will generally involve:

Default action = Deny

followed by explicitly allowing the required networks or IP ranges.

3. IP-Based Firewall Rules

Key Vault can allow access from specific public IPv4 addresses or IPv4 CIDR ranges.

For example, you could allow:

203.0.113.10

or:

203.0.113.0/24

This is useful when an application or administrative environment has a known, static public IP address.

Example

Suppose an organization’s administrative network uses the public address:

198.51.100.25

The Key Vault firewall can be configured to allow that address while denying all other public addresses.

Conceptually:

Key Vault
   |
   +-- Default: Deny
   |
   +-- Allow: 198.51.100.25

Requests originating from other public IP addresses are denied at the network layer.

4. Important IP Rule Limitation

Key Vault IP firewall rules are intended for public IPv4 addresses.

You cannot simply enter an RFC 1918 private address such as:

10.10.1.25
172.16.10.20
192.168.1.25

as a Key Vault public IP firewall rule.

These are private address ranges.

If you need to allow workloads located inside an Azure virtual network, use a virtual network rule/service endpoint or a private endpoint, depending on the desired architecture.

Exam Trap

A question might describe a VM with a private IP address such as:

10.1.2.15

and ask how to allow that VM to access Key Vault.

Do not automatically choose an IP firewall rule.

Instead, consider:

• A virtual network/subnet rule using a Key Vault service endpoint, or
• A private endpoint architecture.

5. Virtual Network Rules

Key Vault can also restrict access to specific Azure virtual networks and subnets.

This is particularly useful when workloads have dynamically assigned private IP addresses.

For example:

Virtual Network
└── Application Subnet
    ├── VM
    ├── VM
    └── Application
           |
           | Key Vault access
           v
      Azure Key Vault

Instead of maintaining individual IP addresses for each VM, you can authorize the appropriate subnet.

This makes virtual network rules especially useful when:

• Workloads have dynamic IP addresses.
• Multiple resources in a subnet need Key Vault access.
• You want to establish a network boundary around an application tier.

6. Key Vault Virtual Network Service Endpoints

Virtual network access to Key Vault can use an Azure service endpoint.

A service endpoint extends the identity of a virtual network/subnet to Azure services over the Azure backbone.

For Key Vault, the subnet can be configured to use the Key Vault service endpoint, after which the subnet can be added to the vault’s virtual network rules.

The basic architecture is:

Azure VNet
   |
   +-- Application Subnet
          |
          | Key Vault service endpoint
          |
          v
     Azure Key Vault

The Key Vault firewall can then allow the specific subnet.

Important distinction

A service endpoint does not create a private IP address for the Key Vault inside your virtual network.

Instead, it allows the subnet to access the Key Vault service through Azure’s service endpoint mechanism.

A private endpoint is different.

7. Private Endpoints for Key Vault

A private endpoint provides a private network interface in your virtual network that connects privately to the Key Vault service through Azure Private Link.

Conceptually:

Virtual Network
       |
       | Private IP
       v
+-------------------+
| Private Endpoint  |
+-------------------+
       |
       | Private Link
       v
+-------------------+
|   Azure Key Vault |
+-------------------+

This is generally a stronger network-isolation option than simply allowing selected public IP addresses.

A particularly restrictive architecture is:

Public network access = Disabled

with access provided through private endpoints.

This means public data-plane access is blocked and workloads must use the private endpoint path.

Exam Tip

If the requirement says:

“The Key Vault must not be accessible over the public network.”

Think:

Private Endpoint + Disable public network access

rather than simply configuring a list of public IP firewall rules.

8. Firewall Rules vs. Private Endpoints

These two approaches solve related but different problems.

Exam Scenario

If an organization has a corporate office with a fixed public IP address and wants to allow administrators to access Key Vault:

IP firewall rules may be appropriate.

If an application runs in an Azure subnet and has dynamically changing private IP addresses:

Virtual network rules/service endpoints may be appropriate.

If an organization requires the Key Vault to be reachable only through private connectivity:

Private Endpoint + disabled public network access is generally the stronger solution.

9. Allow Trusted Microsoft Services to Bypass the Firewall

Key Vault provides an option to allow certain trusted Microsoft services to bypass the network firewall.

The setting is commonly represented as:

bypass = AzureServices

When enabled, supported Microsoft services can access the Key Vault even when firewall restrictions would otherwise block them.

However, this is an important exam concept:

“Trusted Microsoft services” does not mean every Microsoft or Azure service.

Only services that are specifically recognized as trusted for the applicable Key Vault scenario can use this bypass.

A Microsoft service that isn’t included in the supported trusted-service scenarios does not automatically gain access merely because it is an Azure service.

10. Trusted Services Do Not Bypass Identity Authorization

Allowing trusted Microsoft services to bypass the firewall does not mean that those services automatically have permission to read secrets, keys, or certificates.

Network access and authorization are separate security layers.

For example:

Application
     |
     | 1. Network check
     v
Key Vault Firewall
     |
     | Allowed?
     v
     | 2. Authentication
     v
Microsoft Entra ID
     |
     | 3. Authorization
     v
Key Vault data-plane permissions

A trusted service must still authenticate appropriately and have the required permissions for the requested operation.

Exam Tip

If an answer says:

“Enable trusted Microsoft services, which automatically grants the service access to secrets.”

That is incorrect.

The trusted-service setting addresses the network boundary, not the complete authorization model.

11. Firewall Rules Apply to the Key Vault Data Plane

One of the most important details for the SC-500 exam is understanding the difference between the control plane and data plane.

Control plane

The control plane is used to manage the Azure resource itself.

Examples include:

• Creating the Key Vault
• Modifying Azure resource properties
• Deploying resources
• Managing the resource through Azure Resource Manager

Data plane

The data plane is used to interact with the contents of the vault.

Examples include:

• Reading a secret
• Creating a secret
• Retrieving a key
• Performing key operations
• Accessing certificates

Key Vault firewall rules primarily restrict data-plane access.

Therefore, don’t assume that configuring a Key Vault firewall blocks every management operation performed through Azure Resource Manager.

Exam Tip

When you see a question asking:

“Which operations are affected by Key Vault firewall rules?”

Look for data-plane operations such as retrieving secrets, keys, or certificates.

12. Azure Portal Access Can Also Be Affected

A common source of confusion is Azure portal access.

You may be able to see the Key Vault resource in the Azure portal while being unable to view its secrets, keys, or certificates.

Why?

Because browsing the Azure resource and retrieving Key Vault data are different operations.

For example:

User's computer
      |
      +---- Azure Resource Manager
      |       |
      |       +---- Can see Key Vault resource
      |
      +---- Key Vault data plane
              |
              +---- Firewall blocks request

If the administrator’s computer isn’t inside an allowed network boundary, data-plane operations through the portal can be blocked.

Exam Tip

Do not assume:

“The user can see the Key Vault in the portal, therefore the user can access its secrets.”

Those are separate considerations.

13. Firewall Configuration Does Not Replace RBAC

Network security controls and identity-based authorization should be used together.

A request can be blocked because:

1. The originating network isn’t allowed, or
2. The caller doesn’t have sufficient Key Vault permissions.

For example:

Network allowed
       +
Microsoft Entra authentication successful
       +
Required Key Vault RBAC permission
       =
Access permitted

If any required layer fails, the operation can fail.

This is an important implementation of defense in depth.

14. Azure RBAC and Key Vault Access

Modern Key Vault deployments commonly use the Azure RBAC permission model.

With RBAC, permissions are granted through Azure role assignments.

Examples of relevant built-in roles include roles that provide:

• Secret read access
• Key management access
• Certificate management access
• Broader Key Vault data-plane permissions

The precise role should be selected according to the principle of least privilege.

For example, if an application only needs to retrieve secrets, don’t grant it broad administrative permissions over the entire vault.

Important distinction

RBAC answers:

“What is this identity allowed to do?”

The firewall answers:

“From which network locations can the request reach the vault?”

These controls complement each other.

15. Combining Firewall Rules With Private Endpoints

A highly secure architecture can combine several controls.

For example:

                    Internet
                       |
                 X Public Access
                       |
                       |
              +----------------+
              | Azure Key Vault|
              +----------------+
                       ^
                       |
                 Private Link
                       |
              +----------------+
              | Private Endpoint|
              +----------------+
                       |
              +----------------+
              | Azure VNet     |
              |                |
              | Application    |
              | Subnet         |
              +----------------+

The vault can be configured so that public network access is disabled.

The application then accesses Key Vault through the private endpoint.

This reduces exposure of the Key Vault data plane to public networks.

16. When Should You Use Each Configuration?

A useful way to approach SC-500 scenarios is to map the requirement to the appropriate network control.

Requirement: Allow one known public office IP

Use:

IP firewall rule

Requirement: Allow a specific Azure subnet

Use:

Virtual network rule + Key Vault service endpoint

Requirement: Allow multiple Azure workloads with dynamic private IPs

Consider:

Virtual network/subnet-based access

rather than managing individual IP addresses.

Requirement: Key Vault must not be publicly accessible

Use:

Private Endpoint + Disable public network access

Requirement: A supported Microsoft service needs to bypass the firewall

Consider:

Allow trusted Microsoft services to bypass the firewall

provided the service and scenario are supported.

Requirement: Restrict access to the smallest possible network boundary

Use:

Default Deny + explicitly allowed network sources

and combine it with identity-based authorization.

17. Important Firewall Limits

For Key Vault network rules, several limits and restrictions are useful to remember for the exam.

Key Vault supports:

• Up to 200 virtual network rules
• Up to 1,000 IPv4 firewall rules/ranges
• IPv4 network rules
• Public IPv4 addresses/ranges for IP rules

Private RFC 1918 addresses aren’t used as public IP firewall rules.

These limits can influence architecture decisions in large environments.

For example, if hundreds of individual workloads need access, managing individual public IP rules may be less desirable than using subnet-based or private endpoint architectures.

18. Key Vault Firewall and Defense in Depth

The firewall should be considered one layer of a broader Key Vault security architecture.

A strong design might include:

Layer 1 — Identity

Use Microsoft Entra ID and Azure RBAC.

Layer 2 — Network

Use:

• Firewall rules
• Virtual network rules
• Private endpoints
• Restricted public network access

Layer 3 — Data protection

Protect:

• Secrets
• Keys
• Certificates

Layer 4 — Monitoring

Use logging and monitoring to detect suspicious access.

Layer 5 — Security posture

Use Microsoft Defender for Cloud and Azure Policy where appropriate.

This produces a defense-in-depth model:

                 Key Vault Security
                        |
        +---------------+---------------+
        |               |               |
     Identity        Network        Monitoring
        |               |               |
      RBAC          Firewall         Logs
   Entra ID         VNet rules       Alerts
                    Private Link     Defender

19. Common SC-500 Exam Traps

Trap 1: “Firewall provides authorization”

Incorrect.

The firewall provides network-level access control.

Identity-based authorization is still required.

Trap 2: “Trusted Microsoft services means all Azure services”

Incorrect.

Only supported trusted services and scenarios qualify.

Trap 3: “A private IP can be added as an IP firewall rule”

Incorrect.

Key Vault IP rules are for public IPv4 addresses/ranges.

Use virtual network rules/service endpoints or private endpoints for private network scenarios.

Trap 4: “Disabling public network access automatically creates a private endpoint”

Incorrect.

You must configure the private endpoint separately.

The recommended sequence is generally:

1. Configure the private endpoint.
2. Verify private connectivity and DNS.
3. Disable public network access.

Trap 5: “Firewall rules block Azure Resource Manager operations”

Not generally.

Key Vault firewall restrictions apply to the data plane rather than all control-plane operations.

Trap 6: “Seeing the Key Vault in the portal means you can access its secrets”

Incorrect.

The Key Vault data plane has its own network and authorization requirements.

Trap 7: “Default Allow is the most secure setting”

Incorrect.

For a restricted network architecture, Default Deny is normally the appropriate starting point.

20. Practical Configuration Example

Suppose an organization has this requirement:

A Key Vault contains production secrets. Only an application running in the ProductionSubnet should access the vault. Internet-based access should be denied.

A suitable architecture is:

Internet
   |
   X
   |
Key Vault
   |
   | Default = Deny
   |
   +---- ProductionSubnet
              |
              +---- Application

The subnet can be authorized using the appropriate Key Vault virtual network/service endpoint configuration.

The application still requires appropriate Microsoft Entra authentication and Key Vault permissions.

The security model therefore becomes:

Production subnet
       +
Valid application identity
       +
Required Key Vault permission
       =
Access

Everything else is denied.

21. Another Scenario: Maximum Network Isolation

Suppose the requirement changes:

The production Key Vault must not be exposed through the public network under any circumstances.

A stronger architecture is:

Production VNet
      |
      v
Private Endpoint
      |
      v
Azure Key Vault
Public Network Access
        |
        X
      Disabled

The application accesses the Key Vault using the private endpoint.

This is an important distinction:

Firewall with selected public IPs still provides a public network path.

Private endpoint with public network access disabled provides a much stronger private-only architecture.

22. Exam-Focused Summary

For SC-500, remember these core concepts:

The Most Important Mental Model

When you see a Key Vault access scenario on the exam, ask these questions in order:

1. Who is calling?

→ Microsoft Entra identity and RBAC

2. What does the caller need to do?

→ Determine the required Key Vault data-plane permission.

3. Where is the caller coming from?

→ IP address, VNet/subnet, trusted service, or private endpoint.

4. Should public access exist?

→ If no, use private connectivity and disable public network access.

5. What should happen to everything else?

→ Use Default Deny when implementing a restricted network boundary.

This layered approach will help distinguish the correct answer from options that address only identity or only networking.

Practice Exam Questions

Question 1

A company has an Azure Key Vault that contains production secrets. Administrators connect to Azure from a corporate network that has a single static public IPv4 address. The security team wants to allow administrators to access the Key Vault while blocking access from all other public IP addresses.

Which configuration should you implement?

A. Add the corporate public IPv4 address to the Key Vault firewall and set the default network action to Deny.

B. Add the corporate private IP address to the Key Vault firewall and set the default network action to Deny.

C. Create a private endpoint for every administrator’s workstation.

D. Enable the trusted Microsoft services bypass.

Answer: A

Explanation

An IP firewall rule is appropriate when the authorized client has a known static public IPv4 address. Setting the default action to Deny ensures that other public IP addresses cannot access the Key Vault data plane.

B is incorrect because private RFC 1918 addresses aren’t valid public IP firewall rules.

C is unnecessarily complex and doesn’t match the stated requirement.

D applies to supported Microsoft services, not corporate administrator workstations.

Question 2

An Azure application runs on virtual machines in a subnet. The VMs have dynamically assigned private IP addresses. The application needs to retrieve secrets from an Azure Key Vault.

Which approach is most appropriate if the organization wants to authorize the subnet rather than maintain individual IP addresses?

A. Add the private IP addresses of every VM to the Key Vault IP firewall.

B. Enable the appropriate Key Vault service endpoint on the subnet and authorize the subnet using a Key Vault virtual network rule.

C. Enable the trusted Microsoft services bypass.

D. Assign a public IP address to every VM and add the addresses to the firewall.

Answer: B

Explanation

Virtual network rules are designed for scenarios in which Azure workloads need access from an authorized VNet/subnet. A Key Vault service endpoint can be enabled on the subnet, and the subnet can then be added to the Key Vault network rules.

A is incorrect because private IP addresses aren’t used as public Key Vault IP firewall rules.

C does not apply merely because the workload runs in Azure.

D unnecessarily exposes the VMs through public IP addresses.

Question 3

A security architect must ensure that an Azure Key Vault cannot be accessed through the public network. Applications must access the vault through Azure Private Link.

Which configuration should the architect implement?

A. Configure an IP firewall rule for the application’s public IP address.

B. Enable the trusted Microsoft services bypass.

C. Create a private endpoint for the Key Vault and disable public network access.

D. Set the Key Vault firewall default action to Allow.

Answer: C

Explanation

A private endpoint provides private connectivity to Key Vault through Azure Private Link. Disabling public network access prevents public data-plane connectivity.

A still leaves a public network path.

B is intended for supported trusted Microsoft service scenarios and doesn’t provide private-only access.

D would make the network boundary less restrictive.

Question 4

A Key Vault has its firewall configured with defaultAction set to Deny. An Azure service needs to access the vault. The service is listed as a supported trusted Microsoft service for the required Key Vault scenario.

What should you configure?

A. Add the service’s private IP address as an IP firewall rule.

B. Create a private endpoint for the service automatically.

C. Change the firewall default action to Allow.

D. Enable the Key Vault option that allows trusted Microsoft services to bypass the firewall.

Answer: D

Explanation

The trusted-service bypass allows supported Microsoft services to bypass the Key Vault network firewall. The service must still authenticate and have the appropriate Key Vault permissions.

A is incorrect because private IP addresses aren’t configured as public IP firewall rules.

B isn’t necessarily required for a supported trusted service.

C unnecessarily opens network access more broadly.

Question 5

An administrator can see an Azure Key Vault resource in the Azure portal but receives an error when attempting to list its secrets. The Key Vault firewall allows only a specific corporate network, and the administrator is working from an unapproved network.

What is the most likely cause?

A. Azure RBAC cannot be used with Key Vault.

B. Key Vault firewall restrictions can prevent data-plane access even when the resource is visible through the portal.

C. The Key Vault must be deleted and recreated.

D. The administrator must enable trusted Microsoft services.

Answer: B

Explanation

The Azure portal can display the Key Vault resource through management-plane operations while Key Vault data-plane operations can still be blocked by network restrictions. Listing secrets is a data-plane operation.

A is incorrect because Azure RBAC can be used for Key Vault authorization.

C is unnecessary.

D doesn’t address access from an administrator’s workstation.

Question 6

A security engineer configures a Key Vault with defaultAction = Deny and allows a specific application subnet. The application can reach the Key Vault network endpoint but receives an authorization error when attempting to retrieve a secret.

What should the engineer check next?

A. Whether the application identity has the required Key Vault data-plane permission.

B. Whether the Key Vault has another public IP firewall rule.

C. Whether the trusted Microsoft services bypass is enabled.

D. Whether the Key Vault has been assigned a public IP address.

Answer: A

Explanation

The network boundary and identity authorization are separate controls. If the application has passed the network restrictions but receives an authorization error, the next step is to verify that its Microsoft Entra identity has the appropriate Key Vault permission, such as the required RBAC role.

The firewall does not grant data access permissions.

Question 7

An organization wants to restrict access to an Azure Key Vault to a specific Azure subnet. The subnet contains workloads whose private IP addresses can change over time.

Which solution avoids maintaining individual IP firewall rules?

A. Assign static public IP addresses to all workloads.

B. Add every current private IP address to the firewall.

C. Use a Key Vault virtual network rule for the subnet, with the appropriate service endpoint configuration.

D. Enable anonymous access to the Key Vault.

Answer: C

Explanation

A virtual network rule can authorize a specific subnet and avoids the need to maintain individual workload IP addresses. The appropriate Key Vault service endpoint must be configured for this architecture.

A creates unnecessary public exposure.

B is not supported as a public IP firewall strategy for private RFC 1918 addresses and would also be difficult to maintain.

D is not an appropriate Key Vault security configuration.

Question 8

Which statement correctly describes the relationship between the Key Vault firewall and Azure RBAC?

A. The firewall replaces Azure RBAC when defaultAction is set to Deny.

B. Azure RBAC controls network access, while the firewall controls secret permissions.

C. The firewall and Azure RBAC perform exactly the same function.

D. The firewall controls network access to the Key Vault data plane, while RBAC can determine what an authenticated identity is authorized to do.

Answer: D

Explanation

The two controls provide different security layers.

The firewall determines whether network traffic is permitted to reach the Key Vault data plane.

Azure RBAC determines what an authenticated identity is authorized to do with Key Vault resources and data, based on the assigned role.

Both controls can therefore be required for successful access.

Question 9

A company wants to use the most restrictive network configuration possible for a production Key Vault. The vault should be accessible only from applications in an Azure virtual network, and no public network access should be permitted.

Which architecture best meets the requirement?

A. Use a private endpoint and disable public network access for the Key Vault.

B. Use a public IP firewall rule for the application’s current outbound IP.

C. Set the firewall default action to Allow.

D. Enable the trusted Microsoft services bypass.

Answer: A

Explanation

A private endpoint provides private connectivity through Azure Private Link. Disabling public network access prevents public data-plane connectivity.

B still relies on public network access.

C provides broad access rather than private-only access.

D is designed for supported trusted Microsoft services and doesn’t provide the requested private-only architecture.

Question 10

A security engineer is reviewing Key Vault firewall behavior. Which statement is correct?

A. Key Vault IP firewall rules accept private RFC 1918 addresses such as 10.0.0.0/8.

B. Key Vault firewall rules apply only to Azure Resource Manager control-plane operations.

C. Key Vault firewall rules primarily restrict data-plane access, and IP rules use public IPv4 addresses/ranges.

D. Enabling the trusted Microsoft services bypass grants every Azure service access to all Key Vault data.

Answer: C

Explanation

Key Vault IP network rules are intended for public IPv4 addresses/ranges, and firewall restrictions primarily govern data-plane access.

A is incorrect because RFC 1918 private addresses aren’t used as public IP firewall rules.

B is incorrect because the firewall applies to Key Vault data-plane access.

D is incorrect because the trusted-service bypass applies only to supported Microsoft services and scenarios, and those services still require appropriate authentication and authorization.

Go to the SC-500 Exam Prep Hub main page