Azure Policy

About Azure Policy

Azure Policy is Microsoft's governance service for defining rules that evaluate Azure resources and resource actions against organizational standards. Depending on the selected effect, Policy can audit, deny, modify, append, deploy required configuration, or block selected delete actions. It sits at the governance layer rather than the runtime layer: Policy does not host applications, replace identity permissions, or provide operational telemetry. It is best used to turn architecture, compliance, cost, security, and configuration requirements into repeatable controls that can be assigned across management groups, subscriptions, resource groups, or individual resources.

What does Azure Policy do?

Azure Policy evaluates Azure resources and resource actions against policy definitions. A definition describes the condition to check and the effect to apply when that condition matches. Organizations can use built-in definitions supplied by Microsoft or create custom definitions for their own standards. Common examples include restricting allowed deployment regions, requiring tags, auditing diagnostic settings, blocking unsupported resource types, or requiring selected security configurations.

Policy assignments apply a definition or initiative to a chosen scope. Because Azure scope follows the Resource Manager hierarchy, a policy assigned at a management group can affect subscriptions and resources below it unless exclusions, resource selectors, or exemptions change applicability.

How do definitions, initiatives, assignments, and exemptions differ?

A policy definition is one rule. An initiative groups multiple policy definitions so a broader standard can be assigned and reported as one package. An assignment connects a definition or initiative to a scope and can supply parameters, enforcement settings, exclusions, resource selectors, overrides, and non-compliance messages.

Exemptions are different from exclusions. An exclusion removes a scope from evaluation and compliance counting. An exemption keeps the resource visible in governance reporting but marks it as exempt for a documented reason. Microsoft supports optional exemption expiration dates, which is useful for temporary waivers that should not become permanent exceptions.

What effects can Azure Policy enforce?

Azure Policy supports effects that range from visibility to enforcement. Audit-style effects identify non-compliant resources without blocking deployment. Deny can prevent a resource action that violates a rule. Modify can add, update, or remove supported tags and update supported resource properties. deployIfNotExists can deploy related resources or configuration when required items are missing. Other effects include append and auditIfNotExists.

Azure Policy also supports denyAction for selected actions. Microsoft currently documents DELETE as the supported denyAction action, which can be used to protect critical resources from accidental deletion. The effect matters because it changes rollout risk, so strong enforcement should be tested before broad assignment.

How can teams stage policy rollout safely?

Microsoft recommends safe deployment practices for Azure Policy instead of moving a new deny or modify rule directly across production. Resource selectors can narrow an assignment to selected resource locations, resource types, or resources without a location. Assignment overrides can temporarily change a policy effect or definition version for selected portions of scope.

A practical pattern is to start with a low-risk tier using audit behavior, validate compliance results and application health, then expand the selector to more regions or resource groups. After the rule behaves as expected, the effect can be moved toward deny or enforcement in stages. The same pattern can be used when moving assignments to newer built-in policy definition versions.

How does remediation work?

Existing resources do not automatically become compliant just because a policy is assigned. For policies that use modify or deployIfNotExists, Azure Policy can use remediation tasks to update supported existing resources. These actions use a managed identity associated with the policy assignment and require the appropriate Azure RBAC roles.

Microsoft currently documents a default remediation resource count of 500 and a maximum of 50,000 resources per remediation task. Parallel deployment count can be configured from 1 to 30, with 10 as the default. Teams should still use change control and monitoring because remediation can alter production resources at scale.

What Azure Policy limits matter at scale?

Azure Policy has documented object and request limits that matter in large governance estates. Microsoft currently lists up to 500 policy definitions per management group or subscription scope, 200 initiative definitions per scope, 2,500 initiative definitions per tenant, 200 policy or initiative assignments per scope, and 1,000 exemptions per scope.

A policy definition can have up to 20 parameters. An initiative can include up to 1,000 policies and 400 parameters. One assignment can contain up to 400 exclusions. Microsoft also documents a 1,048,576 byte request-body limit for policy definitions, initiatives, and assignments, and a 50,000-resource maximum for a remediation task. These limits make reusable initiatives, naming standards, ownership, and cleanup important as governance grows.

How do manual compliance attestations work?

Azure Policy compliance can include a manual effect for requirements that cannot be evaluated automatically. Microsoft documents manual compliance as dependent on the definition's default compliance state and any active attestation for the resource. A resource can therefore be marked compliant or non-compliant through an attestation process rather than through normal resource-property evaluation.

This is useful for controls that depend on evidence outside Resource Manager, but it also creates an operational responsibility. Organizations should define who is authorized to attest, what evidence is required, how often attestations are reviewed, and how expired or superseded evidence is handled.

What does Azure Policy cost?

Microsoft states that Azure Policy is offered at no additional cost to Azure subscribers for the core Azure Policy service. Pricing was rechecked on September 6, 2026. The wider environment can still create cost when policies deploy or enable billable Azure resources such as diagnostic destinations, security services, networking, storage, or compute.

Organizations using guest configuration or governance capabilities with Azure Arc should also review the pricing of those related services separately. Buyers should separate the Policy control-plane price from the cost of resources that policies create, enable, or monitor.

How is Azure Policy different from Azure RBAC, Azure Monitor, and Defender for Cloud?

Azure RBAC controls who can perform actions. Azure Policy evaluates whether resources and actions meet organizational rules. A user can have permission to create a resource through RBAC while Policy still denies the deployment because it violates location, tagging, security, or configuration requirements.

Azure Monitor focuses on telemetry, logs, metrics, traces, and alerts. Azure Policy focuses on configuration and compliance evaluation. Microsoft Defender for Cloud provides cloud security posture and workload protection and can use policy-based controls, but it is not a replacement for Azure Policy as the general Azure governance engine.

What are the main limitations and operational tradeoffs?

Policy coverage depends on resource-provider support, policy mode, aliases, scope, and the effect being used. Not every resource property can be modified or evaluated in the same way. Compliance results can also take time to update after an assignment or resource change, so the dashboard should not be treated as a real-time transaction log.

Large policy estates can become difficult to understand when overlapping assignments, exemptions, exclusions, parameters, overrides, and custom definitions accumulate. Poorly tested deny, modify, or deployIfNotExists policies can disrupt legitimate deployments. Strong governance therefore depends on ownership, version control, documentation, testing, staged rollout, and periodic removal of obsolete assignments.

Who should choose something else?

Teams that only need access control should start with Azure RBAC rather than trying to express permissions as Policy. Teams that need alerting and operational telemetry should use Azure Monitor. Organizations that need workflow automation should look at Logic Apps or Azure Automation, while security teams needing broader posture management and threat protection should evaluate Defender for Cloud.

Azure Policy is the better fit when the requirement is repeatable Azure resource governance: define what compliant infrastructure should look like, measure resources against those rules, prevent selected violations, manage documented exceptions, and remediate supported configuration drift at scale.