ExamFinch.com My Study

Study guide

11.1 Azure Key Vault: Secret Storage & Retrieval

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.1 Azure Key Vault: Secret Storage & Retrieval

Key Takeaways Explain This Topic AI

Azure Key Vault stores secrets, keys, and certificates; apps should retrieve secrets at runtime through managed identity rather than embedding credentials in code or config files.

Azure RBAC is the recommended authorization model for Key Vault data-plane access; vault access policies remain supported but are legacy for new designs.

Key Vault Secrets User grants get/list on secrets; Key Vault Administrator is broader and should be reserved for operators, not application identities.

App Service and Azure Container Apps can inject Key Vault references so platform-managed identity resolves secret values without putting plaintext secrets in app settings.

SDK retrieval uses SecretClient.GetSecret (or GetSecretAsync) against the vault URI; always pin or resolve the current version deliberately when designing rotation-safe clients.

Last updated: July 2026

11.1 Azure Key Vault: Secret Storage & Retrieval

Quick Answer: Store application secrets in Azure Key Vault and retrieve them at runtime with a managed identity that has Key Vault Secrets User (or equivalent RBAC). Prefer Azure RBAC over vault access policies for new deployments, use SecretClient.GetSecret in code, and use Key Vault references in App Service or Container Apps when you want the platform to resolve secret values into configuration.

On the AI-200 exam, secure Azure solutions means keeping credentials, connection strings, API keys, and certificates out of source control, container images, and plain app settings. Azure Key Vault is the central service for storing those sensitive values and controlling who (or what) can read them. This section focuses on storage and retrieval : how secrets live in the vault, how identities authenticate, how authorization is granted, and how apps and PaaS platforms pull secret values safely.

What Key Vault Stores

Key Vault exposes three primary object types on the data plane:

Secrets — arbitrary string values such as connection strings, passwords, tokens, and third-party API keys. Most application retrieval scenarios use secrets.

Keys — cryptographic keys (RSA, EC, and managed HSM-backed keys depending on the SKU) used for encrypt/decrypt and sign/verify operations inside or via the vault.

Certificates — X.509 certificates managed with optional issuer integration and automatic renewal policies.

For AI-200 secure-app design questions, assume application configuration secrets are stored as Key Vault secrets , not as keys, unless the scenario explicitly involves cryptography.

  • Object type Typical AI/app use Common data-plane operations
  • Secret DB connection string, OpenAI API key, service principal secret Get, List, Set, Delete
  • Key Envelope encryption, signing tokens Encrypt, Decrypt, Sign, Verify, Wrap, Unwrap
  • Certificate TLS for custom domains, client cert auth Get, Import, Create, Renew

Vaults also support soft delete (recoverable deletion for a retention period) and optional purge protection (blocks permanent purge during retention). Enable both in production so a mistaken delete or a compromised identity with delete rights cannot immediately destroy secrets.

Authentication: Managed Identity First

Applications should authenticate to Key Vault with Microsoft Entra ID , almost always via a managed identity :

System-assigned managed identity — lifecycle tied to one Azure resource (for example, one App Service or one Container App).

User-assigned managed identity — independent identity you attach to one or more resources; useful when several apps share the same Key Vault permissions.

The identity obtains an Entra access token for the Key Vault resource audience. No client secret is stored in the app for vault access itself. On the exam, prefer managed identity over embedding a service principal client secret to call Key Vault—embedding another secret just moves the problem.

Authorization: Prefer Azure RBAC Over Access Policies

Key Vault historically used vault access policies (per-principal allow lists of secret/key/certificate permissions on the vault resource). Microsoft guidance for new vaults is Azure role-based access control (RBAC) on the data plane.

Model How permissions are assigned Guidance for new AI-200 designs

Azure RBAC Built-in or custom roles at vault, resource group, or subscription scope Preferred; aligns with Azure Policy, PIM, and consistent IAM

Access policies Vault-specific policy entries for secrets/keys/certificates Legacy for greenfield; still appears on older vaults

Important built-in roles for secret retrieval:

  • Role Typical assignee Capability relevant to retrieval
  • Key Vault Secrets User Application managed identity Get and list secrets (read path)
  • Key Vault Secrets Officer Automation / operators who set secrets Full secret management including set/delete
  • Key Vault Reader Auditors needing metadata Read metadata; does not return secret values
  • Key Vault Administrator Platform admins Broad control; avoid for app identities

Exam tip: Grant the least privilege needed for retrieval. An App Service that only reads connection strings should get Key Vault Secrets User , not Administrator. Separately, management-plane roles (Contributor on the vault resource) do not automatically grant secret get—data-plane secret access is distinct.

When a vault still uses access policies, you would add the managed identity’s object ID and enable Get (and usually List ) on secrets. Do not mix mental models on the exam: RBAC roles replace those policy permission checkboxes for RBAC-permissioned vaults.

Retrieving Secrets in Code: SecretClient and GetSecret

In .NET, Java, Python, JavaScript, and Go, the Azure SDK pattern is the same idea: create a SecretClient bound to the vault URI, authenticate with DefaultAzureCredential (or an explicit managed identity credential), then call GetSecret / GetSecretAsync .

Conceptual flow:

Resolve vault URI: https://{vault-name}.vault.azure.net/ .

Build credential chain that succeeds for managed identity in Azure (and optionally Azure CLI locally).

Call GetSecret(secretName) or GetSecret(secretName, version) .

Read the returned secret’s Value property; never log it.

If you omit the version, the client returns the current (latest enabled) version. Explicit versioning matters when you design rotation (covered in the next section). For retrieval-only designs, applications often cache the secret in memory with a short TTL and refresh on failure (401/403 after rotation) rather than calling Key Vault on every request.

Network constraints also affect retrieval: private endpoints, firewall IP rules, and “allow trusted Microsoft services” settings can block a correctly authorized identity. If GetSecret fails with a network/timeout symptom while RBAC looks correct, check vault networking next.

Key Vault References in App Service and Container Apps

Not every workload must call the SDK directly. Azure App Service (including Azure Functions on App Service plans) supports Key Vault references in application settings. You store a reference string instead of the plaintext secret, for example:

@Microsoft.KeyVault(SecretUri=https://contoso-vault.vault.azure.net/secrets/DbConnection)

or the shorthand form with vault name and secret name. At runtime, App Service uses the app’s managed identity to resolve the reference and injects the secret value into the configuration surface the app already reads ( GetEnvironmentVariable , IConfiguration , and so on).

Azure Container Apps similarly supports secret references backed by Key Vault so container environment secrets are resolved via the Container App’s managed identity rather than baked into the revision YAML as plaintext.

  • Approach Who calls Key Vault Best when
  • SDK GetSecret in app code Your process Custom caching, multi-secret orchestration, non-App Service hosts
  • App Service Key Vault reference App Service platform Classic web/API apps already driven by app settings
  • Container Apps Key Vault secret Container Apps platform Containers that should not embed vault SDK code

Both platform-reference patterns still require: managed identity enabled, RBAC (or access policy) granting secret get, and network path to the vault.

Retrieval Security Checklist for AI Solutions

AI-200 scenarios often combine Azure OpenAI, Storage, Search, and custom backends. Treat every API key and connection string the same way:

Create secrets in Key Vault (never commit them).

Assign Key Vault Secrets User to each consuming managed identity.

Prefer Key Vault references for App Service/Container Apps configuration; use SDK GetSecret when the platform cannot resolve references.

Restrict vault network access; prefer private endpoints for production.

Enable soft delete and purge protection; monitor diagnostic logs for secret get/list anomalies.

Retrieval is only half of secret hygiene. Once multiple versions and zero-downtime updates enter the picture, you need deliberate rotation patterns —the focus of the next section.