1. Key Vault Architecture

App Service / Function / AKS Pod
→ authenticates via
System or User-assigned MI
→ requests secret/key/cert
Vault (software) or Managed HSM (FIPS 140-2 L3)
→ returns
Secrets | Keys | Certificates
  • Standard Vault — Software-protected keys (FIPS 140-2 Level 1). Most workloads.
  • Premium Vault — HSM-backed keys (Level 2). Keys never leave HSM boundary.
  • Managed HSM — Dedicated single-tenant HSM pool (Level 3). Payment/signing workloads, full BYOK control.
  • Soft-delete — Enabled by default (7–90 days retention). Recovers accidentally deleted objects.
  • Purge protection — Once enabled, cannot be disabled. Prevents permanent deletion until retention period expires — required for compliance.

2. Object Types

  • Secrets — Connection strings, API keys, passwords. Stored as versioned, opaque byte blobs (≤25 KB). Use when the app needs the plaintext value.
  • Keys — RSA/EC cryptographic keys. Support sign, verify, encrypt, decrypt, wrap, unwrap. Use for data encryption at rest (CMK), token signing, envelope encryption. Key material can stay inside HSM — operations execute server-side.
  • Certificates — X.509 certs with lifecycle management. Auto-renewal with DigiCert/GlobalSign or self-signed. Stores both the public cert and private key. Use for TLS termination, code signing.

3. Access Models: Vault Access Policy vs Azure RBAC

Aspect
Vault Access Policy
Azure RBAC (recommended)
Granularity
Per-vault, per-principal (all keys or all secrets)
Per-object (individual secret/key scope)
Limit
1024 policies per vault
Azure subscription role-assignment limits
Conditional Access
Not supported
Supported via Azure AD conditions
Audit
Vault-level only
Unified Azure RBAC audit log
Migration
Legacy — still supported
Switch in vault properties; both cannot coexist
Best For
Simple single-team vaults
Enterprise, multi-team, fine-grained access

Key roles: Key Vault Secrets User (read), Key Vault Secrets Officer (read/write), Key Vault Crypto User (sign/decrypt), Key Vault Administrator (full).

4. Networking & Private Endpoints

  • Private Endpoint — Places Key Vault on your VNet with a private IP. DNS resolves myvault.vault.azure.net → 10.x.x.x. Eliminates public internet exposure.
  • Firewall rules — Allow specific public IPs or VNet subnets via service endpoints. Default deny when enabled.
  • Trusted Services Bypass — Allows Azure services (Backup, Storage, SQL, App Service) to reach the vault even when firewall is on. Enable "Allow trusted Microsoft services."
  • Design pattern: Private endpoint + DNS zone for production; firewall IP allowlist for CI/CD agents that can't use private connectivity.

5. Integration Patterns

  • App Service / Functions — Key Vault References
    @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DbConn/) in app settings. Resolves at runtime; no code changes. Requires system-assigned MI with Secrets User role.
  • AKS — Secrets Store CSI Driver
    Mounts secrets as files in pod volumes or syncs to Kubernetes Secrets. Uses workload identity (federated credential) → Key Vault. No secret values stored in etcd.
  • Managed Identity access
    System-assigned: tied to resource lifecycle. User-assigned: shared across resources, portable. Both eliminate credential storage entirely.
  • SDK / REST — SecretClient (Azure.Security.KeyVault.Secrets) + DefaultAzureCredential for local dev and production with zero config change.

6. Key Rotation Strategies

  • Auto-rotation policy — Configure rotation interval (e.g., 90 days) directly on a key. Key Vault generates a new version automatically.
  • Event Grid notifications — Microsoft.KeyVault.SecretNearExpiry and SecretExpired events trigger Azure Function / Logic App to rotate credentials (e.g., regenerate Storage key, update secret).
  • Rotation pattern: Event Grid → Function regenerates credential → writes new secret version → app picks up via Key Vault reference (next restart or cache expiry).
  • Secret versioning — Always reference the latest version URI (no version GUID) so apps auto-resolve new values on rotation.

7. Backup & DR

  • Built-in geo-redundancy — Vault contents replicated to paired region automatically. Read-only failover during regional outage (RPO ~minutes).
  • Backup/Restore — az keyvault secret backup creates an encrypted blob restorable only within same Azure AD tenant and geography. Use for critical secret archival.
  • Managed HSM — Security domain (quorum of keys) required for DR. Export security domain → restore to new HSM pool in paired region.
  • Limitation: Cannot restore a backup to a vault in a different Azure geography (e.g., US → EU).

🌍 Real-World Scenario

Microservices Platform: Centralized Secrets + Payment HSM

A fintech company runs 40 microservices on AKS. A central Key Vault (RBAC model) stores database connection strings and API keys — each service's workload identity has Secrets User on only its own secrets. The Secrets Store CSI driver mounts values as files; no secrets in Kubernetes manifests or environment variables. Certificates for mTLS between services auto-renew via Key Vault integrated CA (DigiCert). A separate Managed HSM handles payment transaction signing — private keys never leave the HSM boundary, meeting PCI-DSS requirements. Event Grid triggers a rotation Function every 60 days for storage account keys, writing new versions back to Key Vault with zero downtime.

📝 Exam Tip

When a question asks about fine-grained, per-secret access control, the answer is Azure RBAC (not vault access policies). If the scenario requires keys that never leave HSM boundaries with FIPS 140-2 Level 3, choose Managed HSM — not Premium vault (Level 2). For "no code changes" secret consumption in App Service, pick Key Vault references in app settings.

🧪 Knowledge Check

Q1: Which access model allows scoping permissions to an individual secret?

Q2: How do App Service Key Vault references work?

Q3: Which Key Vault option meets FIPS 140-2 Level 3 with single-tenant HSM?

Q4: What triggers automatic secret rotation notifications?