What's changed: Added per-section figures (cert-figure-retrofit). New SC-500 Chapter 1 (Domain 1 "Manage identity, access, and governance": Entra ID = PIM/conditional access/MFA-passwordless/app identities-OAuth consent/managed identities; Key Vault = RBAC vs access policies/network restriction/soft-delete-purge protection/Defender CSPM secret scanning-Defender for Key Vault; governance = Azure Policy/Defender for Cloud regulatory compliance/RBAC over-privilege remediation/resource locks/Azure Backup/IaC)
1.2Protecting secrets and keys with Azure Key Vault
Learn Azure Key Vault for safely storing secrets, keys, and certificates: deployment, the access models (RBAC vs access policies), network restriction (firewall / private endpoint), managing keys/secrets/certificates, and threat detection via Defender CSPM secret scanning and Defender for Key Vault.
Hard-coding secrets like passwords, connection strings, API keys, encryption keys, and TLS certificates into code or config makes a leak costly. Azure Key Vault is a managed service that stores them centrally and encrypted, tightly controls access, and audits use. For SC-500 you design not just storage but who can access (authorization model), where access is allowed from (network), and how leaks/anomalies are detected (Defender) as one whole.
1.2.1Access model: RBAC vs access policies
Key Vault authorization has two models. Azure RBAC (recommended) controls data-plane operations (using keys, reading secret values, etc.) through role assignments, unified with PIM, conditional access, and other Azure resources. The older vault access policy model grants permissions per vault (e.g., "allow this identity to get keys"). For new vaults, choose RBAC. In either model, enforce least privilege (e.g., allow getting a secret but not deleting or managing it).
1.2.2Network restriction: firewall and private endpoints
By default Key Vault has a public endpoint. Firewall settings can narrow it to "only selected virtual networks / IPs," and a private endpoint (Private Link) restricts traffic to a private IP inside the virtual network only, removing public exposure. Combined with the "allow trusted Microsoft services" option, you can block external access while still letting legitimate services like Defender reach the vault. Authorization (RBAC) and network restriction are separate layers; applying both gives defense in depth.
1.2.3Keys, secrets, certificates, and lifecycle protection
- Keys: cryptographic keys for encryption/signing—used for Storage CMK, SQL TDE protector, etc. HSM-backed protection is available.
- Secrets: sensitive strings such as passwords, connection strings, API keys.
- Certificates: TLS/SSL certificates, with automatic renewal (lifecycle management).
- Soft-delete + purge protection: guarantee recovery from accidental/malicious deletion; with purge protection, permanent deletion is blocked during the retention period.
1.2.4Detection: Defender CSPM secret scanning and Defender for Key Vault
Beyond storage and control, detect "is anything leaking or being used suspiciously?" Defender CSPM secret scanning finds hard-coded secrets (plaintext keys or connection strings) in VMs, code, and resources and pushes you to move them into Key Vault. Microsoft Defender for Key Vault detects anomalous access patterns to the vault (unusual locations, bulk retrieval, etc.) and raises alerts. The two differ in role: proactive discovery (CSPM) vs runtime threat detection (a Defender plan).
| Aspect | Feature | Key point |
|---|---|---|
| Who can access | Azure RBAC (recommended) / access policy (legacy) | Least privilege; RBAC for new vaults |
| Where access is allowed | Firewall / private endpoint | Remove public exposure (defense in depth) |
| Protect from deletion | Soft-delete + purge protection | Block permanent delete during retention |
| Find hard-coded secrets | Defender CSPM secret scanning | Proactive posture (drives migration) |
| Detect suspicious vault access | Defender for Key Vault | Runtime threat alerts |
Do not mix RBAC and access policies: a vault operates under one authorization model. Microsoft recommends standardizing on Azure RBAC for new vaults and migrations.
Watch the mix-ups: (1) authorization (RBAC/access policy) vs network restriction (firewall/private endpoint) are separate layers—both are needed. (2) Defender CSPM secret scanning (proactively finds hard-coded secrets) vs Defender for Key Vault (runtime detection of suspicious access). (3) soft-delete (recoverable) vs purge protection (blocks permanent delete during retention).
Common: requirement → Key Vault setting. E.g., "limit vault access to inside the VNet" = private endpoint/firewall; "find plaintext keys in code" = Defender CSPM secret scanning; "detect anomalous vault access" = Defender for Key Vault; "recover from accidental deletion" = soft-delete + purge protection; "grant least-privilege access" = Azure RBAC.
1.2.5Section summary
- Key Vault = central, encrypted, audited store for secrets/keys/certs; eliminates hard-coding
- Authorize via Azure RBAC (recommended) or legacy access policies; enforce least privilege
- Network: firewall + private endpoint remove public exposure
- Detect with Defender CSPM secret scanning (proactive) and Defender for Key Vault (runtime); soft-delete + purge protection guarantee recovery
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. For a new Key Vault, which authorization model does Microsoft recommend, unified with PIM and conditional access?
Q2. Which approach limits Key Vault traffic to a private IP inside the virtual network and removes public exposure?
Q3. Which feature proactively finds hard-coded plaintext secrets (keys/connection strings) in VMs and code and drives migration to Key Vault?
Q4. Which raises alerts at runtime for anomalous access patterns to a Key Vault?
Q5. Which combination guarantees recovery by preventing permanent deletion of Key Vault objects during a retention period?
Q6. Which statement about securing Key Vault is correct?