Conflict
Azure Conflict means ARM or a resource provider rejected an operation because the target resource is in a state, lock, or concurrent operation window that conflicts with the request.
Last reviewed: April 30, 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 Conflict Mean?
The request reached the Azure control plane, but current resource state or an overlapping operation makes the action invalid right now. The useful boundary is state and ownership: which operation is already running, which state the resource is in, what prerequisite transition is required, and whether the conflict is a broad ARM state conflict versus an ETag/version conflict.
Common Causes
- -Operation requires a different resource state, such as a VM needing to be deallocated before resize.
- -Another ARM operation is already modifying the same resource or parent scope.
- -Deployment starts the next mutation before a long-running operation reaches terminal state.
- -Resource lock, dependency, extension, or platform operation blocks the requested transition.
- -Automation retries the same request without refreshing provisioning state or Activity Log context.
How to Fix Conflict
- 1Read current provisioning state, power/runtime state, locks, and latest operation status for the target resource.
- 2Complete prerequisite transition such as stop, deallocate, detach, unlock, or wait for extension completion.
- 3Serialize mutating operations by full resource ID and parent scope.
- 4Retry only after Azure reports the previous operation terminal and the resource state satisfies the next operation.
- 5If the failure is based on stale ETags or version tokens, switch to ResourceModified-style refresh/rebase handling.
Step-by-Step Diagnosis for Conflict
- 1Capture conflict error details, correlation ID, target resource ID, current provisioning/runtime state, and deployment operation ID.
- 2Inspect Azure Activity Log and deployment operations for overlapping writes or long-running operations on the same resource.
- 3Validate operation prerequisites against provider documentation for that resource type and SKU.
- 4Check resource locks, policy effects, extension operations, detach/attach state, and parent resource transitions.
- 5Replay only after prerequisite state is explicitly verified, not after a fixed sleep interval.
Seen in Production
- -A VM resize starts while the VM is still running and the selected size requires deallocation first.
- -A scale operation and VM extension update target the same VMSS at the same time.
- -A disk detach operation is still running when the deployment tries to delete or reattach the disk.
- -A resource lock added by governance blocks a cleanup job and returns a generic conflict-shaped failure.
Resource State Prerequisite Validation
- -Map the failing action to required provisioning, runtime, and dependency states.
- -Inspect current state before retrying, especially for VM, disk, network, extension, and scale-set operations.
Operation Sequencing and Concurrency Controls
- -Correlate overlapping operations in Activity Log and deployment operation timelines.
- -Enforce single-writer orchestration for stateful resources and shared parent scopes.
Decision Shortcut: State Conflict vs Version Conflict
- -If current resource state blocks the action, stay on Azure Conflict and sequence the prerequisite transition.
- -If the resource changed since the caller read an ETag or version token, inspect ResourceModified.
- -If a policy, SKU, or platform rule blocks the action even in the correct state, inspect OperationNotAllowed.
Wrong Fix to Avoid
- -Do not blindly retry a conflict while the previous ARM operation is still running.
- -Do not remove orchestration locks to make parallel deploys faster.
- -Do not treat all Conflict responses as ETag issues; many are lifecycle or operation-order problems.
Implementation Examples
2026-04-30T21:09:33Z operation=Microsoft.Compute/virtualMachines/write
resourceId="/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/api-01"
powerState=VM running requestedAction=resize status=409 error=Conflict correlationId=7aa8f7c2-1111-4444-9999-4d8f92000000az vm get-instance-view \
--resource-group prod-rg \
--name api-01 \
--query "{power:instanceView.statuses[?starts_with(code, 'PowerState/')].displayStatus | [0], provisioning:provisioningState}"
az monitor activity-log list \
--resource-group prod-rg \
--offset 2h \
--status Failedaz vm deallocate --resource-group prod-rg --name api-01 --no-wait
until az vm get-instance-view \
--resource-group prod-rg \
--name api-01 \
--query "instanceView.statuses[?code=='PowerState/deallocated'] | length(@)" \
--output tsv | grep -q '^1$'; do
sleep 15
done
az vm resize --resource-group prod-rg --name api-01 --size Standard_D4s_v5Incident Timeline
21:08 UTC
Deployment issues a state-dependent Azure operation
Signal: Pipeline, autoscaler, or runbook sends a mutation for a resource with active lifecycle state.
Why it matters: The operation depends on current state and absence of competing writes.
21:09 UTC
Azure returns Conflict
Signal: ARM or provider reports the action cannot proceed under current state or overlapping operation.
Why it matters: The next step is state and operation-timeline inspection, not blind retry.
21:14 UTC
Prerequisite or competing operation is identified
Signal: Activity Log shows a previous operation still running, wrong runtime state, lock, or dependency transition.
Why it matters: The fix is sequencing and readiness verification.
21:27 UTC
State gate passes and mutation resumes
Signal: Previous operation is terminal and current resource state matches provider prerequisites.
Why it matters: A state-machine guard should prevent the same conflict class before API call time.
Seen in Production
VM resize attempted while VM is still running
Frequency: common
Example: Deployment fails with Conflict because operation requires VM deallocated state first.
Fix: Deallocate VM, verify state, then execute resize operation.
Two pipelines mutate same resource in parallel
Frequency: rare
Example: Concurrent extension update and scale operation collide and ARM rejects one action.
Fix: Serialize operations by resource ID and gate next action on completion signal.
Wrong Fix vs Better Fix
Fixed sleep vs state gate
Wrong fix: Sleep for 60 seconds and retry the same operation.
Better fix: Poll the relevant operation and resource state until the documented prerequisite is true.
Why this is better: Azure operation durations vary; fixed waits fail under load and waste time when state is already ready.
Parallel deploys vs resource lock
Wrong fix: Let multiple pipelines mutate the same resource ID concurrently.
Better fix: Serialize by resource ID or parent scope for stateful mutations.
Why this is better: Many Conflict responses are caused by overlapping writes, not broken payloads.
Treat as ETag vs classify conflict
Wrong fix: Refresh ETags for every Conflict response.
Better fix: Classify whether the conflict is lifecycle state, concurrent operation, lock, or version token.
Why this is better: Each conflict type has a different safe recovery path.
Debugging Tools
- -Azure Activity Log
- -Resource state inspection (portal/CLI)
- -Deployment operation timeline
- -Pipeline concurrency tracing
How to Verify the Fix
- -Re-run the blocked operation after prerequisites and verify Conflict is cleared.
- -Confirm resource reaches expected end state without additional state-conflict failures.
- -Validate Activity Log and orchestration logs show ordered, non-overlapping state transitions.
- -Run a concurrency test that proves duplicate mutations are queued or rejected before ARM calls.
How to Prevent Recurrence
- -Encode state-machine guards in deployment automation before invoking mutating operations.
- -Add lock/queue controls for operations that target the same ARM resource or parent scope.
- -Use Activity Log and deployment-operation polling rather than static sleeps.
- -Monitor conflict frequency by resource type to detect orchestration regressions early.
Pro Tip
- -maintain per-resource operation lease tokens in your orchestrator so only one state transition can run at a time for each resource ID.
Decision Support
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.