2.2.1. Deploying and Configuring Key Vault
💡 First Principle: A vault's most consequential setting is decided at (or near) deployment time and is awkward to change later — the permission model — so getting it right early avoids a painful migration.
At deployment, a vault is configured with a permission model: either the legacy vault access policy model or Azure RBAC (Microsoft's recommended default for new vaults). Two additional deployment-time protections matter for data durability: soft-delete (enabled by default and no longer optional on new vaults) retains deleted vaults and objects for a configurable retention period, while purge protection prevents anyone — including an Owner — from permanently deleting a vault or its contents before that retention period expires, even if they have delete permissions.
⚠️ Exam Trap: A scenario describing a vault that was "accidentally deleted and immediately purged by an admin, with no way to recover it" is describing a vault without purge protection enabled — soft-delete alone would have kept it recoverable, but only purge protection stops the immediate purge action itself.
Reflection Question: Why might an organization deliberately choose to enable purge protection even though it means even authorized owners can't immediately and permanently delete a vault when they intend to?
