--- cuppy_hub: azure cuppy_path: reference/networking/errors.md cuppy_section: docs cuppy_doc: MF9F-Q83R cuppy_doc_uuid: 424611b4-6c46-4641-a548-8ddf61e1ea52 cuppy_permalink: https://cuppy.io/azure/d/MF9F-Q83R cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/azure/docs/reference/networking/errors cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 8e759d98524b6b02e84600c2e154c109d9f2e0a56c6fcef732d532196f4e9e82 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # Networking errors Network **deployment** errors come back from Resource Manager (`reference/arm/errors.md` for the wrapper and `AuthorizationFailed` in general). Network **connectivity** failures usually aren't errors at all, but timeouts: follow `guides/networking/diagnose-connectivity.md`. ## Subnets and delegation | Code / message | Cause → fix | Check | |---|---|---| | `InUseSubnetCannotBeDeleted`; `Subnet is in use and cannot be deleted.` | NICs, load balancers, private endpoints or service deployments still hold IPs in the subnet. Remove or move them, then retry | `az network vnet subnet show -g --vnet-name -n --query "{ipConfigs:ipConfigurations[].id, pe:privateEndpoints[].id, links:serviceAssociationLinks[].linkedResourceType}"` | | `SubnetHasDelegations` | The subnet is delegated and the service's resources are still there: delete them, then the delegation | `--query "delegations[].serviceName"` | | `SubnetIsDelegatedAndCannotBeUsed` | Deploying a different service (or a private endpoint) into a subnet delegated to another service. Use another subnet, or remove the delegation | Same | | `SubnetWithExternalResourcesCannotBeUsedByOtherResources` | Another service (App Service, SQL Managed Instance, Container Apps …) deployed into the subnet through a service association link | `--query "serviceAssociationLinks[].{link:link, type:linkedResourceType}"` | | `InUseNetworkInterfaceCannotBeAssociatedWithSubnet` | An orphaned NIC still has an IP configuration there: delete it | `az network nic list -g --query "[?virtualMachine==null].name"` | | `NetworkProfileCannotBeDeleted` | A Container Instances network profile still references the subnet | `az network profile list -g ` | | `SubnetHasServiceEndpoints` | Reported alongside other blockers; service endpoints alone don't block deletion | Resolve the other blockers first | Microsoft's deletion order: VMs and their NICs, private endpoints, service deployments (Container Instances, App Service, flexible servers), service association links (wait for their cleanup), service endpoints, the delegation, then the subnet. ## Peering | Symptom | Cause → fix | |---|---| | Status stays `Initiated` | Only one side exists: create the peering on the other VNet | | Status `Disconnected` | One side was deleted, or an address space changed without a sync: re-create the missing link, or `az network vnet peering sync -g --vnet-name -n ` | | Peering rejected for overlapping addresses | Peered VNets can't overlap; re-address one of them | | Peered VMs can't reach a third VNet | Peering isn't transitive (`reference/networking/vnets-subnets-and-peering.md`) | ## Private endpoint creation and permissions | Code / message | Cause → fix | |---|---| | `PrivateEndpointCreationNotAllowedAsSubnetIsDelegated` ("… cannot be created as subnet … is delegated") | Use a subnet without delegations | | `PrivateEndpointAlreadyExists` / name in use | An endpoint (or its NIC) with that name exists or a delete is still running. Wait for the delete, or use a new name; Terraform or Bicep that deletes and re-creates the same name hits this intermittently | | `MissingSubscriptionRegistration` / `NoRegisteredProviderFound` / `LocationNotAvailableForResourceType` | `Microsoft.Network` not registered, or the region doesn't offer it (`reference/arm/errors.md`) | | A message about a limit, quota or maximum number of private endpoints | About 1,000 endpoints per VNet without High Scale, or a subscription/regional cap. Count them before adding | | `AuthorizationFailed` citing `Microsoft.Network/privateEndpoints/write` | Grant Network Contributor on the endpoint's resource group | | `AuthorizationFailed` citing `Microsoft.Network/virtualNetworks/subnets/join/action` | You can read the subnet but not join it: Network Contributor (or a custom role) on the VNet | | `AuthorizationFailed` citing `Microsoft.Network/privateDnsZones/A/write` or `…/virtualNetworkLinks/write` | Private DNS Zone Contributor on the zone (and Network Contributor on the linked VNet) for the zone group | | `LinkedAuthorizationFailed` citing `*/PrivateEndpointConnectionsApproval/action` | You asked for auto-approval without approve rights on the target. Request a manual connection instead, or get the target's contributor role | | Endpoint `Succeeded` but connection `Pending` | The target owner must approve (`az network private-endpoint-connection approve --id `), signed in to the **target's** tenant. Service-managed endpoints (Front Door Premium, managed VNets) always wait for this | Role changes take 5–10 minutes; then retry. ## DNS and access through the endpoint | Symptom | Cause → fix | |---|---| | `nslookup ` from the VNet returns a **public** IP | The client VNet isn't linked to the `privatelink.` zone, the zone has no or a wrong A record, or a custom DNS server doesn't forward to 168.63.129.16 (`reference/networking/private-endpoints-and-dns.md`) | | `** server can't find : NXDOMAIN` inside the VNet only | A linked privatelink zone is authoritative but has no record for that name; add it via a zone group, or set the link's `resolutionPolicy: NxDomainRedirect`. Also check stale negative caching and AAAA lookups | | Storage 403 `This request is not authorized to perform this operation.` from inside the VNet | Usually DNS sent the call to the public endpoint while the account denies public access. Fix DNS first, then data roles (`reference/storage/access-errors.md`) | | Key Vault 403 `Public access is disabled and the request was not made from a trusted service or via an approved private link.` or `This TCP connection does not allow access to vault.azure.net on port 443` | Same pattern for Key Vault (`reference/keyvault/access-and-errors.md`) | | DNS resolves privately but connections time out | Connection `Pending` or `Rejected`, an NSG on the source subnet, a missing peering, or a web app without VNet integration and route-all. A UDR doesn't catch endpoint traffic unless network policies are enabled (`reference/networking/nsgs-and-routes.md`) | ## Deleting zones and endpoints | Symptom | Cause → fix | |---|---| | `ScopeLocked`, "cannot perform delete operation because following scope(s) are locked" | A `CanNotDelete` or `ReadOnly` lock at the resource, group or subscription. Remove it, and check that a pipeline or `DeployIfNotExists` policy doesn't re-create it | | `InUseLinkedDnsZone`, or a `virtualNetworkLinks` reference error after the links look gone | A **ghost link**: its VNet no longer exists, or it's `Failed` or `Disconnected`. Delete the link resource itself: `az network private-dns link vnet list -g -z -o table`, then `… link vnet delete` | --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 107 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/azure/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.