A Key Vault secret was deleted ten minutes ago and the vault still exists. Soft-delete retention has not expired. What should the security engineer do first?
Select an answer to reveal the explanation.
Short Explanation
Ten minutes ago and the vault’s still standing? Soft-delete recover is the fast lane. Save the backup-blob restore for when the vault itself is gone or retention already burned down.
Full Explanation
If a Key Vault secret was deleted minutes ago, the vault still exists, and soft-delete retention has not expired, recover the soft-deleted object in that vault first. Soft-delete recovery is the direct, least-disruptive path. Reserve encrypted backup-blob restore for vault loss, migration, or cases where retention has ended and the object was purged. Disabling soft-delete or racing to purge only reduces recovery options during the lock-lab incident.
Immediately purging and recreating the secret under a new name fails by concept as a first step: purge removes the recoverable soft-deleted copy (when purge is allowed) and forces application renames. Restoring from an encrypted backup blob even though soft-delete recover is available fails operational priority—backup restore is heavier and constrained when in-vault recover works. Disabling soft-delete so the delete becomes permanent before investigating fails recovery posture and may not even apply the way operators expect on already-deleted objects.
Exam caveat: prefer recover over recreate-with-new-name to keep secret URIs stable for applications. Operational check: list deleted secrets in the existing vault, recover the object within retention, confirm the original name and versions, validate app Get, and only if recover fails escalate to backup restore procedures.