ResourceNotFound
Azure ResourceNotFound means ARM or a resource provider could not resolve the requested resource ID in the exact subscription, resource group, provider, type, and location context.
Last reviewed: April 29, 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 Resource Not Found Mean?
Azure did not find the resource identity the request targeted. The useful boundary is not just the display name: it is the full ARM ID, subscription, resource group, provider namespace, type hierarchy, parent/child path, API scope, and whether deployment outputs still match live inventory.
Common Causes
- -Pipeline is authenticated to the wrong subscription or tenant when it builds the resource ID.
- -Resource group, provider namespace, resource type, parent name, or child name is stale after a move or replacement.
- -Template output, Key Vault secret, config map, or environment variable still points to a deleted resource.
- -Child resource deployment runs before the parent resource exists or before the parent is visible to the provider.
- -Cross-scope ARM/Bicep reference omits subscription, resource group, provider, or nested type segments.
How to Fix Resource Not Found
- 1Copy the exact failing resource ID from the error or deployment operation and resolve it segment by segment.
- 2Run lookup commands in the same subscription, resource group, and provider scope as the failing request.
- 3Regenerate resource IDs from current deployment outputs or Azure inventory instead of cached strings.
- 4Fix dependency ordering for parent/child resources before retrying child updates.
- 5Retry only after the identifier, scope, and provider path are corrected or confirmed visible.
Step-by-Step Diagnosis for Resource Not Found
- 1Capture failed resource ID,
x-ms-correlation-request-id, deployment operation details, active account, tenant, subscription, and resource group. - 2Run
az resource showor a service-specificshowcommand using the exact same subscription and resource group. - 3Compare the failing ID with current deployment outputs, Terraform state, Bicep outputs, and Azure portal inventory.
- 4Inspect recent move, rename, delete, replacement, and blue/green cutover events for identifier drift.
- 5Validate parent resources and extension-resource scopes before debugging permissions or retries.
Seen in Production
- -A GitHub Actions job logs into the staging subscription, then tries to update a production resource ID.
- -A resource group migration succeeds, but application settings still reference the old resource group path.
- -A child resource such as a diagnostic setting, extension, or private endpoint connection deploys before the parent exists.
- -Terraform replaces a resource and downstream ARM templates keep using the old output value.
Full ARM ID and Scope Validation
- -Validate every ARM ID segment: subscription, resource group, provider namespace, type, parent, child, and resource name.
- -Confirm the active CLI/SDK subscription and tenant match the target resource owner before running lookups.
Deployment Output and State Drift Checks
- -Diff runtime config and template outputs against live inventory after moves, replacements, and blue/green cutovers.
- -Inspect parent-child dependency ordering for nested and extension resources.
Decision Shortcut: Missing vs Wrong Scope vs Hidden
- -If the subscription ID itself cannot be resolved or accessed, inspect SubscriptionNotFound.
- -If the resource group is missing, inspect ResourceGroupNotFound before individual resources.
- -If the resource exists but caller cannot see or modify it, inspect AuthorizationFailed alongside ResourceNotFound symptoms.
Wrong Fix to Avoid
- -Do not retry the same ARM ID repeatedly without refreshing inventory.
- -Do not patch only the resource name when the subscription, group, provider, or parent path may be wrong.
- -Do not turn this into a broad permission grant until the full resource ID has been proven correct.
Implementation Examples
2026-04-29T10:13:44Z operation=Microsoft.Network/privateEndpoints/write
resourceId="/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/old-prod-rg/providers/Microsoft.Network/privateEndpoints/api-pe"
status=404 error=ResourceNotFound correlationId=9f8a7c6d-1111-4444-9999-2f4c6d8a9000az account show --query '{name:name,subscription:id,tenant:tenantId}'
az resource show \
--ids "/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/prod-rg/providers/Microsoft.Network/privateEndpoints/api-pe" \
--query '{id:id,location:location,type:type}'STORAGE_ID=$(az deployment group show \
--resource-group prod-rg \
--name app-platform \
--query 'properties.outputs.storageAccountId.value' \
--output tsv)
az resource show --ids "$STORAGE_ID" --query '{id:id,type:type,location:location}'Incident Timeline
10:12 UTC
Deployment builds a resource reference
Signal: Pipeline, template output, Terraform state, or app config emits a full or partial ARM ID.
Why it matters: The generated ID is the source of truth Azure will try to resolve.
10:13 UTC
Azure returns ResourceNotFound
Signal: ARM or provider operation cannot find the target under the supplied subscription/resource group/provider path.
Why it matters: The next step is scope and identity reconciliation, not blind retry.
10:19 UTC
Inventory differs from runtime reference
Signal: Live resource exists under another subscription, group, parent path, or replacement ID.
Why it matters: The failure is stale reference drift or wrong execution context.
10:31 UTC
Reference source is corrected
Signal: Deployment outputs, app config, or state are refreshed and child dependencies wait for parent existence.
Why it matters: The same operation now resolves the intended resource.
Seen in Production
Pipeline runs in default subscription instead of target production subscription
Frequency: common
Example: Template reference fails with ResourceNotFound because resource exists only in another subscription.
Fix: Set explicit subscription context in pipeline before deployment execution.
Resource moved to new resource group but template still references old group
Frequency: rare
Example: Deployment update fails on reference function targeting legacy path.
Fix: Update resource IDs and resource group inputs from current inventory source of truth.
Wrong Fix vs Better Fix
Retry same ID vs refresh inventory
Wrong fix: Rerun the same deployment hoping the resource appears.
Better fix: Query live inventory in the same scope and rebuild the resource ID from current outputs.
Why this is better: ResourceNotFound is usually deterministic until the identifier or scope changes.
Name-only fix vs full ID fix
Wrong fix: Correct only the display name in a variable file.
Better fix: Validate subscription, resource group, provider namespace, type hierarchy, parent, and child name together.
Why this is better: ARM resolution depends on the complete path, not just the final resource name.
Manual portal edit vs state reconciliation
Wrong fix: Create a replacement resource manually and leave old deployment outputs unchanged.
Better fix: Import or update the source of truth so all callers receive the new ARM ID.
Why this is better: Manual fixes often create the next ResourceNotFound when dependent services keep stale IDs.
Debugging Tools
- -az account show / az account set
- -az resource show / az resource list
- -ARM deployment operation history
- -Azure portal resource inventory
- -Terraform or Bicep output/state diff
How to Verify the Fix
- -Re-run the failing ARM or provider operation and verify ResourceNotFound is no longer returned.
- -Confirm lookup commands return the resource under the expected subscription, resource group, provider, and parent scope.
- -Validate downstream deployments, app settings, identities, and diagnostic settings no longer use stale IDs.
- -Run a dependency-order test that proves child resources wait for parent resources.
How to Prevent Recurrence
- -Generate resource IDs from centralized deployment outputs rather than hard-coded strings.
- -Enforce tenant, subscription, and resource-group context checks at deployment start.
- -Snapshot environment manifests and fail deployments when runtime references drift from live inventory.
- -Add validation tests for ARM/Bicep reference functions, cross-scope IDs, and parent-child dependency ordering.
Pro Tip
- -store full ARM IDs, not just resource names, in service contracts so scope drift is visible during review.
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.