Use an applicability funnel, not one vague idea of scope
Definition location
Determines where a custom definition is available for assignment in the Azure hierarchy.
Assignment scope
Includes a management group, subscription, resource group, resource and applicable descendants.
Excluded scope
Removes named child scopes or resources through the assignment's notScopes property.
Exemption
Creates a tracked exception for a hierarchy or resource that would otherwise be evaluated.
Applicability checklist
A resource must be reachable from the definition location, inside the assignment scope, outside notScopes, outside an applicable exemption, inside any resource-selector subset, and matched by the definition conditions before its effect matters.
This layered model prevents a common troubleshooting mistake: inspecting only the policy rule. A correct rule does nothing to a resource outside the assignment hierarchy, excluded, exempt, filtered out by a selector or not applicable to its conditions.
Definition location and assignment scope are different
A custom definition is stored at a subscription or management-group location. That location establishes where the definition can be assigned:
- Subscription definition: available within that subscription and its child resource groups and resources.
- Management-group definition: available within that management-group hierarchy, including eligible child management groups and subscriptions.
The assignment selects the actual governance boundary. An assignment at a management group can flow to child subscriptions; an assignment at a subscription flows to resource groups and resources. Store shared definitions at a common ancestor containing every intended target.
AZ-104 clue: if a custom definition cannot be selected for another subscription, check its definition location and management-group hierarchy before rewriting the policy rule.
Inclusion, notScopes and exemption compared
Choose notScopes when the boundary is structural
A development sandbox might be permanently outside a production-only initiative. Adding that resource group to notScopes makes the boundary explicit in the assignment. Updating inclusion or notScopes changes the assignment object.
Choose an exemption when the exception needs governance
A legacy production resource might temporarily require public network access while a migration is completed. An exemption can record the assignment, reason, owner, approval reference and expiration while keeping the exception visible in compliance data.
Do not use exceptions to hide bad scope design. If hundreds of unrelated resources need exemptions, reconsider the assignment scope, definition conditions, initiative composition or rollout strategy.
Design an auditable Azure Policy exemption
An exemption is a separate Azure Resource Manager child object created on the exempted resource or hierarchy and linked to one policy or initiative assignment. A useful exemption records:
- Display name and description: the business and technical reason.
- Assignment ID: the exact policy or initiative assignment being bypassed.
- Category: Waiver when noncompliance is temporarily accepted; Mitigated when another method satisfies the policy intent.
- Expiration: an optional expiresOn date for time-bound approval.
- Metadata: requester, approver, ticket, review date and compensating-control evidence.
- Initiative references: policyDefinitionReferenceIds when the exemption applies only to selected definitions inside an initiative.
An expired exemption remains as an object but stops being honored. That helps record keeping, but operations still need to remove stale objects and address the newly applicable policy state.
Creating an exemption requires permission to write policy exemptions at the target hierarchy or resource and the exempt/Action permission on the assignment. This additional authorization reduces silent governance bypass.
Do not confuse exceptions with rollout controls
For safe rollout, start with DoNotEnforce or an audit effect and use resource selectors for an initial region or resource type. Expand after reviewing impact. That is more transparent than creating permanent exclusions for each rollout wave.
Worked scenario: one initiative, three environments
A management-group initiative restricts locations and requires diagnostic settings across production, development and a temporary legacy workload.
- Main assignment: assign the initiative at the management group so child subscriptions inherit it.
- Permanent lab boundary: if an isolated lab subscription is outside the initiative's purpose, add it to notScopes.
- Time-bound legacy exception: create a Waiver exemption on the legacy resource group for the affected definition, with owner, ticket and expiresOn.
- Compensating control: if an alternate monitoring solution meets the diagnostic intent, use Mitigated and record evidence.
- Staged rollout: use resource selectors for initial regions, then expand the assignment instead of treating untested regions as exceptions.
- Pre-enforcement review: use DoNotEnforce to inspect impact before enabling deny or corrective behavior.
The lab is excluded and absent from compliance for that assignment. The legacy workload appears Exempt and remains reviewable. Production resources are evaluated normally. These are materially different outcomes.
Troubleshoot “Why is this resource not evaluated?”
- Confirm definition location: is the target inside the hierarchy where the custom definition can be assigned?
- Trace assignment inheritance: inspect management group, subscription, resource group and resource scopes.
- Review notScopes: check whether the resource or an ancestor is excluded.
- Review exemptions: find exemption child resources linked to the assignment, including partial initiative exemptions.
- Check expiration: determine whether the exemption is active; an expired object can still exist.
- Inspect resource selectors: verify location and type conditions include the resource.
- Inspect mode and overrides: distinguish evaluation from enforcement and confirm the effective effect.
- Check applicability: validate policy mode, resource type, aliases, parameters and if conditions.
- Allow evaluation time or trigger a scan: recent hierarchy, assignment or exemption changes might not yet appear.
Fast symptom map
Absent from compliance: scope, notScopes, selectors or applicability. Shown as Exempt: exemption object. Noncompliant but allowed: audit or DoNotEnforce. Unexpected deny: inherited assignment, parameters or expired exemption.
AZ-104 practice checks with explanations
A test resource group should permanently stay outside a production-only policy and need not appear in compliance. What should you use?
Best answer: add the resource group to notScopes. It is a durable structural exclusion rather than a tracked exception.
A storage account needs public access for 30 days and the exception must remain visible. What should you use?
Best answer: create a Waiver exemption with an owner, approval record and expiresOn date.
A team satisfies the policy intent with an approved alternative control. Which category?
Best answer: Mitigated. Record evidence of the compensating control in metadata or a linked ticket.
A deny assignment should be evaluated in only two regions before wider rollout. Which feature helps?
Best answer: resource selectors narrow evaluation to selected locations and can be expanded gradually.
Common AZ-104 mistakes
- Confusing definition location with assignment scope.
- Assuming an excluded resource appears as Exempt.
- Using notScopes for a temporary exception that needs an audit trail.
- Creating an exemption without expiration, owner or evidence.
- Using Waiver when a compensating control meets the intent.
- Exempting an entire initiative when only one definition needs an exception.
- Assuming an exemption object is deleted automatically when it expires.
- Using exclusions instead of resource selectors for staged deployment.
- Believing DoNotEnforce removes resources from evaluation.
Frequently asked questions
What is the difference between an Azure Policy exclusion and exemption?
An exclusion is stored in the assignment's notScopes array and removes that resource hierarchy or resource from evaluation and compliance counts. An exemption is a separate child resource tied to an assignment; it remains visible as Exempt for tracking and can include a category, metadata and expiration.
When should I use notScopes instead of a policy exemption?
Use notScopes for a broad or durable boundary that should not be evaluated, such as a test resource group outside the policy's governance intent. Use an exemption for a specific or time-bound exception that needs a recorded reason, owner, approval trail or expiration.
What are Waiver and Mitigated Azure Policy exemption categories?
Waiver means the noncompliant state is temporarily accepted. Mitigated means the policy's intent is met through another method. The category documents the rationale; it does not itself implement the alternative control.
Does an expired Azure Policy exemption get deleted automatically?
No. After expiresOn is reached, the exemption is no longer honored, but the exemption resource remains for record keeping until it is removed.
Official Microsoft references
- Current AZ-104 study guide
- Understand scope in Azure Policy
- Azure Policy exemption structure
- Azure Policy assignment structure
- Azure Policy compliance states
Verify current hierarchy, assignment behavior and permissions before changing production governance. ITCertPath uses original learning scenarios and does not reproduce confidential exam questions.