3.5 Secrets, Certificates & Key Management Design

Why Secrets Management Design Matters

An architecture that authenticates users correctly but stores a database connection string or an API key in application configuration files has not solved the security problem — it has just moved it. AZ-305 tests whether you can design a secrets, certificate, and key management solution that eliminates hard-coded credentials entirely, using Azure Key Vault and managed identities together as the standard pattern.

Azure Key Vault: Three Object Types

Key Vault stores three distinct object types, and the exam expects you to distinguish them:

Key Vault comes in two tiers: Standard (software-protected keys) and Premium (hardware security module, or HSM-protected keys, for workloads with regulatory requirements for HSM-backed key material). A separate offering, Managed HSM, provides a single-tenant, FIPS 140-2 Level 3 validated HSM pool for the highest-assurance key management needs, distinct from the multi-tenant Key Vault Premium tier.

Access Model: RBAC vs. Access Policies

Key Vault has historically supported two separate authorization models, and choosing correctly is now a scored design decision:

• Access policies (legacy model) — permissions are configured directly on the vault itself, at the whole-vault level (keys, secrets, certificates as broad categories). A serious weakness: any principal with Microsoft.KeyVault/vaults/write permission (including Contributor) can edit a vault's access policy and grant themselves data access — a privilege-escalation path.
• Azure RBAC (recommended model) — permissions use the same Azure RBAC system as every other resource, restrict permission management to Owner and User Access Administrator roles, support scoping down to an individual secret/key/certificate, and integrate with Conditional Access.

As of Key Vault API version 2026-02-01, new vaults default to the Azure RBAC authorization model. Existing vaults still using access policies should be migrated deliberately — documenting current permissions, creating equivalent RBAC role assignments (e.g., Key Vault Secrets User for read-only secret access, Key Vault Administrator for full management), and testing before cutover. A vault uses exactly one model at a time; a design cannot mix RBAC and access policies on the same vault.

Managed Identities: Eliminating Hard-Coded Credentials

A managed identity is an identity Entra ID manages automatically for an Azure resource (a VM, App Service, Function App, and others), letting that resource authenticate to Key Vault (or any Entra-ID-protected service) without any credential stored in code or configuration.

Microsoft's guidance favors user-assigned managed identities for most enterprise scenarios: because the identity and its role assignments exist independently of any single resource, teams can provision RBAC access in advance, reuse one identity across a scale set or a fleet of Function Apps, and avoid re-granting access every time a resource is recreated. System-assigned identities remain the simpler choice for a single, long-lived resource where reuse is not needed.

Soft-Delete and Purge Protection

Key Vault enables soft-delete by default (and it cannot be disabled on new vaults), retaining a deleted vault or object for a configurable period — 90 days by default — during which it can be recovered. Purge protection is a separate, stronger setting that prevents anyone, including a subscription Owner, from permanently purging a vault or its contents before the retention period elapses, protecting against both accidental and malicious permanent deletion. A design for a regulated workload (financial services, healthcare) should explicitly enable purge protection rather than relying on soft-delete alone.

Exam Scenario

A web application running on Azure App Service needs to read a database connection string at startup without any secret ever appearing in application settings, source control, or a deployment pipeline variable. The correct design: enable a system-assigned managed identity on the App Service instance, grant that identity the Key Vault Secrets User RBAC role scoped to the specific Key Vault (or the specific secret), and have the application call the Key Vault SDK or use a Key Vault reference in App Service configuration to retrieve the secret at runtime. No credential is ever stored — the App Service's own platform-issued identity is the credential.

Common Traps

• Recommending access policies for a new vault when the scenario has no stated legacy constraint — RBAC is now the default and the more secure choice.
• Forgetting that Contributor-level access on a vault using the access-policy model can be a privilege-escalation path; this is precisely why RBAC restricts permission changes to Owner/User Access Administrator.
• Choosing system-assigned managed identity for a scenario that clearly needs the same identity reused across many resources (e.g., an entire VM scale set) — user-assigned is the correct fit there.
• Assuming soft-delete alone protects against malicious deletion — only purge protection prevents permanent purging during the retention window.
• Mixing RBAC and access-policy permissions on one vault — a vault operates under exactly one authorization model at a time.