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
      --> Manage keys, secrets, and certificates

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 manage sensitive information used by applications, services, and users. Three of its most important object types are:

• Keys — cryptographic keys used for encryption, decryption, signing, and verification.
• Secrets — sensitive values such as passwords, connection strings, API keys, and application credentials.
• Certificates — digital certificates used primarily to establish identity and secure communications, such as TLS/SSL.

For the SC-500 exam, it is important not only to know what each object does, but also to understand how to control access, manage versions, rotate credentials, protect objects from deletion, and monitor their lifecycle.

1. Understanding Key Vault Objects

Keys, secrets, and certificates are all stored as objects in Azure Key Vault, but they serve different purposes.

A common SC-500 exam trap is confusing a key with a secret.

A key is intended to participate in cryptographic operations. A secret is primarily a value that an authorized application retrieves and uses.

For example:

• Database password → Secret
• Encryption key → Key
• HTTPS/TLS certificate → Certificate

2. Managing Keys

Azure Key Vault supports cryptographic keys that can be used by applications and Azure services without requiring the application to directly manage the underlying key material.

Key Vault supports software-protected keys and, depending on the Key Vault configuration/SKU, HSM-protected keys.

Common key types include:

• RSA
• Elliptic Curve (EC)
• HSM-specific key types where supported

Keys can be used for operations such as:

• Encrypt
• Decrypt
• Sign
• Verify
• Wrap
• Unwrap

The application generally receives the result of a cryptographic operation rather than gaining unrestricted access to the underlying key material.

Why this matters

Centralizing cryptographic key management provides:

• Controlled access
• Centralized lifecycle management
• Key versioning
• Rotation capabilities
• Auditing
• Integration with Azure services

3. Key Versions

Azure Key Vault supports multiple versions of keys.

When a key is changed or rotated, a new version can be created rather than overwriting the previous version.

For example:

EncryptionKey
   ├── Version 1
   ├── Version 2
   └── Version 3

This is important because applications and encrypted data may still depend on an earlier version.

A key identifier can therefore identify either:

• A specific key version, or
• The key without specifying a particular version

Exam consideration

If a scenario requires an application to consistently use a particular cryptographic key version, use the version-specific identifier.

If the application should be able to use the current version as the key is rotated, the application can use the appropriate versionless identifier and lifecycle mechanism.

4. Key Rotation

Cryptographic keys should be rotated periodically according to organizational security requirements.

Key Vault supports key rotation capabilities, including automatic rotation for supported key configurations.

A typical rotation process looks like:

Existing Key
     ↓
Create New Key Version
     ↓
Update Consumers
     ↓
Validate New Version
     ↓
Retire Old Version

Rotation reduces the amount of time that a compromised key can remain useful.

Important distinction

Rotation is not the same as deletion.

Rotating a key creates a new version. The older version may still need to remain available for decrypting existing data.

For example, if data was encrypted with Key Version 1, immediately deleting Version 1 could make that data impossible to decrypt.

5. Key Backup and Recovery

Critical keys should have appropriate backup and recovery procedures.

Key Vault provides backup capabilities for supported objects.

However, backup permissions should be carefully restricted because a backup of a key can potentially be restored into another Key Vault.

Therefore:

The ability to back up a cryptographic key is itself a sensitive privilege.

Apply least privilege when assigning permissions related to:

• Backup
• Restore
• Delete
• Purge
• Key management

6. Managing Secrets

Secrets are intended for sensitive values that applications need to retrieve.

Common examples include:

• Database passwords
• API keys
• Connection strings
• Service credentials
• Application passwords
• Tokens
• Other sensitive configuration values

Instead of storing a password in application source code:

connectionString = "Server=...;Password=MyPassword123"

the application should retrieve the secret from Key Vault.

A better architecture is:

Application
     │
     │ Authenticates using its identity
     ↓
Azure Key Vault
     │
     │ Retrieves authorized secret
     ↓
Application

This prevents sensitive credentials from being embedded directly in source code or configuration files.

7. Secret Versions

Secrets are versioned in Key Vault.

For example:

DatabasePassword
   ├── Version 1
   ├── Version 2
   └── Version 3

A new secret value creates a new version.

This is especially useful when rotating credentials.

For example:

1. Create a new database password.
2. Store the new password as a new Key Vault secret version.
3. Update the application or database configuration as appropriate.
4. Verify that applications are using the new credential.
5. Retire the previous credential when it is no longer required.

Important exam concept

Updating a secret does not simply overwrite the existing version. Key Vault maintains secret versions.

8. Secret Expiration and Activation Dates

Secrets can have lifecycle properties that help control when they are usable.

Important properties include:

• Enabled/disabled state
• Activation date
• Expiration date
• Tags

Expiration is particularly useful for credentials that should not remain valid indefinitely.

For example, an organization could establish a policy that application credentials expire every 90 days.

This creates a lifecycle such as:

Create
  ↓
Active
  ↓
Approaching expiration
  ↓
Rotate
  ↓
Disable old credential
  ↓
Delete when appropriate

9. Secret Rotation

Secret rotation is different from key rotation.

A key can have new versions generated through Key Vault’s key-management capabilities.

Secrets, however, frequently represent credentials that must also be changed in the external system that accepts the credential.

For example:

Application
     │
     ├── Gets password from Key Vault
     ↓
Key Vault
     │
     └── Stores database password

Changing the Key Vault secret alone does not necessarily change the password in the database.

A complete secret rotation process may therefore require:

1. Generate a new credential.
2. Update the target system.
3. Store the new credential in Key Vault.
4. Update or restart consuming applications if necessary.
5. Validate access.
6. Retire the old credential.

This is an important distinction for scenario-based questions.

10. Managing Certificates

Azure Key Vault can store and manage digital certificates.

Certificates are commonly used for:

• TLS/SSL
• Application authentication
• Server identity
• Secure communications

A Key Vault certificate includes certificate-related information and is associated with a key and secret representation.

This allows Key Vault to provide certificate lifecycle management rather than requiring administrators to manually distribute certificate files.

11. Certificate Policies

A certificate policy defines how a certificate is created and managed.

Certificate policies can specify information such as:

• Certificate subject
• Validity period
• Key type
• Key size
• Key usage
• Extended key usage
• Issuer
• Renewal behavior

When creating certificates through Key Vault, the policy determines how the certificate should be issued and managed.

12. Certificate Issuers

Key Vault can integrate with supported certificate authorities.

An issuer configuration can be associated with a certificate policy.

This allows Key Vault to request certificates from an integrated certificate authority and manage the resulting certificate lifecycle.

Certificate scenarios can include:

• Self-signed certificates
• Certificates issued by an integrated CA
• Imported certificates

13. Certificate Renewal

Certificates have expiration dates, so certificate lifecycle management is essential.

Key Vault supports certificate renewal capabilities.

Depending on the certificate configuration, Key Vault can:

• Automatically renew a certificate
• Notify contacts about certificate lifecycle events
• Require manual renewal

For certificates that are automatically renewed, the renewal process creates a new certificate version.

Why certificate rotation matters

An expired TLS certificate can cause:

• HTTPS failures
• Application outages
• Authentication failures
• Client trust errors

Automated certificate renewal helps reduce the possibility of outages caused by expired certificates.

14. Certificate Contacts

Key Vault supports certificate contacts for lifecycle notifications.

Contacts can receive notifications related to certificate events, such as upcoming expiration or renewal-related events.

A key point for the exam is that certificate contacts are associated with the Key Vault, rather than being completely independent contacts for every certificate.

Therefore, carefully read scenario questions involving certificate notifications.

15. Certificate Lifecycle Management

A secure certificate lifecycle might look like this:

Create Certificate
       ↓
Deploy Certificate
       ↓
Monitor Lifetime
       ↓
Approaching Expiration
       ↓
Renew Certificate
       ↓
Deploy New Version
       ↓
Retire Previous Version

The goal is to ensure that certificates are renewed before expiration while maintaining application availability.

16. Access Control for Keys, Secrets, and Certificates

One of the most important security concepts is controlling who or what can access Key Vault objects.

Azure Key Vault supports Azure role-based access control (Azure RBAC) as the recommended authorization model for Key Vault data-plane access.

Access should follow the principle of:

Least privilege

An identity should receive only the permissions required to perform its task.

For example:

• An application that only retrieves secrets should not automatically receive permission to manage keys.
• A certificate administrator should not automatically receive permission to retrieve all secrets.
• A security administrator responsible for purge operations should not necessarily receive permission to read application secrets.

17. Separate Permissions for Keys, Secrets, and Certificates

Key Vault permissions are granular.

Depending on the authorization model and role being used, permissions can distinguish between operations involving:

• Keys
• Secrets
• Certificates

For example, a role may permit an identity to manage certificates without granting that identity permission to retrieve application secrets.

This is particularly important in environments where multiple teams share a Key Vault.

Exam scenario

Suppose:

A certificate administrator needs to renew certificates but must not be able to read database passwords stored as secrets.

The appropriate solution should provide certificate-specific permissions rather than granting broad Key Vault access.

18. Azure RBAC and Legacy Access Policies

Key Vault historically supported Key Vault access policies.

Azure RBAC is now the recommended authorization model for Key Vault data-plane access.

When designing new environments, prefer Azure RBAC unless there is a specific compatibility or migration reason to use access policies.

Exam tip

Do not confuse:

• Azure RBAC — authorization through Azure role assignments.
• Key Vault access policies — the older Key Vault-specific authorization model.

Also remember that assigning someone a broad Azure resource-management role does not necessarily mean that they should automatically be able to read every secret, key, or certificate in a vault.

19. Managed Identities and Key Vault

Applications should generally avoid storing credentials used to authenticate to Key Vault.

Azure resources can use managed identities to obtain Microsoft Entra tokens.

For example:

Azure App Service
       │
       │ Managed Identity
       ↓
Microsoft Entra ID
       │
       │ Access token
       ↓
Azure Key Vault
       │
       ↓
Authorized Secret

This eliminates the need to store a Key Vault client secret in the application.

Managed identities can be:

• System-assigned
• User-assigned

The identity must still be granted the appropriate Key Vault permissions.

Critical exam concept

A managed identity provides an identity.

It does not automatically grant access to Key Vault.

You must still authorize the identity appropriately.

20. Soft Delete

Key Vault supports soft delete for protecting against accidental or malicious deletion.

When an object such as a key, secret, or certificate is deleted, it can remain recoverable during the configured retention period.

The retention period can be configured between 7 and 90 days, with 90 days being the default in current Key Vault behavior.

Soft delete essentially provides a recovery mechanism similar to a recycle bin.

For example:

Secret
  ↓
Delete
  ↓
Soft-deleted
  ↓
Recover OR Purge

Soft delete is enabled by default for newly created Key Vaults and cannot be disabled once enabled.

21. Purge Protection

Purge protection provides stronger protection than soft delete.

Without purge protection:

Delete
  ↓
Soft Delete
  ↓
Purge
  ↓
Permanent deletion

With purge protection:

Delete
  ↓
Soft Delete
  ↓
Purge blocked during retention period
  ↓
Recover OR wait for retention period

Purge protection is especially important for keys that protect encrypted data.

Exam distinction

Soft delete:

Protects against accidental deletion by allowing recovery.

Purge protection:

Prevents permanent deletion during the retention period.

Purge protection can only be enabled after soft delete is enabled.

Once purge protection is enabled, it cannot simply be disabled or overridden to immediately purge an object.

22. Key Vault Object Deletion

The lifecycle of an object can therefore involve several states:

Active
  │
  ├── Disable
  │
  └── Delete
        │
        ↓
   Soft-deleted
        │
        ├── Recover
        │
        └── Purge

The distinction between disable, delete, and purge is important.

Disable

The object remains present but is not available for normal use.

Delete

The object enters the deleted state when soft delete is enabled.

Purge

The object is permanently deleted.

23. Monitoring Key, Secret, and Certificate Operations

Security teams should monitor operations performed against Key Vault.

Examples include:

• Key creation
• Key rotation
• Secret retrieval
• Secret modification
• Certificate creation
• Certificate renewal
• Deletion
• Recovery
• Purge
• Unauthorized access attempts

Key Vault diagnostic logging can be integrated with Azure Monitor and Microsoft Sentinel to support security monitoring and investigation.

This allows organizations to detect suspicious activity such as:

An identity that normally retrieves a secret suddenly attempts to delete or purge multiple Key Vault objects.

24. Defense in Depth for Key Vault

Securing the objects themselves is only one layer of Key Vault security.

A defense-in-depth design can combine:

Identity

• Microsoft Entra ID
• Managed identities
• MFA
• Conditional Access
• Privileged Identity Management

Authorization

• Azure RBAC
• Least privilege
• Separation of duties

Network

• Private endpoints
• Firewall/network restrictions
• Restricted public access

Data protection

• Soft delete
• Purge protection
• Key rotation
• Secret rotation
• Certificate renewal

Monitoring

• Diagnostic logs
• Azure Monitor
• Microsoft Defender for Cloud
• Microsoft Sentinel

The strongest architecture combines these controls rather than depending on a single security mechanism.

25. Keys vs. Secrets vs. Certificates — Exam Comparison

26. Common SC-500 Exam Traps

Trap 1: Confusing a secret with a key

A password is a secret, not a cryptographic key.

Trap 2: Assuming managed identity automatically grants Key Vault access

It doesn’t.

The managed identity must be authorized.

Trap 3: Confusing soft delete with purge protection

Soft delete allows recovery.

Purge protection prevents permanent deletion during the retention period.

Trap 4: Assuming rotation means deletion

Rotation creates a new version. Older versions may still be required.

Trap 5: Assuming updating a secret changes the external credential

If a secret represents a database password, changing the Key Vault value does not automatically change the password in the database.

Trap 6: Giving applications excessive Key Vault permissions

If an application only needs to retrieve one secret, don’t grant it broad administrative permissions.

Trap 7: Treating certificate expiration as an access-control problem

Certificate expiration is primarily a lifecycle-management issue. Use renewal/autorotation and appropriate notifications.

Trap 8: Assuming Key Vault network restrictions replace authorization

Network controls restrict where requests can originate.

Authorization determines what an authenticated identity is allowed to do.

Both are important.

27. Scenario-Based Decision Framework

When answering an SC-500 question involving Key Vault, ask these questions in order:

Step 1 — What type of object is involved?

• Encryption/signing → Key
• Password/API key/credential → Secret
• TLS/digital identity → Certificate

Step 2 — Who needs access?

Identify:

• User
• Application
• Managed identity
• Administrator
• Service principal

Step 3 — What operation is required?

Examples:

• Get
• List
• Create
• Update
• Rotate
• Delete
• Recover
• Purge
• Backup

Step 4 — What is the least privilege required?

Select the narrowest appropriate role or permission.

Step 5 — Is network isolation required?

Consider:

• Private endpoint
• Firewall/network restrictions
• Public network access

Step 6 — What lifecycle protection is required?

Consider:

• Rotation
• Expiration
• Soft delete
• Purge protection
• Backup/recovery

Step 7 — What monitoring is required?

Consider:

• Diagnostic logs
• Azure Monitor
• Defender for Cloud
• Microsoft Sentinel

This decision process can eliminate many incorrect answers on scenario-based questions.

28. Key Takeaways

For the SC-500 exam, remember these core principles:

1. Keys perform cryptographic operations.
2. Secrets store sensitive values.
3. Certificates provide digital identity and secure communications.
4. All three object types support lifecycle management and versioning.
5. Use Azure RBAC and least privilege to control access.
6. Managed identities eliminate the need to store application credentials for Azure resource authentication.
7. Soft delete protects against accidental or malicious deletion by enabling recovery.
8. Purge protection prevents permanent deletion during the retention period.
9. Key rotation creates new key versions; it does not necessarily mean deleting older versions.
10. Secret rotation may require coordination with the external system whose credential is being changed.
11. Certificate renewal should be automated whenever practical.
12. Key Vault security should combine identity, authorization, network controls, data protection, and monitoring.
13. Never grant an application more Key Vault permissions than it requires.
14. Monitor sensitive Key Vault operations, especially deletion, recovery, purge, and unusual secret access.

Practice Exam Questions

Question 1

An organization stores database passwords in Azure Key Vault. An Azure App Service needs to retrieve one of the passwords without storing any credentials in the application configuration.

Which solution should you implement?

A. Store a Key Vault administrator password in the App Service configuration.

B. Enable a managed identity for the App Service and grant it the minimum required Key Vault data-plane permissions.

C. Grant the App Service subscription Owner permissions.

D. Create a certificate and store the certificate password in the application configuration.

Answer: B

Explanation:
A managed identity allows the App Service to authenticate to Azure resources without storing credentials in application code or configuration. The identity must then be granted the appropriate least-privilege Key Vault permissions. Granting Owner permissions would violate least privilege.

Question 2

A security administrator wants to ensure that a deleted Key Vault secret can be recovered if an administrator accidentally deletes it.

Which Key Vault feature provides this capability?

A. Azure Firewall

B. Soft delete

C. Private Link

D. Azure RBAC

Answer: B

Explanation:
Soft delete retains deleted Key Vault objects for a configurable retention period so they can be recovered. Private Link provides network isolation, Azure RBAC provides authorization, and Azure Firewall provides network traffic filtering.

Question 3

A company uses an encryption key stored in Azure Key Vault. The security team wants to prevent an administrator from permanently deleting the key during its retention period, even if the administrator has significant privileges.

Which feature should be enabled?

A. Key expiration

B. Key versioning

C. Purge protection

D. Certificate autorenewal

Answer: C

Explanation:
Purge protection prevents permanently purging a soft-deleted Key Vault object during the configured retention period. This provides protection against malicious or accidental permanent deletion.

Question 4

An application stores a database password as a secret in Azure Key Vault. The database administrator changes the actual database password but forgets to update Key Vault.

What is the most likely result?

A. Key Vault automatically discovers the new password.

B. Key Vault automatically changes the database password.

C. The application continues retrieving the old password from Key Vault.

D. The Key Vault secret is automatically deleted.

Answer: C

Explanation:
Key Vault stores the secret value; it does not automatically know that an external system’s credential has changed. Secret rotation often requires coordination between the external system, Key Vault, and consuming application.

Question 5

An organization needs to store an asymmetric cryptographic object that an application will use for signing and verification.

Which Key Vault object should be used?

A. Secret

B. Key

C. Certificate contact

D. Resource lock

Answer: B

Explanation:
Cryptographic keys are designed for operations such as signing and verification. Secrets are intended for sensitive values such as passwords and connection strings. A certificate may contain an associated key, but the cryptographic operation itself is performed using the key.

Question 6

A company manages several TLS certificates in Azure Key Vault. Security administrators want to receive notifications about certificate lifecycle events.

What should they configure?

A. Certificate contacts

B. Key Vault resource locks

C. Secret tags

D. Azure Firewall application rules

Answer: A

Explanation:
Key Vault supports certificate contacts for certificate lifecycle notifications. Contacts can receive notifications associated with certificate events such as renewal and expiration.

Question 7

A security team rotates an Azure Key Vault encryption key. Existing encrypted data was encrypted using the previous key version.

What should the security team consider before removing the previous key version?

A. The previous version is always automatically converted into a secret.

B. The previous version is irrelevant after a new version is created.

C. Existing encrypted data may still require the previous key version for decryption.

D. Key Vault automatically decrypts all existing data when a key is rotated.

Answer: C

Explanation:
Key rotation creates a new version, but existing data may still have been encrypted with an earlier version. Removing an old version prematurely can prevent applications from decrypting existing data.

Question 8

An organization wants an application to retrieve secrets from Key Vault but does not want the application to have permission to manage or purge keys.

Which security principle should guide the design?

A. Grant the application the Key Vault Owner role.

B. Grant the application broad subscription-level Contributor permissions.

C. Grant the application only the specific Key Vault data-plane permissions it requires.

D. Disable Microsoft Entra authentication.

Answer: C

Explanation:
Least privilege requires granting only the permissions necessary for the application’s task. If the application only needs to retrieve secrets, it should not receive administrative permissions over keys or the vault.

Question 9

A company has enabled soft delete on a Key Vault. A malicious administrator deletes a critical encryption key and immediately attempts to permanently purge it.

What feature is designed to prevent the purge during the retention period?

A. Key rotation

B. Purge protection

C. Certificate renewal

D. Secret versioning

Answer: B

Explanation:
Soft delete makes the object recoverable after deletion. Purge protection goes further by preventing permanent deletion during the configured retention period. It is particularly important for protecting keys used to encrypt important data.

Question 10

An organization wants to prevent its application from storing a Key Vault credential while accessing secrets from Key Vault.

Which approach is most appropriate for an Azure-hosted application?

A. Store the Key Vault administrator password in source code.

B. Store a service principal secret in an application configuration file.

C. Use a managed identity and grant it the required Key Vault permissions.

D. Grant anonymous access to the Key Vault.

Answer: C

Explanation:
Managed identities allow Azure resources to authenticate to supported services without requiring credentials to be stored in application code or configuration. The managed identity must still be granted appropriate Key Vault permissions.

Final Exam Reminder

When you see an SC-500 scenario involving Azure Key Vault, don’t immediately jump to the feature name. First determine what is being protected and what operation is required.

A useful mental model is:

What is it? → Who needs it? → What can they do? → How is it protected? → How is it rotated/recovered? → How is it monitored?

If the question involves a password, connection string, or API credential, think secret.

If it involves encryption, decryption, signing, or verification, think key.

If it involves TLS, identity, or secure communications, think certificate.

If it involves recovering deleted objects, think soft delete.

If it involves preventing permanent deletion, think purge protection.

If it involves application authentication without stored credentials, think managed identity.

And if it asks how to limit what an application can do, think least privilege and Azure RBAC.

Go to the SC-500 Exam Prep Hub main page