ExamFinch.com My Study

Study guide

11.2 Key Vault Secret Rotation Patterns

Practice this exam

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

11.2 Key Vault Secret Rotation Patterns

Key Takeaways Explain This Topic AI

Key Vault versions every secret set operation; applications can pin a version or always read the latest enabled version depending on the rotation strategy.

Dual-secret (or dual-credential) rotation keeps the old and new secret valid during a cutover window so instances can refresh without downtime.

Automate rotation with Key Vault rotation policies where supported (commonly for keys and certain integrated scenarios) and with Event Grid + Azure Functions for custom secret providers.

After rotating, update dependents in order: create new version, grant consumers time to refresh, then disable or delete the old version.

Platform Key Vault references and SDK clients must be designed to pick up new versions—cached secrets are a common cause of post-rotation outages.

Last updated: July 2026

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:

Confidentiality over time — assume breach of a credential is possible; shrink its useful life.

Availability during change — rotate without forcing a hard outage.

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:

  • Property Role in rotation
  • Enabled flag Disabled versions are not returned as “current”
  • Activation / expiration dates Optional notBefore/expiry windows for time-boxed versions
  • Content type / tags Metadata for automation (for example, provider=sql)
  • Primary vs secondary naming Dual-secret pattern may use two secret names , not only two versions

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

Create a new version of AppDbPassword with the new password (also set on the database).

Leave the previous version enabled temporarily or ensure the database accepts both passwords during overlap if the platform supports dual credentials.

Signal applications to refresh (restart, configuration reload, or cache invalidation).

Verify all instances retrieved the new version (metrics, logs without secret values).

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 :

Rotate the inactive slot (for example, secondary) to a new value at the provider.

Update the corresponding Key Vault secret.

Flip application configuration to prefer the newly rotated slot (feature flag, app setting, or App Configuration—see next section).

Rotate the former primary on the next cycle.

Pattern Pros Cons

Dual versions, one name Simple naming; latest-version clients auto-follow Requires careful disable timing; pinned-version clients break

  • Dual names primary/secondary Explicit slot flip; easy rollback Apps must understand which slot is active
  • Hard cutover (single value) Simple mentally Causes outages unless all consumers reload instantly

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:

Rotation policy on keys/certificates — Key Vault can schedule near-expiry rotation for cryptographic objects and integrate with certificate issuers.

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.

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.

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:

Create upstream credential (database user password, API key).

Write new Key Vault version (or secondary secret).

Expand acceptance on the upstream system if dual credentials are supported.

Trigger consumer refresh; wait for healthy dependencies.

Disable old Key Vault version; revoke old upstream credential.

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.