Backup operators on the canal estate were given Owner on the Recovery Services vault and can delete the vault itself. Which change restores least privilege for daily backup work?

Least privilege for daily canal-estate backup work means replacing Owner with Azure Backup job-function roles—Backup Contributor, Backup Operator, or Backup Reader—matched to what each operator actually does. Those roles cover backup management, job execution, and read access without granting the ability to delete the Recovery Services vault itself. Removing Owner from day-to-day operators closes the demolition path while still letting the crew run backups and restores.

Leaving Owner in place and using Azure Policy only to audit vault deletes after they occur is detective, not preventive: the vault can still be deleted, and an audit alert arrives too late. Assigning Contributor at the subscription so operators can recreate any deleted vault quickly still allows broad destructive rights across many resources and treats vault loss as an acceptable recreate loop rather than preventing the delete. Moving the vault into a sandbox subscription while keeping Owner for convenience changes the address of the problem without fixing privilege; Owner on a production-critical vault remains excessive regardless of which subscription hosts it.

Exam caveat: Backup Operator and Backup Contributor are not interchangeable with classic Contributor/Owner on the vault resource—know which built-in backup roles allow vault deletion versus only backup jobs, and do not assume Contributor is "safer" than Owner if it still permits vault lifecycle operations you intended to block.

Operational check: review Azure RBAC assignments on the vault (and parent scopes), remove Owner/Contributor from daily backup identities, assign the least Backup * role that still allows required jobs, then confirm a test operator can run backup/restore workflows but cannot delete the vault.