Implement governance to enforce security and regulatory compliance

A single requirement can arrive in four different shapes: stop anyone from creating a storage account that accepts anonymous traffic, stop the wrong people from touching production at all, stop everyone including the subscription owner from deleting the backup vault, and show an auditor how much of a compliance standard the environment currently passes. Those are four different controls, and reaching for the wrong one is the most common governance mistake in this objective.

Azure RBAC (role-based access control) decides which principals may perform which operations. Azure Policy decides which resource configurations are allowed, and can correct or deploy configuration itself. Resource locks, together with the vault-level protections in Azure Backup, refuse specific changes no matter who asks. Microsoft Defender for Cloud measures what already exists against a control set and reports the result; blocking is not its usual role, and it happens only where Deny or Enforce is turned on for one of the Azure recommendations that support it.

Which slice of the domain this page covers

The other two pages of this domain answer the questions that come first. Securing access with Microsoft Entra ID covers who can sign in and how an application obtains an identity; securing secrets and keys with Azure Key Vault covers where credentials, keys, and certificates live. This page starts after that point, with what an already-authenticated principal may build, change, or delete, and how the resulting estate is measured against a standard.

The scope ladder all four controls attach to

Every control here binds to the same Azure resource hierarchy^[1]: management group, then subscription, then resource group, then the individual resource. A policy assignment or a role assignment placed at one level is inherited by every level beneath it, and the management group tree supports up to six levels of depth, not counting the root management group or the subscription level.

The levels are not interchangeable, and the figure below traces which control can attach at each one. A resource lock^[2] cannot be placed on a management group at all, so a lock always starts at a subscription or lower. A Defender for Cloud security standard is normally enabled on a management group or subscription so that everything nested below aggregates into one compliance view.

Read the ladder as the answer to a single question: how far does this control reach? Almost every governance question in this objective is really asking you to pick the control type first, and then the level of that ladder where it binds.

A policy definition is one rule: a condition that selects resources and an effect that says what happens to them. An initiative (also called a policy set) bundles related definitions so they are assigned, parameterized, and tracked as one unit, and an assignment^[3] binds either object to a scope. Nothing is evaluated until an assignment exists, which is why an unassigned custom definition never affects a deployment.

Microsoft publishes built-in definitions for common controls, so a custom definition is written only when the required rule is specific to your organization. The figure below traces the whole path, from the definition through an optional initiative to an assignment, its evaluation, and the remediation task that repairs what already exists.

The pieces of a definition

The listing below is a complete custom definition body that blocks anonymous blob access. mode set to Indexed restricts evaluation to resource types that support tags and location, parameters declares values the assignment supplies later, and policyRule holds the if condition and the then effect. Nothing has been elided from it.

Custom policy definition: deny storage accounts that allow anonymous blob access

{
  "properties": {
    "displayName": "Storage accounts must disable anonymous blob access",
    "mode": "Indexed",
    "parameters": {
      "effect": {
        "type": "String",
        "allowedValues": ["Audit", "Deny", "Disabled"],
        "defaultValue": "Deny"
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
          { "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "notEquals": false }
        ]
      },
      "then": { "effect": "[parameters('effect')]" }
    }
  }
}

The field value in the second condition is an alias^[4], the name Azure Policy uses to reach a property inside the resource type's own API shape. The [parameters('effect')] expression reads the value the assignment supplies, which is what keeps one definition reusable across scopes that need different strictness.

Two scopes decide reach, not one

The definition location and the assignment scope are separate settings and both matter. A custom definition must be saved at a management group or subscription that is an ancestor of every scope you intend to assign it at, because it can only be assigned inside its own location's hierarchy; a shared management group is the usual home when several subscriptions need the same rule. The assignment scope^[5] then selects the resources actually evaluated, and it reaches downward only. Assigning at one subscription never governs a sibling subscription in the same management group, however high the definition itself is saved.

Excluding a scope versus exempting a resource

Two mechanisms take something out of an assignment's reach, and they are not interchangeable. The assignment's notScopes property permanently removes a child scope from applicability, which suits an environment the rule was never meant to cover. A policy exemption^[6] is a separate object that waives a specific resource or scope while keeping it visible in compliance reporting as Exempted, with an optional expiresOn timestamp after which the waiver lapses on its own.

Choose notScopes when nobody should ever have to look at that scope again, and an exemption when the exception itself has to stay auditable and time-bound.

You have written the rule and chosen the scope, and one field is still unset: the one that decides whether a matching deployment is refused, recorded, or corrected on the spot. The effect is where enforcement lives. An assignment with the audit effect and an assignment with the deny effect can be identical in every other respect, and only one of them stops a deployment.

The effects this objective turns on

Effect	What Azure Policy does	Choose it when
deny	Rejects a create or update request that matches the condition	A prohibited configuration must never exist
audit	Records the resource as noncompliant and lets the request through	You need visibility without breaking deployments
modify	Adds, updates, or removes properties on the resource itself	A property such as a tag or a setting should be corrected in place
deployIfNotExists	Deploys a related resource when the condition matches	A companion configuration such as a diagnostic setting must exist
disabled	Turns off evaluation for that assignment	You are testing a definition and want no result at all

Azure Policy defines further effects, including append, auditIfNotExists, denyAction, and manual; the five above are the ones this objective exercises. The full behavior of each is in the effect reference^[7].

Why deny alone never cleans up an estate

Deny acts at request time, so it can only stop something that has not happened yet. Everything already deployed keeps its configuration and simply reports as noncompliant. Correction is the job of modify and deployIfNotExists, and those two need three things that deny does not.

First, the assignment needs a managed identity, either system-assigned or user-assigned, because Azure Policy performs the change as that identity rather than as the person who created the assignment. Second, that identity must hold the Azure roles named in the definition's roleDefinitionIds, which is the definition's own declaration of the permissions its change requires. Third, existing resources are only touched when you create a remediation task^[8] for the assignment; without one, the effect fires only when a matching resource is next created or updated.

Evaluation timing and safe rollout

Compliance is re-evaluated when a resource in scope is created or updated, when the assignment changes, and otherwise on a standard cycle of about every 24 hours, with an on-demand scan available. A dashboard that has not caught up yet is a stale view, not a passing grade.

Before a deny rule goes wide, assign it at a limited scope and inspect the results. Setting the assignment's enforcementMode to DoNotEnforce evaluates compliance and reports it without applying the effect, so you learn how many resources the rule would have blocked before it blocks anything. That is the difference between a governance rollout and a self-inflicted deployment outage across the tenant root.

Azure RBAC^[9] is additive, and that single sentence explains most of the wrong answers people give about it. Effective permissions are the union of every role assignment that applies at every scope in the chain, so a narrower assignment can never trim a broader inherited one. Contributor at the subscription plus Reader on one resource group is still Contributor on that resource group.

A role assignment binds exactly three things: a principal (a user, a group, a service principal, or a managed identity), a role definition, and a scope. Change any one of them and you change the grant. Assignments are subject to real limits, currently 4,000 role assignments per subscription and 500 per management group^[10], which is one reason group-based assignment beats per-user assignment at scale.

The only construct that subtracts is a deny assignment, and those are created by Azure itself, for example by a deployment stack or a managed application. A deny assignment belongs to Azure RBAC and settles who may act; it is not the Azure Policy deny effect from the previous section, which settles which configuration may exist. Administrators cannot author them, so "add a deny assignment" is never the answer to an overprivileged user.

Start from the built-in roles

Four built-in roles^[11] apply to every resource type: Owner (full management plus the ability to assign roles), Contributor (full management but no role assignment), Reader (view only), and User Access Administrator (manage user access, including assigning Owner, but not the resources themselves). Role Based Access Control Administrator is the newer, narrower alternative to User Access Administrator: it assigns roles but cannot grant access by other means such as Azure Policy. Beyond those four, Azure ships hundreds of service-specific built-in roles, and the correct starting move is always to search for one that already contains the required operations.

The classic subscription administrator roles, Account Administrator, Service Administrator, and Co-Administrator, are retired^[12], so access is managed exclusively through role assignments now.

Finding and fixing overprivileged access

Microsoft Defender for Cloud surfaces identity and access recommendations that flag patterns such as a service principal holding an administrative role at subscription scope, or privileged accounts that never use their permissions. Its risk prioritization^[13] sorts those findings by the resource's context rather than by severity alone, which matters because the two orderings disagree often. Note the boundary: recommendations come with the foundational CSPM plan, but the risk-prioritization columns require the Defender CSPM plan.

Remediation follows from the additive model. Because nothing subtracts, adding Reader on top of an Owner assignment changes nothing at all, and neither does a narrower assignment lower down. The fix is to remove the broad assignment and replace it with the least-privileged role at the smallest scope that still covers the workload's verified operations.

A custom role is the answer only when no built-in role expresses the required permissions, and the first decision is which plane the permissions live on. Microsoft Entra roles^[12] govern the directory: users, groups, applications, and their objects, scoped to the tenant, an administrative unit, or a single object. Azure RBAC roles govern Azure Resource Manager: subscriptions, resource groups, and resources. The two are separate authorization systems, and neither leaks into the other by default. A Global Administrator has no access to Azure resources, and an Azure custom role never becomes assignable as a directory role.

Anatomy of an Azure custom role definition

An Azure custom role^[14] is a JSON document with four permission arrays and one scope array. Actions holds control-plane operations (managing the resource through Resource Manager), DataActions holds data-plane operations (reading or writing the data inside it), NotActions and NotDataActions subtract from those, and AssignableScopes limits where the role may be assigned at all.

Azure custom role definition, as accepted by az role definition create

{
  "Name": "AI Guardrail Operator",
  "IsCustom": true,
  "Description": "Read AI account configuration and manage its diagnostic settings.",
  "Actions": [
    "Microsoft.CognitiveServices/accounts/read",
    "Microsoft.Insights/diagnosticSettings/read",
    "Microsoft.Insights/diagnosticSettings/write"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-0000-0000-0000-000000000000"
  ]
}

NotActions is the field readers most often misread. It subtracts only from the wildcard grants inside this same role definition; it is not a deny rule. If another assignment grants the same operation, the user still has it, because the union across assignments is computed after each role definition resolves its own NotActions. That is the additive model from the previous section, restated at the level of a single definition.

AssignableScopes is the other quiet trap. A role definition whose assignable scope is one subscription cannot be assigned in a second subscription, even when both sit under the same management group. Widening the reach means editing AssignableScopes to a shared management group, not creating a second assignment.

Microsoft Entra custom roles

A Microsoft Entra custom role^[15] is built from the directory's own permission catalog and is assigned at the tenant, an administrative unit, or a single directory object such as an app registration. It cannot contain Azure DataActions, and it cannot be assigned at a subscription or resource group. Assigning a Microsoft Entra custom role requires a Microsoft Entra ID P1 licence for each user who holds one, which built-in directory roles do not require.

The one bridge between the planes

Azure provides exactly one default bridge, and it is a recovery tool rather than a design pattern. A Global Administrator can turn on access management for Azure resources^[16], which assigns that administrator the User Access Administrator role at root scope (/), covering every subscription and management group in the tenant. Use it to repair a subscription whose owners were all removed, then remove the root-scope assignment or turn the setting back off. Left on, it is a standing tenant-wide grant that no resource-level review will show you.

A resource lock^[2] does not check permissions, it overrides them. An Owner who holds every relevant Action is still refused while the lock is in place, which is exactly the point: locks defend against a mistake made by someone who is fully entitled to make it.

There are two levels. CanNotDelete allows reading and modifying the resource but refuses deletion. ReadOnly refuses updates as well, leaving behaviour equivalent to the Reader role. Locks placed on a subscription or resource group are inherited by everything within, and where several locks apply, the most restrictive one in the chain wins. Owner and User Access Administrator hold the Microsoft.Authorization/locks/* permissions needed to create or remove them: lock management lives in the Microsoft.Authorization namespace, which is why the role that manages access rather than resources appears in that list. Locks cannot be applied to management groups.

The figure below places the lock in the order a control-plane request is checked, after the permission check and the policy evaluation, immediately before Resource Manager applies the change.

What "control plane" excludes, precisely

A lock covers operations that go to Azure Resource Manager, and nothing else. Deleting a blob, purging a Key Vault secret, or dropping a table are data-plane operations that reach the service's own endpoint directly, so a ReadOnly lock on a storage account does not stop a single blob from being deleted. Protecting stored data is the job of that service's own features, such as blob soft delete and versioning, immutability policies, or Key Vault purge protection.

The reverse surprise is also worth knowing. Because a lock blocks the POST method to Resource Manager, ReadOnly blocks operations that read nothing at all in the intuitive sense: listing storage account keys is a POST, and so is restarting a virtual machine. A lock also stops a complete-mode ARM or Bicep deployment^[17], because complete mode deletes resources the template omits.

Treat a lock as protection against deletion and reconfiguration through Resource Manager, and pair it with a data-plane protection whenever the thing you actually care about is the data.

Backup is the control an attacker attacks last and a governance review notices last. Azure Backup answers that with layers that stay effective after an administrator account is fully compromised, and each layer covers a different move the attacker would make.

Separate the duties first

Assign the Azure Backup built-in roles^[18] at vault scope: Backup Contributor to manage backups without deleting the vault, Backup Operator to run backups and restores without altering the backup policy, and Backup Reader to monitor. Subscription Owner is never a requirement for routine backup work, and granting it converts one stolen credential into a whole-subscription problem.

Require a second authorization for critical operations

Multi-user authorization^[19] (MUA) makes the vault check a second Azure resource, the Resource Guard, before it performs a critical operation. Disabling soft delete and removing MUA protection are mandatory protected operations; optional ones include deleting protection, reducing retention in a backup policy, changing encryption settings, and disabling immutability. The figure below traces one such request.

The protection only works when the guard is genuinely out of the vault administrator's reach. The Resource Guard must be owned by a different user, ideally in a different subscription or tenant, and the vault administrator must not hold Contributor, Backup MUA Admin, or Backup MUA Operator permissions on it. A backup administrator with full vault permissions but no Backup MUA Operator role on the guard simply cannot perform the protected operations. The Yes branch in the figure is therefore the path of a caller who does hold sufficient permission on the guard, which by design is not the vault administrator.

Keep deletion reversible and retention irreversible

Soft delete retains deleted backup data so it can be recovered, and it is now enforced by default^[20] as part of secure-by-default assurance, generally available for Recovery Services vaults across Azure public regions and national clouds, and in preview for Backup vaults. Where the enforcement applies, the soft-delete state can no longer be changed in the portal. The retention period is 14 days by default and can be extended to 180 days.

Immutable vault^[21] attacks the other direction: it blocks operations that would shorten retention or delete protected data before its time, and the setting itself can be locked to make that irreversible. Enabled-and-locked immutability is generally available in all Azure regions for Recovery Services vaults. Soft delete, immutability, and MUA are complementary rather than alternatives, which is why Microsoft's own guidance pairs them.

Encryption, network path, and monitoring

Backup data is encrypted at rest with platform-managed keys by default, with no action required. Use customer-managed keys^[22] stored in Azure Key Vault only when the organization must control the key itself. Private endpoints^[23] for a Recovery Services vault keep backup and restore traffic off public IP addresses, but the supported scenarios are specific, covering SQL Server and SAP HANA in Azure VMs and on-premises servers using the MARS agent among the documented cases, so do not assume every workload takes that path. Finally, built-in monitoring and alerts^[24] plus Backup Reports are what turn all of the above into something you notice: they surface unusual restore activity and administrative changes while there is still time to react.

Defender for Cloud's main job on this page is measurement: it assesses, scores, and recommends, and every one of its compliance numbers is produced by Azure Policy underneath. It can also block, but only where Deny or Enforce is turned on for one of the supported Azure recommendations, so blocking here is an opt-in on named recommendations rather than something a standard does by itself. Understanding that Azure Policy dependency answers most exam questions about it.

Standards are policy initiatives with a dashboard

Industry frameworks, regulatory frameworks, and benchmarks appear in Defender for Cloud as security standards^[25], each made of compliance controls that group related recommendations. The Microsoft Cloud Security Benchmark^[26] is applied automatically when an account is onboarded and acts as the default baseline; other standards are added when the organization needs mappings to a specific framework.

Assign a standard at the highest applicable management group or subscription so compliance data is aggregated and tracked for nested resources, which requires Owner or Policy Contributor permission at that scope.

Two reporting behaviours surprise people. A control that cannot be assessed automatically appears greyed out rather than failed, because Defender for Cloud will not guess. And a standard assigned to a subscription with no relevant resources does not appear in the dashboard at all.

Recommendations, and what ranks them

Security recommendations^[27] are the actionable half: each names the affected resources and the fix. Their ordering is the part worth learning, because Defender for Cloud ranks by risk derived from the resource's context, including internet exposure, sensitive data, possible lateral movement, and attack paths, rather than by a static severity label. As noted in the role section, that risk view requires the Defender CSPM plan; recommendations themselves come with the foundational plan.

When a recommendation genuinely does not apply, exempt the resource^[28] rather than ignoring the finding, so the exception is recorded and stays visible.

What the compliance percentage is not

The regulatory compliance dashboard^[29] reports how your resources score against the assessments in an assigned initiative. It is an internal measurement, useful for finding gaps and producing evidence, and it is not a certification issued by Microsoft. Formal attestation still comes from an external audit, and a stem that offers "the compliance score proves the organization is certified" is offering a distractor.

Everything on this page can be clicked once in a portal and lost on the next environment. The durable version expresses each control in the deployment itself, keeps the governance artifacts in source control, and checks both before anything reaches production.

Put the security properties in the template

Managed identities, private access, diagnostic settings, purge protection, and role or policy assignments are all deployable resource properties, so an ARM template, a Bicep file, or a Terraform configuration can carry them. Doing so makes posture a property of the code rather than of whoever deployed it, and it makes a difference visible in a pull request review.

Secrets are the exception that needs its own handling. Never place a password, key, or connection string in a template or a parameter file. ARM and Bicep support Key Vault references in parameter files^[30], which pass a secure value by reference at deployment time, and a deployment identity with its own role assignment removes the need for many credentials entirely.

Treat policy artifacts as code

Policy as Code^[31] means storing custom definitions, initiatives, assignments, parameter values, and exemptions in a repository and deploying them through a controlled pipeline. The gain is not the automation, it is the history: every change to a governance rule arrives as a reviewable diff, and the same artifact promotes from a test scope to production instead of being recreated by hand. This is also what makes the limited-scope validation from the effects section repeatable rather than a one-off.

Scan the templates before deployment

Microsoft Security DevOps^[32] (MSDO) runs as a GitHub action or an Azure DevOps extension and analyzes source code, artifacts, containers, and infrastructure as code. Restricting it to the IaC category keeps the pipeline fast when template misconfigurations are what you are hunting.

GitHub Actions workflow running Microsoft Security DevOps on IaC only

name: MSDO
on:
  push:
    branches: [ main ]
jobs:
  sample:
    runs-on: windows-latest
    permissions:
      contents: read
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v3
      # Run only the infrastructure-as-code analyzers; drop `categories` to run them all.
      - name: Run Microsoft Security DevOps
        uses: microsoft/security-devops-action@latest
        id: msdo
        with:
          categories: 'IaC'
      # ... optional step to upload results to the code-scanning tab omitted

The categories input takes a comma-separated list whose accepted values are code, artifacts, IaC, and containers, and it defaults to all of them; the IaC scanning guide^[33] shows the Azure DevOps pipeline equivalent. Findings land in the repository, where the fix is a template change, rather than in a postdeployment assessment where the fix is a change to a resource that is already running.

SC-500 governance questions are usually built by describing a symptom and offering one answer from each of the four control families. Recognising which family the symptom belongs to eliminates two or three options before you evaluate any detail.

Stems and the discriminator that settles them

"Resources keep being created without . What should you do?" The requirement is about configuration, so it is Azure Policy, and the discriminator is the verb. Must never be created means the deny effect. Must be reported means audit. Must be corrected on existing resources means modify or deployIfNotExists plus a remediation task. Role assignments are the decoy here: no role expresses "resources must have this property".

"The policy is assigned to Sub1 but Sub2 is still noncompliant." Assignment scope reaches downward only. Re-assign at the management group that is the common ancestor. A definition saved at a management group does not help by itself; saving and assigning are different scopes, and only the assignment governs.

"A managed identity was created but existing resources are unchanged." The assignment fires on create or update. The missing step is the remediation task, and the second thing to check is whether that identity holds the roles from the definition's roleDefinitionIds.

"An admin must not delete the resource, but must still manage it." CanNotDelete. If the stem instead says no changes at all, ReadOnly. If the stem is about deleting blobs, secrets, or rows, no lock qualifies, because that is the data plane.

"A user has Owner at the subscription. Add Reader on the resource group so they only read." Impossible: Azure RBAC is additive. So is the NotActions variant, where an operation added to NotActions is expected to override a grant from another assignment. Both fail for the same reason, and the correct answer removes or re-scopes the broad assignment.

"Create a Microsoft Entra custom role that grants blob data access." Wrong plane. Directory roles cannot carry Azure DataActions; that requires an Azure custom role, whose AssignableScopes must also include the target subscription.

"The Global Administrator cannot see the subscription." Expected behaviour, not a defect. The recovery path is elevating access to gain User Access Administrator at root scope, used temporarily and turned off afterwards.

"Prevent the backup admin from disabling soft delete." Multi-user authorization with a Resource Guard the admin has no permissions on. A resource lock on the vault is the classic distractor: it is not scoped to security-setting changes and it is removable by an Owner.

"Show the auditor our ISO 27001 posture." Enable the standard in Defender for Cloud at the management group. Watch for the option that treats the resulting percentage as a certification, and for the one that enables the standard on each resource group and expects aggregation.

"Stop insecure templates from reaching production." Microsoft Security DevOps with the IaC category in the pipeline. Runtime threat protection is the distractor, because it inspects deployed resources rather than the template that produced them.

One habit covers all of them: read the stem for the noun it is protecting, a configuration, a permission, an existing resource, or a report, and let that noun choose the control family before you compare the specific options.