Azure Key Vault Patterns
Key Vault for secrets, keys, certs — accessed via Managed Identity, never via direct secret references. Cache aggressively; KV has tight throttling limits.
Deep dive
Three object types
Secrets (opaque strings), Keys (HSM-backed crypto operations), Certificates (managed PFX lifecycle). Pick the right one — Keys never leave the HSM; secrets do.
Throttling
KV allows ~2000 ops/10s per vault by default. A hot service that reads a secret per request hits this fast. Always cache with a TTL (5–15 min) and a background refresh.
CSI driver vs SDK
- Secrets Store CSI Driver: mounts secrets as files in the pod. App reads from disk. Good for legacy apps; supports auto-rotation.
- SDK direct: more flexible, lets you cache and react to rotation events.
Soft delete + purge protection
Both should be on in production. They've saved teams from accidental terraform destroy.
Real-world example
From productionA consumer service hit KV throttling during a traffic spike — every request fetched a JWT signing key fresh. Added a 10-minute in-memory cache with a jittered background refresh; KV calls dropped 99.9%, latency p99 dropped 80 ms.
Interview questions
1 senior-levelQ1How do you avoid Key Vault throttling?▾
Cache secrets in memory with a TTL and a background refresh, ideally with jitter to avoid herding. For pod-mounted secrets, use the CSI driver which handles caching for you. Never read KV on the hot request path.
Common mistakes
Reading secrets on every request.
Granting
Key Vault Administratorto runtime identities — runtime needsSecrets User, period.Disabling soft delete to 'clean up' a vault.
Trade-offs
CSI driver is hands-off but tied to file rotation semantics — apps that hold the value in memory still need restart or signal handling.