The production Key Vault and Recovery Services vault for the canal must survive an accidental delete by a privileged operator. Which control should be applied?

A CanNotDelete resource lock on the production Key Vault and Recovery Services vault is the direct preventive control against accidental deletion by a privileged operator on the canal estate. With the lock in place, delete operations fail until an authorized person removes the lock—an intentional extra step that stops casual or mistaken destruction of irreplaceable vaults. Pairing locks with Azure Policy that audits or denies missing locks on critical resource types keeps the control from silently disappearing.

Assigning Contributor on both vaults so operators can recreate them from ARM templates after a delete assumes loss is acceptable and still permits the delete to succeed; recreation does not restore every secret version, soft-deleted state nuance, or backup chain without careful recovery procedures. Storing vault names in a wiki and training operators never to click Delete is process-only guidance with no technical enforcement. Moving both vaults to a free-tier subscription where deletes are billed as a reminder invents a billing gimmick that is not a deletion safeguard and may violate production placement and SLA expectations.

Exam caveat: CanNotDelete stops deletion but does not by itself prevent all destructive configuration changes (for example, some purge or policy changes may still be possible depending on the resource); combine locks with purge protection, RBAC least privilege, and immutability where the resource type supports them.

Operational check: apply CanNotDelete locks to both vaults, verify a non-break-glass identity cannot delete them, and run a Policy compliance query to confirm every production Key Vault and Recovery Services vault in the canal subscriptions still has the expected lock.