🚨 Azure Error Guide: 'RequestDisallowedByPolicy' Resource Blocked by Azure Policy

Exact Error Message

When Azure Resource Manager evaluates a create or update request against an assigned policy with a deny effect and the resource violates the rule, the deployment fails with RequestDisallowedByPolicy:

(RequestDisallowedByPolicy) Resource 'stprodeastus001' was disallowed by policy. Reasons: 'Storage accounts should not allow public blob access'. See error details for policy resource IDs.
Policy assignment name: 'deny-public-blob', policy assignment ID: '/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Authorization/policyAssignments/deny-public-blob', policy definition ID: '/providers/Microsoft.Authorization/policyDefinitions/4733ea7b-a883-42fe-8cac-97454c2a9e4a'.
Code: RequestDisallowedByPolicy

From the portal or pipeline you often get the full additionalInfo JSON that names every offending policy:

{
  "code": "RequestDisallowedByPolicy",
  "message": "Resource 'stprodeastus001' was disallowed by policy.",
  "additionalInfo": [
    {
      "type": "PolicyViolation",
      "info": {
        "policyAssignmentId": "/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Authorization/policyAssignments/deny-public-blob",
        "policyAssignmentName": "deny-public-blob",
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/4733ea7b-a883-42fe-8cac-97454c2a9e4a",
        "policyDefinitionName": "4733ea7b-a883-42fe-8cac-97454c2a9e4a",
        "policySetDefinitionId": "/providers/Microsoft.Authorization/policySetDefinitions/casa4-iso27001",
        "policyDefinitionReferenceId": "storageAccountsPublicBlobAccess"
      }
    }
  ]
}

What the Error Means

Azure Policy is a governance control plane that evaluates resource requests before the resource provider provisions anything. When a policy assignment with the deny effect matches your resource and the policy rule evaluates to true, Azure Resource Manager rejects the PUT/PATCH request outright and returns RequestDisallowedByPolicy. Nothing is created or modified.

This is an authorization-at-the-resource-shape decision, not an RBAC decision. Your identity may have every permission needed, the token may be perfectly valid, and the template may be syntactically correct — but the contents of the request (region, SKU, a missing tag, a forbidden property) break a rule that your organization assigned. The error payload always tells you exactly which assignment and definition blocked you via the policyAssignmentId and policyDefinitionId fields, which is the single most important thing to read.

Common Causes

• Disallowed location. An “Allowed locations” policy denies any resource outside an approved region list, and your deployment targets eastus2 when only eastus and westeurope are permitted.
• Missing required tags. A “Require a tag on resources” policy denies resources that lack CostCenter, Environment, or Owner.
• Disallowed SKU. An “Allowed virtual machine SKUs” or “Allowed storage account SKUs” policy denies premium or oversized SKUs.
• Public network access. Policies such as “Storage accounts should not allow public blob access” or “Disable public network access” deny resources that leave publicNetworkAccess enabled.
• Encryption / TLS requirements. A policy denies storage accounts without minimumTlsVersion: TLS1_2 or disks without customer-managed keys.
• Initiative (policySet) assignment. The deny came from one definition inside an initiative — note the policySetDefinitionId and policyDefinitionReferenceId to find the specific rule.
• Inherited management-group assignment. A policy assigned at a management group flows down to every subscription and resource group beneath it, so the assignment may not live in your subscription at all.
• A newly added policy. A deployment that worked last week now fails because governance added or tightened a deny policy.
• A non-compliant parameter. A pipeline parameter or variable supplied a value (region, SKU, name) that violates the rule.

How to Reproduce the Error

Assign a deny policy, then attempt a violating create. This is a minimal, realistic reproduction:

# Assign the built-in "Storage accounts should not allow public blob access" policy
az policy assignment create \
  --name deny-public-blob \
  --display-name "Deny public blob access" \
  --policy 4733ea7b-a883-42fe-8cac-97454c2a9e4a \
  --scope "/subscriptions/$SUB_ID/resourceGroups/rg-demo"

# Now try to create a storage account that allows public blob access
az storage account create \
  --name stprodeastus001 \
  --resource-group rg-demo \
  --location eastus \
  --sku Standard_LRS \
  --allow-blob-public-access true
# -> (RequestDisallowedByPolicy) Resource 'stprodeastus001' was disallowed by policy.

Diagnostic Commands

All of the following are read-only. They inspect assignments, definitions, and compliance state without changing any governance configuration.

# 1. List every policy assignment in effect at the scope (includes inherited).
#    --include-inherited surfaces management-group assignments flowing down.
az policy assignment list \
  --scope "/subscriptions/$SUB_ID/resourceGroups/rg-demo" \
  --disable-scope-strict-match -o table

# 2. Show the specific assignment named in the error.
az policy assignment show --name deny-public-blob \
  --scope "/subscriptions/$SUB_ID/resourceGroups/rg-demo"

# 3. Read the underlying definition to see the deny condition (policyRule.if / then.effect).
az policy definition show --name 4733ea7b-a883-42fe-8cac-97454c2a9e4a \
  --query "policyRule" -o json

# 4. List non-compliant resources and the policies that flagged them.
az policy state list \
  --filter "complianceState eq 'NonCompliant'" \
  --query "[].{resource:resourceId, policy:policyDefinitionName, assignment:policyAssignmentName}" \
  -o table

# 5. Pull a definition that lives inside an initiative directly via the REST API.
az rest --method get \
  --url "https://management.azure.com/providers/Microsoft.Authorization/policyDefinitions/4733ea7b-a883-42fe-8cac-97454c2a9e4a?api-version=2023-04-01"

Note: az policy state trigger-scan forces a fresh compliance evaluation. It is a scan, not a config change, but it can take several minutes and is rarely needed for diagnosis — the RequestDisallowedByPolicy error already names the offending policy, so prefer the steps above.

Step-by-Step Resolution

1. Read the policy IDs from the error. Copy policyAssignmentName and policyDefinitionId from the additionalInfo block. They are the keys to everything that follows.

2. Inspect the deny condition. Run az policy definition show (command 3 above) and read policyRule.if. This tells you the exact field and value being checked, for example field: 'Microsoft.Storage/storageAccounts/allowBlobPublicAccess' equals true → effect: deny.

3. Make the resource compliant — the preferred fix. Adjust whatever the rule checks:

   • Wrong region → redeploy to an allowed location.
   • Missing tag → add --tags CostCenter=1234 Environment=prod.
   • Disallowed SKU → choose an approved SKU.
   • Public access → set --allow-blob-public-access false or --public-network-access Disabled.
   • Encryption/TLS → set --min-tls-version TLS1_2 or supply the required key.

4. Validate before deploying again with what-if. For ARM/Bicep, az deployment group what-if evaluates the change against assigned policies and surfaces a policy block before you commit:

   az deployment group what-if \
     --resource-group rg-demo \
     --template-file storage.bicep

5. If the resource legitimately must violate the policy, request an exemption. Exemptions are auditable and scoped, and require Microsoft.Authorization/policyExemptions/write:

   az policy exemption create \
     --name exempt-legacy-storage \
     --policy-assignment "/subscriptions/$SUB_ID/providers/Microsoft.Authorization/policyAssignments/deny-public-blob" \
     --exemption-category Waiver \
     --scope "/subscriptions/$SUB_ID/resourceGroups/rg-demo" \
     --description "Approved waiver INC-4821, expires Q3" \
     --expires-on 2026-09-30T00:00:00Z

6. Or adjust the assignment scope if the policy was assigned too broadly — narrow the management-group/subscription scope or add a notScopes exclusion. Do this through your governance change process, not ad hoc.

For a deeper walkthrough of building guardrails that warn before they block, see our Azure governance guides.

Prevention and Best Practices

• Run what-if (or az deployment ... validate) in CI so policy denials fail the pipeline early, not at apply time.
• Start new policies as audit or Audit if not exists, review the non-compliant inventory, then flip to deny once teams have remediated.
• Publish the assigned policy set so engineers know the allowed regions, SKUs, and required tags up front and bake them into templates.
• Template the compliant defaults (allowed location, minimumTlsVersion, tags) into Bicep modules so every deployment is compliant by construction.
• Use scoped, time-boxed exemptions with --expires-on and a ticket reference instead of weakening the policy for everyone.

Related Errors

• AuthorizationFailed — RBAC, not Policy. The identity lacks a role assignment for the action over the scope. RequestDisallowedByPolicy means you are allowed to act but the request shape is non-compliant.
• InvalidTemplateDeployment — A wrapper error; the inner details array frequently contains a RequestDisallowedByPolicy entry, so always read the nested error.
• PolicyViolation — The type value inside the additionalInfo block of a policy deny; it carries the assignment and definition IDs.
• DisallowedByPolicy — A close variant emitted by some resource providers for the same underlying cause: a deny policy matched the request.
• ResourceModificationConflict — A concurrency error from simultaneous writes to the same resource, unrelated to Policy; do not confuse it with a deny.

Frequently Asked Questions

What is the difference between a deny and an audit policy? A deny effect blocks the create/update request at the control plane and returns RequestDisallowedByPolicy. An audit effect lets the deployment succeed but records the resource as non-compliant in the compliance dashboard. Audit is for visibility; deny is for enforcement.

I am the subscription Owner — why am I still blocked? Because Azure Policy is evaluated independently of RBAC. Owner grants you permission to attempt the action, but a deny policy rejects the request based on its contents. No RBAC role bypasses a deny effect; you must make the resource compliant or create a policy exemption.

A policy was just added — how long until it takes effect, and how long to clear? New and updated deny assignments are typically enforced on new requests within about 30 minutes of assignment. Compliance reporting for existing resources is separate and can lag several hours; trigger an on-demand scan if you need fresh state sooner. The deny itself applies to your next deployment, not retroactively to already-provisioned resources.

The error names a policy set, not a single policy — where do I look? Use the policySetDefinitionId and policyDefinitionReferenceId from the error to identify the specific rule inside the initiative, then run az policy definition show on the referenced definition to read its deny condition.