This chapter covers Azure Key Vault architecture for secrets management, a core topic for the AZ-305 exam under domain Identity Governance (objective 1.1). Key Vault is central to securing application secrets, keys, and certificates in Azure, and approximately 15-20% of exam questions touch on Key Vault design, access policies, soft-delete, and integration patterns. Mastering this material is essential for designing secure, compliant solutions.
Jump to a section
Imagine a bank with a massive vault room. Inside are hundreds of safe deposit boxes, each owned by a different customer. Each box has a unique number and can only be opened with the customer's key and the bank's master key together. The customer (application) brings their key (Azure AD authentication token) to the bank teller (Key Vault authentication endpoint). The teller verifies the key against the customer's ID (Azure AD identity) and then escorts them to the vault. The customer inserts their key, and the teller uses the bank's master key to open the box. The customer retrieves or deposits items (secrets, keys, certificates). Critically, the customer never sees the bank's master key, and the bank never copies the customer's key. If the customer loses their key, they cannot access the box until a new key is issued (regenerate secrets). The vault has multiple layers: outer door (firewall), inner door (network ACL), and the box itself (access policy). The bank manager (administrator) can grant or revoke access to boxes, and every access is logged (Azure Monitor). This mirrors exactly how Key Vault works: the vault is a secure container, each secret is a separate storage item, access requires both authentication and authorization, and all operations are audited.
What is Azure Key Vault?
Azure Key Vault is a cloud service for securely storing and accessing secrets (e.g., connection strings, passwords), cryptographic keys, and certificates. It provides hardware security module (HSM) backed storage, centralized management, and fine-grained access control. Key Vault eliminates the need for developers to hardcode secrets in code, reducing the risk of credential leakage.
Why Key Vault Exists
Before Key Vault, developers often stored secrets in configuration files, environment variables, or source code repositories – all insecure. Key Vault centralizes secret storage, enforces encryption at rest and in transit, and integrates with Azure AD for authentication. It also supports rotation policies, soft-delete for recovery, and logging for auditing.
How Key Vault Works Internally
Key Vault operates as a multi-tenant service with isolated per-customer vaults. Each vault has a unique DNS name (e.g., myvault.vault.azure.net). When an application requests a secret:
1. The application authenticates to Azure AD (using managed identity, service principal, or user) and obtains an OAuth 2.0 access token.
2. The application sends an HTTPS request to the vault's REST API endpoint (e.g., GET /secrets/{name}) with the token in the Authorization header.
3. Key Vault validates the token (issuer, audience, expiry) and extracts the object ID and tenant.
4. Key Vault evaluates the vault's access policy (or RBAC role assignment) to determine if the caller has get permission on secrets.
5. If authorized, Key Vault decrypts the secret from its encrypted storage (using a vault-specific encryption key) and returns it over HTTPS.
6. All operations are logged to Azure Monitor and optionally to Azure Event Hub or Log Analytics.
Key Components and Defaults
Vault: Top-level container. Default soft-delete retention period: 90 days (configurable 7-90). Default purge protection: disabled.
Secrets: Key-value pairs (max 25 KB each). Stored encrypted at rest using AES-256. Versioned automatically on each update.
Keys: Cryptographic keys (RSA, EC, or symmetric) backed by FIPS 140-2 Level 2 (software) or Level 3 (HSM). Operations (sign, encrypt) performed inside the vault – keys never leave.
Certificates: X.509 v3 certificates, can be auto-issued by integration with trusted CAs.
Access Policies: Assign permissions (get, list, set, delete, etc.) to Azure AD users, groups, or service principals. Up to 1024 policies per vault.
RBAC: Alternative to access policies using Azure RBAC roles (Key Vault Secrets User, Key Vault Certificates Officer, etc.). Only one authorization model can be active per vault.
Soft-Delete: When enabled, deleted secrets are retained for 90 days (recoverable). During retention, the secret name cannot be reused. Purge protection prevents permanent deletion until retention expires.
Network ACLs: Restrict access to specific VNet/subnets or IP addresses. Default: allow all networks.
Firewall: Can disable public access and allow only trusted services.
Configuration and Verification Commands
#### Create a vault (Azure CLI):
az keyvault create --name myvault --resource-group myrg --location eastus --enable-soft-delete true --enable-purge-protection true#### Set a secret:
az keyvault secret set --vault-name myvault --name mysecret --value "MySecurePassword123!"#### Retrieve a secret:
az keyvault secret show --vault-name myvault --name mysecret --query value#### Assign access policy:
az keyvault set-policy --name myvault --object-id <aad-object-id> --secret-permissions get list#### Enable RBAC authorization:
az keyvault update --name myvault --enable-rbac-authorization true#### Diagnostic settings:
az monitor diagnostic-settings create --name kvdiag --resource /subscriptions/.../vaults/myvault --workspace /subscriptions/.../workspaces/mylaw --logs '["AuditEvent"]' --metrics '["AllMetrics"]'Interaction with Related Technologies
Azure AD Managed Identity: Allows Azure resources (VMs, App Services, Functions) to authenticate to Key Vault without storing credentials. The identity is automatically managed by Azure AD.
Azure App Configuration: Can reference Key Vault secrets as values, enabling dynamic configuration without exposing secrets.
Azure Policy: Enforce Key Vault settings (e.g., require soft-delete, restrict SKU) across subscriptions.
Azure Monitor / Log Analytics: Collects AuditEvent logs for all vault operations – critical for compliance.
Azure DevOps / GitHub Actions: Use Key Vault task to fetch secrets during CI/CD pipelines.
Performance and Scaling
Key Vault has throttling limits: 2,000 transactions per second per vault for secrets, 10,000 for keys (varies by SKU). Standard tier uses software-backed HSM; Premium tier uses FIPS 140-2 Level 3 HSMs. For high-volume applications, use caching or multiple vaults with sharding.
Security Best Practices
Enable soft-delete and purge protection.
Use RBAC over access policies for centralized management.
Limit network access to specific VNets.
Rotate secrets regularly using automated workflows.
Store connection strings as secrets, not in app settings.
Use separate vaults for production vs. non-production.
Monitor audit logs for unauthorized access attempts.
Create an Azure Key Vault
Use Azure CLI, PowerShell, or portal to create a vault. Specify a globally unique name (3-24 alphanumeric characters, starts with letter), resource group, location, and SKU (Standard or Premium). Enable soft-delete and purge protection for production. The vault is provisioned with a DNS name `https://<vault-name>.vault.azure.net`. Access policies are initially empty – you must grant yourself permissions.
Grant Access to the Vault
Decide on authorization model: access policies or RBAC. For access policies, assign permissions to an Azure AD user, group, or service principal. For RBAC, assign a role like 'Key Vault Secrets User' at the vault scope. Each permission set includes operations like get, list, set, delete, backup, restore, etc. The vault can only use one model at a time – switching requires migration.
Store a Secret
Use `az keyvault secret set` or REST API to store a secret. The secret is encrypted immediately using the vault's encryption key (AES-256). It gets a version ID (GUID) automatically. You can set an activation date and expiration date. The secret value is opaque to the vault – it just stores bytes. Maximum secret size is 25 KB. Tags can be added for organization.
Retrieve a Secret from an Application
Application obtains an Azure AD token (e.g., via Managed Identity endpoint `http://169.254.169.254/metadata/identity/oauth2/token`). It then calls `GET https://myvault.vault.azure.net/secrets/mysecret/{{version}}?api-version=7.4`. The vault validates the token, checks access policy, and returns the secret value in JSON. The application should cache the secret to avoid repeated calls and throttling.
Enable Soft-Delete and Purge Protection
Soft-delete retains deleted secrets for a configurable retention period (7-90 days, default 90). During retention, the secret can be recovered using `az keyvault secret recover`. Purge protection prevents permanent deletion until the retention period ends. These are enabled at vault creation or later (but cannot be disabled after enabling). They protect against accidental or malicious deletion.
Monitor and Audit Key Vault Access
Configure diagnostic settings to stream AuditEvent logs to Log Analytics workspace, Storage Account, or Event Hub. Logs include operation name, caller identity, result status, and timestamp. Use Azure Monitor alerts to detect anomalous activity (e.g., multiple failed access attempts). For compliance, retain logs according to regulatory requirements (e.g., 1 year).
Enterprise Scenario 1: Microservices Secrets Management
A financial services company runs hundreds of microservices on Azure Kubernetes Service (AKS). Each service needs database credentials, API keys, and TLS certificates. They create a single Key Vault per environment (dev, test, prod) and use managed identity for each pod via AKS Pod Identity (or Workload Identity). Each pod authenticates to Key Vault without storing any credentials. The security team enforces RBAC roles: 'Key Vault Secrets User' for read-only, 'Key Vault Secrets Officer' for secret management. They also implement automated secret rotation using Azure Automation runbooks triggered by Azure Policy. In production, they see about 5,000 secret retrievals per second – close to the throttling limit, so they implement client-side caching with a 5-minute TTL. The biggest issue they faced was forgetting to enable soft-delete initially – a mistaken secret deletion caused a 90-minute outage until they restored from backup. Now they always enable purge protection.
Enterprise Scenario 2: Certificate Auto-Renewal
A large e-commerce platform uses Key Vault to store SSL/TLS certificates for its CDN endpoints. They integrate with a trusted CA (DigiCert) to auto-issue and auto-renew certificates. The vault's certificate management feature handles the entire lifecycle: creation, issuance, renewal, and expiration alerts. They use the 'Key Vault Certificate' resource type and configure the certificate policy with 80% lifetime renewal threshold. The vault automatically generates a new version when renewed, and the CDN pulls the latest version via Key Vault reference in Azure Front Door. A common misconfiguration is setting the renewal threshold too low (e.g., 99%) – the certificate expires before renewal completes. They learned to set threshold at 80% to allow time for propagation.
Enterprise Scenario 3: Shared Secrets for Hybrid Cloud
A multinational corporation uses Azure Key Vault to store secrets shared between on-premises applications and Azure workloads. They deploy a Key Vault in each region and use Azure Private Link to expose the vault over ExpressRoute. On-premises apps authenticate using Azure AD Application Proxy or a service principal with certificate-based authentication. They store VPN shared keys, database passwords, and storage account keys. The challenge is managing access for thousands of applications – they use Azure AD groups for access policies and automate group membership via HR system. They also face throttling issues during peak hours, solved by implementing a local cache with Azure App Configuration. A critical lesson: never store secrets in plaintext in on-premises config files – always reference Key Vault via SDK.
What AZ-305 Tests on Key Vault
Objective 1.1: 'Design a solution for identity governance' – specifically, 'Recommend a solution for securing secrets, keys, and certificates using Azure Key Vault'. Exam questions focus on:
Choosing between access policies and RBAC (know that only one can be active per vault).
Soft-delete and purge protection (default retention 90 days, configurable 7-90).
Network restrictions (VNet service endpoints, private endpoints, firewall rules).
Managed identity integration for authentication.
Secret rotation strategies.
Throttling limits (2,000 ops/sec for secrets, 10,000 for keys).
Backup and restore of vaults (backup is a downloadable blob, restore to same Azure region).
Common Wrong Answers and Why
'Use access policies and RBAC simultaneously' – Wrong. A vault can only use one authorization model. If both are enabled, RBAC takes precedence and access policies are ignored.
'Soft-delete retention period is 30 days by default' – Wrong. Default is 90 days. Many candidates confuse it with Azure AD's 30-day recycle bin.
'Premium SKU is required for all secrets' – Wrong. Premium is only needed for HSM-backed keys; secrets are equally secure in Standard tier (software-backed HSM).
'Key Vault automatically rotates secrets' – Wrong. It can auto-renew certificates but not secrets. You must implement rotation via Azure Automation or Functions.
'You can recover a purged secret after 90 days' – Wrong. Purged secrets are permanently deleted immediately. Soft-delete allows recovery only during retention period.
Specific Numbers and Terms to Memorize
Maximum secret size: 25 KB.
Soft-delete retention: 7-90 days (default 90).
Maximum access policies per vault: 1024.
Throttling: 2,000 requests/sec for secrets, 10,000 for keys (per vault).
Vault name: 3-24 characters, alphanumeric, starts with letter.
API version: 7.4 (latest as of 2025).
RBAC roles: Key Vault Secrets User (read), Key Vault Secrets Officer (full control), Key Vault Certificates Officer, Key Vault Crypto Officer, etc.
Edge Cases and Exceptions
If you enable RBAC on a vault that previously used access policies, the access policies are disabled but not deleted – they become inactive. Reverting to access policies requires disabling RBAC.
Soft-delete must be enabled at vault creation; you cannot enable it later if it was disabled initially. You can, however, enable purge protection after creation.
Key Vault firewall rules do not apply to Azure services that are trusted by default (e.g., Azure App Service) unless you disable 'Allow trusted Microsoft services'.
Backup of a Key Vault does not include the secrets' values if the backup is taken with --include-managed-keys flag? Actually, backup includes all secrets, keys, and certificates (encrypted). Restore must be to the same Azure geography (e.g., same region).
How to Eliminate Wrong Answers
If a question asks about 'most secure' or 'recommended' approach:
Prefer managed identity over service principal (no credentials to manage).
Prefer private endpoints over service endpoints (traffic stays on Microsoft backbone).
Prefer RBAC over access policies for large-scale environments (centralized management).
Always enable soft-delete and purge protection for production.
Use separate vaults for different environments (dev, test, prod).
Key Vault encrypts secrets at rest using AES-256 and in transit using TLS.
Soft-delete default retention: 90 days (configurable 7-90). Purge protection prevents permanent deletion.
Maximum secret size: 25 KB. Throttling: 2,000 ops/sec for secrets, 10,000 for keys per vault.
Only one authorization model (access policies or RBAC) can be active per vault.
Managed identity is the preferred authentication method for Azure resources.
Use private endpoints to restrict network access to Key Vault.
Certificates can be auto-renewed; secrets require custom rotation automation.
Backup and restore of Key Vault must be to the same Azure region.
These come up on the exam all the time. Here's how to tell them apart.
Access Policies
Per-vault permissions assigned directly to Azure AD principals.
Supports up to 1024 policies per vault.
Granular permissions per secret type (get, list, set, delete).
No support for Azure Policy or management groups.
Legacy model; harder to manage at scale.
RBAC
Azure RBAC roles assigned at vault, resource group, or subscription scope.
No hard limit on number of role assignments.
Roles like 'Key Vault Secrets User', 'Key Vault Secrets Officer'.
Integrates with Azure Policy, management groups, and Privileged Identity Management.
Modern model; recommended for new deployments.
Mistake
Key Vault stores secrets in plaintext and encrypts them only during transmission.
Correct
Key Vault encrypts secrets at rest using AES-256 encryption, and also encrypts them in transit using TLS 1.2/1.3. The encryption key is stored in the vault itself (or HSM) and never exposed.
Mistake
You can use both access policies and RBAC simultaneously on the same vault.
Correct
Only one authorization model can be active at a time. If RBAC is enabled, access policies are ignored. You must choose one.
Mistake
Soft-delete retention period is fixed at 30 days.
Correct
The default retention period is 90 days, but it is configurable between 7 and 90 days. This is a common exam trap.
Mistake
Premium SKU is required to store secrets securely.
Correct
Both Standard and Premium tiers offer the same level of encryption for secrets. Premium adds HSM-backed keys (FIPS 140-2 Level 3) but secrets are equally secure in Standard.
Mistake
Key Vault automatically rotates secrets like it does for certificates.
Correct
Key Vault only supports automatic rotation for certificates (via integration with CAs). Secrets must be rotated manually or via custom automation (Azure Automation, Functions).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Access policies are per-vault permissions assigned directly to Azure AD principals, limited to 1024 policies. RBAC uses Azure roles at any scope (vault, resource group, subscription) and integrates with Azure Policy. Only one model can be active per vault. RBAC is recommended for large-scale environments.
The default retention period is 90 days, but it is configurable between 7 and 90 days. During this period, the secret can be recovered. After retention expires, the secret is permanently deleted (purged).
Yes, as long as the on-premises app can authenticate to Azure AD (e.g., using a service principal with certificate or client secret) and has network access to the vault (via VPN, ExpressRoute, or public internet with firewall rules).
Key Vault does not automatically rotate secrets. You must implement rotation using Azure Automation, Azure Functions, or a scheduled task that updates the secret with a new value and updates the consuming applications.
The vault returns HTTP 429 (Too Many Requests). To handle this, implement client-side caching, retry with exponential backoff, or distribute requests across multiple vaults.
No. A Key Vault backup can only be restored to the same Azure geography (region). This is a security constraint to prevent cross-region data exfiltration.
Yes. Standard tier uses FIPS 140-2 Level 2 validated HSMs. Premium tier uses FIPS 140-2 Level 3 validated HSMs for key operations.
You've just covered Key Vault Architecture for Secrets Management — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?