Before meeting any tool, understand the pain it removes. Once the pain is clear, every feature of Azure Policy looks sensible instead of random.

Freedom is the cloud’s gift and its danger

The cloud lets anyone with permission create resources in minutes. That speed is wonderful for innovation, but it means mistakes also spread in minutes. Consider what can go wrong in a company without automatic rules.

Why training and documents are not enough

Companies often write governance documents: a PDF that says “all storage must be encrypted and private.” But a PDF cannot stop anything. People forget, new staff never read it, and the document goes out of date. Even careful engineers make errors on a bad day. The only dependable guardrail is one that works automatically, at the moment a resource is created or changed, and keeps checking afterward.

What a good guardrail does

• Prevents clearly forbidden settings, so mistakes cannot happen.
• Detects existing resources that break the rules, so you know where you stand.
• Fixes problems automatically where it is safe to do so.
• Proves to auditors and managers, with data, that the rules are followed.
• Stays out of the way of legitimate work, with clear messages and a process for exceptions.

An illustrative example

Take a hypothetical software company with 300 engineers and 60 Azure subscriptions. A security review finds that 14 storage accounts allow public access and 40 percent of virtual machines have no owner tag. The security team assigns a policy that denies new public storage accounts and another that requires an owner tag. From that day, nobody can create such storage, and untagged resources are listed in a compliance report, giving each team a clear to-do list. Within a few weeks, the percentage of tagged resources rises sharply, and the security team spends its time on real threats instead of chasing settings.

Azure Policy has a compact vocabulary. Learn these words once and every later chapter reads easily.

The words, one at a time

The building blocks in one picture

The relationship between the pieces is simple. You write or choose a definition, which holds a condition and an effect. You may group many definitions into an initiative. You then create an assignment that applies the definition or initiative to a scope, filling in any parameters. From then on, Azure evaluates resources within that scope against the rule and records a compliance state for each. For existing problems, you can run a remediation.

Definitions come in two flavours

Built-in definitions are written and maintained by Microsoft. There are many hundreds, covering common needs such as allowed locations, required tags, encryption, private networking, and backup. Custom definitions are rules you write yourself when no built-in one matches your standard. A wise team starts with built-in definitions, because they are tested, updated as Azure evolves, and understood by auditors, and writes custom ones only for real gaps.

Policy is about resources, not people

One idea causes endless confusion for beginners, so state it early. Azure Policy asks: “Does this resource have an allowed configuration?” It does not ask “Is this person allowed to do this?” The second question belongs to a different feature, Azure role-based access control (RBAC). A person with full rights may still be blocked by a policy if the resource they try to create breaks a rule, and a person without rights cannot create anything regardless of policy. Chapter 3 explains how the two work together.

Azure has several governance and security features that sound alike. Putting Azure Policy next to them makes its role clear.

A short history

In the early days of Azure’s resource-manager model, teams controlled risk mostly with access rights and manual reviews. As companies moved hundreds of workloads to the cloud, they needed rules about the shape of resources, not just about who could create them. Microsoft introduced Azure Policy to fill that gap, and over time it grew to include effects that can modify and deploy settings, rules for data-plane operations in services like Kubernetes and Key Vault, built-in bundles that map to industry standards, and integration with tools such as Microsoft Defender for Cloud, which uses policy initiatives to show security recommendations. Today it sits at the centre of Microsoft’s guidance for cloud governance, including the Azure landing zone reference designs.

What Azure Policy does

Policy versus RBAC

Policy versus other features

Cost and where it runs

Azure Policy itself has no separate charge for evaluating and enforcing policies on Azure resources. Some related capabilities have their own pricing, for example machine configuration for servers outside Azure, Defender for Cloud plans that use policy-based assessments, and the resources that remediation tasks deploy, such as log workspaces. Always check the current pricing pages, since packaging changes over time.

To use Azure Policy well, you must understand the hierarchy it works within and the components that cooperate to enforce a rule.

flowchart TD
  TEN["Microsoft Entra tenant"] --> RMG["Tenant root management group"]
  RMG --> MG1["Management group Platform"]
  RMG --> MG2["Management group Landing Zones"]
  MG2 --> SUB1["Subscription Online Apps"]
  MG2 --> SUB2["Subscription Corporate Apps"]
  SUB1 --> RG1["Resource group web"]
  SUB1 --> RG2["Resource group data"]
  RG1 --> RES1["Web app"]
  RG2 --> RES2["Storage account"]
  DEF["Policy definitions and initiatives"] --> ASG["Policy assignment"]
  ASG -->|"applies to scope and inherits downward"| MG2
  ASG --> ENG["Policy engine in Azure Resource Manager"]
  ENG --> CMP["Compliance results and Activity Log"]

The Azure hierarchy

Azure organises everything in a tree. At the top is the tenant, which is your organisation’s identity directory in Microsoft Entra ID. Under it sits the tenant root management group. Management groups are folders that hold subscriptions and other management groups, up to six levels deep (not counting the root and the subscription level). A subscription is a billing and security boundary that holds resources. Within a subscription, resource groups hold related resources. Finally come the resources themselves.

Inheritance: rules flow downward

A policy assigned at a scope applies to everything beneath it, including resources created later. Assign “allowed locations” at a management group and every subscription, resource group, and resource below obeys it. This is the secret to governing at scale: one assignment can protect thousands of resources. You can carve out exceptions with exclusions (a child scope left out of the assignment) and exemptions (a formal, auditable waiver).

The components

Reading the diagram

The upper part of the figure shows the tree, from the tenant down to individual resources. The lower part shows the policy side: definitions and initiatives are stored once and then attached through an assignment to a scope, in this case the Landing Zones management group. The assignment feeds the policy engine inside Azure Resource Manager, which checks resources beneath that scope and records the outcome as compliance results, while important actions also appear in the Activity Log.

Where definitions should live

A definition is available to assign only at its own location and below. A definition stored at a subscription can be used only in that subscription. A definition stored at a management group can be used by any scope beneath that group. So organisations store shared custom definitions high up, usually at a dedicated top-level management group for their company, and assign them lower down as needed.

Follow a single request from an engineer’s click to a decision, and you will understand most of what Azure Policy does.

sequenceDiagram
  participant U as Engineer or pipeline
  participant ARM as Azure Resource Manager
  participant PE as Policy engine
  participant RP as Resource provider
  participant PI as Policy Insights
  U->>ARM: Create or update resource request
  ARM->>ARM: Check authentication and RBAC
  ARM->>PE: Evaluate request against assignments in scope
  PE->>PE: Apply Disabled then Modify and Append then Deny then Audit
  alt Request violates a Deny rule
    PE-->>ARM: Deny with policy message
    ARM-->>U: Request rejected with error
  else Request allowed
    PE-->>ARM: Allow with any modifications
    ARM->>RP: Create or update resource
    RP-->>ARM: Success
    ARM->>PE: Evaluate AuditIfNotExists and DeployIfNotExists
    PE->>PI: Record compliance state
    ARM-->>U: Success
  end

The steps in words

When does evaluation happen?

An important consequence: Deny does not touch existing resources

A Deny rule stops new or changed resources. It does not delete or alter anything that already exists. Existing resources that break the rule simply appear as non-compliant. If someone later edits such a resource, the update may be blocked, even if the edit has nothing to do with the broken setting. That surprises teams who find they cannot change a tag on an old resource because the resource also violates an unrelated deny rule. Plan for this when rolling out strict rules.

Timing and eventual consistency

Compliance data is not instant. After a change, there is often a delay before the dashboard reflects it. Treat the dashboard as an accurate-in-minutes view, not a live meter. When you need certainty right now, trigger an on-demand scan or inspect the resource directly.

A policy definition is a small structured document. Knowing its parts lets you read any policy, built-in or custom, and write your own when needed.

The parts

The mode

The mode decides what the policy looks at. Two common ones are All, which evaluates resource groups, subscriptions, and every resource type, and Indexed, which evaluates only resource types that support tags and location. Use Indexed for policies about tags and locations, so that resource types that cannot be tagged do not show up as false non-compliance. Other modes are resource provider modes, such as those for Kubernetes admission control, Key Vault data operations, and some network data operations. These reach inside a service rather than only at its outer settings.

The rule: if this, then that

The policy rule has two halves. The if half describes which resources match the condition. The then half says which effect to apply to those that match. Importantly, the “if” describes the problem condition. For a rule that says “storage accounts must not allow public access,” the “if” matches storage accounts that do allow public access, and the “then” denies them.

Conditions and logic

Inside the “if,” you compare properties of the resource with expected values. Properties are named by fields, such as the resource type, the location, a tag name, or an alias for a specific property like a network setting. A rich set of comparison operators exists: equals, not equals, contains, like with wildcards, in a list, greater and less than, exists, and several others. Conditions can be combined with logical operators: allOf (every condition must be true, like AND), anyOf (at least one must be true, like OR), and not (reverses a condition). They can be nested to express complex rules.

Aliases: looking inside resources

Resources have many properties that are specific to their type, such as whether a storage account allows public network access. An alias is a stable name that Azure Policy provides for such a property, so a rule can refer to it without worrying about the underlying structure. Aliases can be discovered with command line tools and the portal. If a property you care about has no alias, it cannot be checked by policy until the resource provider adds one, which is a real limit worth knowing.

Parameters make rules reusable

Instead of hard-coding “allowed regions are East US and West Europe,” a good definition declares a parameter named something like “listOfAllowedLocations” and reads it in the rule. One definition can then be assigned with different values in different places: a European business unit assigns European regions, and a US unit assigns US regions. Parameters can offer a list of permitted values, default values, and a drop-down in the portal. Making the effect itself a parameter is a common practice, since it lets one definition be assigned as Audit during testing and Deny in production.

A readable example in words

Here is an example described without code. A custom policy is meant to ensure that every resource group has an “owner” tag. Its mode is All. Its “if” says: the resource type is a resource group, and the tag called owner does not exist. Its “then” uses the effect from a parameter, with a default of Audit. When assigned at a subscription, resource groups with no owner tag are shown as non-compliant. When the team is ready, they change the parameter to Deny, and from that point no new resource group can be created without the tag.

The effect is the action half of a rule. Choosing the right effect is the single most important design decision when you write or assign a policy.

flowchart TD
  A["Resource request or existing resource"] --> B{"Does the if condition match"}
  B -->|"No"| C["Compliant, nothing happens"]
  B -->|"Yes"| D{"Which effect is set"}
  D -->|"Disabled"| E["Rule is skipped"]
  D -->|"Append or Modify"| F["Request is changed to add or fix properties"]
  D -->|"Deny"| G["Request is rejected with a message"]
  D -->|"Audit"| H["Resource is flagged as non compliant"]
  D -->|"AuditIfNotExists"| I["Check for a related resource, flag if missing"]
  D -->|"DeployIfNotExists"| J["Check for a related resource, deploy it if missing"]
  D -->|"DenyAction"| K["Block a specific action such as delete"]
  D -->|"Manual"| L["Compliance set by human attestation"]

The effects, one by one

Order of evaluation

When several policies apply to the same request, Azure evaluates effects in a defined order: Disabled first (simply skipped), then Append and Modify, then Deny, then Audit. Related-resource effects such as AuditIfNotExists and DeployIfNotExists are evaluated after the resource provider has handled the request. This ordering gives useful behaviour. A Modify policy can add a missing required tag before a Deny policy checks for it, so the request passes instead of being rejected.

Audit versus Deny: the rollout path

The most common safe path is to begin with Audit, learn which resources would be affected, fix them, tell teams, and only then switch to Deny. Rolling out Deny first often blocks urgent work, triggers a flood of complaints, and teaches the company to see governance as an obstacle. Rolling out Audit first shows you the size of the problem and gives teams time to adjust. Design definitions with the effect as a parameter, so that moving from Audit to Deny is a small, easily reviewed change.

Modify and DeployIfNotExists: the repair effects

These two effects can change things, so they need power. When an assignment uses them, Azure creates or uses a managed identity for the assignment, and you must give that identity the roles listed in the definition, for instance Contributor on the scope or a narrower role such as Tag Contributor. Without those roles, remediation fails. Because these identities can change many resources, treat them like any other privileged identity: give the smallest role possible, and review them regularly.

Choosing the right effect

Managing hundreds of single rules one by one would be exhausting. Initiatives bundle rules so that you manage a theme, not a pile.

What an initiative is

An initiative definition, also called a policy set, is a group of policy definitions with a shared purpose. Instead of assigning 40 separate storage policies one at a time, you assign one “Storage security baseline” initiative. Compliance can then be reported for the whole initiative as well as for each member policy. An initiative can have its own parameters that feed several member policies, so you fill in “allowed regions” once and it flows to all of them.

Policy groups and compliance controls

Initiatives can organise members into policy definition groups. Regulatory compliance initiatives use groups to map to the controls of a standard. For instance, a group might correspond to “encryption of data at rest” in a standard, and the member policies below it are the Azure checks that provide evidence for it. The compliance dashboard can then show, control by control, which are covered and which have gaps.

Built-in initiatives you will meet

Customising an initiative

Built-in initiatives are read-only, but you can copy one, remove members you do not need, add your own custom policies, and change parameters. When copying, remember that your copy does not automatically follow future changes Microsoft makes to the original, so schedule periodic comparisons. Some organisations prefer to assign the built-in initiative unchanged and use exemptions or parameter choices for differences, so that updates keep flowing in.

Initiative design guidelines

• Group by theme or owner. A “network security” initiative managed by the network team is easier to govern than a mixed bag.
• Keep sizes manageable. There are documented limits on how many policies an initiative can hold and on the number of initiatives per scope, and very large initiatives slow troubleshooting.
• Use parameters thoughtfully. Surface the choices people really need to make, such as effects and allowed values, and keep sensible defaults for the rest.
• Name clearly. Names should tell a new engineer what the initiative is for, and descriptions should say who owns it.
• Version and document. Record what each release changed and why.

Overlapping initiatives

When two initiatives contain the same policy with different parameters, both evaluate and both report. This can create confusing duplicate findings, and, when one uses Deny and the other Audit, the strictest effect wins at request time. Review overlaps, particularly when you assign a regulatory initiative on top of your own baseline, to avoid duplicated noise.

A rule only matters where it is assigned. Choosing scope and handling exceptions wisely is the heart of day-to-day policy work.

What an assignment contains

Enforcement mode: a safe test switch

Setting an assignment to DoNotEnforce lets you see what a rule would do without blocking anything. The compliance results appear, the Activity Log shows what would have been denied, but real requests proceed. This is an excellent way to test a Deny rule in production before turning it on. Flip the assignment to the default mode when you are confident.

Choosing the right scope

A good rule of thumb is to assign as high as is sensible, so that new subscriptions are covered automatically, and to avoid scattering the same rule at many low levels, which becomes a maintenance burden.

Exclusions versus exemptions

Managing exemptions well

• Require a ticket or approval reference in the exemption description.
• Set an expiry date, and review expired or soon-to-expire exemptions regularly.
• Restrict who can create exemptions, since this is a power to bypass governance.
• Report on the number of exemptions per policy; a policy with many exemptions may need redesign.

Conflicts between assignments

If a resource falls under several assignments, all of them are evaluated. There is no “closest assignment wins.” A Deny anywhere in the chain blocks the request. You cannot loosen a parent’s Deny from a child scope except through an exemption. This is why top-level assignments should be few, well-reviewed, and truly universal. Rules that apply only to some workloads belong lower in the tree.

Policies that only prevent future mistakes leave the old ones behind. Remediation closes that gap.

Two kinds of problems

New resources that arrive after the policy was assigned are handled at request time: Deny stops them, Modify corrects them, and DeployIfNotExists adds missing parts. Existing resources are different. They were created before the rule, or they drifted, and the policy engine merely marks them non-compliant. Fixing them requires either a human or a remediation task.

How a remediation task works

Risks of remediation

• Surprise changes in production. Changing a setting on a live resource may interrupt service. For example, enabling a feature that restarts a service. Test on a small scope first.
• Too much privilege. An identity with Contributor on a whole management group can change everything. Prefer narrow roles listed in the definition.
• Cost. Deploying diagnostic settings or agents across thousands of resources can generate large volumes of logs and charges.
• Template limits. The deployment template in a DeployIfNotExists definition must work for every matching resource, including unusual configurations. Failures are common when resources are in unexpected states.
• Race with other automation. A pipeline that sets a value and a policy that sets a different value can fight each other forever.

When not to auto-remediate

Some problems are not safe to fix automatically. Disabling public access on a storage account that a partner relies on would break an integration. In such cases, use Audit, notify the owner, and let a human decide, perhaps with an exemption for the justified case. Automatic repair suits settings with an obvious safe value, such as adding tags, enabling logging, and attaching standard monitoring.

Policy gets its power from where you attach it. A well-designed hierarchy makes policy simple, and a poor one makes it painful.

flowchart TD
  ROOT["Tenant root group"] --> CO["Company top group"]
  CO --> PLAT["Platform"]
  CO --> LZ["Landing Zones"]
  CO --> SAND["Sandbox"]
  CO --> DEC["Decommissioned"]
  PLAT --> IDN["Identity"]
  PLAT --> MGT["Management"]
  PLAT --> CON["Connectivity"]
  LZ --> CORP["Corp private workloads"]
  LZ --> ONL["Online internet facing workloads"]
  CO -.->|"Baseline policies for all"| CO
  LZ -.->|"Workload guardrails"| LZ
  SAND -.->|"Light touch cost and region rules"| SAND

Azure landing zones

A landing zone is a well-prepared Azure environment where workloads can be deployed safely: networking, identity, monitoring, and policy are ready before the first application arrives. Microsoft’s Azure landing zone reference architecture proposes a management group layout, shown in simplified form above, and ships a coordinated set of policy definitions and assignments for it. Platform groups hold shared services such as identity, central networking, and monitoring. Landing zone groups hold application subscriptions, further divided into “Corp” for internally connected workloads and “Online” for internet-facing ones. A Sandbox group provides an area for experiments with light rules, and a Decommissioned group holds subscriptions waiting for deletion.

Which policies where

Design principles

• Keep the tree shallow. Deep trees are hard to reason about. A few levels are usually enough.
• Do not mirror the org chart. Reorganisations happen often, while the governance needs of workloads change slowly.
• Use a dedicated top group beneath the tenant root, so that you can manage policies without touching the root, which is hard to undo.
• Subscriptions as units of scale. Create separate subscriptions per application or environment, because many limits and billing views work at that level, and policy can be tailored by moving the subscription to a different group.
• Automate subscription vending. A repeatable process creates new subscriptions, places them in the right group, and sets up networking and access, so policies apply from the first minute.

Clicking through the portal does not scale, leaves no history, and invites mistakes. Mature teams manage policies as code with reviews, tests, and automated rollout.

Why policy as code

Policies are powerful: a single wrong change can block every deployment in a company. They deserve at least the same care as application code. Keeping definitions, initiatives, assignments, and exemptions in a Git repository gives you version history, peer review, an audit trail of who approved what, easy rollback, and the ability to recreate the same governance in a new tenant or a test environment.

flowchart LR
  A["Change policy files in a branch"] --> B["Pull request"]
  B --> C["Automated validation and linting"]
  C --> D["Deploy to sandbox with DoNotEnforce"]
  D --> E["Check compliance impact report"]
  E --> F{"Reviewers approve"}
  F -->|"No"| A
  F -->|"Yes"| G["Merge to main"]
  G --> H["Deploy to production management group"]
  H --> I["Start with Audit effect"]
  I --> J["Monitor and fix findings"]
  J --> K["Switch to Deny after readiness"]

What goes into the repository

Tooling options

Testing policies

Controlling who can change policy

Because policy changes are high impact, restrict them. Only a small platform or governance team should hold rights to write definitions and assignments at high scopes, and ideally only through the pipeline’s identity. Protect the main branch, require review by the governance team, and have the pipeline use OIDC with a narrowly scoped identity. Treat any manual portal change at the top of the hierarchy as an incident.

Policy is a security tool, but it is also a powerful system that attackers or careless insiders could change. This chapter covers how to protect it and how to use it to protect everything else.

Who may do what with Policy

Some actions need more than one permission. Creating an assignment that uses Modify or DeployIfNotExists needs the right to create the assignment, and also the right to give roles to its managed identity. This split intentionally prevents a policy author from silently granting themselves wide powers.

Threats to the governance system

Defences

• Least privilege. Limit Resource Policy Contributor and Owner at high scopes to a handful of people and one pipeline identity. Use time-limited elevation with Privileged Identity Management for humans.
• Alert on changes. The Activity Log records changes to assignments, exemptions, and definitions. Send them to your monitoring system and alert on any change at high scopes outside the pipeline.
• Protect management group moves. Restrict who can move subscriptions and who can create them.
• Review remediation identities. Give them only the roles in the definition, and prefer user-assigned identities you can inventory.
• Code review for custom templates. Treat DeployIfNotExists templates as privileged code.
• Use resource locks and DenyAction for the most critical resources, such as the central log workspace and policy-related storage.
• Cover the gaps. Combine Policy with Defender for Cloud, network controls, and regular configuration reviews.

Using Policy to raise security everywhere

Policy runs on every resource request in your tenant. It is designed to be fast, but a poor design can still cause pain at scale.

Effect on deployments

Evaluation of a request happens within Azure Resource Manager and is generally fast. You rarely notice it. What you do notice are Deny messages that interrupt a deployment and the time taken by DeployIfNotExists remediation deployments that run after the main deployment. A pipeline that creates a resource and then immediately depends on a related resource that a policy will add later can fail, because the policy-created resource appears minutes afterwards. Design pipelines to create what they need explicitly, or to wait for policy effects.

Limits to keep in mind

Exact numbers are published in the Azure subscription and service limits documentation and are changed occasionally. Check them when designing a very large estate. If you approach limits, restructure: assign initiatives rather than single policies, and assign at higher scopes instead of repeating assignments.

Compliance data at scale

Large estates generate large compliance data sets. Use the portal for overviews and Azure Resource Graph for queries across subscriptions. For historical trends and executive dashboards, export compliance data to a data store or workbook, because the live view shows the current state and recent history only. Be patient after big changes; a new assignment on thousands of resources can take a while to produce full results.

Cost view

Always verify current pricing on the official pages, since packaging of Defender and Arc features changes over time.

Azure Policy can reach beyond the outer properties of resources. It can inspect what runs inside clusters and servers, and it can control certain data operations.

Azure Policy for Kubernetes

Kubernetes is a system that runs many containers across a group of machines. In Azure, the managed version is Azure Kubernetes Service (AKS). Azure Policy can govern what is allowed inside a cluster by installing an add-on or extension that works with Gatekeeper, an open-source admission controller built on the Open Policy Agent. An admission controller is a gatekeeper that inspects every request to run something in the cluster before it is accepted. Policies can then forbid privileged containers, require resource limits, allow only images from approved registries, block public load balancers, or require certain labels. Results appear in the same compliance dashboard as Azure resource policies.

Machine configuration (formerly Guest Configuration)

Some important settings live inside a server’s operating system, such as password rules, installed software, or firewall state, and are invisible to the Azure control surface. Azure Machine Configuration (earlier called Guest Configuration) uses an agent on Azure virtual machines and on servers connected via Azure Arc to check these settings and report them back as policy compliance. Built-in policies cover common security baselines, and you can author custom configurations. Some policies can also apply a configuration, not just audit. Because these checks run on the machine itself, they need the agent and a managed identity, and they add some load to servers.

Resource provider modes and data-plane control

Most policies govern the control plane, the operations that create and configure resources. A few services expose a data plane, the operations that work with the data itself. Resource provider modes allow policy for some of these. For example, policies can govern key properties in Key Vault, such as secret expiry or key types, and they can restrict certain network data operations. Support differs by service and changes over time, so check documentation for the one you need.

Policy with Azure Arc and hybrid estates

Azure Arc projects servers, Kubernetes clusters, and databases running elsewhere, such as on-premises or in another cloud, into Azure as manageable resources. Once projected, Azure Policy can assess them with the same rules and dashboards. This gives one governance view over a hybrid estate, though supported policies and features differ between Azure-native and Arc-enabled resources.

A guardrail system must be observed. You need to know what it blocks, what it finds, and why something behaves unexpectedly.

Where to look

Useful reports

• Compliance percentage by management group, subscription, and owner team, trended over time.
• Top ten non-compliant policies and top ten teams with findings.
• Exemptions list with expiry dates and reasons.
• Denied deployments per week, to see whether a rule is causing friction.
• Remediation task success rate.
• Changes to definitions and assignments, with who changed them.

Common problems and their usual causes

A calm method for investigating

Azure Policy is one tool among several. Using each for what it does best gives a stronger and simpler governance design.

flowchart TD
  Q["What do you want to control"] --> A{"Who can do an action"}
  A -->|"Yes"| RBAC["Azure RBAC and Privileged Identity Management"]
  A -->|"No"| B{"What a resource may look like"}
  B -->|"Yes"| POL["Azure Policy"]
  B -->|"No"| C{"Prevent accidental delete or change of one resource"}
  C -->|"Yes"| LOCK["Resource locks or DenyAction"]
  C -->|"No"| D{"Find threats and weaknesses"}
  D -->|"Yes"| DEF["Microsoft Defender for Cloud"]
  D -->|"No"| E{"Standardise how resources are deployed"}
  E -->|"Yes"| TPL["Templates, template specs, deployment stacks"]
  E -->|"No"| F{"Control spending"}
  F -->|"Yes"| COST["Budgets and Cost Management plus cost policies"]
  F -->|"No"| G["Review other governance options"]

Each tool in its lane

Policy and other clouds

If your company uses more than one cloud, remember that Azure Policy governs Azure and Arc-connected resources. Other clouds have their own equivalents, such as service control policies and organisation policies, and there are third-party tools and open standards such as Open Policy Agent that work across environments. Many multi-cloud teams use each cloud’s native guardrails for enforcement and a central tool for reporting. Azure Policy remains the most direct way to enforce rules on Azure resource requests.

Questions to settle the design

• Which rules must be absolutely enforced, and which are advisory?
• Which regulations or internal standards apply, and which evidence do auditors need?
• Who owns each rule, and how do engineers request exceptions?
• How will changes be tested, approved, and rolled back?
• Which resources or properties are outside what policy can see, and how will you cover them?

Teams that govern Azure well repeat a few good designs. Teams that struggle repeat a few familiar mistakes. Knowing both saves months.

Patterns that work

Habits compared

Four decisions worth recording

Teams that write down their key decisions avoid arguing about them again a year later. These short records use the common format of context, decision, and consequences. They are illustrative examples, not mandates.

This chapter gathers the advice of the whole book into one checklist to use before launch, during reviews, and after incidents.

Best practices

Common mistakes

The following scenarios are invented illustrations built from common situations. They are not case studies of real companies, and the numbers are examples chosen to make the ideas concrete.

Short answers to the questions beginners ask most often.

You began with an apartment complex that could not be inspected by hand. You now have the blueprint for building the rules into the building itself.

Azure Policy evaluates the shape of resources, not the rights of people. A rule has a condition and an effect, rules are grouped into initiatives, and assignments attach them to scopes in the management group hierarchy, where they flow downward to everything beneath. Deny prevents, Audit reveals, Modify and DeployIfNotExists repair, and exemptions record justified exceptions. Remediation tasks fix the past, and policy as code with staged rollout keeps the system itself safe. Around all this sit the disciplines of good design: a clean hierarchy, careful scoping, friendly messages, monitoring, and humility about what the dashboard cannot see.