Azure Key Vault: — Getting Secrets, Keys and Certs Out of Your Code

① The secrets-in-code problem — and what Key Vault actually is

Meet Sneha, an L1 cloud engineer at Infosys. On her second day she opens a teammate's web app and finds this in appsettings.json: "ConnectionString": "Server=...;Password=Sup3r!". That one line is the most common security mistake in the cloud. The moment it is committed, the password lives in Git history forever, gets baked into the container image, and shows up in stack traces and CI logs. Rotating it means a code change and a redeploy across every environment.

This is not a hypothetical. Public Git scanners find tens of thousands of live cloud credentials a year, and most real breaches start not with a clever exploit but with a leaked key sitting in a repo or a log file. A hard-coded secret is a single shared password — once anyone sees it, everyone who can reach your database does too.

Azure Key Vault is the managed locker that fixes this. It stores three object types, and knowing the difference matters because the exam and the job both test it. A secret is any sensitive string — a DB password, an API key, a connection string. A key is a cryptographic key (RSA or EC) used for encrypt/decrypt, sign/verify or wrap/unwrap; in the Premium tier these are HSM-backed so the private key never leaves the hardware. A certificate is an X.509 cert plus its private key, with lifecycle management on top (auto-renewal from an integrated CA).

The four leak paths a hard-coded secret rides

Tap each card — these are the exact paths a password in code escapes to people who shouldn't have it.

② Access models — RBAC vs access policy, managed identity & network controls

Now the part that decides whether your vault is actually secure: who can read what. Key Vault separates two distinct surfaces. The control plane manages the vault resource (create it, set firewall rules). The data plane is the data inside — reading a secret, using a key. Mixing these up is the #1 confusion on AZ-500, so keep them separate in your head: control plane = the locker; data plane = what's inside it.

For the data plane, Key Vault gives you two authorisation models, and the choice is not cosmetic. Vault access policies are the legacy model: a flat list on the vault granting operations like get/list secrets. Azure RBAC is the modern, recommended model — and starting with Key Vault API version 2026-02-01 it is the default for new vaults, matching the portal. The reason to prefer RBAC is concrete: with access policies, anyone holding Microsoft.KeyVault/vaults/write (such as a Contributor) can add themselves to the policy and read every secret. That is privilege escalation by design.

RBAC fixes that with granular built-in roles you scope at the vault or even a single secret: Key Vault Secrets User (read secret values — what an app needs), Key Vault Secrets Officer (manage secrets), Key Vault Crypto User/Officer (keys), Key Vault Certificate Officer (certs), and Key Vault Administrator (everything — give it to almost nobody). Crucially, granting access now requires Owner or User Access Administrator, so reading and granting are different powers. RBAC also plugs into PIM for time-limited access.

So how does an app authenticate without a credential to store? With a managed identity. Azure gives your App Service or VM its own identity in Entra ID; you grant that identity the Key Vault Secrets User role; at runtime the platform fetches a short-lived token for it. There is no password, no certificate, nothing for you to keep safe — the credential you would otherwise leak simply does not exist.

# get the app's managed-identity principal id
PID=$(az webapp identity show -g rg-shop -n shop-api --query principalId -o tsv)

# scope the role to THIS vault only (least privilege)
az role assignment create \
  --assignee "$PID" \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/aaaa1111-2222-3333-4444-bbbb55556666/resourceGroups/rg-shop/providers/Microsoft.KeyVault/vaults/kv-shop-prod"

{
  "principalId": "7f3c9d2e-1a4b-4c8e-9f0a-2b6d1e8c4a90",
  "roleDefinitionId": ".../4633458b-17de-408a-b874-0445c86b69e6",
  "roleDefinitionName": "Key Vault Secrets User",
  "scope": ".../vaults/kv-shop-prod"
}

Identity is half the story; the other half is the network. A vault on the public internet, even with perfect RBAC, is still reachable by every IP on earth to attempt access. Lock the door with the vault firewall, a private endpoint (so traffic stays on your VNet), or service endpoints, and then set public network access = Disabled. One real gotcha: disabling public access also locks you out of the portal unless you keep a management IP allowed or route through the private endpoint.

③ Keys, certs & lifecycle — HSM, rotation, soft-delete, purge & logging

Secrets are just strings; keys and certificates are where Key Vault earns the 'vault' in its name. A key in the Standard tier is software-protected (types RSA, EC, oct). In the Premium tier you get HSM-backed keys (RSA-HSM, EC-HSM, oct-HSM) — the private key is created inside, and never leaves, the hardware module. You'd pick HSM keys for customer-managed encryption keys, compliance mandates, or anything where 'the key can't be exported, even by an admin' is a hard requirement.

Long-lived secrets are a liability, so Key Vault automates rotation. Keys support an automatic rotation policy (rotate N days after creation or before expiry; minimum interval 7 days), and you can also rotate on demand with az keyvault key rotate. Microsoft's baseline is to rotate encryption keys at least every two years, more often for sensitive workloads. Key Vault versions every object automatically, so a new version doesn't break data already encrypted with the old one.

Certificates get the most automation. Create a cert with an integrated CA (DigiCert or GlobalSign) and Key Vault handles end-to-end renewal — by default it auto-renews at 80% of the certificate's lifetime, configurable in the Issuance Policy as a 'Lifetime Action Type'. Services like App Service, Application Gateway and Front Door then pick up the new version automatically (usually within 24 hours, no restart). The classic outage this prevents: a TLS cert silently expiring on a Friday and taking the site down.

Two safety nets you must understand cold for AZ-500. Soft-delete is ON by default and cannot be disabled; the retention window is 7–90 days (default 90) and is fixed at vault creation. Purge protection is the stronger sibling: with it on, a soft-deleted object cannot be purged early by anyone — admin or attacker — until retention elapses. Purge protection is not on by default, and once you enable it you can't turn it back off. That irreversibility is the point: it stops a 'delete then purge' ransom/destruction attack.

# soft-delete is already ON by default; recover a vault someone deleted
az keyvault recover --name kv-shop-prod

# make destruction impossible until retention elapses (one-way switch)
az keyvault update --name kv-shop-prod -g rg-shop --enable-purge-protection true

# stream every secret/key/cert access to Log Analytics for Sentinel
az monitor diagnostic-settings create --name kv-audit \
  --resource $(az keyvault show -n kv-shop-prod --query id -o tsv) \
  --logs '[{"category":"AuditEvent","enabled":true}]' \
  --workspace law-soc-prod

{
  "name": "kv-shop-prod",
  "properties": {
    "enableSoftDelete": true,
    "softDeleteRetentionInDays": 90,
    "enablePurgeProtection": true
  }
}

④ App integration done right — managed identity, references, gotchas & the cheat-sheet

Time to put it together the way you'll actually ship it. A web app needs a database password. The wrong way you've now seen. The right way has three moves: (1) store the password as a secret in Key Vault, (2) give the App Service a managed identity with the Key Vault Secrets User role, and (3) point the app's config at the vault with a Key Vault reference. The app code reads the same app setting it always did — but the value now comes from the vault.

The reference syntax is the one string to memorise: @Microsoft.KeyVault(SecretUri=https://kv-shop-prod.vault.azure.net/secrets/db-password/). Drop that as the value of an app setting (say DB_PASSWORD) and App Service resolves it from the vault using the app's managed identity — your code just reads DB_PASSWORD like any environment variable, never knowing it came from Key Vault. The big payoff: rotate the secret in the vault and the app picks up the new value with no redeploy (leave off the version in the URI so it always tracks 'latest').

# 1) put the password in the vault
az keyvault secret set --vault-name kv-shop-prod \
  --name db-password --value 'P@ss-from-secure-source'

# 2) app reads it via a Key Vault reference (resolved by managed identity)
az webapp config appsettings set -g rg-shop -n shop-api --settings \
  DB_PASSWORD='@Microsoft.KeyVault(SecretUri=https://kv-shop-prod.vault.azure.net/secrets/db-password/)'

[
  {
    "name": "DB_PASSWORD",
    "value": "@Microsoft.KeyVault(SecretUri=https://kv-shop-prod.vault.azure.net/secrets/db-password/)",
    "slotSetting": false
  }
]
# Portal shows a green 'Key Vault Reference' resolved tick once the role propagates

For your certification path, this lesson maps straight onto AZ-500 (Microsoft Azure Security Technologies) — specifically the 'Secure data and applications' area, objective 'configure and manage Azure Key Vault': access (RBAC vs access policies), managing secrets/keys/certificates, key rotation, soft-delete and purge protection, and backup/recovery. Nail the RBAC-vs-policy distinction and the soft-delete/purge pair and you've covered the highest-frequency Key Vault questions on the exam. Career-wise, this is daily bread for any Azure security or cloud-support role in India.

RBAC role vs the job it does — match them fast

Tap each card — interviewers love asking 'which role would you give X?' Least privilege means picking the smallest one that works.