Every estate has resources that break the rules for reasons somebody once considered good. The question is not whether you allow them. It is whether the allowance is written down, attributed, and dated, or whether it is a scope quietly missing from an assignment nobody has opened in two years.
Two ways to stop a rule applying, and they are not equivalent
An excluded scope is a property of the assignment. You list a subscription or a resource group in notScopes and the assignment stops reaching it. The resources there are not evaluated, do not appear in compliance results, and produce no record of any kind. From the compliance page they are indistinguishable from resources that do not exist.
An exemption is a separate object, created on the resource or the hierarchy being exempted, referencing the assignment it exempts from. The resources still appear in compliance results, carrying the state Exempt. They are counted, they are visible, and the exemption object itself carries who, why, which parts, and until when.
Both are legitimate. They answer different questions. An exclusion says this rule was never intended to reach here, which is a statement about the design of the assignment. An exemption says this rule was intended to reach here and we have decided, for a stated reason, that it will not for now. Confusing the two is how estates end up with governance that looks complete and is full of holes nobody can enumerate.
An exclusion is a claim about scope. An exemption is a claim about risk. Only one of them leaves evidence that a decision was made.
Waiver and Mitigated, and why the choice is not cosmetic
An exemption must carry a category and there are exactly two. Mitigated means the intent of the policy is met by some other means, so the control objective holds even though this particular rule does not evaluate it. Waiver means the non-compliant state is simply accepted for now.
Treat these as different operational objects rather than as two labels for the same thing. A Mitigated exemption should name the compensating control in its description, and it is reviewable on the same cadence as that control. A Waiver is an accepted risk with an owner, and it needs a date. In my experience the ratio between them tells you more about an organisation’s governance than the compliance percentage does. An estate whose exemptions are almost all Waivers has a backlog it is not working through. An estate whose exemptions are almost all Mitigated, with no compensating control named in any description, is an estate where somebody learned that Mitigated attracts fewer questions.
Waiver has a second documented use worth knowing, which is excluding a resource from one or more definitions inside an initiative rather than from the whole initiative. That is done through policyDefinitionReferenceIds, the identifiers set when the initiative was authored. It is the difference between exempting a legacy application server from one encryption rule and exempting it from your entire security baseline, and the second is what happens when nobody knows the first is available.
Expiry, and the thing it does not do
An exemption can carry expiresOn, a UTC timestamp after which it stops being honoured. This is the single most valuable field on the object and it is optional, which means most exemptions do not have one.
The behaviour at expiry is worth being precise about, because people assume the wrong one. The exemption is not deleted. The object is preserved deliberately, for record-keeping, and simply stops taking effect. So the resource reverts to being evaluated and will start reporting non-compliant, or being denied, depending on the effect, while the exemption remains in the estate as evidence that the decision was made and when it lapsed. That is good design. It also means an expiry date is a scheduled compliance event, and if the underlying problem was not fixed in the interim, the expiry lands as a surprise on whoever owns the workload rather than on whoever granted the exemption.
So I set expiry dates on every waiver, short ones, and I put the review before the date rather than on it. An exemption that has been renewed three times is telling you something true about the estate, and it is a far more useful artifact than one that never expires and therefore never prompts the conversation.
Narrowing an exemption
Exemptions accept resource selectors, the same mechanism assignments use, and for the same reason: so the exemption can be rolled out or rolled back across part of its scope rather than all at once. An exemption scoped to a management group but selected to one region exempts far less than it appears to, which is usually what somebody actually meant when they exempted a management group.
There is also a property called assignmentScopeValidation, which controls whether the platform checks that the exemption sits at or beneath the scope of the assignment it exempts from. It defaults to validating. Setting it to DoNotValidate exists for real situations, mostly ordering problems during automated deployment, and it is also a way to create an exemption that refers to an assignment which is not where you think it is. Leave it at the default unless a deployment sequence forces otherwise, and treat any exemption carrying DoNotValidate as something to look at during a review.
Exempting a principal rather than a resource
The newest capability here lets an exemption name a user, a managed identity, a service principal or a security group, through selector kinds for user principal and group principal identifiers. The enforcement of an assignment is then bypassed for requests made by those principals rather than for particular resources.
The obvious application is the break-glass case: a deployment pipeline that must be able to build something the estate otherwise forbids, or an emergency identity that has to work during an incident when the person using it has no time to argue with a deny assignment. Done well it is narrower than the alternatives people currently reach for, which are usually excluding an entire subscription or disabling the assignment.
Three things about its maturity, all checked in August 2026 and all worth stating plainly. The exemption resource type has no stable API version at all: every published version is a preview, which is unusual for a capability this old. The identity selector kinds first appeared in one of those previews and their casing has already changed between versions, so anything you write against them today may need editing. And neither the Azure CLI nor Azure PowerShell exposes them, so creating an identity-based exemption means ARM templates, Bicep or a direct REST call. Build it if it solves a real problem, keep the definition in source control where a casing change is a diff rather than a mystery, and do not put it on a slide as a shipped capability.
Why there is no build sheet for this article
Every cluster in this series ships a doctrine article and a reproducible build sheet, and this one deliberately does not. Creating an exemption is two commands, and both appear where they belong: inside the staged rollout in the next cluster, where an exemption is what lets the rollout continue past a resource that cannot comply yet, and at the close of the first build sheet in this series. The value here is not the mechanics. It is deciding what an exemption is for, who signs it, and what happens on the day it lapses, and no command demonstrates that.
What I would build instead, and what I recommend building, is the report. A scheduled query over your exemptions listing category, owner, expiry and days remaining, delivered to the people who granted them, is worth more than any single control in this series. The exemption ledger is the only place your estate honestly records the difference between the governance you designed and the governance you are actually running.
From here
Exemptions handle the resources that cannot comply. The next article handles the far more common problem, which is a rule that is correct and would break production if you switched it on everywhere at once.
Azure Policy
‹ Previous: [AP 7.1] Build Sheet: A Custom Definition From Scratch
Next: [AP 9] Changing Policy Safely: Rollout Is the Job ›
