11.2 Key Vault Secret Rotation Patterns

11.2 Key Vault Secret Rotation Patterns

Quick Answer: Rotate secrets by writing a new Key Vault secret version while keeping the previous version valid until every consumer refreshes (dual-secret cutover). Prefer automated rotation with versioning, Event Grid notifications, and least-privilege managed identities—and always design apps to reload secrets instead of caching them forever.

Retrieving secrets securely is incomplete without a plan to change them. Compromised API keys, expired database passwords, and long-lived service principal secrets are common Azure AI incident sources. This section focuses on rotation: how Key Vault versions work, how dual-secret patterns avoid downtime, how automation hooks into the vault, and how App Service/Container Apps consumers stay in sync.

Why Rotation Matters for Secure Azure Solutions

Rotation limits the lifetime of any single credential. Even if a secret leaks into logs, a support ticket, or a discarded container layer, a short validity window reduces blast radius. AI-200 solutions often integrate multiple services—Azure OpenAI, Azure AI Search, Storage, SQL, third-party model APIs—so a single unrotated key can unlock a large surface.

Rotation goals on the exam:

1. Confidentiality over time — assume breach of a credential is possible; shrink its useful life.
2. Availability during change — rotate without forcing a hard outage.
3. Auditability — prove when versions were created, disabled, and read.

Secret Versioning Behavior

Every time you set a secret value in Key Vault, the vault creates a new version identified by a version GUID. The secret name stays stable (DbPassword, OpenAiApiKey), while versions accumulate:

• https://vault.vault.azure.net/secrets/OpenAiApiKey → current version
• https://vault.vault.azure.net/secrets/OpenAiApiKey/<version-id> → specific version

Properties that matter during rotation:

Applications that call GetSecret(name) without a version always follow the latest enabled version. Applications that pin a version URI are immune to accidental updates—but they will not see rotations until someone updates the pin. Choose deliberately.

Dual-Secret and Dual-Version Cutover

Zero-downtime rotation usually follows a dual validity window:

Pattern A — Two versions of one secret name

1. Create a new version of AppDbPassword with the new password (also set on the database).
2. Leave the previous version enabled temporarily or ensure the database accepts both passwords during overlap if the platform supports dual credentials.
3. Signal applications to refresh (restart, configuration reload, or cache invalidation).
4. Verify all instances retrieved the new version (metrics, logs without secret values).
5. Disable the old version and revoke the old database password.

Pattern B — Two secret names (primary/secondary)

Many identity providers and databases support two active credentials. Store them as ApiKey-Primary and ApiKey-Secondary:

1. Rotate the inactive slot (for example, secondary) to a new value at the provider.
2. Update the corresponding Key Vault secret.
3. Flip application configuration to prefer the newly rotated slot (feature flag, app setting, or App Configuration—see next section).
4. Rotate the former primary on the next cycle.

Exam tip: If a scenario emphasizes near-zero downtime across multiple App Service instances, choose a dual-secret/dual-credential approach with a refresh window—not an immediate disable of the only valid version.

Automating Rotation

Manual portal edits do not scale. Common automation building blocks:

1. Rotation policy on keys/certificates — Key Vault can schedule near-expiry rotation for cryptographic objects and integrate with certificate issuers.
2. Event Grid — Key Vault emits events (for example, secret near expiry or a custom topic after a version is set). An Azure Function or Logic App rotates the upstream credential, writes a new secret version, and notifies apps.
3. Azure Functions + provider APIs — For secrets Key Vault cannot rotate itself (arbitrary third-party API keys), a function uses a managed identity to call the provider, then SetSecret on the vault.
4. Managed identity for the rotator — The rotation function needs Key Vault Secrets Officer (or narrower custom role with set/get), not merely Secrets User.

Keep the rotator’s privileges separate from application read identities. Applications keep Secrets User; only automation sets new versions.

Consumer Refresh: SDK Caches and Platform References

Rotation fails in production when consumers never reload:

• In-process cache — If your worker caches GetSecret results indefinitely, it keeps the old password after Key Vault and the database have moved on. Use a TTL, listen for a refresh signal, or refresh on authentication failure with backoff.
• App Service Key Vault references — References resolve to the current version when the site configuration is refreshed. After rotation, restart or use configuration update mechanisms so instances re-resolve. If the reference pins a version GUID, update the setting to the new version URI as part of the rotation runbook.
• Container Apps secrets — New revisions or secret refreshes may be required depending on how the secret was mounted; plan revision strategy alongside vault version updates.
• Multiple regions / slots — Staging slots and secondary regions need the same dual-validity window; rotate shared vaults carefully so slot swap does not strand an old pin.

Safe Disable and Cleanup Order

A reliable runbook order for AI-200-style answers:

1. Create upstream credential (database user password, API key).
2. Write new Key Vault version (or secondary secret).
3. Expand acceptance on the upstream system if dual credentials are supported.
4. Trigger consumer refresh; wait for healthy dependencies.
5. Disable old Key Vault version; revoke old upstream credential.
6. Confirm soft-delete retention is sufficient if you delete rather than disable.

Never revoke the old credential before consumers have demonstrably switched. Soft delete helps recovery if step ordering goes wrong, but purge protection still blocks immediate permanent loss—good for safety, not a substitute for dual-validity planning.

Putting Rotation Together with Retrieval

Secure retrieval (managed identity + RBAC Secrets User + GetSecret or references) plus disciplined rotation (versioning + dual validity + automation + refresh) is the full Key Vault story for AI-200. Configuration that is not secret—feature toggles, endpoint URLs, non-sensitive thresholds—belongs in Azure App Configuration, which is designed for dynamic settings and feature flags rather than credential storage.