SC-500 Azure Governance: Policy, Defender for Cloud Compliance, Locks, RBAC and Backup Security

Choose the effect from what the requirement wants to happen to a non-compliant request: deny rejects it, modify fixes it on the way in, audit lets it through and reports it, and deployIfNotExists adds a missing related resource after the fact. The effect lives in the definition's then block, and is often a parameter so the same definition can be assigned in audit mode first and enforced later.

Two near-twins decide many scenarios. Deny versus modify: both guarantee the end state, but deny does it by failing the deployment, while modify rewrites the request so it succeeds with the secure value. If existing templates must keep working unchanged, modify is the fit; if engineers must see an error at deploy time, deny is. Because modify runs before deny, a request can be corrected before deny ever evaluates it. Deny versus denyAction: deny only evaluates create and update requests and never sees a DELETE. To stop deletions at scale, use denyAction with actionNames set to delete; its cascadeBehaviors setting for resourceGroup (default deny, and available only in Indexed mode) also blocks deleting a resource group that holds a matching resource. Assigned at a management group, it cannot be edited or removed by subscription Owners, although anyone with exemption rights at a lower scope can still exempt resources, so those rights need governing too.

Policy is a guardrail, not a replacement for a resource lock or a role: a ReadOnly lock blocks every write to a scope, while a deny policy blocks only the requests its rule matches.

Resources that existed before an assignment are only reported, never changed, until you run a remediation task. Azure Policy applies modify during new create or update requests and deployIfNotExists after they succeed, so new resources are fixed automatically while existing ones simply show as non-compliant. A compliance scan refreshes that report but deploys nothing, and switching enforcement mode does not reach existing resources either.

• Only two effects support remediation: modify (it carries operations on tags or properties) and deployIfNotExists (it carries a template). Append, audit, auditIfNotExists, deny and denyAction have nothing to execute against existing resources.
• The task runs as the assignment's managed identity (system-assigned or user-assigned), not as the person who starts it or the pipeline that created the assignment. That identity needs the roles listed in the definition's roleDefinitionIds, at a scope that covers the resources.
• The portal grants those roles automatically; an assignment created with Bicep, ARM templates, the Azure CLI or PowerShell does not, so you add that role assignment as a separate step. Missing it shows up as authorization failures in every remediation deployment, however much access the operator has. A policy-management role such as Resource Policy Contributor does not help: the identity must be allowed to deploy or change the remediated resources themselves.

A custom definition is a JSON policyRule with an if block that selects resources and a then block that names the effect, plus a mode and optional parameters. You write one when no built-in definition expresses your rule; built-ins should be your first stop.

• Aliases expose properties. A rule can evaluate a resource property only through an alias used in a field condition, for example Microsoft.Storage/storageAccounts/minimumTlsVersion. Policy sees the resource request and its stored properties; it never sees template parameters, and a tag is just a label that proves nothing about real configuration. Find aliases with Get-AzPolicyAlias, the CLI or the Azure Policy extension for Visual Studio Code.
• Mode All versus Indexed. Indexed evaluates only resource types that support tags and location, and it skips resource groups and subscriptions. Use All for most definitions, and always when the rule targets resource groups. The evaluated type string for a resource group is Microsoft.Resources/subscriptions/resourceGroups (not Microsoft.Resources/resourceGroups). A tag-enforcing rule written in Indexed mode is the classic reason untagged resource groups deploy and never show in compliance results.
• The details block of the IfNotExists effects. For auditIfNotExists and deployIfNotExists, if picks the primary resource (for example a firewall), details.type names the related resource to look for (for example Microsoft.Insights/diagnosticSettings), and existenceCondition says which related resource counts. Without an existenceCondition, any related resource of that type makes the primary compliant, so a diagnostic setting pointing at the wrong workspace passes. The existenceCondition is evaluated against the related resource, which is why a check on its workspaceId belongs there and not in the if block.
• Initiatives (policy set definitions) group definitions under one assignment; each member has a policyDefinitionReferenceId that exemptions can target.

An exclusion (notScopes on the assignment) removes a scope from evaluation entirely and permanently, while an exemption keeps the resource evaluated but records it as Exempt with a reason. Pick by whether the resource should still be assessed and counted.

Exemptions have two categories. Waiver means the non-compliance is accepted, usually temporarily (for example, a legacy workload scheduled for migration next quarter that cannot yet meet a tagging or SKU rule). Mitigated means the policy's intent is met another way (for example, a compensating control outside the policy's view delivers the outcome the definition checks for). Combine a category, a definition-level scope and, where the exception is temporary, an expiry date, so the exception ends without anyone remembering to remove it. Setting an effect to disabled through a parameter is a different tool: it switches the rule off for every resource the assignment covers.

Defender for Cloud's Regulatory compliance dashboard shows how a scope measures up against standards such as PCI DSS, ISO/IEC 27001, NIST SP 800-53 or CIS, and each of those standards is an Azure Policy initiative under the hood. The Microsoft cloud security benchmark (MCSB) is assigned automatically when Defender for Cloud is enabled on an Azure subscription, and its recommendations drive the secure score; every other standard is optional.

To add a standard you switch it on for the scope from the security policies page (Environment settings). Two prerequisites apply:

• A qualifying paid plan: any Defender plan except Defender for Servers Plan 1 and Defender for APIs Plan 1 must be enabled on the scope, for example Defender CSPM.
• Permission to assign policy: Owner or Policy Contributor on the scope, because you are assigning an initiative. Security Reader can view the dashboard but not add standards.

Reading the dashboard: controls that can be assessed automatically show resources as passing or failing. Controls about procedures, documentation or staff (for example a written policy) have no automated assessment, so they appear greyed out with no resources counted; they are evidenced outside Defender for Cloud. Separately, a standard can be hidden or show nothing when the scope has no resources relevant to it. Standards for Azure, AWS and GCP resources are managed in Defender for Cloud itself, on the security policies page.

Custom standards and recommendations

A security standard in Defender for Cloud is a set of recommendations you assign to a scope; a recommendation is one check with a severity and remediation steps. Beyond the built-in standards you can create custom ones, and there are two ways to build custom recommendations:

So a check that must cover AWS accounts as well as Azure subscriptions points to a KQL custom recommendation in a custom standard. A query you only run or save yourself produces findings, not a recommendation: it has no severity, no remediation guidance and no secure-score effect until it is part of a custom recommendation. Exempting a recommendation in Defender for Cloud changes what is assessed, not what can be deployed; enforcement remains Azure Policy's job.

A resource lock stops control-plane deletion (CanNotDelete) or every control-plane change (ReadOnly) on a subscription, resource group or resource, and it applies to everyone, including Owners, until the lock itself is removed. That removal is the deliberate extra step that protects against accidents.

• Locks beat roles. Granting Owner or another role never gets past a lock, so when a lock breaks a legitimate task you change the lock type, not the role.
• Inheritance. A lock on a parent scope applies to all resources in it, including ones added later; the most restrictive inherited lock wins. A resource group that contains a locked resource cannot be deleted.
• Control plane only. Locks act on Azure Resource Manager operations. Data-plane actions, such as reading or deleting blobs with Entra ID or an account key, are untouched, so a lock protects the resource, not its data. ReadOnly can still break things that look like reads because they are POSTs (listing keys).
• Role assignments are protected too: CanNotDelete on a scope blocks deleting role assignments at that scope.
• Who can create locks: you need Microsoft.Authorization/locks/*. Owner and User Access Administrator have it; Contributor does not (it excludes Microsoft.Authorization writes); Role Based Access Control Administrator does not either. A custom role granting only Microsoft.Authorization/locks/* lets a pipeline manage locks without being able to grant roles.
• Locks in IaC: a Bicep or ARM template can declare a Microsoft.Authorization/locks resource, using the scope property to attach it to another resource, so locks are deployed with what they protect.

An Azure role assignment is a security principal, a role definition and a scope, and least privilege means the narrowest role at the narrowest scope that still does the job. Scopes form a hierarchy (management group → subscription → resource group → resource) and assignments inherit downward, never sideways to sibling subscriptions.

Read-only access to everything in one subscription is Reader at that subscription, not at the management group above it (too wide) and not Security Reader (it shows security data, not all configuration). To delegate role assignment without letting the delegate grant Owner to anyone, including themselves, assign Role Based Access Control Administrator and add a condition that limits which roles they can assign (for example only Virtual Machine User Login or Storage Blob Data Reader) and, optionally, to which principal types. A condition can be added to any role that includes Microsoft.Authorization/roleAssignments/write, but Owner and User Access Administrator grant far more (resource management, or every Microsoft.Authorization action), so Role Based Access Control Administrator plus a condition is the least-privilege choice.

Finding and right-sizing overprivileged access

Overprivileged access is any assignment broader than what the identity actually uses, and you fix it with evidence: find unused or excessive permissions, then replace the assignment with a narrower role at a narrower scope. The tool for continuous, usage-based analysis is the permissions management (CIEM) capability of Defender CSPM. It evaluates the effective permissions and activity of users, service principals and managed identities across Azure, AWS and GCP, and raises recommendations to remove inactive identities and right-size overprovisioned ones. The retirement of the separate Microsoft Entra Permissions Management product does not affect these Defender for Cloud capabilities.

Choose by the question being asked. CIEM answers "what does this identity actually use?" from activity data. Tools built for other jobs, such as periodic attestation or configuration rules, can confirm that access was approved or is shaped correctly, but not whether it is used.

The general right-sizing method works for people, apps and automation alike:

1. Scope: narrow the assignment to the smallest scope the activity evidence shows is used (a resource group or a single resource instead of a subscription).
2. Resource actions: pick the narrowest built-in role that covers what the identity does there, for example a service-specific contributor role rather than a general one, or a custom role when no built-in fits.
3. Access-management actions: if it must also grant access, split that out into a separate, conditioned role-assignment permission instead of keeping a role that bundles it with everything else.
4. Remove and verify: delete the broad assignment and confirm the workload still runs.

Privileged Identity Management for just-in-time activation is covered in the Entra ID access lesson; it complements right-sizing but does not replace it.

Azure custom roles and Microsoft Entra custom roles are different things: Azure custom roles control Azure resources through Azure RBAC and need no extra licence, while Entra custom roles control directory objects and need Microsoft Entra ID P1 or P2.

Azure custom roles

• A definition has Actions and NotActions (control plane), DataActions and NotDataActions (data plane), and AssignableScopes.
• NotActions is not a deny. It only subtracts from that role's own Actions. Azure RBAC adds up all of a principal's assignments, so another role (such as Virtual Machine Contributor) can still grant what a NotActions entry leaves out. Only a deny assignment or a lock blocks it. There is no precedence between custom and built-in roles.
• AssignableScopes controls where the role can be assigned: list each subscription or resource group, or at most one management group. The root scope (/) is not allowed for custom roles. A role with DataActions cannot be assigned at management group scope, so one definition listing the management group is assigned at each subscription beneath it.
• Creating or updating a custom role needs Microsoft.Authorization/roleDefinitions/write on every assignable scope, which Owner and User Access Administrator have. Role Based Access Control Administrator can assign roles but cannot write role definitions. Role names are unique in the tenant, so you extend one definition's AssignableScopes rather than duplicating it.

Microsoft Entra custom roles

• Built from the permissions Entra makes available for custom roles, such as microsoft.directory/applications/credentials/update for rotating app secrets.
• Assign at directory scope (every object) or at a single app registration (or enterprise app) scope for least privilege. Administrative units hold users, groups and devices, not app registrations. A built-in role like Application Administrator, even scoped to one app, grants far more than one permission.

Azure Backup's security features protect backups from an attacker or insider who has gained admin rights: soft delete keeps deleted backup data recoverable, an immutable vault prevents early deletion of recovery points, and multi-user authorization (MUA) requires a second team's approval for critical operations. They apply to Recovery Services vaults and Backup vaults.

Match the requirement precisely. A recovery window after deletion is soft delete retention, not backup policy retention (which governs active recovery points). "Can never be deleted early, even by an Owner, and cannot be turned off later" is only an immutable vault that is enabled and locked; unlocked immutability can be disabled, MUA lets an approved operator proceed, and a resource lock can be removed by an Owner (and protects the vault resource, not its backup items).

Resource Guard roles

• With MUA, Azure Resource Manager checks the caller's permissions on the Resource Guard before critical operations such as disabling soft delete, reducing retention, or stopping protection with delete.
• Backup admins must hold no Contributor, Backup MUA Admin or Backup MUA Operator role on the guard by default, because those permissions satisfy the check.
• For an approved request the security team grants Backup MUA Operator temporarily (ideally just in time through PIM): it allows only the protected operations. Backup MUA Admin and Contributor also allow deleting the guard. Roles that manage the vault itself do not satisfy the guard check; only permissions on the Resource Guard do.

Infrastructure as code gives you two security control points: scan templates before deployment, and protect deployed resources with controls that travel with the template. Azure Policy remains the deployment-time backstop for anything that slips through.

Scanning with Microsoft Security DevOps

Microsoft Security DevOps (MSDO) is a GitHub action and an Azure DevOps extension that runs open-source analyzers in the pipeline and, for repositories onboarded to Defender for Cloud, surfaces the findings on the DevOps security page. It needs no GitHub Advanced Security licence. Set the IaC category to run the template scanners:

The point of these scanners is that they read the template files themselves, before anything is deployed; tools that only preview a deployment or watch running workloads act at a different stage and do not evaluate template security rules.

Deployment stacks and deny settings

A deployment stack manages a set of resources from one template and can apply deny settings that create a deny assignment on the managed resources, which even Owners cannot override:

• none, denyDelete (updates allowed, deletion blocked) or denyWriteAndDelete (both blocked).
• Excluded principals (such as the pipeline identity) and excluded actions bypass the deny settings, so the pipeline can keep updating or pruning resources that the people working in the resource group cannot touch.
• Store the stack at a parent scope (for example the subscription for resources in a resource group) so the people who hold Owner on the resource group cannot edit or delete the stack and its deny settings.
• A stack protects only the resources it manages; it is not a way to guard resources deployed by others.