AZ-305 Key Vault and Managed Identity: Secrets, Certificates, RBAC, or Managed HSM?

For AZ-305 security design questions, separate four decisions before picking a service. Use managed identity when Azure-hosted code needs credential-free access to a downstream service. Use Key Vault secrets for values such as connection strings and API keys that still exist as secrets. Use Key Vault certificates when certificate lifecycle and renewal matter. Use Key Vault keys or Managed HSM when the scenario is about cryptographic keys, customer-managed encryption, HSM-backed protection, or stronger isolation. Then decide authorization: Key Vault uses Microsoft Entra ID authentication, and the data plane can use Azure RBAC or legacy access policies (Key Vault authentication, Key Vault RBAC guide).

This is current AZ-305 scope. Microsoft lists Design identity, governance, and monitoring solutions at 25-30%, and the exam page says the English exam was updated on April 17, 2026 (AZ-305 exam page, AZ-305 study guide).

Compact Decision Shortcut

Need app-to-service access without stored credentials?

Start with managed identity. Microsoft describes managed identities as Microsoft Entra identities for Azure resources that let code obtain tokens without developers managing credentials (managed identities overview).

Need to store a password, connection string, or API key?

Use Key Vault secrets. Key Vault stores keys, secrets, and certificates as distinct object types, and secrets are intended for values such as passwords and database connection strings (Key Vault keys, secrets, and certificates).

Need TLS certificate lifecycle, renewal, or certificate storage?

Use Key Vault certificates instead of storing certificates as generic secrets. Microsoft explicitly warns not to store service-owned certificates as secrets and recommends Key Vault certificates with autorotation where appropriate (secure your Key Vault).

Need encryption keys or customer-managed keys?

Use Key Vault keys for many app and platform encryption scenarios. Use Managed HSM when the requirement calls for single-tenant HSM isolation, FIPS 140-3 Level 3 validated HSMs, local RBAC isolation, or high-value keys that need stronger sovereignty boundaries (Managed HSM overview).

Need private access to the vault?

Use Key Vault firewall rules or Private Link depending on the exposure requirement. Microsoft says disabling public network access and using private endpoints is the most restricted option, and Private Link brings the service into a VNet through a private IP (secure your Key Vault, Key Vault Private Link).

One Mental Model

The common exam trap is treating Key Vault as the answer to every security prompt. Key Vault stores and protects secrets, certificates, and keys. Managed identity answers a different question: how the workload authenticates without embedding credentials. RBAC or an access policy answers who can perform the requested operation. Private Link answers whether the network path is private.

The AZ-305 Decision Boundary

The strongest answer usually starts by removing secrets rather than hiding them. If an Azure workload can use managed identity to reach a service that supports Microsoft Entra authentication, prefer that over creating an app registration secret. Microsoft says managed identity token acquisition does not require secrets, and its supported-services page lists many Azure services that can use managed identities (managed identities overview, services supporting managed identities).

Then use Key Vault for the sensitive objects that remain: third-party API keys, legacy connection strings, TLS certificates, and customer-managed encryption keys. A good design can use both managed identity and Key Vault: the identity authenticates, and the vault controls access to the protected object.

System-Assigned vs User-Assigned Managed Identity

Use a system-assigned identity when one Azure resource needs its own lifecycle-bound identity. It is created and deleted with the resource, which is useful when permissions should disappear with the resource.

Use a user-assigned identity when multiple resources perform the same role, permissions must be preauthorized before deployment, or resource churn would create identity and role-assignment noise. Microsoft notes that user-assigned identities can be shared, have decoupled lifecycles, and reduce role assignment overhead; Microsoft also recommends least privilege for any managed identity (managed identity best practices).

Exam clue: if four identical web apps need the same Key Vault read permission, a user-assigned identity is often cleaner. If one VM must have unique permissions and the identity should be removed with the VM, system-assigned identity is often cleaner.

Key Vault Authorization: Control Plane vs Data Plane

Key Vault has two planes. The control plane manages the vault resource itself. The data plane works with protected objects: get a secret, sign with a key, import a certificate, rotate a key, or recover an object. Microsoft documents that the control plane uses Azure RBAC, while the data plane uses either legacy Key Vault access policies or Azure RBAC for Key Vault data-plane operations (Key Vault RBAC guide).

This matters because Contributor on a vault is not the same as permission to read secrets. Microsoft also warns that a user with Key Vault control-plane contributor permissions can grant themselves data-plane access by setting an access policy, so that role must be tightly controlled (Key Vault RBAC guide).

For new designs, prefer Azure RBAC for Key Vault permissions unless the scenario gives a reason to use access policies. Use vault-per-application-per-environment boundaries when possible; Microsoft recommends separating vaults by application, region, and environment to reduce blast radius (Key Vault RBAC guide, secure your Key Vault).

Key Vault vs Managed HSM

Use Key Vault when the workload needs centralized management for secrets, certificates, software-protected keys, or HSM-protected keys in a multitenant vault model. That is the common architecture answer for most application secret and certificate scenarios.

Use Managed HSM when the question emphasizes dedicated single-tenant HSMs, local RBAC isolation, FIPS 140-3 Level 3 validated HSMs, key sovereignty, or high-value key custody. Microsoft describes Managed HSM as a fully managed, highly available, single-tenant HSM service dedicated to one customer with a separate customer-specific security domain (Managed HSM overview).

Boundary: Managed HSM is for cryptographic keys, not for secrets and certificates. Key Vault supports secrets, certificates, and keys; Managed HSM is the specialized answer for HSM-backed key management.

Resilience and Deletion Protection

For protected keys and secrets, deletion behavior can be part of the architecture. Microsoft says soft-deleted Key Vault resources are recoverable for 7 to 90 days, with 90 days as the default. Purge protection prevents purge until the retention period passes and is recommended when using keys for encryption; Microsoft also notes that some integrated services require purge protection to prevent data loss (Key Vault soft delete).

Exam clue: if the scenario says accidental deletion of encryption keys would make data unrecoverable, do not stop at "put the key in Key Vault." Include soft delete and purge protection.

Network Security: Do Not Confuse Identity With Reachability

Managed identity and RBAC can allow an operation, but the network path can still block it. Key Vault can allow public endpoint access, firewall-restricted access, trusted Microsoft services where appropriate, or Private Link. Microsoft positions disabling public network access and using private endpoints as the most restricted Key Vault network option (secure your Key Vault).

Private Link is not an authorization replacement. It gives the vault a private endpoint in a virtual network and routes traffic over the Microsoft backbone, but the caller still needs Microsoft Entra authentication and the right Key Vault permissions (Key Vault Private Link, Key Vault authentication).

Worked Scenario: Payment App With Secrets, Certs, and Encryption Keys

A company runs a payment application on Azure App Service and background workers on VMs. Requirements:

• The web app must connect to Azure SQL without secrets where possible.
• A payment processor API still requires an API key.
• The public website uses TLS certificates that must renew predictably.
• Azure Storage uses a customer-managed encryption key.
• Production and development must be isolated.
• Security requires private access from the workload VNet and protection from accidental key deletion.

First, remove credentials where Azure supports identity-based access. Give the App Service and workers managed identities and grant only the roles they need. Use a user-assigned identity for repeated workers with the same access, and a system-assigned identity when one VM needs unique lifecycle-bound permissions.

Second, place remaining objects in the right Key Vault type. Store the payment processor API key as a secret, TLS material as a certificate, and customer-managed encryption material as a key. Use separate vaults for production and development so one compromised app identity does not inherit access to unrelated secrets.

Third, choose authorization and network controls. Use Key Vault data-plane Azure RBAC for the managed identities. Avoid broad vault contributor assignments. Add Private Link or firewall restrictions if the requirement says private access. Enable soft delete and purge protection for encryption-key scenarios.

Exam-ready answer: managed identity for authentication, Key Vault objects for protected material, Azure RBAC for least-privilege data-plane access, separate vaults by application and environment, Private Link for private reachability, and purge protection for encryption-key resilience.

What Wrong Answers Reveal

If you choose Key Vault but still put a client secret in app settings, you may be hiding credentials instead of removing them. If you choose managed identity for a third-party API key, you missed that a secret still exists. If you grant Contributor to solve a secret-read problem, you confused control-plane management with data-plane access. If you choose Managed HSM for passwords or certificates, you missed that Managed HSM is a key-management service, not a general secret store.

Where CramHQ Fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this topic, CramHQ can help turn missed identity and security questions into a targeted loop: identify whether the miss came from authentication, object type, authorization plane, network reachability, HSM boundary, or deletion protection, then route remediation, lessons, targeted practice, and readiness planning around that gap.

When you are ready, take the AZ-305 assessment. After each missed security-design question, write one sentence: "I picked the wrong control because I missed ____." Fix that boundary, then retest nearby scenarios.

Quick Recap

Use managed identity to avoid credentials in Azure-hosted workloads. Use Key Vault secrets for remaining secret values, Key Vault certificates for certificate lifecycle, and Key Vault keys for cryptographic-key scenarios. Use Managed HSM when single-tenant HSM isolation and high-value key governance are explicit requirements. Keep authentication, authorization, network reachability, vault boundaries, and deletion protection separate in your reasoning.