Symptoms
- Deployment or
azcommand fails withRequestDisallowedByPolicy. - A hotfix, scale-out or restore is blocked during an incident.
- Often after a new initiative was assigned at management group level, or a policy changed from Audit to Deny.
1. Read the error properly
The error message names the policy assignment and definition. Copy the full JSON:
az deployment group show -g rg-app -n <deployment-name> --query properties.error
Look for policyAssignmentId, policyDefinitionId and, for initiatives, policyDefinitionReferenceId. That last one tells you which rule inside the initiative fired.
2. Find the assignment and its scope
az policy assignment show --ids "<policyAssignmentId>" \
--query "{name:name, display:displayName, scope:scope, enforcement:enforcementMode, params:parameters}"
az policy definition show --name <definition-guid> --query "{name:displayName, effect:policyRule.then.effect}"
If the effect is a parameter, the actual value is in the assignment parameters.
| Typical deny | What it blocks | Quick legitimate fix |
|---|---|---|
| Allowed locations | Resource in a region not on the list | Deploy in an allowed region |
| Allowed SKUs | VM or DB SKU used in a scale-up | Pick an allowed SKU or exemption |
| Require tags | Missing costCenter etc. | Add the tags to the template |
| Deny public network access | PaaS with public access enabled | Set publicNetworkAccess=Disabled and use private endpoint |
| Deny public IP | Emergency jump box | Use Bastion |
Most of the time the right fix is to change the deployment to comply. Only exempt when compliance is impossible during the incident.
3. Create a narrow exemption
Exempt the smallest scope, for the one assignment, with an expiry:
az policy exemption create \
--name incident-INC12345-allow-sku \
--policy-assignment "<policyAssignmentId>" \
--scope /subscriptions/<sub>/resourceGroups/rg-app \
--exemption-category Mitigated \
--expires-on 2026-11-03T00:00:00Z \
--display-name "INC12345 temporary SKU exemption" \
--description "Emergency scale-up approved by <name>"
For an initiative, exempt only the failing rule:
az policy exemption create ... --policy-definition-reference-ids "<policyDefinitionReferenceId>"
Caution
Do not delete the assignment or flip
enforcementModetoDoNotEnforceat management group level. That removes the guardrail for every subscription underneath, and it is easy to forget to turn back on.
4. Retry and verify
Exemptions apply quickly but can take a few minutes. Retry the deployment. Then confirm the exemption is visible:
az policy exemption list --scope /subscriptions/<sub>/resourceGroups/rg-app -o table
5. Modify and DeployIfNotExists surprises
Not every policy failure is a deny:
- Modify policies can change your resource (for example add tags or turn off public access) right after deployment, which can break the app.
- DeployIfNotExists remediation tasks can push settings such as diagnostic settings or agents.
Check recent policy activity on the resource:
az policy state list --resource <resource-id> \
--query "[].{policy:policyDefinitionName, state:complianceState, action:policyDefinitionAction}" -o table
Prevent it next time
- Roll out new deny policies in Audit first, review non-compliance for a week, then switch to Deny.
- Use
enforcementMode=DoNotEnforcefor staged rollouts to production subscriptions, then enforce. - Keep a documented break-glass exemption process with who can approve.
- Review and delete expired exemptions monthly.