Azure Key Vault: Secrets, Rotation, Retrieval

Why everything ends up in Key Vault

Simple explanation

Azure Key Vault is where every secret string in your app belongs: API keys, database passwords, certificate private keys, encryption keys, OAuth client secrets. Two things matter most for AI-200:

How services retrieve secrets without a copy. Container Apps, Functions, App Service, AKS all support pulling Key Vault secrets at startup using managed identity.
How you rotate secrets without downtime. Most Azure services Key Vault integrates with auto-rotate; for the rest you write a small rotation function.

Key Vault has access models (RBAC vs legacy access policies), and SKUs (Standard for software-protected keys, Premium for HSM-protected). The exam tests when each matters.

Access model — RBAC is the modern path

Key Vault has two coexisting access models:

Model	What it does	Status
Microsoft Entra RBAC	Azure roles control access (`Key Vault Secrets User`, `Key Vault Secrets Officer`, etc.)	Recommended
Vault access policies	Per-principal access policies stored on the vault	Legacy — being deprecated

# Switch a vault to RBAC permission model
az keyvault update --name roo-kv --enable-rbac-authorization true

# Grant the Container App's managed identity read access to secrets
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show -n roo-kv --query id -o tsv)

Built-in data-plane roles you must know:

Role	Permissions
Key Vault Reader	List secret/key/cert metadata only
Key Vault Secrets User	Get a secret value
Key Vault Secrets Officer	Get + Set + List + Delete
Key Vault Crypto User	Use a key to encrypt/decrypt/sign/verify/wrap/unwrap
Key Vault Crypto Officer	Manage keys
Key Vault Certificates Officer	Manage certificates
Key Vault Administrator	Everything (data plane + management plane)

Exam tip: 'least-privilege' = Secrets User, not Officer

When the question says “the worker needs to read the OpenAI API key”, the right role is Key Vault Secrets User — only Get on secrets. Don’t pick Secrets Officer (which adds Set, List, Delete) or Administrator. The exam rewards minimum sufficient privilege.

Retrieval — three patterns

Pattern 1 — Key Vault references in app settings

Used by App Service and Function Apps. The host resolves the reference at startup; the container sees the live value.

OPENAI_API_KEY=@Microsoft.KeyVault(SecretUri=https://roo-kv.vault.azure.net/secrets/OpenAIKey)

Conditions: app has managed identity, identity has Get on the secret, app can reach Key Vault on the network.

Pattern 2 — Container Apps secret with `keyvaultref:`

az containerapp secret set \
  --name roo-fn -g roo-prod \
  --secrets openai-key=keyvaultref:https://roo-kv.vault.azure.net/secrets/OpenAIKey,identityref:system

az containerapp update --name roo-fn -g roo-prod \
  --set-env-vars OPENAI_API_KEY=secretref:openai-key

Pattern 3 — SDK retrieval at runtime

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

client = SecretClient(
    vault_url="https://roo-kv.vault.azure.net",
    credential=DefaultAzureCredential(),
)
secret = client.get_secret("OpenAIKey").value

Use this when you need to fetch fresh values during runtime — for example, after rotation, without an app restart. Cache the value briefly to avoid hammering Key Vault.

Pattern 4 — Secrets Store CSI driver (AKS)

For AKS, the CSI driver projects Key Vault secrets as files (or env vars) into pods, with optional polling for rotation.

Versioning and rotation

Every secret in Key Vault has versions. URLs can target the current version (no version segment) or a specific version:

https://roo-kv.vault.azure.net/secrets/OpenAIKey                  # current
https://roo-kv.vault.azure.net/secrets/OpenAIKey/<version-id>     # specific

For most apps reference the unversioned URL — rotation just produces a new version, and the app picks it up on next read.

Rotation strategies

Strategy	How	Best for
Native auto-rotation	Key Vault auto-rotates the secret on a schedule for supported integrations (e.g., Storage account keys, Cosmos DB keys)	Azure-native services with rotation hooks
Event-driven rotation	Key Vault emits a `Microsoft.KeyVault.SecretNearExpiry` event; an Event Grid subscription triggers a Function that creates a new version	Any service Microsoft doesn’t auto-rotate
Scheduled rotation Function	A timer-triggered Function rotates secrets on a cadence	Simpler shape than event-driven; works without Event Grid

# Auto-rotation example: rotate Storage account keys every 60 days
az keyvault setting update --vault-name roo-kv \
  --name AllowKeyManagementOperationsThroughARM --value true

# Then configure the rotation policy on the secret in the portal
# or via the Microsoft.KeyVault.SetSecretRotationPolicy ARM action

Apps that hold the unversioned URL automatically pick up the new version on next retrieval. Apps that pin a version id must be redeployed — usually NOT what you want.

Soft delete and purge protection

Key Vault has two safety nets every production vault should consider:

Feature	What it does	Default?
Soft delete	Deleted items go to a recoverable state for the retention period (7-90 days)	On by default (mandatory since Feb 2025; cannot be disabled)
Purge protection	Even an admin cannot permanently delete items during the retention window — protects against malicious or accidental destruction	Off by default — opt in for any vault holding production secrets

Soft delete protects against accidental delete; purge protection additionally blocks permanent deletion. They are different controls — enable purge protection explicitly for regulated workloads.

Networking — public, private, or VNet-restricted

Mode	Use
Public access (default)	Quick start, dev/test
Selected networks (firewall)	Allow specific VNets and IP ranges
Private endpoint	The vault is reachable only from a private IP inside your VNet

For regulated AI workloads (Theo’s Tidewater Health), private endpoint + VNet integration on consumers is the standard pattern.