A kelp-forest diver deletes OldSmtp in Key Vault and can still recover it during the retention window. What developer-facing behavior explains that?
Select an answer to reveal the explanation.
Short Explanation
Delete on a soft-delete vault is more like “move to recycle bin” than shredder. Until retention ends—and longer if purge protection blocks purge—you can still recover OldSmtp.
Full Explanation
Soft-delete, enabled by default on modern vaults, retains deleted secrets for a recoverable retention period; purge protection can block permanent purge until that window ends. When the kelp-forest diver deletes OldSmtp and can still recover it, that developer-facing behavior is soft-delete—not magic undelete outside Key Vault. Recover the secret if deletion was accidental; purge only when policy allows and the retention rules are satisfied.
Claiming delete is always hard-purge with no recovery ignores soft-delete and purge-protection settings that municipal vaults commonly enforce. Asserting only Managed HSM pools soft-delete while standard vaults never retain deleted secrets is false for standard Key Vault behavior taught to developers. Saying soft-delete applies only to App Configuration feature flags misattributes the feature—App Configuration has its own soft-delete story, but this item is about Key Vault secrets.
Exam caveat: recovery and purge permissions differ from ordinary get and list; operators need the right RBAC actions to recover versus purge. Operational check: in a non-production vault, delete a disposable secret, list deleted secrets, recover OldSmtp's analogue, then attempt purge with and without purge protection to see which operations the portal or SDK rejects.