Manage identity, access, and governance
Azure Key Vault Defense in Depth
CoreDeploy vaults with recoverability, constrained network reachability, least-privileged data access, governed object lifecycle, posture discovery, and workload threat detection.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
Keys, secrets, and certificates concentrate trust. Authentication, authorization, network isolation, recoverability, rotation, posture findings, and runtime alerts are separate layers that must work together.
Must Know
- Choose tenant, region, service tier, soft-delete retention, and purge protection before dependent workloads make lifecycle changes costly.
- Azure RBAC authorization uses data-plane roles such as Key Vault Secrets User; legacy access policies are a different authorization model and should not be mixed casually.
- A firewall or private endpoint controls network reachability but never substitutes for an identity permission to read a secret or use a key.
- Manage keys, secrets, and certificates as distinct object types with versions, activation and expiration dates, rotation, backup, and recovery requirements.
- Defender CSPM secret scanning finds exposed secrets in supported development and cloud assets; Defender for Key Vault raises workload-protection alerts about suspicious vault activity.
- Soft delete makes deleted objects recoverable for the retention period; purge protection prevents permanent deletion until that period expires.
Compare and Distinguish
- Vault firewall and private endpoint restrict paths; Key Vault RBAC decides what an authenticated principal can do.
- Defender CSPM finds secret exposure and attack paths; Defender for Key Vault detects suspicious access to a deployed vault.
- A key supports cryptographic operations, a secret stores an opaque value, and a certificate combines certificate material with lifecycle handling.
Scenario examples
- Scenario: A production vault must resist malicious purge after deletion. Think: enable soft delete and purge protection before use.
- Scenario: A private workload cannot read a secret. Think: verify DNS and private connectivity separately from the workload identity role.
- Scenario: A repository contains a plaintext credential while vault traffic is normal. Think: remediate the CSPM secret finding rather than expecting a Key Vault alert.
Exam traps
- A private endpoint does not automatically disable every public path; verify the vault public network access and firewall configuration.
- Key Vault Contributor manages the resource but does not inherently grant secret-value access under Azure RBAC.
- Rotating a secret creates a new version; dependent applications must retrieve or transition to it safely.
- Recovering a vault object and restoring its consumer are separate operational steps.
Key takeaways
- Design recoverability and network boundaries before storing production material.
- Grant object-specific data-plane roles at the narrowest workable scope.
- Treat posture discovery and suspicious-activity detection as complementary controls.
How it works
- A caller reaches the vault endpoint, authenticates with Microsoft Entra, and is authorized by the configured data-access model.
- Object versions and deletion state persist according to lifecycle settings while logs and Defender signals supply evidence.
Objects and administrative surfaces
- Key Vault resource settings for recovery, authorization model, networking, diagnostics, and object lifecycle.
- Azure IAM and Key Vault data-plane roles for principals that manage or consume vault objects.
- Defender for Cloud recommendations, secret findings, and Defender for Key Vault alerts.
When to use it
- Use Key Vault for governed keys, secrets, and certificates consumed by identities rather than embedded credentials.
- Use CSPM scanning for exposure discovery and Defender for Key Vault for suspicious activity against vaults.
Security and governance implications
- Require expiration and rotation ownership for sensitive objects and monitor dormant broad assignments.
- Protect production vault deletion, diagnostic destinations, and private DNS from casual change.
Troubleshooting signals
- Test name resolution, route and firewall reachability, identity, and data-plane role in that order.
- For certificate or secret rollover, inspect the active version and consumer refresh behavior before deleting an old version.
More detail
- Deploy vaults with suitable tier, retention, purge protection, and diagnostics.
- Select Azure RBAC or the legacy access-policy model and grant minimum data access.
- Restrict vault networking without forgetting DNS and authorization.
- Respond differently to exposed-secret findings and suspicious vault-access alerts.
Ready for the quiz?
- Which setting stops a privileged actor from immediately purging a deleted secret?
- Why can a private endpoint connection succeed while secret retrieval is forbidden?
- Which Defender capability finds a plaintext credential outside Key Vault?
Related objectives
- D1.2.S1 — Deploy Key Vault
- D1.2.S2 — Configure Key Vault settings
- D1.2.S3 — Configure access to Key Vault
- D1.2.S4 — Configure firewall settings on Key Vault
- D1.2.S5 — Manage keys, secrets, and certificates
- D1.2.S6 — Scan for secrets by using Defender Cloud Security Posture Management (Defender CSPM)
- D1.2.S7 — Implement Defender for Key Vault