4.1.7. Azure Key Vault
💡 First Principle: Applications and services constantly need secrets — API keys, connection strings, certificates, encryption keys — and hardcoding them into application code or config files is a common way credentials leak, so Azure Key Vault exists as a centralized, access-controlled, and optionally hardware-backed (HSM) store for exactly this class of sensitive material.
Beyond storing secrets, Key Vault manages certificate lifecycle (renewal, rotation) and cryptographic keys used for encryption, all governed by RBAC and audited access logs — pairing naturally with managed identities (Phase 3.1.2), which let an application retrieve a Key Vault secret without ever storing a credential to reach Key Vault itself.
⚠️ Exam Trap: Key Vault stores and protects secrets/keys/certificates — it does not itself encrypt application data at rest automatically; applications and other Azure services call Key Vault to retrieve the keys they then use for encryption.
Reflection Question: Why does storing a database connection string in Key Vault, rather than in application source code, reduce the risk of that credential leaking?
