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 Key Vault settings

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

Microsoft Azure Key Vault is a managed service designed to securely store and control access to sensitive information such as:

• Secrets — passwords, connection strings, API keys, tokens, and other sensitive values.
• Keys — cryptographic keys used for encryption, decryption, signing, verification, wrapping, and unwrapping.
• Certificates — certificates and their associated private keys.

For the SC-500 exam, configuring Key Vault is not simply about creating a vault. You need to understand how to configure the vault as a security boundary using identity, authorization, network, and data-protection controls.

A well-secured Key Vault generally follows the principles of:

1. Least privilege
2. Defense in depth
3. Zero Trust
4. Assume breach
5. Minimize public exposure
6. Protect against accidental and malicious deletion

Microsoft’s current security guidance recommends using Azure RBAC, managed identities, network restrictions, private endpoints where appropriate, and just-in-time privileged access.

1. Understand the Key Vault Security Boundary

A Key Vault should generally be treated as a security boundary for the secrets, keys, and certificates associated with an application or workload.

A common secure architecture is:

One Key Vault per application, environment, and region

For example:

Application A
   ├── Development Key Vault
   ├── Test Key Vault
   └── Production Key Vault
Application B
   ├── Development Key Vault
   ├── Test Key Vault
   └── Production Key Vault

This separation reduces the potential blast radius if one application or environment is compromised.

For example, placing development and production secrets in the same vault can unnecessarily allow a compromised development workload to become a pathway toward production secrets.

2. Key Vault Has Two Security Planes

One of the most important concepts to understand is that Key Vault has a control plane and a data plane.

Control plane

The control plane manages the Key Vault resource itself.

Examples include:

• Creating a vault
• Deleting a vault
• Updating vault properties
• Configuring networking
• Configuring diagnostic settings
• Managing certain resource-level settings

Azure RBAC is used for management-plane authorization.

Data plane

The data plane controls access to the actual contents of the vault.

Examples include:

• Reading secrets
• Creating secrets
• Deleting secrets
• Reading keys
• Encrypting or decrypting using keys
• Creating certificates
• Retrieving certificates

Data-plane authorization can use Azure RBAC or the legacy Key Vault access policy model. Azure RBAC is the recommended model.

Exam distinction

A user can have permission to manage the Key Vault resource without necessarily having permission to read the secrets inside it.

For example:

A user with the Key Vault Contributor role can manage the Key Vault resource, but the role does not automatically grant access to keys, secrets, and certificates.

This distinction is extremely important for SC-500 questions.

3. Configure the Authorization Model

Azure Key Vault supports two data-plane authorization models:

1. Azure RBAC
2. Key Vault access policies

Azure RBAC

Azure RBAC is the recommended authorization model.

RBAC provides centralized authorization using:

• Security principal
• Role definition
• Scope

For example:

Managed Identity
       ↓
Key Vault Secrets User
       ↓
Production Key Vault

RBAC provides several security advantages:

• Centralized authorization
• Integration with Microsoft Entra ID
• Integration with Privileged Identity Management
• Consistent Azure authorization model
• Better separation between resource administration and data access
• Support for least-privilege role assignments

Current Azure Key Vault documentation identifies RBAC as the recommended authorization model, and starting with API version 2026-02-01, RBAC is the default authorization model for newly created vaults.

4. Key Vault RBAC Roles

Several built-in roles are particularly important.

Key Vault Contributor

Allows management of the Key Vault resource itself.

It does not provide access to secrets, keys, or certificates.

This is an important exam trap.

Key Vault Secrets User

Allows a principal to read secret contents.

A common scenario is:

An Azure App Service needs to retrieve a database connection string stored as a Key Vault secret.

The application could use a managed identity with an appropriate Key Vault RBAC role.

Key Vault Secrets Officer

Provides broader management permissions for secrets.

It is appropriate when a principal needs to manage secrets rather than merely read them.

Key Vault Crypto User

Provides permissions for cryptographic operations involving keys.

For example, an application may need to use a key for cryptographic operations without being granted broad administrative access to the vault.

Key Vault Administrator

Provides extensive data-plane permissions.

This role should be carefully controlled because it provides significant access to Key Vault data.

5. Use Managed Identities

Applications should generally authenticate to Key Vault using managed identities rather than storing credentials in application configuration.

For example:

Azure Function
      │
      │ Managed Identity
      ▼
Microsoft Entra ID
      │
      ▼
Azure Key Vault
      │
      ▼
Secret

The major advantage is that the application doesn’t need to store a client secret, password, or certificate merely to authenticate to Key Vault.

Exam scenario

If a question says:

An Azure Web App needs to access a Key Vault secret without storing credentials in application configuration.

The preferred solution is typically:

Enable a managed identity on the Web App and assign an appropriate Key Vault RBAC role.

6. Apply Least Privilege

Do not give applications more Key Vault permissions than they require.

For example:

The key principle is:

Grant the smallest role that satisfies the requirement.

Avoid assigning broad roles such as Owner or Contributor when a narrower Key Vault role is sufficient.

7. Understand the Legacy Access Policy Model

Key Vault access policies are the older authorization mechanism.

An access policy can specify permissions for:

• Keys
• Secrets
• Certificates

For example, a principal might receive:

Secrets:
   Get
   List

Although access policies remain supported, Azure RBAC is preferred for new deployments.

There is an important security reason.

With the legacy access policy model, a principal with sufficient control-plane permissions to modify the vault can potentially grant itself data-plane access through an access policy.

Azure RBAC provides stronger separation of responsibilities because granting data-plane RBAC permissions requires appropriate authorization to create role assignments.

Exam takeaway

If a question asks:

Which authorization model should be used for a new security-sensitive Key Vault?

The answer will generally be:

Azure RBAC.

8. Configure Soft Delete

Soft delete protects deleted Key Vaults and Key Vault objects from immediate permanent deletion.

When an object is deleted, it enters a recoverable deleted state rather than immediately disappearing permanently.

This helps protect against:

• Accidental deletion
• Malicious deletion
• Application errors
• Administrative mistakes
• Certain ransomware scenarios

Soft delete applies to Key Vault objects such as:

• Secrets
• Keys
• Certificates

It also protects the vault itself from immediate permanent deletion.

9. Understand Soft-Delete Retention

The soft-delete retention period determines how long deleted objects remain recoverable.

The current configurable retention period is:

7–90 days

The default retention period is 90 days.

Once the retention setting is established for a vault, it cannot subsequently be changed.

Exam trap

Do not confuse:

Soft delete

with:

Purge protection

They solve related but different problems.

10. Configure Purge Protection

Purge protection provides an additional layer of protection against permanently deleting soft-deleted Key Vaults or objects.

Without purge protection:

Delete
  ↓
Soft-deleted
  ↓
Can potentially be purged
  ↓
Permanent deletion

With purge protection:

Delete
  ↓
Soft-deleted
  ↓
Purge blocked
  ↓
Retention period expires
  ↓
Permanent deletion becomes possible

Purge protection is especially important when Key Vault keys are used to protect critical data.

For example, if an Azure Storage encryption key is permanently deleted, the encrypted data may become unrecoverable.

Microsoft specifically recommends purge protection when keys are used for encryption.

11. Important Purge Protection Characteristics

Purge protection:

• Works with soft delete
• Prevents premature permanent deletion
• Helps protect against malicious destruction
• Is irreversible once enabled
• Is particularly important for encryption keys

Exam rule

If a question says:

A Key Vault contains keys used for encryption of critical data, and administrators must be prevented from permanently deleting those keys before the retention period expires.

The key setting is:

Purge protection.

12. Configure Network Security

Key Vault can be protected using network controls.

The goal is to prevent unauthorized network access to the vault.

Important network controls include:

• Public network access settings
• Firewall rules
• Virtual network restrictions
• Private endpoints
• Private Link
• Trusted Microsoft services

Microsoft’s current security guidance favors disabling public network access and using private endpoints when the workload architecture supports it.

13. Configure the Key Vault Firewall

A Key Vault firewall can restrict access based on network location.

You can restrict access using:

• IP network rules
• Virtual network rules
• Other supported network controls

For example:

Internet
   X
   │
   │ blocked
   ▼
Key Vault
   ▲
   │
Allowed corporate network

This reduces the attack surface compared with allowing unrestricted public access.

14. Public Network Access

Key Vault has a setting controlling whether the vault accepts traffic through its public endpoint.

Conceptually:

Public network access: Enabled
        ↓
Public endpoint can be used
        ↓
Firewall/network rules determine access

versus:

Public network access: Disabled
        ↓
Public access blocked
        ↓
Private endpoint access can be used

When public network access is disabled, traffic through the public endpoint is blocked; private endpoint traffic can still provide access.

Exam clue

If a question says:

The organization requires that Key Vault not be accessible from the public Internet.

Look for:

Disable public network access and use a private endpoint.

15. Use Private Endpoints

An Azure Private Endpoint provides a private network interface in an Azure virtual network that connects privately to the Key Vault service through Azure Private Link.

Conceptually:

Azure VNet
│
├── Application
│
└── Private Endpoint
        │
        │ Private Link
        ▼
    Azure Key Vault

The application can access Key Vault through a private IP address instead of relying on a publicly accessible endpoint.

Private endpoints are particularly useful for:

• Production workloads
• Sensitive workloads
• Regulated environments
• Internal applications
• Workloads requiring private network connectivity

16. Private DNS Is Important

When using a private endpoint, DNS configuration is an important part of the architecture.

Applications should resolve the Key Vault hostname to the private endpoint’s IP address when appropriate.

A common architecture is:

Application
    │
    ▼
Private DNS Zone
    │
    ▼
Private Endpoint IP
    │
    ▼
Azure Key Vault

Therefore, a scenario involving a private endpoint may also require appropriate private DNS configuration.

Exam clue

If the question says:

A VM can reach the private endpoint’s network but continues resolving the Key Vault hostname to a public address.

The problem may be:

DNS configuration.

17. Private Endpoint vs. Firewall

These controls are related but not identical.

Firewall

Controls which network sources can access the public Key Vault endpoint.

Private Endpoint

Provides private connectivity to the Key Vault service through a virtual network.

Strong security architecture

For a highly restricted workload, you may use:

Public network access
        ↓
Disabled
Private Endpoint
        ↓
Enabled
Private DNS
        ↓
Configured
RBAC
        ↓
Least privilege
Soft Delete
        ↓
Enabled
Purge Protection
        ↓
Enabled

This is a classic defense-in-depth configuration.

18. Trusted Microsoft Services

Some Azure services may need to access Key Vault while network restrictions are enabled.

Key Vault supports an option allowing certain trusted Microsoft services to bypass network restrictions where supported.

This should not be interpreted as:

“Allow all Microsoft services.”

It is a controlled exception for supported trusted services.

Exam consideration

If a question requires a particular Azure service to access a firewall-protected Key Vault and the scenario specifically identifies the service as requiring trusted-service access, consider the Allow trusted Microsoft services setting.

However, don’t enable broad exceptions when a more restrictive private-network architecture satisfies the requirement.

19. Configure Key Vault for Defense in Depth

A strong Key Vault configuration should combine multiple security layers.

For example:

Identity

• Microsoft Entra ID
• Managed identities
• MFA for privileged administrators
• Conditional Access where appropriate

Authorization

• Azure RBAC
• Least privilege
• PIM for privileged roles

Network

• Private endpoint
• Private DNS
• Firewall/network restrictions
• Disabled public network access where appropriate

Data protection

• Soft delete
• Purge protection
• Appropriate secret/key lifecycle management

Monitoring

• Diagnostic logging
• Azure Monitor
• Microsoft Defender for Cloud
• Alerts for suspicious activity

20. Use Privileged Identity Management

Administrators should not necessarily have permanent high-level Key Vault privileges.

Microsoft Entra Privileged Identity Management (PIM) can provide eligible, just-in-time access.

Instead of:

Administrator
    ↓
Permanent Key Vault Administrator

use:

Administrator
    ↓
Eligible role
    ↓
Activation
    ↓
MFA / approval
    ↓
Temporary privileged access

This reduces the amount of time privileged permissions are available.

Current Microsoft guidance specifically recommends using PIM for eligible, just-in-time Key Vault administrative roles.

21. Configure Azure Policy

Azure Policy can help enforce Key Vault security standards across an organization.

For example, policies can help ensure that Key Vaults:

• Use Azure RBAC
• Disable public network access
• Use private endpoints
• Have firewall protection
• Follow organizational security requirements

Azure provides built-in Key Vault policies for many of these scenarios.

For example:

Subscription
     │
     ▼
Azure Policy
     │
     ├── Require RBAC
     ├── Restrict public access
     ├── Require firewall
     └── Require private connectivity

Audit vs. Deny

A policy can often be configured to:

Audit

Identify noncompliant resources without preventing deployment.

or:

Deny

Prevent deployment/configuration that violates the organization’s requirements.

A common implementation strategy is:

Audit first → remediate → enforce with Deny

This helps reduce the risk of unexpectedly breaking existing workloads.

22. Monitor Key Vault Security

Security configuration is not enough. You should also monitor Key Vault activity.

Useful monitoring capabilities include:

• Azure Monitor
• Diagnostic settings
• Log Analytics
• Microsoft Defender for Cloud
• Alerts
• Activity logs

Monitoring can help identify:

• Unexpected secret access
• Unusual key operations
• Unauthorized access attempts
• Configuration changes
• Suspicious administrative activity

Microsoft Defender for Cloud can also provide security recommendations for Key Vault, including recommendations related to RBAC and secret expiration.

23. Secret Expiration

Secrets should generally have an appropriate expiration date.

For example:

Database password
       │
       ├── Created: January 1
       ├── Rotation: Every 90 days
       └── Expiration: March 31

Permanent credentials increase the window of opportunity if a credential is compromised.

Defender for Cloud includes recommendations related to ensuring Key Vault secrets have expiration dates.

24. Common Configuration Choices

The following table summarizes the most important settings.

25. High-Value SC-500 Exam Distinctions

Memorize these distinctions.

RBAC vs. Access Policy

RBAC = preferred modern authorization model.

Access Policy = legacy Key Vault authorization model.

Control Plane vs. Data Plane

Control plane = manage the Key Vault resource.

Data plane = access keys, secrets, and certificates.

Soft Delete vs. Purge Protection

Soft delete = recover deleted objects.

Purge protection = prevent permanent deletion before the retention period expires.

Firewall vs. Private Endpoint

Firewall = restrict network access based on network rules.

Private endpoint = provide private connectivity through a VNet.

Contributor vs. Secrets User

Key Vault Contributor = manage the vault resource.

Key Vault Secrets User = read secret contents.

Permanent Privileges vs. PIM

Permanent role = privilege remains available.

PIM = eligible, time-limited privileged access.

26. Recommended Secure Key Vault Configuration

For a security-sensitive production workload, a strong configuration could look like this:

                    Microsoft Entra ID
                           │
                 ┌─────────┴─────────┐
                 │                   │
          Managed Identity          PIM
                 │                   │
                 ▼                   ▼
           Application         Administrator
                 │                   │
                 └─────────┬─────────┘
                           ▼
                    Azure RBAC
                           │
                           ▼
                    Azure Key Vault
                 ┌─────────┼─────────┐
                 │         │         │
             Secrets     Keys    Certificates
                 │
                 │
        ┌────────┴────────┐
        │                 │
   Soft Delete       Purge Protection
        │
        └────────┬────────┘
                 │
          Network Security
                 │
       ┌─────────┴─────────┐
       │                   │
 Firewall / Rules    Private Endpoint
                           │
                      Private DNS

The exact configuration depends on the workload, but this architecture demonstrates the defense-in-depth mindset expected from a security engineer.

27. SC-500 Exam Tips

When you encounter a Key Vault scenario, ask these questions in order:

Question 1: Who needs access?

Identify the:

• User
• Group
• Application
• Managed identity
• Service principal

Question 2: What do they need to do?

Determine whether they need to:

• Read
• Create
• Update
• Delete
• Manage
• Encrypt/decrypt
• Sign/verify

Question 3: Which authorization model?

For modern deployments:

Azure RBAC

Question 4: Does the workload need public access?

If not:

Disable public network access.

Question 5: Does the application need private connectivity?

If yes:

Private Endpoint + appropriate DNS configuration.

Question 6: What happens if someone deletes the secret/key?

Use:

Soft delete

Question 7: What if someone tries to permanently purge it?

Use:

Purge protection

Question 8: Does an administrator need permanent privileges?

If not:

PIM / just-in-time access

Question 9: Must this configuration be enforced across many subscriptions?

Consider:

Azure Policy

This decision process can help eliminate incorrect answers quickly.

Practice Exam Questions

Question 1

A company has an Azure App Service that needs to retrieve a database password stored in Azure Key Vault. The company does not want to store credentials in the App Service configuration.

What should you implement?

A. Enable a managed identity for the App Service and assign an appropriate Key Vault RBAC role.

B. Store a Key Vault access key in an App Service application setting.

C. Create a Key Vault access policy that contains the App Service’s password.

D. Enable anonymous access to the Key Vault.

Answer: A

Explanation

A managed identity allows the App Service to authenticate to Azure resources without storing credentials in application configuration. The identity should then receive the minimum Key Vault RBAC permissions required.

B is incorrect because it introduces credentials that must be stored and managed.

C is incorrect because an access policy does not itself eliminate the need for application authentication.

D would violate basic security principles.

Question 2

A Key Vault contains encryption keys used to protect critical business data. Security administrators want to ensure that a deleted key cannot be permanently purged before the configured retention period expires.

Which setting should you configure?

A. Azure Firewall

B. Private Endpoint

C. Purge protection

D. Azure RBAC

Answer: C

Explanation

Purge protection prevents a soft-deleted Key Vault or Key Vault object from being permanently purged before the applicable retention period expires.

Soft delete provides recoverability, while purge protection prevents premature permanent deletion.

Question 3

A security team wants applications to access Key Vault privately from an Azure virtual network. The Key Vault must not be accessible through its public endpoint.

What should you implement?

A. Key Vault access policies

B. A private endpoint and disable public network access

C. Azure RBAC and enable public network access

D. A resource lock on the Key Vault

Answer: B

Explanation

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

RBAC controls authorization; it does not itself create private network connectivity.

A resource lock protects resource management operations but does not provide private network access.

Question 4

An administrator has the Key Vault Contributor role on a Key Vault. The administrator attempts to read a secret but receives an authorization error.

What is the most likely explanation?

A. Key Vault secrets cannot be accessed through Azure RBAC.

B. The administrator must have the Owner role on the subscription.

C. Key Vault requires a private endpoint before secrets can be read.

D. Key Vault Contributor provides management-plane permissions but does not grant access to secret contents.

Answer: D

Explanation

Key Vault Contributor is a control-plane role. It allows management of the Key Vault resource but does not automatically grant access to keys, secrets, or certificates.

A data-plane role, such as an appropriate Key Vault secrets role, must be assigned.

Question 5

A company wants to protect a Key Vault against accidental deletion of secrets. Deleted secrets must remain recoverable for a defined retention period.

Which feature should be enabled?

A. Soft delete

B. Azure Policy

C. Private Link

D. Conditional Access

Answer: A

Explanation

Soft delete places deleted Key Vault objects into a recoverable state instead of immediately permanently deleting them.

Purge protection provides an additional control against permanent deletion, but the basic requirement described here is recoverability after deletion.

Question 6

An organization wants to prevent users from deploying new Key Vaults that allow unrestricted public network access.

Which Azure service should be used to enforce this requirement across subscriptions?

A. Azure Bastion

B. Microsoft Sentinel

C. Azure Policy

D. Azure Private DNS

Answer: C

Explanation

Azure Policy can evaluate and enforce organizational requirements across Azure resources. Key Vault has built-in policies that can audit or deny configurations such as unrestricted public network access.

Azure Private DNS provides name resolution and does not enforce resource configuration.

Question 7

A company uses Azure RBAC for Key Vault. A security administrator should only have elevated permissions when performing a specific administrative task. The organization requires MFA and approval before the administrator receives the elevated role.

What should be used?

A. Azure Resource Lock

B. Microsoft Entra Privileged Identity Management

C. Azure Firewall

D. Azure Private Link

Answer: B

Explanation

Microsoft Entra Privileged Identity Management supports eligible, just-in-time privileged access. Organizations can configure requirements such as MFA and approval for activation.

This reduces the amount of time highly privileged permissions remain active.

Question 8

A company is deploying a new security-sensitive Key Vault. The security team wants a centralized authorization model that supports Azure RBAC and Privileged Identity Management.

Which authorization model should be selected?

A. Key Vault access policies

B. Shared access signatures

C. Anonymous authorization

D. Azure RBAC

Answer: D

Explanation

Azure RBAC is the recommended Key Vault authorization model and integrates with broader Azure authorization capabilities, including Privileged Identity Management.

Access policies are the legacy Key Vault authorization model.

Question 9

An organization has configured a private endpoint for an Azure Key Vault. Applications can reach the virtual network but resolve the Key Vault hostname to an address associated with public connectivity rather than the private endpoint.

What should the administrator investigate first?

A. Private DNS configuration

B. Key Vault soft-delete retention

C. Purge protection

D. Secret expiration dates

Answer: A

Explanation

Private endpoint implementations commonly require appropriate DNS configuration so that the Key Vault hostname resolves to the private endpoint.

Soft delete, purge protection, and secret expiration are unrelated to hostname resolution.

Question 10

A security team wants to reduce the blast radius of a compromised development application. The application currently shares a Key Vault with a production application.

What is the best security improvement?

A. Give the development application the Key Vault Administrator role.

B. Enable anonymous access for development.

C. Separate the Key Vaults by application and environment and grant each workload only the permissions it requires.

D. Store production and development secrets under different secret names in the same vault.

Answer: C

Explanation

A Key Vault should generally be treated as a security boundary. Separating vaults by application and environment reduces the blast radius of a compromise.

Simply separating secrets by name does not provide the same degree of isolation.

Granting development administrators broader permissions would increase risk rather than reduce it.

Key Takeaways

For SC-500: Configure Key Vault settings, remember the following:

RBAC → preferred authorization model

Managed identity → preferred way for Azure workloads to authenticate without stored credentials

Key Vault Contributor → manages the vault resource, not the secrets

Soft delete → recover deleted vaults/objects

Purge protection → prevents premature permanent deletion

Private endpoint → private connectivity to Key Vault

Disable public network access → eliminate public endpoint access

Firewall/network rules → restrict network sources

Private DNS → helps private endpoint name resolution

PIM → just-in-time privileged administration

Azure Policy → enforce Key Vault security standards at scale

Least privilege + defense in depth → the overarching security strategy

The most important exam mindset is to separate identity, authorization, network security, and data-protection requirements. A scenario may require several controls simultaneously, and the best answer is usually the one that satisfies the requirement with the least privilege and least network exposure rather than simply adding a broad administrative role.

Go to the SC-500 Exam Prep Hub main page