5.1.1. Azure Key Vault: Secrets, Rotation, and Retrieval
💡 First Principle: Key Vault's design goal is that a secret is used without being possessed: applications authenticate with a managed identity (which cannot leak — it has no password), fetch the secret at runtime, and hold it only in memory. Once secrets live nowhere durable except the vault, rotation becomes an update in one place instead of a scavenger hunt.
Key Vault stores three object types — secrets (arbitrary sensitive strings: connection strings, API keys), keys (cryptographic material for encrypt/sign operations), and certificates (TLS certs with lifecycle management). AI-200 centers on secrets. Every secret is versioned: setting a new value creates a new version with its own URI, and fetching without a version pin returns the latest — the mechanism rotation relies on.
Retrieval in Python is the identity-over-secrets pattern from 2.1.1, completed:
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
client = SecretClient(vault_url="https://mm-vault.vault.azure.net",
credential=DefaultAzureCredential())
openai_key = client.get_secret("openai-key").value # latest version
DefaultAzureCredential resolves to a managed identity in Azure (no credential to store — solving the "who guards the key to the safe?" regress), granted access via Azure RBAC roles like Key Vault Secrets User (the modern model, preferred over legacy access policies). Cache fetched secrets briefly rather than calling the vault per request — vaults have throttling limits.
Rotation is where the exam gets specific, because the automation is assembled, not built-in:
Key Vault publishes system events (SecretNearExpiry, SecretNewVersionCreated) to Event Grid; a Function subscribes, generates the new credential in the target service, and writes it back as a new secret version; consumers picking up "latest" get the new value on next fetch. This is Phase 4's fact-then-command composition, redeployed as security automation. Two supporting facts: soft delete (deleted secrets are recoverable during retention — enabled by default) and purge protection guard against destructive mistakes.
⚠️ Exam Trap: Secrets do not rotate themselves. Keys can carry auto-rotation policies and certificates can auto-renew, but a secret's rotation is your event-driven automation. Also recall the Container Apps interaction from 3.2.1: apps that read a secret at startup won't see the new version until restart or refresh — rotation isn't complete until consumers re-fetch.
Access and network hardening complete the vault picture. The RBAC ladder runs from Key Vault Reader (metadata only) through Key Vault Secrets User (read secret values — the workload role) to Key Vault Secrets Officer (manage them — the pipeline role); granting workloads the officer role is a classic least-privilege violation. Vault firewalls and private endpoints restrict network reach, layering beneath identity checks. In code, get_secret(name) returns latest while get_secret(name, version=...) pins — and pinning is why "rotated but nothing changed" bugs happen. For caching, minutes-scale TTLs (5–15) balance throttling protection against rotation lag, with refresh-on-auth-failure as the self-healing backstop. The Event Grid system topic emits SecretNearExpiry, SecretExpired, and SecretNewVersionCreated — near-expiry drives rotation, new-version drives cache busting.
One irreversibility note: purge protection, once enabled, cannot be disabled — deleted objects stay recoverable for the full retention window no matter who asks. Auditors love it; hasty cleanup scripts do not.
Reflection Question: Why does managed identity + Key Vault eliminate the "turtles all the way down" problem that plagues storing an encryption key to protect your secrets store?
