An AZ-305 scenario asks you to recommend a solution so that the data in a storage account is encrypted with customer-managed keys. The recommendation has three parts. The key lives in Azure Key Vault, or in a Managed HSM when the scenario calls for dedicated HSMs. The storage account reaches the key through a managed identity, with wrapkey, unwrapkey, and get permissions at minimum. The vault has soft delete and purge protection enabled. Microsoft lists both as requirements on the key store that holds the key (Customer-managed keys overview for Azure Storage).
The other Key Vault and managed identity questions on AZ-305 are the same pattern. Something protects the object, something authenticates to reach it, and something authorizes the operation. Decide each one separately, and the recommendation is the set of answers in order. Microsoft measures these decisions in the Design identity, governance, and monitoring solutions domain, which carries 25-30% of the exam, so it gets about a quarter of your study time. The study guide's task list names "Recommend a solution to manage secrets, certificates, and keys" directly (skills measured as of April 17, 2026) (AZ-305 study guide). Recheck that study guide before you book. Microsoft updates the English version of the exam first, and the skills list carries the date of the current update.
Where the customer-managed key lives and how the storage account reaches it
Azure Storage supports two key stores for customer-managed keys. They are Azure Key Vault and Azure Key Vault Managed HSM. The two use the same APIs and management interfaces for this configuration, so the choice is about the protection level. The setup is the same either way (customer-managed keys overview). Key Vault is the default answer. Pick Managed HSM when the scenario asks for dedicated single-tenant HSMs or FIPS 140-3 Level 3 validated hardware (Managed HSM overview).
The key itself must be an RSA or RSA-HSM key, with a size of 2048, 3072, or 4096 bits. A key size outside that range, or a key type that is not RSA or RSA-HSM, does not meet the storage CMK requirement.
The storage account authenticates to the vault with a managed identity. A Key Vault administrator grants the identity permission on the key, and the identity is either the system-assigned managed identity associated with the storage account or a user-assigned identity you create. Configuring CMK at account creation requires a user-assigned identity. On an existing account, either works. The minimum key permissions are wrapkey, unwrapkey, and get (customer-managed keys overview).
The reason is the wrap step. When CMK is enabled, Azure Storage wraps the account's root data encryption key with the customer-managed key, and for every read and write it asks the vault to unwrap it. The identity only needs to read the key and wrap and unwrap with it. Enabling CMK for the account always covers Blob Storage and Azure Files, while Queue and Table storage are covered only if you opt them in when the account is created (customer-managed keys overview).
Two behaviors the exam likes to probe. Rotation. Azure Storage does not rotate the key. You rotate it in the vault, typically at least every two years, and if you leave the key version unset, Storage checks the vault once a day for a new version. Revocation. Disabling the key in the vault makes the storage account's read and write operations fail with error code 403. The key's state is the data's availability (customer-managed keys overview).
Each scenario cue maps to one control
| The scenario says | Pick | Why |
|---|---|---|
| An app on Azure must reach a service without stored credentials | A managed identity, system- or user-assigned | Managed identity replaces access keys and passwords, and token acquisition needs no secrets (managed identities overview) |
| A connection string, API key, or password must be stored | A Key Vault secret | Key Vault protects secrets such as connection strings and passwords (secure your Key Vault) |
| A TLS certificate must renew or rotate on schedule | A Key Vault certificate | Microsoft says not to store service-owned certificates as secrets. Store them as Key Vault certificates with autorotation (secure your Key Vault) |
| An encryption key, customer-managed encryption, or HSM-backed key protection | A Key Vault key, or a Managed HSM for single-tenant FIPS 140-3 Level 3 isolation | Managed HSM is a key management service with a dedicated security domain per customer (Managed HSM overview) |
| Access to the vault must stay inside a virtual network | Key Vault firewall or Private Link. Disable public network access with Private Endpoints only is the most restricted option | The secure page orders the network options from most restricted to least restricted (secure your Key Vault) |
The failure this table prevents is treating Key Vault as the answer to every security prompt. Key Vault protects the object. Managed identity answers how the workload authenticates. A data-plane role or access policy answers who can perform the operation. Private Link answers whether the network path is private.
System-assigned for one resource, user-assigned for many
Use a system-assigned identity when the permission belongs to one resource and should disappear with it. The service principal behind the identity is tied to the resource's lifecycle, and it is deleted when the resource is deleted. The identity cannot be shared with another resource.
Use a user-assigned identity when multiple resources need the same permission, when the permission must exist before the resources are deployed, or when the resources churn and the permission should stay consistent. It is a standalone resource with its own lifecycle, and Microsoft lists it as the recommended managed identity type for Microsoft services (managed identities overview).
Four identical web apps that need the same Key Vault read permission point to a user-assigned identity. One VM with unique permissions that should be removed with the VM points to system-assigned. The CMK section adds a third cue. A new storage account configured for CMK at creation must use a user-assigned identity.
Authorize on the right plane
Key Vault has two planes. The control plane manages the vault resource itself. The data plane works with the objects inside. Get a secret, sign with a key, import a certificate. Both planes authenticate with Microsoft Entra ID. For authorization, the control plane uses Azure RBAC, and the data plane uses a legacy access policy or Azure RBAC for data-plane operations (RBAC guide).
Contributor on a vault is not permission to read its secrets. The Key Vault Contributor role covers control-plane management only. The trap the exam uses is documented. A user with Contributor on the control plane can grant themselves data-plane access by setting an access policy, so Microsoft says that role needs tight control (RBAC guide). If a scenario asks who should be able to read a secret, the answer is a data-plane role or an access policy entry, not Contributor.
For new designs, Azure RBAC is the default access control model for newly created vaults starting with API version 2026-02-01, and Microsoft's guidance is to prefer it over legacy access policies, which lack Privileged Identity Management support (RBAC guide, secure your Key Vault). Vault boundaries follow applications. Microsoft recommends one vault per application, region, and environment to reduce the impact of a breach (secure your Key Vault). For the storage CMK identity, note the built-in Key Vault Crypto Service Encryption User role. Its description is read key metadata and perform wrap and unwrap operations, the cryptographic operations the storage account performs on the key (RBAC guide).
Key Vault for the general answer, Managed HSM for key custody
Key Vault stores secrets, certificates, and keys, software-protected or HSM-protected, in a multitenant service. It is the common architecture answer for application secrets and certificates.
Managed HSM is a fully managed, highly available, single-tenant service dedicated to key management. Each instance is one customer's cluster of HSM partitions inside a customer-specific security domain, and the fleet runs on FIPS 140-3 Level 3 validated HSMs (Managed HSM overview). Its local RBAC model gives designated HSM cluster administrators control over the HSMs that management group, subscription, or resource group administrators cannot override. The keys also stay in the region the instance is deployed in, which is the sovereignty cue in a scenario.
The scenario's wording decides. Dedicated single-tenant HSMs, local RBAC isolation, FIPS 140-3 Level 3 validation, key sovereignty, or high-value key custody point to Managed HSM. A general secret, certificate, or encryption-key scenario points to Key Vault. The service is built for keys. Generate them, protect them, and release them to workloads. Passwords and TLS certificates are Key Vault objects, so those scenarios stay Key Vault no matter how the security story is framed.
When deleting the key would delete the data
If a key protects data, its deletion behavior is part of the architecture. With soft delete on, a deleted key stays recoverable for a configurable 7-90 days, and 90 is the default. That window exists so an accidental deletion can be noticed and undone. Soft delete is on by default for new vaults, and once enabled it cannot be disabled. Purge protection is different. It is optional and off by default, and it blocks purge until the retention period passes (soft-delete overview).
A recommendation that stops at "put the key in Key Vault" is missing the vault's requirements. For a storage account, soft delete and purge protection are not optional. Microsoft's soft-delete page states that most Azure services that integrate with Key Vault, such as Storage, require purge protection to prevent data loss (soft-delete overview), and the CMK overview lists both as key store requirements (customer-managed keys overview). The reason is concrete. If the key a storage account wraps its encryption with is disabled or deleted, the account's data operations start returning errors (secure your Key Vault). So when a scenario says accidental deletion of the encryption key would make the data unrecoverable, the answer includes soft delete and purge protection.
The network path is a separate decision
Managed identity and RBAC can both authorize an operation while the network still blocks it. Key Vault's network options are ordered from most to least restricted. Disable public network access and use Private Endpoints only. A Key Vault firewall limited to your VNets or specific public IPs. Or public access. Private Link gives the vault a private access point from a virtual network, and disabling public access blocks data-plane connections. None of them replaces authorization. The caller still needs Entra authentication and the right data-plane permission on the vault (secure your Key Vault).
A scenario asking for private access from the workload VNet points to Private Link. One asking for no public exposure at all points to disabling public network access with Private Endpoints only. One asking to restrict by IP or VNet points to the firewall.
Worked scenario: a payment app with secrets, certificates, and a CMK storage account
A company runs a payment application on Azure App Service with background workers on VMs. The requirements:
- The web app connects to Azure SQL without stored credentials where the service supports Entra authentication.
- A payment processor API still requires an API key.
- The public website uses TLS certificates that must renew predictably.
- A storage account holds encrypted backups and must use a customer-managed encryption key.
- Production and development are isolated.
- The workload VNet reaches the vault privately, and accidental deletion of the key must not make the backups unrecoverable.
The recommendation assembles from the sections above. First, remove credentials where Azure supports identity. Give the App Service and the workers managed identities with only the roles they need. A user-assigned identity for the repeated workers, since they share a role. A system-assigned identity for a worker whose permission should die with the VM.
Second, put each object in the right place. The processor API key is a Key Vault secret. The TLS material is a Key Vault certificate with autorotation. The storage encryption key is a Key Vault key in a vault with soft delete and purge protection enabled, and the storage account's managed identity has wrapkey, unwrapkey, and get on that key.
Third, separate the boundaries and the path. One vault per environment, Azure RBAC for the data plane, no vault-wide Contributor assignments, and Private Link from the workload VNet to the vault.
What the wrong answers reveal
- Picking Key Vault but leaving a client secret in app settings hides a credential instead of removing it. Managed identity was available for that connection.
- Picking managed identity for a third-party API key misses that the secret still exists. It belongs in Key Vault.
- Granting Contributor to solve a secret-read problem confuses the control plane with the data plane.
- Picking Managed HSM for passwords or certificates misses that the service manages keys.
- Recommending a customer-managed key without the vault's soft delete and purge protection recommends a key store that does not meet Microsoft's requirements for storage CMK.
Find which boundary you miss
If you keep missing one boundary on these questions, the free AZ-305 assessment is where you start. It is free, needs no card, and returns a Readiness Report with your top gaps and a targeted repair preview. As you work the practice questions, CramHQ notes which boundary each miss points to, weighs each gap by the points it costs on the exam, and orders the Pass Plan so the gaps that cost the most points lead the list. One of the sample gap areas on the AZ-305 path is Identity and network boundaries, the same two layers this article keeps separate (free AZ-305 assessment).
After each security-design question you miss, write one sentence. "I picked the wrong control because I missed ____." Fix that boundary, then retest the nearby scenarios. The full AZ-305 path is the paid path. Its core is the Pass Plan, the ranked list of repair tasks that target your gaps. The practice tests and the timed simulation check your readiness and support that list. The path costs US$34.99 for 12 months of access, and the first repair is free (AZ-305 course).