Quick Note — Recommend a Solution to Manage Secrets, Certificates, and Keys
AZ-305 › Unit 1 › Design authentication and authorization solutions › Recommend a solution to manage secrets, certificates, and keys
Quick Note — Recommend a Solution to Manage Secrets, Certificates, and Keys
Every Azure workload eventually needs three things it cannot hard-code: a secret (a database password, an API key), a key (a cryptographic key used for encryption or signing), and a certificate (a signed public/private key pair with a lifetime). Storing any of these in source control, App Service configuration blades, or a developer's laptop is a well-trodden path to a breach headline. Azure's answer is Azure Key Vault — a managed, audited, policy-governed service that treats each of those three objects as first-class citizens with their own identity, version history, and access controls.
Retrieval target
- Recommend a Solution to Manage Secrets, Certificates, and Keys
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Azure Key Vault | A managed service that stores and controls access to secrets, certificates, and cryptographic keys. Has two planes: management (create / configure the vault, authorized via Azure RBAC) and data (read / write secrets etc., authorized via RBAC or access policies). All operations authenticate to Entra ID — no anonymous access. |
Three object types in Azure Key Vault | Keys — encryption keys used to wrap data (e.g., for SQL TDE, Storage CMK). Secrets — opaque text values: passwords, connection strings, API tokens. Certificates — X.509 certs (with their associated private key stored as a key); Key Vault can generate self-signed, request from an integrated CA (DigiCert / GlobalSign), or import existing certs. |
Key Vault Standard vs Premium tier | Standard — software-protected keys at FIPS 140-2 Level 1. Sufficient for most workloads. Premium — adds HSM-protected keys at FIPS 140-2 Level 2 (a shared, multi-tenant HSM-backed key store). Pick Premium when compliance requires HSM-backed keys but you don't need single-tenant isolation. Both tiers share the same management plane and APIs. |
Soft-delete + purge protection on Key Vault | Soft-delete — deleted vaults / keys / secrets enter a recoverable state for 7–90 days (default 90); the name stays reserved during the window. On by default and cannot be turned off for new vaults. Purge protection — adds the rule that no admin can purge (hard-delete) during the soft-delete window; the vault must age out.… |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.