D1 · Identity, Governance & Monitoring

Key Vault, Secrets and Keys

Azure Key Vault centralizes secrets, cryptographic keys and certificates. AZ-305 evaluates the design: which tier to choose based on HSM/compliance requirements, how to grant access (RBAC vs policies), how many vaults, and how to protect against deletion.

Contents

Secrets, keys and certificates
Standard vs Premium vs Managed HSM
Access models: RBAC vs access policies
Protection: soft delete, purge, network
Design patterns and rotation
Decision table

Secrets, keys and certificates

Secrets

•Sensitive strings: connection strings, passwords, API keys
•The app READS them — Key Vault stores them encrypted
•Automatic versioning on update
•Even better: eliminate the secret entirely using Managed Identity

Keys

•RSA/EC cryptographic keys — NEVER leave the vault
•Operations happen inside the vault: encrypt, decrypt, sign, wrap
•Backbone of Customer-Managed Keys (CMK) for Storage/SQL/Disks
•BYOK (Bring Your Own Key) support from an on-prem HSM

Certificates

•Full lifecycle management for X.509 certificates
•Auto-renewal with integrated CAs (DigiCert, GlobalSign)
•App Service/App Gateway consume them directly
•Expiration notifications

Standard vs Premium vs Managed HSM

Offering	Key protection	When to choose it
Key Vault Standard	Software-protected keys	Default for secrets, certs and keys with no HSM requirement
Key Vault Premium	FIPS 140-2 Level 2 HSM-backed keys (multi-tenant)	Compliance requiring HSM (CMK with HSM, PCI). Same API, moderate cost
Managed HSM	Dedicated single-tenant HSM, FIPS 140-2 Level 3, own security domain	Strict regulation (banking, government): full control of the cryptographic domain, keys never shared with other tenants
Dedicated HSM / Cloud HSM	Dedicated HSM appliance (Thales)	Lift-and-shift for apps that speak PKCS#11 directly — no integration with Azure services

Exam signals

"FIPS 140-2 Level 2" → Key Vault Premium. "FIPS 140-2 Level 3" or "single-tenant HSM" → Managed HSM. "Just application secrets" → Standard is enough.

Access models: Azure RBAC vs access policies

Azure RBAC (recommended)

•Data plane roles: Key Vault Administrator, Secrets User, Crypto Officer...
•Granularity down to an individual secret (per-object scope)
•Integrates with PIM, Conditional Access, deny assignments
•Unified governance with the rest of Azure
•Default on new vaults and what the exam expects as the answer

Access policies (legacy)

•Per-vault list of identities with permissions (get, list, set...)
•No per-object granularity — permissions over the ENTIRE vault by type
•No PIM or management group inheritance
•Only keep for existing, unmigrated vaults

How many vaults?

Recommendation: one vault per app, per environment, per region. The vault is the security and throttling boundary — sharing a vault across apps mixes blast radius, request limits and permissions. Vaults are free (you pay per operation), so there's no cost reason to share them.

Protection: soft delete, purge protection, network

Deletion and recovery

• Soft delete (mandatory): deleted objects/vault recoverable for 7-90 days
• Purge protection: prevents permanent deletion during the retention period — NO ONE can purge, not even Microsoft. Irreversible once enabled
• Mandatory to enable purge protection if the vault stores CMKs (if you purge the key, the encrypted data is lost forever)

Network and resiliency

• Private Endpoint + disable public access for VNet-only traffic
• "Allow trusted Microsoft services" so Azure services can access it despite the firewall
• Automatic replication within the region and to the paired region — read failover managed by Microsoft
• Audit logging with diagnostic settings (who accessed which secret)

Design patterns and rotation

Pattern	How
App reads secrets without credentials	Managed Identity + Key Vault Secrets User role
App Service consumes secrets transparently	Key Vault references in app settings (@Microsoft.KeyVault(...))
AKS consumes secrets	Secrets Store CSI Driver with workload identity
Encrypt Storage/SQL/Disks with your own key	CMK: key in Key Vault + the service's managed identity with wrap/unwrap permissions
Automatic key rotation	Rotation policy on the key (auto-rotate) + services pointing to the "latest" version
Rotating third-party secrets	Event Grid (near-expiry event) → Function that rotates it on the external system and updates the secret
Zero secrets	The best secret is the one that doesn't exist: Managed Identity for everything that supports it

Decision table

Requirement	Design
Store an app's connection strings	Key Vault Standard + Managed Identity + RBAC
CMK with FIPS 140-2 Level 2 HSM	Key Vault Premium
A bank requires single-tenant Level 3 HSM	Managed HSM
Prevent CMK loss from accidental/malicious purge	Soft delete + purge protection
The vault should only be reachable from the VNet	Private Endpoint + deny public access
Per-secret permission granularity	RBAC model (not access policies)
Separate apps without shared blast radius	One vault per app/environment/region
A TLS certificate that renews itself	Key Vault certificate with an integrated CA and auto-renewal

Did you get this topic?

Test what you just learned

A bank designs its data encryption in Azure: the encryption keys must (1) be in a single-tenant FIPS 140-2 Level 3 validated HSM, (2) be irrecoverably protected against purge, and (3) be used as Customer-Managed Keys for Storage and SQL. Which solution do you choose?

Ready to test "Key Vault, Secrets and Keys"?

Put what you learned to the test with original AZ-305 exam questions.

Start AZ-305 mock exam

Unlimited mock exams with the Pro plan

PreviousMonitoring DesignIdentity, Governance & Monitoring NextRelational Data DesignData Storage