This chapter covers Azure Key Vault from a developer's perspective, focusing on how to securely store and access secrets, keys, and certificates in your applications. Key Vault is a critical component of the AZ-204 exam's Security domain (Objective 3.2), appearing in roughly 10-15% of exam questions. You'll learn the mechanisms behind Key Vault's operations, how to integrate it with your code, and the exact values and configurations the exam tests. Mastering Key Vault is essential for architecting secure Azure solutions that protect sensitive information.
Jump to a section
Think of Azure Key Vault as a bank's safe deposit box system. The vault itself is the bank branch — a hardened, monitored facility. Inside, each safe deposit box is a separate key vault secret, key, or certificate. To access a box, you must present two things: a valid key (the vault's URI) and proper identification (a Microsoft Entra ID token). The bank teller (Key Vault's authentication layer) verifies your identity against a list of authorized personnel (access policies) before allowing you to open the box. Once opened, you can retrieve the contents (secret value), but the teller never gives you the box itself — only its contents. Crucially, the box contents are stored encrypted at rest using a hardware security module (HSM) — like the bank's vault door. If you lose your key (compromised credentials), the bank can revoke your access instantly. The bank also rotates the locks periodically (key rotation) without you needing to change your keychain. This mirrors how Key Vault separates the responsibility of storing secrets from the applications that use them, providing centralized access control, auditing, and automatic rotation.
What is Azure Key Vault and Why Does It Exist?
Azure Key Vault is a cloud service for securely storing and accessing secrets, cryptographic keys, and certificates. It solves the fundamental problem of how to manage sensitive information in applications. Without Key Vault, developers often hard-code secrets in configuration files, environment variables, or source code — all of which are vulnerable to exposure. Key Vault provides a centralized, hardware-backed (HSM) store with fine-grained access control, auditing, and automatic rotation.
For the AZ-204 exam, you need to understand three main object types: secrets (e.g., connection strings, passwords, API keys), keys (cryptographic keys for encryption/signing), and certificates (X.509 certificates managed by Key Vault). The exam tests how to create, retrieve, and manage these objects using the Azure SDK, REST API, and Azure CLI.
How Key Vault Works Internally
When you create a Key Vault in Azure, it is backed by a tenant-specific HSM pool. Each vault has a unique DNS name (e.g., myvault.vault.azure.net) that serves as the endpoint for all operations. Authentication is handled via Microsoft Entra ID (formerly Azure AD). To access a vault, you must have a valid OAuth 2.0 token from Microsoft Entra ID, which you obtain by authenticating with a service principal, managed identity, or user principal.
Once authenticated, authorization is enforced through access policies (for secrets, keys, and certificates) or Azure RBAC (for management plane operations). Access policies specify which security principals (users, groups, service principals) can perform specific operations (e.g., get, set, delete, list) on each object type. The vault also supports soft-delete (default enabled) and purge protection to prevent accidental permanent deletion.
Key Components, Values, and Defaults
Vault URI: https://<vault-name>.vault.azure.net
Soft-delete retention period: 90 days (configurable during creation, but once enabled, cannot be changed).
Purge protection: When enabled, vaults and objects cannot be purged until the retention period expires.
Access policies: Up to 1024 access policy entries per vault.
Throttling limits: 2000 operations per second per vault for secrets, 1000 for keys, 500 for certificates (subject to change; always check latest docs).
Key types: RSA (2048, 3072, 4096), EC (P-256, P-384, P-521, P-256K), and symmetric (AES 128, 192, 256) — but symmetric keys are only for Managed HSM, not standard Key Vault.
Secrets: Up to 25 KB per secret (value is stored as a byte array).
Certificates: Key Vault can generate self-signed certificates or import existing ones. It supports automatic renewal with Certificate Authority integration.
Configuration and Verification Commands
To create a Key Vault using Azure CLI:
az keyvault create --name myvault --resource-group myrg --location eastus --enable-soft-delete true --enable-purge-protection trueTo add a secret:
az keyvault secret set --vault-name myvault --name mysecret --value "MySecretValue123"To retrieve a secret:
az keyvault secret show --vault-name myvault --name mysecret --query value -o tsvTo set an access policy:
az keyvault set-policy --name myvault --object-id <object-id> --secret-permissions get listTo enable managed identity for an Azure resource (e.g., VM) and grant access:
az vm identity assign --resource-group myrg --name myvm
az keyvault set-policy --name myvault --object-id <managed-identity-principal-id> --secret-permissions getHow Key Vault Interacts with Related Technologies
Key Vault integrates deeply with other Azure services:
- Azure App Service: You can reference Key Vault secrets in app settings using @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/). This is called Key Vault References.
- Azure Functions: Same as App Service — use Key Vault references in application settings.
- Azure Kubernetes Service (AKS): Use the Secrets Store CSI driver to mount secrets as volumes or environment variables.
- Azure DevOps: Link Key Vault to variable groups for pipeline secrets.
- Azure Policy: Enforce Key Vault settings (e.g., require soft-delete, disable public network access).
For developers, the most common pattern is to use Managed Identities to authenticate to Key Vault from Azure resources (VMs, App Services, Functions). This eliminates the need to store credentials in code. The managed identity automatically obtains a Microsoft Entra ID token that Key Vault accepts.
Access Control: Access Policies vs. Azure RBAC
Key Vault supports two authorization models: vault access policies (legacy) and Azure RBAC (newer). Access policies are scoped to a specific vault and grant permissions on secrets, keys, and certificates. Azure RBAC allows you to use built-in roles (e.g., Key Vault Secrets User) at management plane scope (subscription, resource group, vault). The exam expects you to know that RBAC is the preferred model for centralized management, but access policies are still widely used.
Soft-Delete and Purge Protection
Soft-delete is enabled by default for all new vaults. When you delete a secret, key, or certificate, it becomes disabled and can be recovered within the retention period (90 days). To permanently delete, you must purge the object. Purge protection prevents purging until the retention period ends. This is critical for compliance and accidental deletion scenarios.
Key Vault Firewall and Virtual Network Service Endpoints
To secure Key Vault, you can restrict network access using firewall rules and service endpoints. You can allow access only from specific virtual networks or IP addresses. When using service endpoints, traffic from the VNet to Key Vault stays on the Microsoft backbone. The exam tests that you can configure these settings to prevent data exfiltration.
Key Rotation and Expiration
Key Vault supports automatic key rotation for keys and certificates. For keys, you can set an expiration date and create new versions. For certificates, you can configure auto-renewal with a Certificate Authority. The exam may ask about the --rotation-policy parameter or how to trigger rotation programmatically.
Monitoring and Auditing
All Key Vault operations are logged to Azure Monitor (diagnostic settings). You can send logs to Log Analytics, Storage Account, or Event Hub. The exam expects you to know how to enable logging and query for specific operations (e.g., failed access attempts).
Best Practices for Developers
Use Managed Identities whenever possible to avoid storing credentials.
Grant least privilege — only the permissions needed (e.g., 'get' for secrets, not 'list' or 'set').
Enable soft-delete and purge protection to prevent accidental loss.
Use Key Vault references in App Service and Functions to automatically fetch secrets at runtime.
Cache secrets in your application to avoid throttling, but honor TTL (time-to-live) from Key Vault.
Rotate secrets regularly and use multiple versions.
Monitor access logs for anomalies.
Common Pitfalls
Throttling: Exceeding 2000 operations per second causes HTTP 429 errors. Implement retry logic with exponential backoff.
Access policy misconfiguration: Forgetting to grant 'get' permission leads to 403 Forbidden errors.
Soft-delete confusion: Deleting a vault puts it in soft-delete state; you must recover or purge it before creating a new vault with the same name.
Managed Identity not assigned: You must assign the managed identity to the Azure resource and grant it access to the vault.
Create a Key Vault
Use the Azure portal, CLI, or ARM template to create a new vault. Choose a globally unique name (3-24 characters, alphanumeric and hyphens). Select a region, resource group, and pricing tier (Standard or Premium). Premium supports HSM-backed keys. Enable soft-delete and purge protection (recommended). The vault endpoint will be `https://<vault-name>.vault.azure.net`. After creation, you can configure access policies, firewall, and diagnostic settings.
Assign Access Policy
Identify the security principal (user, group, service principal, or managed identity) that needs access. In the Azure portal, go to the vault's Access policies blade, click 'Add Access Policy', select the principal, and choose permissions (e.g., Get, List for secrets). Alternatively, use CLI: `az keyvault set-policy --name myvault --object-id <object-id> --secret-permissions get list`. The object ID is the principal's ID in Microsoft Entra ID. You can also use Azure RBAC roles like 'Key Vault Secrets User'.
Store a Secret
Use the CLI to store a secret: `az keyvault secret set --vault-name myvault --name mysecret --value "MySecretValue123"`. The secret is encrypted at rest using the vault's key. You can also set attributes like expiration date, content type, and tags. The secret is versioned; each set creates a new version. To retrieve, use `az keyvault secret show --vault-name myvault --name mysecret --query value -o tsv`. In code, use the Azure SDK for .NET, Python, etc., to call `GetSecretAsync`.
Access from App with Managed Identity
Enable system-assigned managed identity on your Azure resource (e.g., App Service). In the portal, go to Identity, set Status to On. Then grant that identity access to Key Vault via access policy (use the identity's object ID). In your application code, use the Azure Identity library to get a token: `var credential = new DefaultAzureCredential(); var client = new SecretClient(vaultUri, credential);`. The SDK automatically obtains a token using the managed identity. No credentials in code.
Use Key Vault Reference in App Settings
In Azure App Service or Functions, you can reference a Key Vault secret directly in an application setting. The syntax is `@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)`. The runtime will automatically fetch the secret value when the app starts. Ensure the app's managed identity has 'Get' permission on the secret. This eliminates the need to change code when secrets rotate. The reference is resolved at runtime; if the secret is updated, the app must be restarted to pick up the new value.
Enterprise Scenario 1: E-commerce Application Connection Strings
A large e-commerce platform uses Azure App Service with multiple deployment slots (production, staging). The connection string to the payment gateway database is stored as a secret in Key Vault. The production slot uses a managed identity that has 'Get' permission on the secret. The staging slot uses a different managed identity with access to a separate secret version (or a different secret) for the staging database. This ensures that developers never see production credentials. The operations team configured Key Vault firewall to allow access only from the App Service's outbound IP addresses. They also enabled diagnostic logging to track every secret access. When the database password is rotated, the team updates the secret in Key Vault and restarts the production slot. The application uses a caching mechanism (e.g., IMemoryCache) to avoid fetching the secret on every request, with a 5-minute TTL to pick up changes.
Enterprise Scenario 2: Microservices Certificate Management
A financial services company runs a Kubernetes cluster (AKS) with multiple microservices that communicate via TLS. They use Key Vault to store the TLS certificates for each service. The Secrets Store CSI driver mounts the certificates as volumes in the pods. Each pod has a managed identity that is granted 'Get' permission on the specific certificate. When a certificate is about to expire, Key Vault auto-rotates it (if configured with a CA), and the CSI driver updates the mounted file without pod restart. The security team audits all certificate access via Azure Monitor. They also use Key Vault's certificate lifecycle management to generate new certificates with a 90-day validity and auto-renewal. This eliminates manual certificate distribution and reduces the risk of expired certificates causing outages.
Common Misconfigurations
Overly Permissive Access Policies: Granting 'all' permissions to a wide group leads to security risks. Always use least privilege.
No Soft-Delete: If soft-delete is disabled, accidental deletion is irreversible. Always enable it.
Public Network Access: Leaving the vault accessible from all networks increases attack surface. Use firewall and service endpoints.
Ignoring Throttling: High-traffic apps may hit the 2000 ops/sec limit. Implement caching and retry logic.
Not Using Managed Identity: Storing service principal credentials in code defeats the purpose of Key Vault.
What AZ-204 Tests on Key Vault (Objective 3.2)
The exam expects you to:
Create and configure a Key Vault (including soft-delete, purge protection, firewall).
Authenticate to Key Vault using managed identity, service principal, or user identity.
Store and retrieve secrets, keys, and certificates programmatically using the Azure SDK.
Implement Key Vault references in App Service and Azure Functions.
Manage access policies and RBAC roles.
Enable and query diagnostic logs.
Understand key rotation and expiration.
Common Wrong Answers and Traps
Choosing 'Key Vault Contributor' role for an application to read secrets: The Contributor role grants management plane access (e.g., create/delete vaults), not data plane access. To read secrets, you need 'Key Vault Secrets User' (RBAC) or 'get' permission in an access policy. Many candidates pick Contributor because it sounds broad, but it doesn't allow secret retrieval.
Using connection strings in app settings directly: The exam presents a scenario where a developer stores a database password in an App Service application setting. The correct answer is to use a Key Vault reference. The wrong answer might be to encrypt the app setting using Azure Key Vault — but app settings are not encrypted; they are stored in plain text in the configuration store.
Forgetting to enable soft-delete: A question might ask how to recover a deleted secret. If soft-delete is not enabled, the secret is permanently deleted. The exam tests that soft-delete is enabled by default, but if it was explicitly disabled, recovery is impossible.
Using the wrong endpoint: The vault URI is https://<vault-name>.vault.azure.net, not https://<vault-name>.keyvault.azure.net (which is a common mistake).
Specific Numbers and Terms
Soft-delete retention: 90 days (fixed).
Secret size limit: 25 KB.
Throttling: 2000 ops/sec for secrets, 1000 for keys, 500 for certificates.
Key types: RSA 2048, 3072, 4096; EC P-256, P-384, P-521, P-256K.
Access policies: up to 1024 per vault.
CLI commands: az keyvault secret set, az keyvault secret show, az keyvault set-policy.
SDK: SecretClient class in Azure.Security.KeyVault.Secrets.
Managed Identity: DefaultAzureCredential() from Azure.Identity.
Edge Cases and Exceptions
Vault in soft-delete state: You cannot create a new vault with the same name until the old one is purged or recovered.
Purge protection: If enabled, you cannot purge until the retention period ends, even if you have delete permissions.
Key Vault in a different tenant: Cross-tenant access requires guest users or service principal consent.
Private endpoint: If the vault is behind a private endpoint, you must resolve the DNS to the private IP.
How to Eliminate Wrong Answers
If the question involves reading a secret from code, look for options that use DefaultAzureCredential or ManagedIdentityCredential — those are correct. Options using ClientSecretCredential with hard-coded credentials are wrong.
If the question is about recovering a deleted secret, check if soft-delete is mentioned. If not, assume it's enabled (default). The answer should involve az keyvault secret recover or the portal recover option.
If the question is about granting access, distinguish between management plane (RBAC roles like Contributor) and data plane (access policies or RBAC data roles like Secrets User).
Azure Key Vault stores secrets, keys, and certificates with encryption at rest (AES-256 or HSM).
Secret size limit is 25 KB; for larger data, use blob storage with a SAS token in Key Vault.
Soft-delete is enabled by default with a 90-day retention period; purge protection prevents permanent deletion.
Throttling limits: 2000 ops/sec for secrets, 1000 for keys, 500 for certificates.
Use Managed Identity with DefaultAzureCredential to authenticate to Key Vault without credentials.
Key Vault References in App Service use syntax @Microsoft.KeyVault(SecretUri=...).
Access policies grant data plane permissions; Azure RBAC can grant both management and data plane access.
Enable diagnostic settings to log all Key Vault operations to Azure Monitor.
Key rotation for keys and certificates can be automated with rotation policies.
Always use least privilege access; grant only required permissions (e.g., 'get' not 'list').
These come up on the exam all the time. Here's how to tell them apart.
Access Policies
Scoped to a single vault
Granular permissions per object type (secret, key, cert)
Up to 1024 entries per vault
Legacy model, still widely used
Configured via 'Access policies' blade or CLI
Azure RBAC for Key Vault
Scoped to management group, subscription, resource group, or vault
Built-in roles: Key Vault Secrets User, Key Vault Contributor, etc.
No hard limit on role assignments
Newer model, recommended for centralized management
Configured via Azure RBAC blade or CLI
Mistake
Key Vault stores secrets in plain text but encrypts them in transit.
Correct
Secrets are encrypted at rest using AES-256 or HSM-backed keys. They are also encrypted in transit using TLS. The encryption is transparent to the user.
Mistake
You can store secrets larger than 25 KB by splitting them into multiple secrets.
Correct
Each secret value is limited to 25 KB. If you need to store larger data, store it in Azure Storage Blob and store the blob URL and SAS token in Key Vault.
Mistake
Key Vault access policies and Azure RBAC are interchangeable and do the same thing.
Correct
Access policies are scoped to a vault and control data plane access (secrets, keys, certs). Azure RBAC can control both management plane (create/delete vaults) and data plane (via built-in roles like Key Vault Secrets User). They are separate authorization systems.
Mistake
Once you delete a secret, it is gone forever.
Correct
By default, soft-delete is enabled, so deleted secrets are retained for 90 days and can be recovered. Only after purging (or after the retention period) is the secret permanently deleted.
Mistake
Managed identity requires storing a client ID and secret in the application.
Correct
Managed identity automatically handles authentication. The Azure infrastructure provides a token endpoint that the application uses to get a token without any credentials in code.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
If soft-delete is enabled (default), use `az keyvault secret recover --vault-name myvault --name mysecret` or the Azure portal: go to the vault, select 'Secrets', click 'Manage deleted secrets', select the secret, and click 'Recover'. The secret will be restored with its previous versions. If soft-delete is disabled, the secret is permanently deleted and cannot be recovered.
Standard tier uses software-backed keys (encrypted at rest with AES-256). Premium tier uses hardware security modules (HSMs) for key storage and cryptographic operations, providing FIPS 140-2 Level 2 validation. Premium is required for sensitive workloads that need HSM guarantees. Both tiers support secrets and certificates, but Premium also supports HSM-protected keys.
Enable system-assigned managed identity on the VM (via portal or CLI: `az vm identity assign`). Then grant that managed identity access to the vault via an access policy or RBAC role. In your application code, use `DefaultAzureCredential` from Azure.Identity to authenticate. The SDK will automatically obtain a token using the VM's managed identity endpoint.
The maximum is 1024 access policy entries per vault. Each entry associates a security principal with a set of permissions. If you need more, consider using Azure RBAC instead, which does not have this limit and allows role assignments at higher scopes.
Yes. You can either use a Key Vault reference in the Function's application settings (syntax: `@Microsoft.KeyVault(SecretUri=...)`) or retrieve the secret programmatically using the SDK. The recommended approach is to use a managed identity for the Function and a Key Vault reference. Ensure the Function's managed identity has 'Get' permission on the secret.
Create a new version of the secret by calling `az keyvault secret set` with the same name but a new value. The old version remains active. Update your application to use the new version (e.g., by restarting the app if using Key Vault references). You can also set an expiration date on the old version to enforce rotation. For keys, you can use the `--rotation-policy` to automate rotation.
Key Vault is designed for secrets (sensitive data) with encryption and access control. Azure App Configuration is for non-sensitive configuration data (e.g., feature flags, app settings) and supports hierarchical keys, labels, and feature management. They can be used together: store connection strings in Key Vault and reference them from App Configuration.
You've just covered Key Vault for Developers — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?