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 <name> 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 <rg> --vnet-name <vnet> -n <subnet> --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 <rg> --query "[?virtualMachine==null].name"`
`NetworkProfileCannotBeDeleted`	A Container Instances network profile still references the subnet	`az network profile list -g <rg>`
`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 <rg> --vnet-name <vnet> -n <peering>`
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 <connection-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 <name>` 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 <name>: 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 <rg> -z <zone> -o table`, then `… link vnet delete`