Focus keyphrase: Azure Policy exemptions
Azure Policy exemptions are one of those Azure governance features that sound boring until they save your change window, your audit trail, and possibly your Friday afternoon. Used well, they give teams a controlled way to acknowledge a temporary exception without pretending the resource is compliant. Used badly, they become the cloud version of sticky notes on a monitor: helpful for three days, suspicious forever.
This admin runbook shows when to use Azure Policy exemptions, how to structure them with expiration and ownership metadata, and how to review them before they turn into governance fossils. The goal is not to block delivery. The goal is to let delivery happen without teaching your environment that exceptions are permanent furniture.
Policy, scope, business reason
Owner, ticket, risk decision
Waiver or mitigated category
Compliance and expiry review
Fix, expire, or renew deliberately
Alt text: Five-step lifecycle for governing Azure Policy exemptions from request through removal.
What Azure Policy exemptions actually do
An Azure Policy exemption is a child resource created at a management group, subscription, resource group, or resource scope. It points to a policy assignment and tells Azure Policy that the scoped resource hierarchy should not be evaluated for that assignment, or for selected definitions inside an initiative assignment.
The important detail: exempted resources still show up in compliance reporting as Exempted. That makes exemptions different from quietly carving resources out with broad assignment exclusions. In plain admin terms, an exemption says, “we know about this, here is why, and here is when we will look again.” Much better than “that resource? never met her.”
Exemption, exclusion, or policy change?
Before creating an exemption, decide whether it is the right tool. Azure Policy also supports assignment scope choices and notScopes exclusions. The difference matters because future-you, auditor-you, and “why did production drift?”-you are all counting on today-you to be precise.
| Scenario | Best fit | Why |
|---|---|---|
| Temporary exception for one workload | Exemption | Trackable, scoped, optionally expires |
| Permanent exclusion for a sandbox subscription | notScopes | Broad, intentional bypass of evaluation |
| Policy is too strict for everyone | Policy update | Fix the standard instead of multiplying exceptions |
| Policy intent met another way | Mitigated exemption | Document the compensating control |
Alt text: Decision table comparing exemptions, notScopes exclusions, and policy changes.
The minimum metadata every exemption should carry
Microsoft’s exemption structure supports a flexible metadata object. Use it. The platform does not force your organization’s approval model into those fields, but your governance process should. Without metadata, an exemption becomes a mystery box with an expiration date — and mystery boxes are not a compliance strategy.
Team or person asking for the exception
Risk, platform, or workload approver
Change, incident, or backlog item
UTC deadline for review or cleanup
Alt text: Checklist card showing requestedBy, approvedBy, ticketRef, and expiresOn fields for an Azure Policy exemption.
At minimum, capture:
- Business reason: why the resource cannot comply right now.
- Owner: the team accountable for remediation.
- Approver: the person or group accepting the risk.
- Ticket reference: the change, incident, work item, or risk record.
- Expiration date: when the exemption stops being honored.
- Replacement control: required for mitigated exemptions.
Waiver vs mitigated: do not blur the categories
Azure Policy exemptions support two categories: Waiver and Mitigated. A waiver means the non-compliance is temporarily accepted. Mitigated means the intent of the policy is satisfied through another method. That sounds subtle, but in governance reviews it is the difference between “we accept this risk for 30 days” and “we have another control that covers the risk.”
| Category | Use it when | Example | Review question |
|---|---|---|---|
| Waiver | The resource is temporarily allowed to remain non-compliant. | A legacy app needs 45 days before it can move to approved regions. | What is the fix date? |
| Mitigated | The policy intent is met another way. | A diagnostic setting policy is bypassed because logs are collected by an approved central appliance. | Where is the compensating control documented? |
A practical Azure CLI pattern
The Azure CLI includes az policy exemption create, list, show, update, and delete. The exact command depends on your scope and assignment ID, but the pattern below is a good starting point for an exemption at resource group scope.
az policy exemption create --name "ex-waiver-webapp-eastus-2026q4" --display-name "Temporary waiver for webapp regional migration" --description "Allows the workload to remain outside approved regions until migration completes." --exemption-category "Waiver" --policy-assignment "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/policyAssignments/allowed-locations" --resource-group "rg-prod-webapp" --expires-on "2026-12-15T23:59:00Z" --metadata '{"requestedBy":"Web Platform Team","approvedBy":"Cloud Governance Board","ticketRef":"CHG-18421","remediationOwner":"web-platform","reviewCadence":"weekly"}'Notice the naming convention. It includes the exception type, workload, rough scope, and quarter. You can choose your own format, but make it boringly searchable. Boring is underrated in cloud operations. Boring is how you find the one exception that expires tonight.
Use initiative-level reference IDs when the assignment is broad
If the policy assignment points to an initiative, you do not always need to exempt the resource from the whole initiative. Use policyDefinitionReferenceId to target one or more definitions inside that initiative. This keeps your exception narrow and prevents the classic “we needed one bypass and accidentally turned off twelve guardrails” situation.
{
"properties": {
"policyAssignmentId": "/providers/Microsoft.Management/managementGroups/prod/providers/Microsoft.Authorization/policyAssignments/baseline-governance",
"policyDefinitionReferenceId": [
"allowedLocations",
"requiredTags"
],
"exemptionCategory": "Waiver",
"expiresOn": "2026-11-30T23:59:00Z",
"metadata": {
"requestedBy": "ERP Team",
"approvedBy": "Cloud Governance Board",
"ticketRef": "ADO-4921"
}
}
}Expiration is not deletion
This is the gotcha worth underlining: when expiresOn is reached, the exemption object is preserved for record keeping, but the exemption is no longer honored. That is useful, because you keep the audit trail. It also means you should review expired objects and clean them up deliberately, otherwise your environment collects old exception paperwork like a printer tray nobody admits owning.
Create with owner, ticket, category, expiry
Review remediation progress and compliance impact
Warn owner; renew only with fresh approval
Verify policy evaluation; remove stale object
Alt text: Timeline for creating, reviewing, warning, and cleaning up temporary Azure Policy exemptions.
Review exemptions with compliance data
Azure Policy compliance data can be reviewed in the Azure portal, command line, Azure Monitor logs, and Azure Resource Graph. Microsoft documents that policy evaluations occur on assignment changes, resource changes, exemption changes, an automatic daily cycle, and on-demand scans. After you create, update, or delete an exemption, plan for the related assignment to be evaluated rather than assuming the compliance dashboard changes instantly everywhere.
A useful review question is: “Are our exempted resources decreasing, stable with approved reasons, or growing like someone fed the gremlin after midnight?” If the count keeps rising, you probably have a policy design issue, a migration backlog, or a team using exemptions as a deployment strategy. None of those are solved by adding more exemptions.
Admin checklist for Azure Policy exemptions
- Keep scope tight. Prefer the individual resource or resource group over broad subscription scope unless the exception genuinely applies that broadly.
- Prefer expiration. Use
expiresOnfor temporary waivers and make renewal an explicit approval, not an automatic reflex. - Use metadata consistently. Standardize owner, approver, ticket, business reason, remediation date, and review cadence.
- Use initiative reference IDs. If the assignment is an initiative, exempt only the specific policy definitions that need the exception.
- Separate waivers from mitigations. A compensating control deserves a different review path than accepted non-compliance.
- Audit expired exemptions. Expired exemptions remain as objects, so report on them and remove stale ones after the audit trail is no longer needed.
- Watch for exemption clustering. Many exemptions around the same policy may signal a policy that needs tuning.
A lightweight operating model
For most Azure admin teams, a simple model works well:
- Platform team owns policy definitions, assignments, naming, and reporting.
- Workload team owns the remediation plan and business justification.
- Security or governance approver accepts the risk or validates the compensating control.
- Automation reports exemptions expiring in 7, 14, and 30 days.
That keeps the process lightweight enough that teams will actually use it, but structured enough that exceptions do not disappear into the fog. Governance should be a guardrail, not a maze with a clipboard.
Final take
Azure Policy exemptions are not a failure of governance. They are part of governance when they are scoped, documented, approved, monitored, and allowed to expire. The trick is to treat every exemption like a temporary engineering decision with a named owner, not a secret handshake with the cloud.
Use exemptions to keep delivery moving, use metadata to keep accountability visible, and use review automation so your future self does not have to archaeology their way through yesterday’s emergency.
Sources
- Microsoft Learn: Azure Policy exemption structure
- Microsoft Learn: Understand scope in Azure Policy
- Microsoft Learn: Get policy compliance data in Azure Policy
- Microsoft Learn: az policy exemption command reference
- SharePoint Monkey: Azure Resource Graph Queries: 7 Admin Guardrails to Find Cloud Drift Fast
- SharePoint Monkey: App Service Key Vault References troubleshooting guide
Discover more from SharePoint Monkey
Subscribe to get the latest posts sent to your email.