Governance: Azure Policy, RBAC, Custom Roles, Locks, IaC…

Governance at scale, in one module

Simple explanation

Governance is how you keep the rules of your tenant from quietly breaking. A single security engineer cannot manually inspect every storage account, every NSG rule, every RBAC assignment across thousands of resources. So you express rules and run them automatically:

Azure Policy is the rules engine: “every storage account must require HTTPS”, “no public IPs on production NSGs”, “all SQL servers must have auditing on”. Built-in definitions cover most baseline controls; you write custom definitions for the rules unique to your org.
Regulatory compliance in Defender for Cloud maps your environment against frameworks (ISO 27001, PCI DSS, NIST 800-53, CIS, SOC 2, etc.) and gives you a compliance scorecard with remediation steps.
Resource locks prevent accidental delete or modification on resources that should not change.
RBAC + custom roles let you grant least-privilege at exactly the scope and actions a role needs — and access reviews catch the privilege creep that always returns.
Azure Backup security features protect backup data itself from being attacked (Soft delete, immutability, multi-user authorisation).
IaC security controls push these guardrails leftward into Bicep, ARM, and Terraform pipelines so misconfigurations are caught before they ship.

Azure Policy

Azure Policy evaluates resources against rules at scale. Three primary moving parts:

Azure Policy moving parts — definition, initiative, assignment
Feature	Policy definition	Initiative (policy set)	Assignment
What it is	A single rule (e.g. 'storage accounts must require HTTPS')	A bundle of related policy definitions (e.g. 'CIS Azure benchmark v2.0.0')	Applying a definition or initiative to a scope
Created by	Microsoft (built-in) or you (custom JSON)	Microsoft (built-in) or you (custom)	You — picks scope, parameters, identity for remediation
Effects available	Deny, Audit, AuditIfNotExists, DeployIfNotExists, Modify, Append, Manual, Disabled	Inherited from each contained definition	Effects can be overridden via parameters at assignment time
Scope	N/A — definitions are written but not yet applied	N/A — initiatives are written but not yet applied	Management group, subscription, resource group, or resource
Identity needed	No	No	Managed identity required for DeployIfNotExists and Modify effects

Effects you must know

Deny — blocks creation/update of resources that violate the policy. Hardest gate; pre-incident.
Audit — logs a compliance state but does not block. Most common starting point.
AuditIfNotExists — evaluates a related resource (e.g. “every VM must have a diagnostic setting”) and audits if missing.
DeployIfNotExists (DINE) — auto-deploys a remediation template when the related resource is missing. Requires a system-assigned or user-assigned managed identity on the assignment, with role assignments to deploy the template.
Modify — mutates resource properties on create/update to comply (e.g. add a required tag).
Disabled — turns the policy off without removing the assignment.

Initial-state-vs-future-state trap

A frequent SC-500 exam pattern: “Esme wants to ensure all NEW storage accounts require secure transfer, AND she wants to remediate the 800 existing storage accounts that don’t have it.” The correct answer almost always combines two effects:

Deny for future violations — assigned at the subscription scope, this stops anyone from creating a non-compliant storage account from now on.
Modify or DeployIfNotExists for the existing 800 — assigned with a system-assigned managed identity, then run a remediation task that applies the change to all currently non-compliant resources.

Audit alone is the wrong answer because it leaves the existing 800 non-compliant indefinitely.

Custom policy definitions

When the built-in catalogue doesn’t cover a rule unique to your org, write a custom policy definition in JSON. Two parts:

policyRule.if — the condition that selects resources (e.g. resource type = Microsoft.Network/networkSecurityGroups AND properties.securityRules[*].destinationPortRange contains '22' AND properties.securityRules[*].access = Allow AND properties.securityRules[*].sourceAddressPrefix = '*').
policyRule.then — the effect (Deny, Audit, etc.) and any deployment template for DINE/Modify.

For SC-500, you should be able to read a custom definition’s JSON and explain what it does — not author it from scratch in the exam.

Regulatory compliance in Defender for Cloud

Defender for Cloud’s Regulatory compliance view maps your environment against compliance frameworks. By default, the Microsoft Cloud Security Benchmark (MCSB) is assigned and evaluated. You can add additional standards (PCI DSS, ISO/IEC 27001, NIST SP 800-53, CIS, SOC 2, HIPAA HITRUST, FedRAMP, country-specific frameworks like SWIFT CSCF or the NZISM equivalents).

Each standard breaks down into controls and recommendations. Defender for Cloud evaluates each recommendation against your environment, assigns a status (Healthy / Unhealthy / Not applicable / Not assessed), and aggregates to a per-standard compliance percentage.

For controls that Microsoft cannot automatically evaluate (process controls — “Document an incident response plan”), you can perform manual attestation to mark the control as satisfied.

For controls that genuinely don’t apply, exemptions with a justification and expiry can be granted by an admin. Exemptions are recorded for the auditor and lapse on expiry, prompting re-review.

Resource locks

Two lock types:

CanNotDelete — resource can be modified but not deleted. The protection that prevents an az group delete from accidentally taking out a production resource group.
ReadOnly — resource cannot be modified or deleted. Stronger; useful for highly stable resources whose configuration must not change. Note: ReadOnly can interfere with operations that look like reads but are actually writes underneath — read carefully before applying.

Locks apply at subscription, resource group, or individual resource scope, and inherit downward. Locks override RBAC — even Owner cannot delete a CanNotDelete-locked resource without first removing the lock (which requires Microsoft.Authorization/locks/* permission).

RBAC at scale

Built-in roles cover the common cases — Owner, Contributor, Reader, plus service-specific roles (Key Vault Secrets User, Storage Blob Data Contributor, Virtual Machine Contributor, etc.). Two SC-500 surfaces:

Custom Azure roles — when no built-in role fits, define a custom role with explicit Actions, NotActions, DataActions, NotDataActions, and AssignableScopes. Created at the tenant root or a management group, assignable at any scope at or under AssignableScopes.
Microsoft Entra roles vs Azure roles — Entra roles govern directory operations (user management, app registration, policy admin). Azure RBAC roles govern Azure resource operations. They are separate systems with separate role definitions — Global Administrator is an Entra role, Owner is an Azure RBAC role. SC-500 expects you to know the distinction and pick the right surface for the task.

Detecting and remediating overprivileged access

Two primary signals:

Microsoft Entra Privileged Identity Management access reviews — scheduled review of role holders. Reviewer (manager, named approver, or self-attestation) confirms whether each assignment is still needed; unreviewed assignments can be auto-removed.
Microsoft Entra Permissions Management (formerly CloudKnox) — surfaces actual permission usage across Azure, AWS, and GCP. Identifies identities with unused or excessive permissions and proposes a right-sized role. Treats permission as data, not posture.

For Azure RBAC specifically, you can review assignments via the portal, az role assignment list, or the Microsoft Graph API, filter for assignments at high scopes (subscription Owner / Contributor), and remove or replace with narrower scopes.

Azure Backup security features

Backups must themselves be defended — ransomware actors increasingly target backup vaults specifically because deleting the backup forecloses recovery. Key Recovery Services / Backup vault settings:

Soft delete — deleted backups retained for 14 days (immutable) before purge. Enabled by default, recommended to keep on.
Immutable vaults — once enabled (and made irreversible), no one can shorten retention or delete backups before retention expires.
Multi-user authorisation (MUA) — protects critical operations on the vault (disable soft delete, change retention, delete) with a second-approver workflow via Microsoft Entra Resource Guard.
Cross-region restore — for region-redundant Recovery Services vaults, you can restore in a secondary region if the primary is compromised.

For the exam, the pattern is: “backups should survive a tenant compromise”. The combination of soft delete + immutable + MUA is the answer.

IaC security controls

Two complementary patterns:

Shift-left in pipelines — Defender for DevOps (when GitHub or Azure DevOps is connected) scans Bicep, ARM, Terraform, and Kubernetes manifests for misconfigurations during PRs. Pipelines can fail builds on high-severity findings.
Runtime-side Azure Policy — DINE/Modify policies catch what slips through the pipeline. A workload deployed via a non-compliant template is corrected after the fact.

Microsoft.Security-namespace resources in Bicep let you express security-plan toggles (Defender for Cloud plan enablement, auto-provisioning, contact details, default workspace) as code — version-controlled, peer-reviewed, repeatable across subscriptions.

Scenario: Asha rolls out a tenant-wide governance baseline

Asha at Aurora Health Service is establishing a security baseline across 47 subscriptions under one management group hierarchy:

Custom initiative at the root management group: combines the MCSB built-in initiative + 8 custom policies (no public-IP NSG rules outside the DMZ, all SQL servers have auditing on, all storage accounts require HTTPS + minimum TLS 1.2, no Owner role at subscription scope for human accounts, etc.). Mix of Deny for new and DeployIfNotExists for existing.
Remediation tasks scheduled for each DINE policy to fix the existing fleet. Each remediation runs as the assignment’s managed identity with the minimum role to perform the fix.
Regulatory compliance: in Defender for Cloud, attach NIST SP 800-53 Rev. 5 and ISO/IEC 27001 standards alongside MCSB. Quarterly compliance review with the security committee uses these views.
PIM + access reviews: every standing Owner / Contributor at subscription scope migrated to PIM-eligible. Quarterly access review on the entire eligibility set.
Backup hardening: every Recovery Services vault has soft delete + immutable enabled, MUA configured with two named approvers from outside the data-protection team.
IaC: connect both Azure DevOps and GitHub to Defender for DevOps. Pipeline build fails on high-severity Bicep / Terraform findings. Bicep modules for new subscriptions include the Microsoft.Security plan-enablement resources so Defender for Cloud is on by default.

Result: the tenant has a written baseline expressed in policy, an auditable compliance scorecard, just-in-time admin access, immutable backups, and IaC catches misconfigurations before deploy. The next acquisition gets the same baseline by being added to the management group.