2.2.3. Managing Keys, Secrets, and Certificates
💡 First Principle: Keys, secrets, and certificates aren't interchangeable object types even though they all live in the same vault — each has a different purpose and a different lifecycle discipline that matters for the exam.
Keys are cryptographic keys used for encrypt/decrypt or sign/verify operations, often backing customer-managed encryption for other Azure services. Secrets are opaque values — connection strings, passwords, API keys — that Key Vault stores but doesn't perform cryptographic operations on. Certificates are a managed object type that bundles a private key with an X.509 certificate, and uniquely, Key Vault can automate their renewal through integration with a certificate authority. All three support versioning, meaning a rotation creates a new version rather than overwriting the old one — callers can reference a specific version or always resolve to the latest.
⚠️ Exam Trap: Rotating a secret's value in Key Vault does not automatically update every application that consumes it. Unless an application is configured to always fetch the latest version (or is using a Key Vault reference that resolves dynamically, such as in App Service configuration), it may keep using a cached, now-invalid version until it's restarted or explicitly refreshed.
Reflection Question: Why does Key Vault's ability to auto-renew certificates through a CA integration matter more operationally than auto-rotating a generic secret would?
