Azure Key Vault
Azure Key Vault is a managed store for the three kinds of sensitive material an application needs: secrets (connection strings, API keys), cryptographic keys (for encryption and signing), and certificates (with lifecycle management). Access is governed centrally and every operation is logged, so secrets leave application config and config files for a controlled, audited home.
The pattern Key Vault enables is the one this book repeats: applications authenticate with a managed identity and fetch what they need from the vault at runtime, so no secret is ever stored in code, an environment variable, or a pipeline. A leaked repository or config file then exposes nothing.
Secrets, Keys, and Certificates
Secrets are arbitrary protected values. Keys are cryptographic keys you can use for encrypt/decrypt and sign/verify operations without the key ever leaving the vault. Certificates bundle a key with an X.509 certificate and can be auto-renewed through an integrated certificate authority. Each has its own access model and versioning, so rotating a value leaves the old version available until consumers move over.
Applicationneeds a connection string or key
Managed identityEntra ID issues a token — no secret storedKey Vaultreturns the secret at runtime, every access loggedAccess Model
Access is governed by either Azure RBAC (the recommended model — roles assigned at the vault or secret scope, consistent with the rest of Azure) or the older vault access policies. RBAC is preferred for its granularity and consistency. Either way, the principle is least privilege: an application identity that needs one secret should be able to read that one secret, not the whole vault.
HSM Protection
The Premium tier stores keys in FIPS-validated hardware security modules, and Azure Managed HSM provides single-tenant, fully isolated HSMs for the strictest compliance and key-sovereignty requirements. The HSM guarantee is that key material cannot be exported in the clear — operations happen inside the hardware. Choose HSM backing when regulation demands it; standard software protection suffices otherwise.
Soft Delete and Purge Protection
Soft delete (on by default) retains deleted vaults and objects for a recovery period, and purge protection prevents even a privileged user from permanently deleting them before that period elapses. Together they defend against accidental and malicious deletion of the keys that everything else depends on — losing the key that encrypts a database is an unrecoverable outage, which is exactly what purge protection prevents.
Rotation
Secrets and certificates should rotate on a schedule, and Key Vault supports automated rotation and event notifications so consumers pick up new versions without an outage. Long-lived, never-rotated secrets are a standing risk; the vault's versioning and rotation are what make regular rotation operationally painless rather than a feared manual chore.
Key Vault standard — Software-protected keys, secrets, and certificates. The default for application secrets and most key needs.
Key Vault Premium — Keys in shared FIPS-validated HSMs. Choose it when keys must be hardware-protected but full isolation is not required.
Managed HSM — Single-tenant, fully isolated HSMs. Choose it for strict compliance and key-sovereignty mandates.
- Storing secrets in code, environment variables, or pipeline variables instead of Key Vault — a leaked repo or config then exposes them.
- Granting an application broad access to the whole vault rather than least-privilege access to the specific secrets it needs.
- Disabling soft delete or skipping purge protection on a vault holding keys that encrypt production data — a deletion then becomes unrecoverable.
- Never rotating long-lived secrets, leaving a leaked credential valid indefinitely.
- Using vault access policies for new vaults instead of the recommended Azure RBAC model.
- Paying for Managed HSM when standard software protection met the requirement, or using software keys where regulation demanded an HSM.
- Have applications fetch secrets at runtime via a managed identity; never store secrets in code or config.
- Use Azure RBAC with least privilege — scope access to specific secrets, not the whole vault.
- Keep soft delete and purge protection enabled on vaults holding production keys.
- Automate secret and certificate rotation and subscribe to rotation events so consumers update seamlessly.
- Use Premium or Managed HSM only where compliance requires hardware-protected or isolated keys.
- Reach the vault over a private endpoint and log all access for audit.
Knowledge Check
What is the recommended pattern for an application to use a Key Vault secret?
- Authenticate with a managed identity and fetch the secret at runtime, storing nothing in code or config
- Export the secret into a plaintext environment variable on the host machine at deploy time and read it from there
- Embed the secret directly into one of the built container image layers at build time
- Store the vault access key as a plaintext variable in the deploy pipeline configuration
What does purge protection defend against?
- Permanent deletion of keys and secrets — even by a privileged user — before the soft-delete retention elapses
- Unauthorized read access to stored secrets by external attackers who have breached the network perimeter
- Secrets being rotated far too frequently by misconfigured automation jobs running on a schedule
- Direct network access to the vault endpoint from across the public internet by clients sitting outside the virtual network
When is Azure Managed HSM the right choice over standard Key Vault?
- When strict compliance or key-sovereignty mandates require single-tenant, fully isolated HSMs
- For storing ordinary application connection strings, API keys, and other everyday low-sensitivity secrets
- Whenever soft delete and the recovery of accidentally deleted keys is a requirement
- For automating certificate issuance, renewal, and rotation schedules across applications
You got correct