An insider deletes the lock-lab Key Vault and attempts to purge it the same day. Which control prevents that immediate purge even for a subscription Owner?
Select an answer to reveal the explanation.
Short Explanation
Soft-delete gives you a recycle bin; purge protection welds it shut for the retention window. Even Owner can’t flush the vault the same day once purge protection is on—and you can’t switch that guard off later.
Full Explanation
Purge protection builds on soft-delete: once enabled, soft-deleted vaults and objects cannot be purged until the retention period elapses, even by a subscription Owner. That control is what stops an insider who deletes the lock-lab Key Vault and tries to purge it the same day. Soft-delete alone retains the deleted vault for recovery but still allows privileged principals to purge early unless purge protection is on; purge protection also cannot be turned off after enablement.
Soft-delete alone, which always allows Owners to purge instantly after delete, is therefore insufficient against a same-day purge attempt. Blob versioning on a storage account in another region fails by concept: it protects blobs, not Key Vault purge semantics. A Conditional Access policy that blocks all Azure portal sign-ins permanently fails as a Key Vault recovery control—it is a blunt identity hammer and does not specifically block purge of soft-deleted vaults via API or other clients.
Exam caveat: enable purge protection before an incident; you cannot rely on enabling it after a malicious delete/purge race. Operational check: verify soft-delete and purge protection are Enabled on the vault, attempt a test purge in a non-production twin (expect block), document retention days for the canal authority, and ensure privileged roles understand recover-versus-purge timelines.