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
      --> Deploy 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 a cloud service designed to securely store and control access to secrets, cryptographic keys, and certificates. For the SC-500 exam, understanding how to deploy a security-hardened Key Vault is particularly important because deployment decisions can establish the security posture of the vault before applications begin using it.

A secure Key Vault deployment should consider:

• Authentication and authorization
• Azure RBAC versus access policies
• Soft delete
• Purge protection
• Network access restrictions
• Private endpoints
• Firewall rules
• Public network access
• Azure Policy
• Resource deployment through the Azure portal, CLI, PowerShell, ARM, or Bicep
• Separation of management-plane and data-plane permissions

The key exam concept is that deploying a Key Vault is not simply creating the resource. The deployment should establish appropriate security controls that protect the secrets and cryptographic material stored within it.

1. What Is Azure Key Vault?

Azure Key Vault provides centralized protection for sensitive information used by applications and services.

Common objects stored in Key Vault include:

Instead of embedding a database password or API key directly in application configuration, an application can retrieve the value from Key Vault at runtime.

For example:

Application
     |
     | Authenticate
     v
Microsoft Entra ID
     |
     | Authorized request
     v
Azure Key Vault
     |
     v
Secret / Key / Certificate

This reduces the need to place sensitive credentials in source code, configuration files, deployment scripts, or application settings.

2. Key Vault Has Two Security Planes

One of the most important concepts to understand for the SC-500 exam is the distinction between the control plane and data plane.

Control Plane

The control plane manages the Key Vault resource itself.

Examples include:

• Creating a Key Vault
• Deleting a Key Vault
• Updating Key Vault properties
• Configuring networking
• Configuring diagnostic settings
• Managing resource tags
• Managing certain resource-level settings

These operations are managed through Azure Resource Manager.

Azure RBAC is used to control management-plane access.

For example, the Key Vault Contributor role provides management capabilities for Key Vault resources but does not automatically grant permission to read secrets.

Data Plane

The data plane manages the contents of the vault.

Examples include:

• Reading secrets
• Creating secrets
• Deleting secrets
• Creating keys
• Encrypting data with keys
• Decrypting data with keys
• Managing certificates

Data-plane permissions are particularly important because they determine who can actually access sensitive information.

Therefore:

Being able to manage a Key Vault does not necessarily mean that you can read the secrets stored inside it.

This distinction is a common source of exam questions.

3. Azure RBAC for Key Vault

Azure Key Vault supports Azure role-based access control for controlling access to Key Vault data.

With RBAC, permissions can be assigned at appropriate scopes, such as:

• Management group
• Subscription
• Resource group
• Key Vault
• Individual Key Vault objects where supported

Examples of Key Vault-related roles include:

• Key Vault Administrator
• Key Vault Secrets Officer
• Key Vault Secrets User
• Key Vault Crypto Officer
• Key Vault Crypto User
• Key Vault Certificates Officer
• Key Vault Reader
• Key Vault Purge Operator

The appropriate role depends on what the identity actually needs to do.

Example

Suppose an application only needs to retrieve secrets.

Giving its managed identity Key Vault Administrator would violate least privilege.

A more appropriate role is generally:

Key Vault Secrets User

The important exam principle is:

Assign the smallest Key Vault role that provides the required data-plane permissions.

Azure RBAC is now the default authorization model for newly created vaults when using the current Key Vault API version that introduced that default. Existing vaults retain their existing access model unless changed.

4. Key Vault Access Policies

Key Vault also supports the older vault access policy authorization model.

With access policies, permissions are explicitly configured for identities and can specify operations involving:

• Keys
• Secrets
• Certificates

For example, an identity might be allowed to:

Secrets:
  Get
  List
Keys:
  None
Certificates:
  None

This allows the identity to retrieve secrets without granting access to keys or certificates.

RBAC vs. Access Policies

For exam purposes, remember:

When RBAC authorization is enabled for a vault, the vault’s access policies are ignored for data-plane authorization.

5. Enable Soft Delete

Soft delete protects a Key Vault and its objects from immediate permanent deletion.

When an object is deleted, it enters a recoverable state instead of immediately disappearing permanently.

Soft delete applies to objects such as:

• Secrets
• Keys
• Certificates
• Key Vaults

The retention period can be configured from 7 to 90 days, with 90 days as the default. For newly created vaults, soft delete is enabled by default. Once enabled, it cannot be disabled.

Example

Suppose an administrator accidentally deletes:

Production-Key-Vault
    |
    +-- DatabasePassword

With soft delete enabled:

Delete DatabasePassword
        |
        v
Soft-deleted state
        |
        +---- Recover
        |
        +---- Eventually purge

This provides a recovery window.

Important exam distinction

Soft delete does not prevent deletion.

It makes deletion recoverable.

That distinction is important.

6. Enable Purge Protection

Purge protection provides an additional layer of protection against permanent deletion.

Without purge protection, a sufficiently privileged administrator can potentially:

1. Delete an object.
2. Permanently purge the soft-deleted object.

With purge protection enabled, the object cannot be permanently purged until the applicable retention period has elapsed.

Purge protection requires soft delete and is irreversible once enabled.

Think of the two features this way

Soft delete:

“You deleted it, but we can recover it.”

Purge protection:

“You cannot permanently destroy it during the retention period.”

This is particularly important for keys used to protect encrypted data.

If an encryption key is permanently destroyed, encrypted data might become inaccessible.

Microsoft therefore recommends purge protection for scenarios involving keys used for encryption.

7. Soft Delete vs. Purge Protection

This distinction is highly exam-worthy.

Scenario

An organization stores customer encryption keys in Key Vault.

The security team wants to ensure that even a highly privileged administrator cannot permanently delete a key during the retention period.

The appropriate configuration is:

Soft delete + purge protection

8. Key Vault Network Security

Identity-based authorization is only one layer of Key Vault security.

You should also control where network traffic can originate.

Key Vault supports several network-security mechanisms, including:

• Public network access
• Firewall/network rules
• Virtual network service endpoints
• Private endpoints
• Private Link
• Trusted Microsoft services exceptions

The most restrictive architecture is generally to disable public network access and use private endpoints when the workload architecture supports it.

9. Public Network Access

A Key Vault can be accessible through its public endpoint.

However, simply requiring authentication doesn’t necessarily provide the network isolation that an organization might require.

For sensitive enterprise workloads, you may want to restrict access to known networks or eliminate public data-plane access entirely.

Azure Key Vault supports disabling public network access so that data-plane connections must use private connectivity.

10. Key Vault Firewall

A Key Vault firewall allows you to restrict access to approved network sources.

You can configure network rules to limit access based on permitted sources.

For example:

Internet
   |
   X
   |
Key Vault Firewall
   |
   +---- Approved network
   |
   +---- Approved IP

This provides network-level defense in addition to identity-based authorization.

Azure Policy can also be used to require Key Vault firewall configuration across an environment.

11. Private Endpoints

A private endpoint provides a private IP address within an Azure virtual network for accessing the Key Vault service.

Conceptually:

Azure VNet
   |
   | Private IP
   v
Private Endpoint
   |
   v
Azure Key Vault

This allows applications in a virtual network to access Key Vault using private connectivity rather than exposing the data-plane connection through the public network.

For highly restricted environments, a common architecture is:

Application
     |
     v
Virtual Network
     |
     v
Private Endpoint
     |
     v
Key Vault
Public Network Access = Disabled

Azure’s current security guidance identifies disabling public network access and using private endpoints as the most restricted network-security configuration.

12. Private DNS

Private endpoints normally require appropriate DNS configuration so that the Key Vault hostname resolves to the private endpoint rather than the public endpoint.

A typical architecture uses an Azure Private DNS zone associated with the virtual network.

Conceptually:

Application
     |
     | vault-name.vault.azure.net
     v
Private DNS
     |
     | Resolves to private IP
     v
Private Endpoint
     |
     v
Key Vault

This is an important practical consideration when deploying private Key Vault connectivity.

13. Trusted Microsoft Services

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

Key Vault network rules can allow trusted Microsoft services to bypass certain network restrictions.

However, this should not automatically be enabled simply because it is convenient.

The security principle is:

Enable exceptions only when they are required by the architecture.

This follows the broader principle of minimizing network exposure.

14. Deploy Key Vault with Security Controls at Creation Time

For security-sensitive environments, it is preferable to establish important controls during deployment rather than creating an insecure vault and hardening it later.

A deployment might establish:

Key Vault
│
├── Azure RBAC
├── Soft delete
├── Purge protection
├── Network restrictions
├── Private endpoint
├── Private DNS
└── Diagnostic logging

Infrastructure-as-code is particularly useful because the configuration can be standardized and repeatedly deployed.

Azure provides deployment options through:

• Azure portal
• Azure CLI
• Azure PowerShell
• ARM templates
• Bicep
• REST APIs

For example, Bicep can define a Key Vault with RBAC, soft delete, purge protection, and network settings as part of the infrastructure definition.

15. Example Bicep Deployment

A simplified example looks like this:

param keyVaultName string
param location string = resourceGroup().location
param tenantId string = subscription().tenantId
resource keyVault 'Microsoft.KeyVault/vaults@2025-05-01' = {
  name: keyVaultName
  location: location
  properties: {
    tenantId: tenantId
    enableRbacAuthorization: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    publicNetworkAccess: 'Disabled'
  }
}

The important point for SC-500 is not memorizing the syntax.

Instead, understand what security controls are being established:

• RBAC authorization
• Soft delete
• Purge protection
• Restricted public network access

Actual Bicep property availability and API-version behavior should always be checked against the API version being used for the deployment.

16. Deploying with Azure Policy

Azure Policy can help organizations ensure that Key Vault deployments meet security requirements.

For example, policies can audit or deny Key Vaults that don’t meet organizational requirements.

Policies can be used for requirements such as:

• Soft delete
• Purge protection
• RBAC authorization
• Firewall configuration
• Private endpoints
• Disabled public network access
• Diagnostic logging

For example:

Policy:
Key Vaults must have purge protection enabled
             |
             v
New Key Vault
             |
       +-----+-----+
       |           |
     Meets       Doesn't
    policy       comply
       |           |
       v           v
     Allow        Deny

Depending on the policy definition and effect, Azure Policy can audit, deny, modify, or deploy supporting configuration.

17. Resource Locks vs. Purge Protection

These features can sometimes be confused.

A resource lock protects an Azure resource from certain management-plane operations.

For example:

• Delete
• Modification, depending on lock type

A Key Vault’s purge protection, on the other hand, specifically addresses permanent deletion of the vault or its objects after they enter a deleted state.

They solve different problems.

Exam tip

If a question says:

“Prevent administrators from permanently purging deleted Key Vault secrets during the retention period.”

Think:

Purge protection

If it says:

“Prevent users from deleting the Azure resource.”

Think about:

Resource locks, assuming the scenario calls for that type of management-plane protection.

18. Key Vault and Managed Identities

Applications should generally avoid storing credentials for accessing Key Vault.

Instead, Azure resources can use managed identities.

For example:

Azure App Service
      |
      | Managed Identity
      v
Microsoft Entra ID
      |
      | Token
      v
Azure Key Vault
      |
      | Authorized by RBAC
      v
Secret

This removes the need for the application to store a client secret or certificate for authenticating to Key Vault.

For example, an App Service could have a system-assigned managed identity and receive the Key Vault Secrets User role.

The application then obtains an access token through its managed identity and uses that token to access the required secret.

This is one of the most important patterns to understand when combining the SC-500 topics managed identities, RBAC, and Key Vault.

19. Least Privilege

When deploying Key Vault, don’t focus only on protecting the vault itself.

Also determine who or what needs access to what.

For example:

Application

Needs:

Secret:
    Get

It probably doesn’t need:

Create
Delete
Purge
Manage permissions
Manage keys
Manage certificates

Security administrator

May require:

Key management
Certificate management
Security configuration

Key Vault administrator

May require broader permissions.

The objective is:

Give each identity only the permissions required to perform its job.

This is particularly important when using Azure RBAC because broad built-in roles can provide substantially more access than an application requires.

20. Key Vault Deployment Security Checklist

For SC-500 preparation, use the following checklist when evaluating a Key Vault deployment.

Identity and authorization

• Use Microsoft Entra ID.
• Prefer managed identities for Azure workloads.
• Use Azure RBAC for modern deployments.
• Assign least-privilege roles.
• Avoid unnecessarily broad roles such as Key Vault Administrator.
• Separate management-plane and data-plane permissions.

Data protection

• Enable soft delete.
• Use an appropriate retention period.
• Enable purge protection for sensitive workloads.
• Pay particular attention to keys used for encryption.

Network security

• Restrict public network access when appropriate.
• Configure firewall/network rules.
• Use private endpoints for highly restricted workloads.
• Configure private DNS appropriately.
• Minimize trusted-service exceptions.

Governance

• Use Azure Policy to enforce security requirements.
• Use infrastructure as code for repeatable secure deployments.
• Consider resource locks where management-plane deletion protection is required.

Monitoring

• Configure diagnostic logging.
• Monitor Key Vault operations.
• Integrate relevant security events with your monitoring and security platform.

21. Key SC-500 Concepts to Remember

If you remember only a few things from this topic, remember these:

1. Control plane ≠ data plane

Being able to manage a Key Vault resource doesn’t automatically mean being able to read its secrets.

2. Soft delete ≠ purge protection

Soft delete provides recoverability.

Purge protection prevents permanent deletion during the retention period.

3. Managed identity + RBAC is a strong application pattern

Avoid storing credentials in application configuration when a managed identity can be used.

4. Private endpoint ≠ RBAC

A private endpoint controls network connectivity.

RBAC controls authorization.

They solve different security problems and can be used together.

5. Azure Policy provides governance

Use policy to help ensure Key Vaults consistently meet organizational security requirements.

6. Least privilege applies to Key Vault

Don’t give an application administrator-level Key Vault permissions when it only needs to retrieve a secret.

Practice Exam Questions

Question 1

A company deploys an Azure Key Vault that stores encryption keys for production databases. The security team wants to ensure that a malicious administrator cannot permanently purge a deleted key during the configured retention period.

Which configuration should you enable?

A. Azure Resource Manager read-only lock

B. Azure Firewall

C. Purge protection

D. Private endpoint

Answer: C

Explanation: Purge protection prevents a soft-deleted Key Vault or Key Vault object from being permanently purged during the retention period. It is particularly important for keys used to protect encrypted data. A firewall and private endpoint protect network access, while a resource lock addresses management-plane operations rather than Key Vault’s purge mechanism.

Question 2

An Azure App Service needs to retrieve a database password stored in Azure Key Vault. The organization wants to avoid storing credentials for accessing Key Vault in the application.

What should you implement?

A. A system-assigned managed identity for the App Service

B. A Key Vault access key stored in App Service configuration

C. A storage account access key

D. A certificate stored in the application source code

Answer: A

Explanation: A managed identity allows the App Service to authenticate to Microsoft Entra ID without the application having to manage credentials. The identity can then be granted an appropriate Key Vault RBAC role, such as Key Vault Secrets User, based on the required access.

Question 3

A security administrator can create and delete Azure Key Vault resources but cannot retrieve secrets stored in those vaults.

Is this behavior expected?

A. No. Anyone who can delete a vault can read its secrets.

B. No. Key Vault automatically grants all management permissions to the data plane.

C. Yes, but only when the vault has a private endpoint.

D. Yes. Management-plane permissions and data-plane permissions are separate.

Answer: D

Explanation: Azure Key Vault separates management of the Key Vault resource from access to the data stored in the vault. An identity can have control-plane permissions without automatically receiving permission to read keys, secrets, or certificates.

Question 4

An organization wants deleted Key Vault secrets to remain recoverable for a period of time after accidental deletion.

Which feature should be enabled?

A. Azure Private Link

B. Soft delete

C. Azure Firewall

D. Resource lock

Answer: B

Explanation: Soft delete retains deleted Key Vault objects in a recoverable state for the configured retention period. It protects against accidental or malicious deletion but does not by itself prevent a sufficiently privileged user from eventually purging the object.

Question 5

A company requires that an Azure application access Key Vault without traversing the public network. The application runs inside an Azure virtual network.

Which solution provides private network connectivity to Key Vault?

A. Azure RBAC

B. Key Vault access policies

C. Private endpoint

D. Resource lock

Answer: C

Explanation: A private endpoint provides a private IP address in the virtual network for accessing the Key Vault service. Azure RBAC and access policies control authorization; they do not provide private network connectivity.

Question 6

A Key Vault contains secrets used by several applications. Application A only needs to retrieve secrets. Application B needs to manage secrets. The security team wants to follow the principle of least privilege.

What is the best approach?

A. Give both applications Key Vault Administrator

B. Give both applications Key Vault Reader

C. Give Application A and Application B identical permissions

D. Assign each application the minimum appropriate Key Vault RBAC role

Answer: D

Explanation: Least privilege means giving identities only the permissions required for their functions. An application that only retrieves secrets should not receive administrative permissions, while an application that manages secrets requires broader permissions.

Question 7

A security team wants to ensure that newly deployed Key Vaults cannot be created without purge protection enabled.

Which Azure service is most appropriate for enforcing this requirement across an Azure environment?

A. Azure Policy

B. Azure Bastion

C. Azure Private DNS

D. Microsoft Entra Connect

Answer: A

Explanation: Azure Policy can audit or deny Key Vault deployments that don’t satisfy organizational requirements. This allows security requirements to be applied consistently rather than relying solely on administrators to configure each vault correctly.

Question 8

A company wants to prevent public network access to a Key Vault. Applications inside a virtual network must continue to access it privately.

Which combination is most appropriate?

A. Enable public network access and assign Key Vault Reader

B. Disable public network access and configure a private endpoint

C. Enable a resource lock and assign Key Vault Contributor

D. Enable soft delete and disable Microsoft Entra authentication

Answer: B

Explanation: A private endpoint provides private connectivity from the virtual network to Key Vault, while disabling public network access prevents public data-plane connectivity. The two controls address network exposure rather than authorization.

Question 9

An administrator is designing a Key Vault deployment using Bicep. The security requirements state that the vault must use Azure RBAC, retain deleted objects for 90 days, and prevent purge during that period.

Which combination should the deployment configure?

A. Azure RBAC, soft delete, and purge protection

B. Access policies, a resource lock, and Azure Firewall

C. Private DNS, Azure Bastion, and soft delete

D. Azure Policy, managed identity, and a VPN gateway

Answer: A

Explanation: Azure RBAC establishes the authorization model, soft delete provides recoverability, and purge protection prevents permanent deletion during the retention period. These controls directly satisfy the stated requirements.

Question 10

A company has enabled Azure RBAC authorization on a Key Vault. An administrator adds an access policy granting an application permission to retrieve secrets. The application still cannot retrieve the secrets.

What is the most likely explanation?

A. Access policies cannot be used with Azure Key Vault

B. The private endpoint is automatically blocking the application

C. Azure RBAC authorization causes the configured access policies to be ignored for data-plane authorization

D. Soft delete must be disabled before access policies can be used

Answer: C

Explanation: When a Key Vault is configured to use Azure RBAC for data-plane authorization, the vault’s access policies are not used to authorize data-plane operations. The application should instead receive an appropriate Key Vault RBAC role assignment.

Final Exam Takeaways

For SC-500 — Deploy Key Vault, think about the deployment as a defense-in-depth exercise:

                    Azure Key Vault
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
     Identity         Data Protection    Network
        │                 │                 │
   Entra ID            Soft Delete       Firewall
   Azure RBAC          Purge Protection  Private Endpoint
   Managed Identity                     Public Access
   Least Privilege                      Private DNS
        │                 │                 │
        └─────────────────┼─────────────────┘
                          │
                     Governance
                          │
                     Azure Policy
                          │
                    Monitoring

The most important distinctions to have firmly memorized are:

The central SC-500 mindset is: don’t rely on a single control. Secure Key Vault through layered identity, authorization, data-protection, network, governance, and monitoring controls.

Go to the SC-500 Exam Prep Hub main page