11.1 Azure Key Vault: Secret Storage & Retrieval

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:

1. Secrets — arbitrary string values such as connection strings, passwords, tokens, and third-party API keys. Most application retrieval scenarios use secrets.
2. 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.
3. 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.

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.

Important built-in roles for secret retrieval:

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:

1. Resolve vault URI: https://{vault-name}.vault.azure.net/.
2. Build credential chain that succeeds for managed identity in Azure (and optionally Azure CLI locally).
3. Call GetSecret(secretName) or GetSecret(secretName, version).
4. 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.

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:

1. Create secrets in Key Vault (never commit them).
2. Assign Key Vault Secrets User to each consuming managed identity.
3. Prefer Key Vault references for App Service/Container Apps configuration; use SDK GetSecret when the platform cannot resolve references.
4. Restrict vault network access; prefer private endpoints for production.
5. 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.