Azure Policy becomes much easier to reason about when you start with scope. A policy or initiative assignment applies at a scope such as a management group, subscription, resource group or individual resource. Child resources inside that scope inherit the assignment unless the assignment design excludes them or an approved exemption changes how compliance is evaluated. This inheritance is what makes Azure Policy useful for governance at scale.
It is also what makes poorly tested policy dangerous. A deny assignment at a high-level management group can affect hundreds of subscriptions. A modify or deployIfNotExists policy may require a managed identity and remediation. An exclusion may solve one workload problem while quietly removing a guardrail from an entire branch. Understanding the difference between assignment scope, exclusions and exemptions is therefore central to AZ-104, AZ-305 and cloud governance.
Definitions do nothing until they are assigned
A policy definition describes a rule and its effect. An initiative groups multiple definitions into a coordinated set. Neither governs resources until it is assigned to a scope.
The assignment is where Azure determines which part of the hierarchy is covered. Assign a policy at a subscription and resources in that subscription are in scope. Assign it at a management group and descendant subscriptions, resource groups and resources inherit it.
This separation is useful because the same definition can be assigned differently in different parts of the organization. A policy requiring a tag might run in audit mode in a sandbox branch and in modify or deny behavior in production after testing.
Inheritance follows the Azure resource hierarchy
Azure resources sit inside a hierarchy: management groups can contain subscriptions, subscriptions contain resource groups, and resource groups contain resources. Policy assignments made higher in that hierarchy flow downward.
This is why Azure infrastructure governance often starts with management-group design. The hierarchy determines where a central policy can be expressed once and inherited everywhere below it.
Subscription owners cannot simply remove an inherited assignment that was made at an ancestor scope they do not control. That is a major governance benefit. A central platform team can require allowed regions, diagnostic settings or security controls without relying on each application team to recreate the same assignment.
Inheritance also means policy impact can be wider than the engineer making the change expects. Before assigning a definition at a management group, identify every descendant subscription and test the effect against representative workloads.
NotScopes exclude parts of the assignment
An assignment can include excluded scopes, commonly represented through notScopes. These tell Azure that particular child scopes should not receive that assignment.
An exclusion is appropriate when a branch is structurally outside the intended policy. For example, a global “only approved regions” assignment might exclude a dedicated disaster-recovery subscription if its documented design requires another region.
Exclusions should be used sparingly because they are easy to forget. A resource group excluded from a policy may later host workloads that were never part of the original exception. Document why the exclusion exists and review it when ownership or purpose changes.
Do not create an ever-growing list of notScopes to make a badly scoped assignment work. If half a branch has to be excluded, the assignment probably belongs at a different scope.
Exemptions are different from exclusions
Azure Policy exemptions provide a governance mechanism for resources that are technically in scope but have an approved reason not to be evaluated in the normal way for a period or circumstance. They are useful when the organization wants to keep the assignment structure intact while recording a controlled exception.
This is conceptually different from carving a scope out of the assignment. An exemption can preserve visibility that the resource would otherwise be noncompliant and can carry metadata explaining the reason, category and expiry expectations.
For regulated environments, that distinction matters. Governance teams often need to know not just that a resource is outside enforcement, but why, who approved it and when the exception should be reviewed.
Use exemptions as part of an exception process, not as an informal way to silence compliance findings. An exception that has no owner or review date is simply unmanaged policy debt.
Effects change what inheritance actually does
Inheritance tells you where the policy applies; the effect tells you what happens when a resource matches the rule. Audit effects report noncompliance. Deny can stop noncompliant create or update operations. Modify can change supported properties. DeployIfNotExists can deploy related resources when expected configuration is missing.
These effects have very different operational risk. Audit is a good starting point for discovering impact. Deny can break deployments immediately. Modify and deployIfNotExists can change resources or create supporting configuration and may require a managed identity on the assignment for remediation.
A mature rollout often starts with audit, measures how many existing resources would fail, fixes the largest issues and then moves toward enforcement. Jumping directly to deny at a management-group scope can turn policy into an outage mechanism.
Existing resources and new deployments do not always behave the same way
Policy is evaluated when resources are created or updated and through compliance scans. A new deny assignment may immediately prevent future noncompliant deployments while existing resources appear as noncompliant rather than disappearing or being automatically fixed.
Remediation is therefore part of the design for effects such as modify and deployIfNotExists. The platform may need to run a remediation task to bring existing resources into the desired state. That process uses the assignment’s managed identity where required and should be monitored like any other automated change.
This distinction helps explain a common question: “If we assigned the policy, why is the old resource still wrong?” Assignment creates governance. Remediation may still be required to change existing configuration.
Initiatives make inherited baselines easier to manage
An initiative groups policy definitions that belong to one governance outcome. Instead of assigning dozens of individual policies for a security baseline, a platform team can assign an initiative and manage parameters coherently.
This is especially useful at management-group scope. The organization can maintain a baseline for production, another for sandbox environments and additional regulatory initiatives for specific branches.
Initiatives also improve reporting because compliance can be reviewed against a named control set rather than a flat list of unrelated definitions. However, an initiative is not automatically well designed. Large initiatives should still avoid redundant or conflicting policies and should be tested before wide enforcement.
Policy inheritance and RBAC inheritance are separate systems
Azure Policy governs resource configuration and compliance. Azure RBAC governs who can perform actions. Both can inherit through management groups, subscriptions and resource groups, but one does not replace the other.
A policy can deny creation of a public IP even if a user has Contributor permissions. The user is authorized to create resources, but the governance rule constrains which resource configurations are allowed. Conversely, a policy assignment does not grant someone permission to modify the resource.
This distinction is essential when troubleshooting. An “authorization failed” problem is different from a deployment being denied by policy. Teams should inspect both effective RBAC and policy rather than assuming every blocked deployment is an access issue.
The existing Azure RBAC provides the access-control side of that relationship.
Design inheritance for predictable governance
- Assign policies at the highest scope where the requirement genuinely applies to every descendant.
- Use management groups to express governance boundaries that span subscriptions.
- Start broad new controls in audit mode before moving to deny or automatic remediation.
- Use exclusions only when a child scope is structurally outside the assignment’s intent.
- Use exemptions for approved exceptions that should remain visible and reviewable.
- Document parameters, owners and exception processes for high-impact initiatives.
- Test policy changes against representative deployments before assigning them widely.
- Monitor remediation tasks and do not assume assignment alone fixes existing resources.
Azure Policy inheritance is powerful because it turns a hierarchy into enforceable governance. The same mechanism can also create widespread deployment failures if scope is chosen carelessly. Good policy design therefore begins with a simple question: exactly which descendants should inherit this control, and what should happen when they do not comply?
When that answer is explicit, Policy becomes a scalable architecture tool rather than a collection of mysterious denials. That is the level of understanding expected from engineers working across the cloud architecture and Azure governance domains.
Troubleshoot the effective policy, not just the visible assignment
When a deployment is blocked, engineers often inspect only the policy assignments on the resource group and conclude that nothing should deny the request. Inherited assignments can originate several levels higher, so troubleshooting needs to examine the effective policy state across management group, subscription and resource-group scopes.
Policy initiatives can make this harder because the deny may come from one definition nested inside a larger initiative. The deployment error, compliance details and policy evaluation records should be used to identify the exact definition and assignment responsible before anyone creates an exemption.
Parameters also matter. The same definition may allow one region in one branch and several regions in another. Seeing the definition name alone is not enough; the effective assignment parameters determine the actual rule.
Finally, distinguish a policy failure from an RBAC failure or a resource-provider validation error. Policy usually reports the assignment or definition that denied the request. Authorization errors indicate the caller lacks permission. Resource-provider errors may mean the requested configuration is invalid regardless of governance. Correct diagnosis prevents the common anti-pattern of weakening policy to fix a problem that policy did not cause.