AuthorizationFailed
Azure Resource Manager returns `AuthorizationFailed` when ARM knows who the caller is, but that caller cannot perform the exact `Microsoft.*` action at the evaluated scope.
Last reviewed: April 12, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Authorization Failed Mean?
In live deployments, AuthorizationFailed is usually a scope-resolution problem, a principal mismatch, or a deny override problem rather than a generic login issue. The useful unit of analysis is the exact caller object ID, denied action, and scope string returned by ARM.
Common Causes
- -The caller has a role assignment, but it is attached at the wrong resource, resource group, subscription, or management-group scope.
- -The live principal is not the principal engineers think is calling ARM (example: wrong managed identity, service principal, or tenant context).
- -A deny assignment, Azure Policy effect, or ABAC condition overrides the apparent allow.
- -A role was granted recently, but the token or control-plane propagation state has not caught up yet.
- -The requested action is more specific than the role assumption model (example: caller can read a resource but not write role assignments or deployment operations under that scope).
How to Fix Authorization Failed
- 1Capture the denied
action, fullscope, caller object ID, correlation ID, and subscription from the ARM error payload or deployment operation details. - 2Verify the active tenant, subscription, and principal identity before editing RBAC assignments.
- 3Walk the scope ladder from resource up to resource group, subscription, and management group to find where the allow should exist.
- 4Apply the smallest valid role change at the correct scope, then retry with refreshed credentials after propagation.
Step-by-Step Diagnosis for Authorization Failed
- 1Collect the failed request ID, denied action, scope, caller object ID, and correlation ID from ARM response details.
- 2Run
az account showand confirm the active subscription and tenant match the target resource path. - 3List role assignments for the principal at the resource, resource-group, subscription, and management-group scopes that could satisfy the action.
- 4Inspect Activity Log or deployment operation details for the same correlation ID to confirm the exact control-plane action ARM attempted.
- 5Check deny assignments, policy restrictions, and ABAC conditions that can override an apparent role allow.
- 6Refresh credentials after a role change and retest the same request path instead of a different portal action.
Seen in Production
- -ARM deployment fails with
The client \"11111111-2222-3333-4444-555555555555\" with object id \"11111111-2222-3333-4444-555555555555\" does not have authorization to perform action \"Microsoft.Compute/virtualMachines/write\" over scope \"/subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/api-01\". - -Managed identity looks correct in code review, but the live app service or automation account is still using another identity object ID at runtime.
- -Role assignment exists at one resource group, while the failed deployment writes to a sibling group under the same subscription.
Scope Ladder Validation
- -Verify the required role is attached at or above the exact failing scope (example: role exists on resource group A, but deployment targets resource group B or a nested child resource).
- -Map the denied action to the least-privilege built-in or custom role that actually contains that permission before adding broad contributor access.
Principal and Token Reality Check
- -Confirm the principal identity in the error matches the live caller context (example: managed identity object ID differs from the app registration ID engineers are inspecting).
- -Refresh credentials after RBAC updates because stale Azure CLI or service tokens can continue failing after the role assignment has been created.
Wrong Fix to Avoid
- -Do not grant Owner just to bypass a scope bug; first prove whether the issue is wrong scope, wrong principal, or a deny override.
- -Do not assume successful portal login proves ARM write permission; authentication and control-plane authorization are separate checks.
Implementation Examples
{
"error": {
"code": "AuthorizationFailed",
"message": "The client '11111111-2222-3333-4444-555555555555' with object id '11111111-2222-3333-4444-555555555555' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' over scope '/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/api-01' or the scope is invalid."
}
}az account show --output table
az role assignment list \
--assignee-object-id 11111111-2222-3333-4444-555555555555 \
--scope /subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/prod-rg \
--output table
az monitor activity-log list \
--offset 1h \
--status Failed \
--query "[?contains(properties.statusMessage, 'AuthorizationFailed')]"Seen in Production
Deployment principal can read resources but cannot mutate them
Frequency: common
Example: A service principal with Reader on the subscription tries to create or update a VM and fails with AuthorizationFailed on Microsoft.Compute/virtualMachines/write.
Fix: Grant the minimum role that includes the denied action at the exact deployment scope, then retest with refreshed credentials.
Role assignment exists but at the wrong scope
Frequency: common
Example: Engineers assign Contributor on one resource group, but the deployment target lives in another resource group or subscription.
Fix: Walk the full scope string from the error payload and place the role assignment at or above that exact path.
New RBAC assignment is correct but not yet effective for the live token
Frequency: medium
Example: First deployment fails immediately after role grant, then succeeds after credential refresh and propagation time.
Fix: Add a post-assignment verification step and credential refresh to automation before retrying ARM writes.
Debugging Tools
- -Azure Activity Log
- -
az role assignment list - -
az deployment operation group listor deployment operation history - -
az account showfor active tenant and subscription context - -Policy and deny assignment inspection
How to Verify the Fix
- -Retry the same denied ARM operation and verify
AuthorizationFailedno longer appears for that action and scope. - -Confirm Activity Log or deployment operations show a successful event for the same principal and correlation path.
- -Validate least-privilege boundaries by checking that adjacent higher-risk actions are still blocked.
- -If a role was newly assigned, verify the operation succeeds only after credential refresh or propagation wait, then document that delay for the workflow.
How to Prevent Recurrence
- -Codify RBAC assignment patterns in IaC and require explicit scope review for every deployment identity.
- -Add preflight checks that validate the required ARM actions at the target scope before rollout begins.
- -Continuously audit high-risk subscriptions and resource groups for role drift, deny assignments, and policy changes.
Pro Tip
- -capture
caller + action + scope + correlationIdfrom every failed deployment and map it to the minimum role needed so future fixes do not start from scratch.
Decision Support
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.