Microsoft AZ-500: Key Management, Cryptography and Certificates — Study Guide

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Part of the Microsoft Azure Security Engineer Associate AZ-500 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Key management on Azure centers on Azure Key Vault and Azure Managed HSM. These services provide secure storage of cryptographic material, consistent APIs, and auditable operations that underpin encryption at rest, in transit, and application-layer cryptography. The operational goal is to separate key custodianship from application runtime, minimize blast radius with scoped authorization and networking, and enforce recoverability and rotation to reduce long-lived secret risk.

Azure Key Vault and Managed HSM Architecture and Authorization

Azure Key Vault architecture

• Service composition: multi-tenant front ends, regional partitions for data plane, per-tenant isolation, and Azure AD-backed authentication. Keys are either software-protected (Standard tier) or HSM-protected (Premium tier). Secrets and certificates are always software-protected.
• Tiers: Standard (software keys) for general purpose and cost efficiency; Premium (HSM-backed keys) when FIPS 140-2 Level 2/3-equivalent protection or dedicated HSM boundary for key material is required. Choose Premium for regulatory requirements or when using keys with “RSA-HSM” or “EC-HSM”.
• Soft delete and purge protection: Soft delete is always on with a configurable retention (7–90 days, commonly 90). Purge protection, when enabled, prevents permanent deletion of vault or objects until retention elapses, even by highly privileged users. Operational reasoning: enable purge protection on any vault backing customer-managed keys (CMK). Without it, an accidental or malicious purge could render dependent data (e.g., storage or databases encrypted with that key) irrecoverable.
• Recovery: Deleted vault objects can be listed and recovered; vault-level recovery is supported. Backups produce encrypted blobs that can be restored to compatible vaults in the same Azure region and cloud. Reasoning: periodically export key backups and secure them separately; test restores to validate RTO.

Authorization model

• Permission models: Vault access policies (legacy) vs Azure RBAC (recommended).
  • Access policies: defined per vault; grant granular permissions for keys, secrets, and certificates. Best when you need very tight, object-type-specific runtime rights for a small set of principals.
  • Azure RBAC: set the vault’s Permission model to Azure role-based access control to use RBAC data-plane roles. Advantages: scope at subscription/resource group/vault; PIM-eligible assignments; centralized governance and auditing. Recommended for new deployments and for administrative operations.
• Built-in vault roles (examples): Key Vault Administrator (full management), Key Vault Crypto Officer (key management but not access policies), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Operational guidance:
  • Use RBAC (e.g., Key Vault Administrator) when delegating configuration of access models and network ACLs.
  • Use an access policy or a data-plane RBAC role such as Key Vault Certificates Officer for least-privilege certificate insertion/deletion in a single vault.
• Scope design: Prefer assigning RBAC at the vault scope to avoid over-privileging. Use resource group scope only when multiple vaults share identical operator teams; avoid subscription-scope assignments for runtime access.

Managed HSM

• Architecture and security domains: Managed HSM is a single-tenant, FIPS 140-2 Level 3 validated HSM cluster per customer. A security domain protects the cluster’s key material portability; backup/restore across clusters requires a quorum of security domain private keys. Reasoning: generate and escrow domain keys across distinct custodians; test restore to a DR HSM.
• Role model: Integrated with Azure RBAC. Roles include Managed HSM Administrator, Crypto Officer, Crypto User, and Reader. Separation of duties: administrators manage the cluster; crypto officers manage keys; crypto users use keys for operations.
• High availability: Regionally redundant with multiple HSM partitions and an SLA-backed service; zone redundancy available in supported regions. For disaster recovery across regions, rely on backups + security domain.
• Use cases: Payment processing, code signing, key wrapping for envelope encryption, and regulated workloads requiring Level 3 HSM boundaries.

Objects and Lifecycle: Keys, Secrets, Certificates, and Rotation

Keys, secrets, certificates

• Keys: For cryptographic operations (sign, verify, wrap/unwrap, encrypt/decrypt). Choose key type/size based on algorithm strength and performance (e.g., RSA 3072/4096 for compliance, or ECC P-256/P-384 for performance).
• Secrets: Arbitrary bytes/strings such as passwords, connection strings, and API tokens. Not used for cryptographic operations.
• Certificates: X.509 with private keys. Stored as both a certificate object and a corresponding secret (PFX/PEM). Useful for TLS/MTLS and code signing lifecycles.

Lifecycle operations and rotation

• Versioning: Every set or import generates an immutable version. Applications should reference versioned secrets for deterministic behavior or versionless URIs for automatic pick-up of the latest version depending on change-management needs.
• Rotation strategies:
  • Keys: Prefer versionless key URIs for Azure services that support them (e.g., Storage, SQL TDE, AKV-managed secrets). Rotate by adding a new version; services rebind automatically when supported. If a service requires a pinned version, automate a reconfiguration step. Enforce rotation with AKV rotation policies and alerting.
  • Secrets: Rotate via Azure Automation, Functions, or Logic Apps triggered by Event Grid notifications, or use provider-native rotation (e.g., rotating SAS or database passwords). Avoid long-lived static secrets by replacing with managed identities wherever possible.
  • Certificates: Define certificate policies with “lifetime actions” to auto-renew before expiry; use integrated issuers for hands-free renewal.

Certificate management

• Import/generation: Import existing PFX/PEM (with private key) or generate a CSR and have Key Vault complete issuance with a configured CA.
• Auto-renewal and issuers: Configure issuers such as DigiCert, GlobalSign, or an enterprise Microsoft CA via Key Vault. Enable auto-renew with notification and renewal thresholds.
• Application integration:
  • App Service and Functions: use Key Vault references with managed identity; platform auto-syncs rotated secrets.
  • Application Gateway/WAF: reference certificate secret ID from Key Vault; Gateway picks up new versions automatically.
  • AKS: mount certificates via Secrets Store CSI driver and Azure Key Vault provider.

Example RBAC assignment for least-privilege certificate operations:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Network Security and Service Integration

Key Vault networking

• Firewall rules: Set to Selected networks to restrict to approved sources. Reasoning: prevents internet-origin traffic even with valid tokens.
• Virtual network service endpoints: Allow traffic from specific subnets without private IPs. Simple to enable and reduces exposure. Use when you need quick isolation and do not require DNS changes.
• Private endpoints: Assign a private IP to the vault in your VNet for true private connectivity. Block public network access. Reasoning: strongest exfiltration control, required in high-trust environments and when outbound internet is restricted.
• Trusted services: “Allow trusted Microsoft services” lets specific Azure services reach the vault despite network restrictions. Required for scenarios like Storage encryption scanning keys during rotation. Enable narrowly and document dependencies.

Customer-managed keys (CMK) and key URIs

• Supported services: Azure Storage, SQL Database (TDE), Synapse, Databricks, AKS secrets encryption at rest, App Configuration, Event Hubs, Service Bus, and Managed Disks via Disk Encryption Set.
• Key URI strategy:
  • Versionless URIs: Prefer when service supports automatic rebind on new key versions; enables seamless rotation without service updates.
  • Versioned URIs: Required by some services; automate a service configuration update tied to rotation events.
• Rotation patterns:
  • Staggered rotation: Create new key version; validate service can access; monitor errors; then optionally disable older versions after a safe period.
  • Event-driven: Use Event Grid on key-new-version events to trigger validation or service reconfiguration workflows.

Envelope encryption integration

• Azure services use a data encryption key (DEK) locally (e.g., AES-256) and a Key Encryption Key (KEK) in Key Vault/HSM to wrap the DEK. Operationally, ensure KEK availability and network access, because loss or blocked access can stall service operations.

Example: wrap a DEK with an AKV key

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Cryptography, Data-at-Rest Options, and Secrets Hygiene

Core cryptographic concepts

• Symmetric encryption: One key used to encrypt/decrypt (e.g., AES-GCM/CTR). Fast; ideal for bulk data.
• Asymmetric encryption: Public/private key pairs (RSA/ECC) used for key exchange and signatures. Slower; ideal for establishing trust and wrapping DEKs.
• Hashing: One-way digest (e.g., SHA-256). For integrity; not encryption.
• Signing: Private key produces signature; public key verifies. Non-repudiation and integrity.
• Envelope encryption: Combine asymmetric KEK with symmetric DEK for performance and isolation of key custody.

Azure Disk Encryption and storage encryption

• Managed Disks default encryption: Server-side encryption (SSE) with platform-managed keys (PMK). Minimal ops overhead.
• CMK with Disk Encryption Set (DES): Use a DES referencing a Key Vault or Managed HSM key for disks, snapshots, and images. Reasoning: centralized key lifecycle control and revocation; meets compliance for customer control.
• ADE (Azure Disk Encryption): In-guest BitLocker (Windows) or dm-crypt (Linux). Use when you need OS-level encryption posture, disk-level key protectors bound to domain, or existing compliance mandates. Operational trade-off: higher complexity, extension management, and potential VM provisioning impact.
• Double encryption:
  • Disks: Combine SSE with PMK at the infrastructure layer plus CMK via DES to achieve two independent encryption layers.
  • Storage accounts: Use encryption scopes with separate CMKs per container/workload; combine with infrastructure encryption where available for two layers.
• Encryption scopes (Azure Storage): Define per-container or per-blob scopes with distinct CMKs to isolate tenant/workload risk and enable targeted rotation without broad impact.

Secrets hygiene and operational practices

• Managed identities: Use system- or user-assigned managed identities for Azure resources to obtain tokens for Key Vault and services, eliminating embedded credentials. Scope RBAC or access policies narrowly.
• Secret scanning: Enable Microsoft Defender for DevOps, GitHub Advanced Security secret scanning, and repository protections. Integrate with pull requests to block known credential patterns.
• Pipelines and IaC: Use Key Vault task integrations in Azure Pipelines and GitHub Actions OIDC-based federated credentials to avoid persisted secrets. Do not print secrets in logs; mask outputs. Rotate any leaked material immediately.
• App design: Prefer versionless references where safe; cache minimally and handle 401/403 by re-acquiring tokens and re-fetching secrets to support rotation events.

Certificate Management Deep-Dive

• Policy-driven issuance: Define subject, SANs, key usage, EKUs, key type/size, and reuse-key settings in a Key Vault certificate policy. Reasoning: consistent TLS posture across estates.
• Issuer integration: Configure a CA profile in Key Vault. For private PKI, integrate with Microsoft ADCS via a custom issuer or use Azure Key Vault’s Certificate Connector. Public CAs allow automated renewal without exposing private keys outside AKV.
• Auto-renewal operations: Use lifetime actions (e.g., renew at 60 days before expiry; notify at 90 days). Operationally, align renewal windows with change freezes and ensure dependent services auto-sync.
• Application consumption: Retrieve as a secret (PFX/PEM) or bind by reference in platform services. Prefer platform-native bindings (App Service, Application Gateway) for zero-downtime rollover on new versions. For Kubernetes, mount via CSI to trigger rolling restarts on rotation.

Practical Problem Scenario

Siemens AG must protect IoT telemetry in Azure, enforce strong key custody for data at rest, and automate certificate and secret rotation across a globally distributed fleet.

1. Establish vaults and HSM boundaries

• Create regional Premium Key Vaults for application secrets/certificates and a Managed HSM for KEK operations.
• Rationale: Premium vaults enable HSM-backed keys when needed; Managed HSM provides Level 3 assurance and independent key custody for wrapping operations.

2. Enforce recoverability and guardrails

• Enable purge protection on all vaults and Managed HSM; set soft-delete retention to 90 days. Apply Azure Policy to audit/deny vaults without purge protection.
• Rationale: Prevents catastrophic data loss from purges; policy ensures drift cannot occur.

3. Centralize authorization using RBAC

• Set vaults to Azure RBAC permission model. Assign Key Vault Administrator to a small platform team via PIM; assign Key Vault Secrets Officer to app teams at the vault scope; assign Managed HSM Crypto Officer to security engineers.
• Rationale: RBAC + PIM yields least privilege, time-bound elevation, and consistent auditing. Separation of duties keeps administrators from using keys.

4. Lock down networking with private endpoints

• Create private endpoints in hub VNets; disable public network access. Enable “trusted services” only for Storage accounts using CMK.
• Rationale: Private endpoints eliminate public exposure and block data exfiltration paths while preserving necessary service-to-vault flows.

5. Implement CMK and encryption strategy

• For Storage, define encryption scopes per workload with versionless KEK URIs in the Premium vault; for Managed Disks, use Disk Encryption Sets with CMK from the HSM. Enable infrastructure-level encryption for double encryption.
• Rationale: Per-workload keys reduce blast radius; versionless URIs enable seamless rotation; double encryption satisfies stringent compliance.

6. Automate key and secret rotation

• Configure AKV key rotation policies (e.g., annual expiry, rotate at 9 months) and Event Grid notifications that trigger validation jobs. Use managed identities in services; remove static credentials.
• Rationale: Predictable, automated rotation reduces risk from long-lived keys and secrets; managed identities replace fragile shared secrets.

7. Operationalize certificates

• Use Key Vault certificate policies with DigiCert issuer integration; set auto-renewal at 60 days before expiration. Bind certificates by reference in Application Gateway and App Service.
• Rationale: Automated renewal prevents outages and avoids manual key handling; platform bindings pick up new versions without redeployments.

8. Validate and monitor

• Enable Key Vault and Managed HSM diagnostic logs to Log Analytics; alert on unauthorized attempts, firewall denials, and near-expiry events. Run quarterly restore tests for vault and HSM backups using the security domain quorum.
• Rationale: Continuous monitoring detects misconfigurations or attacks promptly; restore testing ensures recoverability under pressure.

← Data · All domains · Security Posture Management and Governance →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →