2.3.5. Backup Security and Infrastructure as Code Controls

💡 First Principle: Governance doesn't stop at "who can change a live resource" — it extends backward to how resources get created in the first place (infrastructure as code) and forward to whether you can actually recover from a destructive event (backup), and both are frequently the last line of defense when everything upstream fails.

Azure Backup security features — including soft-delete for backup data and multi-user authorization (MUA), which requires a second, independent approver for certain sensitive backup operations — protect backup data itself from being deleted or tampered with, including by a compromised admin account. On the creation side, implementing security controls through infrastructure as code (Bicep, ARM templates, Terraform) means embedding policy compliance and secure defaults directly into deployment templates, so resources are born compliant rather than remediated after the fact — often paired with Azure Policy's DeployIfNotExists effect to catch anything that slips through.

⚠️ Exam Trap: Backup soft-delete protects against deletion of backup data, but multi-user authorization is what specifically protects against a single compromised or malicious admin account unilaterally disabling protection or deleting backups — a scenario emphasizing "even a compromised Owner account shouldn't be able to do this alone" is pointing at MUA, not soft-delete.

Reflection Question: Why does baking security controls into infrastructure-as-code templates reduce reliance on Azure Policy's DeployIfNotExists remediation, rather than replacing the need for Policy altogether?