🚨 Azure Error: 'DeploymentFailed: At least one resource deployment operation failed' — Cause, Fix, and Troubleshooting Guide

Overview

DeploymentFailed is Azure Resource Manager’s outer wrapper error. It tells you a template deployment (ARM, Bicep, or the resources behind Terraform’s azurerm provider) did not complete, but it deliberately hides the real reason inside a nested details array. The literal top-level message is almost always this:

{
  "status": "Failed",
  "error": {
    "code": "DeploymentFailed",
    "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
    "details": [
      {
        "code": "Conflict",
        "message": "{\"status\":\"Failed\",\"error\":{\"code\":\"StorageAccountAlreadyTaken\",\"message\":\"The storage account named mydata is already taken.\"}}"
      }
    ]
  }
}

The outer DeploymentFailed is never actionable on its own. The fix always lives in the innermost error.code — here StorageAccountAlreadyTaken — so the whole job is to unwrap the nesting.

Symptoms

• az deployment group create (or sub/mg/tenant scope) exits non-zero with DeploymentFailed.
• The message says “At least one resource deployment operation failed” and points you to list deployment operations.
• The details payload is a JSON string escaped inside JSON, sometimes several layers deep.
• Some resources in the template were created successfully while others failed, leaving a partial deployment.

Common Root Causes

DeploymentFailed is a container, so the real causes are whatever the inner error says. The most common inner codes:

• Naming/uniqueness — StorageAccountAlreadyTaken, DnsRecordInUse, resource name collisions.
• Authorization — AuthorizationFailed, LinkedAuthorizationFailed, RequestDisallowedByPolicy.
• Quota/capacity — QuotaExceeded, SkuNotAvailable, AllocationFailed, PublicIPCountLimitReached.
• Dependencies — ParentResourceNotFound, InvalidResourceReference from a bad dependsOn or resource id.
• Concurrency — Conflict / AnotherOperationInProgress when two operations touch one resource.
• Provider/template — NoRegisteredProviderFound, InvalidTemplateDeployment, InvalidApiVersionParameter.

How to diagnose

Never stop at the top-level error. List the individual operations to find which resource failed and with what inner code:

az deployment operation group list \
  --resource-group app-rg --name <deployment-name> \
  --query "[?properties.provisioningState=='Failed'].{Resource:properties.targetResource.resourceName, Type:properties.targetResource.resourceType, Code:properties.statusMessage.error.code, Msg:properties.statusMessage.error.message}" \
  -o json

Pull the fully-unwrapped inner error for the deployment as a whole:

az deployment group show \
  --resource-group app-rg --name <deployment-name> \
  --query "properties.error" -o json

If the inner message is still an escaped JSON string, unescape it to read the true code:

az deployment group show -g app-rg -n <deployment-name> \
  --query "properties.error.details[0].message" -o tsv | python3 -m json.tool

For Terraform, the same nested error is in the plan/apply output; note the resource_id and re-query ARM with the command above for the clean version.

Fixes

The fix is dictated by the inner code — resolve that error, then re-deploy. A few worked examples:

Inner StorageAccountAlreadyTaken — pick a globally-unique name, ideally with a deterministic suffix:

param storageName string = 'data${uniqueString(resourceGroup().id)}'

Inner RequestDisallowedByPolicy — read the policy assignment named in the inner additionalInfo and bring the resource into compliance (region, SKU, tags), or request an exemption.

Inner Conflict / AnotherOperationInProgress — serialize the operations; wait for the in-flight one to finish before retrying.

Re-run the deployment once the inner cause is fixed. Prefer incremental mode (the default) so already-created resources are not disturbed:

az deployment group create \
  --resource-group app-rg --name redeploy-01 \
  --template-file main.bicep --parameters @main.parameters.json \
  --mode Incremental

Validate before deploying to catch template-level inner errors early:

az deployment group validate \
  --resource-group app-rg \
  --template-file main.bicep --parameters @main.parameters.json

What to watch out for

• Partial deployments. ARM leaves successfully-created resources in place when a later one fails; a naive retry can hit Conflict on those. Incremental mode handles this, but verify no half-configured resource is live.
• Nested-JSON-in-JSON. The real code can be two or three json.tool unwraps deep; keep unescaping until you reach a leaf error.code with no further escaped string.
• DeploymentFailed is not a root cause in tickets. Never file or triage on the outer code alone — always attach the inner resource + code.
• What-if before big changes. az deployment group what-if surfaces destructive or conflicting operations before they fail mid-run.

Related

• InvalidTemplateDeployment — the pre-flight wrapper that also nests the real error in its details.
• Conflict: another operation is in progress — a frequent inner cause of DeploymentFailed.
• RequestDisallowedByPolicy — another common inner code surfaced through the deployment wrapper.