L5. RBAC, Resource Locks, Backup Security & Infrastructure as Code Guardrails

Azure Built-In Role Assignments

Azure ships broad built-in roles (Owner, Contributor, Reader) alongside narrower service-specific roles (Storage Blob Data Reader, Virtual Machine Contributor, Key Vault Secrets User). The core governance discipline is least privilege: assign the narrowest built-in role that satisfies the actual job, scoped to the smallest resource group or resource possible rather than the subscription.

Custom Roles

When no built-in role fits, a custom Azure role is defined in JSON with:

• Actions — allowed management-plane operations
• NotActions — explicit carve-outs from a broader Actions grant
• DataActions / NotDataActions — data-plane operations (e.g., reading blob content, not just managing the storage account)
• AssignableScopes — which management groups/subscriptions/resource groups the role can be assigned within

Microsoft Entra custom roles work the same way but scope to directory-level permissions (like managing specific app registrations) rather than Azure resource operations, and the two systems (Azure RBAC and Entra RBAC) are managed and assigned independently.

Evaluating and Remediating Overprivileged Access

Standing overprivileged assignments are found through:

• Access reviews (recurring, reviewer-driven confirmation of continued need for a role assignment)
• PIM analytics and audit history, showing which eligible roles are actually activated versus granted but never used
• Manual review of IAM blade role assignments against actual job function, removing legacy assignments left over from role changes or offboarding gaps

Resource Locks

A resource lock is scope-independent of RBAC: even an Owner cannot delete (or, with a stricter lock, modify) a locked resource until the lock itself is removed.

• CanNotDelete: authorized users can still read and modify the resource, but cannot delete it
• ReadOnly: authorized users can read the resource but cannot modify or delete it, effectively freezing it

Locks are commonly applied to production networking components, Key Vaults, and other resources where an accidental delete would be catastrophic and hard to recover from.

Azure Backup Security Features

Ransomware and malicious insiders both target backups, so Azure Backup has hardening features beyond simple scheduling:

• Soft delete: a deleted backup is retained (default 14 days) instead of purged immediately, giving time to detect and reverse a malicious deletion
• Multi-user authorization (MUA): requires a second, independent set of approvers (via Azure Resource Guard, ideally in a separate subscription/tenant) before critical operations like disabling soft delete or deleting a backup can proceed, so a single compromised admin account cannot unilaterally destroy recovery points
• Immutable vaults: once set, backup data in the vault cannot be deleted before its retention period expires, even by someone with full Owner rights, and the immutability setting itself can be locked to prevent reversal
• Cross-region restore: allows recovery into a paired region if the primary region becomes unavailable

Security Controls via Infrastructure as Code

Shifting governance left means catching misconfigurations before deployment rather than after:

• Policy as code / what-if analysis previews what an ARM or Bicep deployment would change before it's applied
• Microsoft Defender for DevOps scans infrastructure-as-code templates (ARM, Bicep, Terraform) in source repositories for misconfigurations, surfacing findings back to the same Defender for Cloud recommendations used for runtime resources, so a bad configuration is caught in the pull request rather than after deployment

Exam tip: Expect a scenario contrasting RBAC (who can act) with resource locks (whether the action is possible at all, regardless of role) with backup MUA (requiring a second approver from a separate authorization boundary specifically to block a single compromised admin from destroying recovery points).