3.3 Keys, Secrets, Certificates & Defender for Key Vault

Keys vs Secrets vs Certificates

Design rule: If the value is a password-like credential the app only needs to read, store a secret. If Azure or your app must perform crypto without exporting private key material, use a key. If you need a public cert + private key lifecycle for TLS, use a certificate (which may create related key/secret objects under the covers).

Secrets support optional contentType, nbf/exp, and enabled attributes. Note that get can still retrieve not-yet-valid or expired secrets for recovery/testing—expiration is informational for operational hygiene, not a hard crypto boundary.

---

Versioning

Every set/create/rotate produces a new version under a stable object name:

• Versioned URI: https://contoso.vault.azure.net/secrets/DbConn/<version-guid> — pins exact material
• Versionless URI: https://contoso.vault.azure.net/secrets/DbConn — resolves to the current version

Best practice for rotation-friendly apps: Configure consumers with versionless identifiers so they pick up new versions after rotation. Persist versioned identifiers with ciphertext when decrypting historical data (CMK wrap patterns), so unwrap still uses the key version that wrapped the DEK.

You can disable an old version without deleting it, list versions, and recover soft-deleted versions according to retention rules.

---

Rotation

Cryptographic keys

Key Vault supports rotation policies per key:

• Auto-rotate a given time after create (for example every 18 months)
• Or auto-rotate a given time before expiry (requires expiry on policy and key)
• Near-expiry Event Grid notifications for manual or custom automation
• On-demand Rotate now

Rotation creates new key material as a new version. For Azure CMK integrations, services re-wrap data encryption keys; they do not necessarily re-encrypt all customer data immediately. Keep prior key versions enabled until re-wrap completes. Microsoft guidance commonly cites rotating encryption keys at least about every two years; many policies use shorter intervals.

Permissions: manage rotation with Key Vault Crypto Officer (RBAC) or access-policy rotate / set rotation policy permissions.

Secrets and certificates

Secrets do not use the same built-in crypto rotation policy object; you set a new secret version (manual, pipeline, or Event Grid–driven automation) and update consumers. Certificates use certificate policy for lifetime, issuer, and auto-renewal—prefer Key Vault–managed renewal over shipping PFX files in repos.

---

Soft-Delete Recovery of Objects

Deleting a key, secret, or certificate with soft-delete enabled:

1. Object becomes inaccessible for normal get/crypto use
2. Remains listable via deleted items APIs for the retention window
3. Recover restores it to active use
4. Purge permanently destroys it (blocked while purge protection is active until retention ends)
5. Name remains reserved while soft-deleted—you cannot create a conflicting new object with the same name

Exam scenario: An operator accidentally deletes secrets/PaymentApiKey. Correct response is recover the soft-deleted secret (with recover permission), not immediately create a new secret of the same name (may fail while deleted object exists) or rotate every dependent system without checking deleted items first.

If the entire vault was soft-deleted, recover the vault first, then re-create RBAC assignments and event subscriptions that were lost.

---

Microsoft Defender for Key Vault

Defender for Key Vault is a Defender for Cloud workload protection plan that detects unusual and potentially harmful access to vaults—anomalous callers, suspicious patterns, possible credential misuse.

Response playbook (exam-aligned):

1. Do not dismiss an alert only because you recognize the app name—verify with the owner; stolen identity is the threat model.
2. If source IP is unexpected: enable/tighten firewall, private endpoints, remove broad access.
3. If principal is unauthorized: remove role assignments or access policies; reduce Entra privileges.
4. Review diagnostic logs for the caller IP / appId / OID around the alert time.
5. Rotate every secret/key/certificate that was accessed; disable old versions; audit downstream apps.

---

Defender CSPM Secret Scanning

Separately from runtime anomaly detection, Defender Cloud Security Posture Management (CSPM) and related Defender capabilities scan for exposed secrets so you can eliminate them at the source:

SC-500 skill language: Scan for secrets by using Defender CSPM and Implement Defender for Key Vault. Treat them as complementary:

• CSPM scanning → find secrets that should never have left Key Vault (or never been created as plaintext)
• Defender for Key Vault → detect abuse of vaults that already hold the crown jewels

---

Exam Scenarios: Key Vault vs App Settings

Classic exam stem: “Developers stored SQL passwords in App Service application settings and checked a backup into source control. Leadership wants centralized control, rotation, and detection of odd access.”
Answer path: Move secrets to Key Vault; use managed identity + Secrets User; enable diagnostics; enable Defender for Key Vault; use CSPM/DevOps secret scanning to catch regressions; purge secrets from git and rotate everything exposed.

Another stem: “Storage account uses CMK. Security wants assurance keys cannot be purged by a compromised admin for 90 days.”
Answer: Soft-delete + purge protection on the vault holding the CMK; restrict Purge Operator; monitor with Defender for Key Vault.

Operational Checklist

1. Classify data: secret vs key vs certificate
2. Enforce RBAC data roles + managed identity
3. Versionless URIs for apps; versioned IDs for ciphertext metadata
4. Rotation policies for CMKs; automated secret set for credentials
5. Soft-delete recover drills; purge protection for encryption vaults
6. Diagnostics → Log Analytics/Sentinel
7. Defender for Key Vault on; CSPM secret scanning on code and cloud
8. Prefer Key Vault over plaintext app settings for credentials

SC-500 Exam Traps (Objects & Defender)

• Certificate ≠ secret: TLS lifecycle needs certificate objects/policies.
• Rotation ≠ delete-and-recreate under a new name when versioning exists.
• Recover before recreating same-named objects.
• Defender for Key Vault ≠ CSPM secret scanning—one is anomalous vault access, the other is finding leaked credentials.
• App settings are not a substitute for Key Vault when the scenario stresses audit, RBAC, rotation, or CMK.