The resource operation completed with terminal provisioning state 'Failed'

The resource operation completed with terminal provisioning state 'Failed'

TL;DR

Something failed during resource provisioning, and this message is the wrapper, not the cause. Pull the deployment operations to find the inner error, then fix that. The correlation ID ties the whole trail together.

The error

The resource operation completed with terminal provisioning state 'Failed'.

Fix it

1. List the deployment operations to find the real error: az deployment operation group list --resource-group [rg] --name [deployment-name]. Expected: one operation shows a failed status with an inner error code.
2. Read the inner error. Common ones: quota exceeded, invalid image reference, or a policy violation. Expected: you have a specific code to work with, like SkuNotAvailable or AllocationFailed.
3. Copy the correlation ID from the failed operation. Support and log searches key off it. Expected: you can trace the failure across activity logs.
4. Fix the inner cause (raise quota, pick an available SKU, fix the image reference) and redeploy. Expected: provisioning completes.
5. If the inner error is AllocationFailed, try another region or VM size. Expected: the new size allocates successfully.

When to use this

• An agent sees the terminal-provisioning-state message during VM creation or ARM deployment.
• A deployment fails with no useful detail at the top level.

When NOT to use this

• Template validation errors (InvalidTemplate). Those fail before provisioning starts.
• DeploymentScriptError. That names the script; this message does not.

Compatibility

• Azure Resource Manager, all resource types. The operations-list pattern is the same everywhere.

Variant phrasings

• "provisioning state 'Failed'"
• "terminal provisioning state"

Root cause

Azure reports provisioning asynchronously. The top-level message only says the operation reached a terminal failed state; the actual failure (bad SKU, quota, image, policy) is nested one level down in the deployment operations. People stare at the wrapper because the portal surfaces it first.

Edge cases

• Transient platform failures produce this too. If the inner error is vague, one redeploy is a legitimate test before deep debugging.
• Policy denials look identical at the top level. Check the inner error for policy language before blaming quota.