Application Gateway: Failed create/update operations — Troubleshooting validation errors

Lennart Bauer 20 Reputation points
2026-09-25T13:55:33.82+00:00

Problem description

I am experiencing issues with creating, updating, and deleting my Application Gateway resource. The operations are failing, and I need assistance to identify and resolve the underlying causes.

Environment

Azure Application Gateway, resource type: Microsoft.Network/applicationGateways, region not specified in case information.

What I've already tried

I have reviewed the available case details and diagnostic information. No specific troubleshooting steps or configurations have been mentioned besides this review.

Current status

I am seeking guidance on how to interpret the error messages and logs, and what steps to take next to resolve the CRUD operation failures.

Azure Web Application Firewall
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-09-25T13:55:58.16+00:00

    Use this read-only triage flow to identify the cause of failed create, update, or delete operations on Azure Application Gateway.

    1. Identify the last failed operation.
      • In Azure portal, go to Application Gateway > Activity log.
      • Filter for:
        • Resource = the Application Gateway
        • Status = Failed
        • Time range = when the issue occurred
      • Open the most recent failed event. If there are multiple failures, start with the first failed operation because later failures can be cascading.
      • Record:
        • Operation name
        • Error code
        • Error message
        • statusMessage in Properties > JSON
      • If the failure came from an ARM deployment, retrieve the deployment error details with az deployment operation group list.
    2. Check the provisioning state and interpret it.
      • Succeeded: the issue may already be resolved or transient. If the symptom persists, continue deeper validation.
      • Failed: inspect the error details and continue based on the error code.
      • Updating for more than 30 minutes: wait up to one hour. If it is still updating after that, file an Azure support request.
    3. Branch by the error code.
      • AuthorizationFailed: the deploying identity is missing required permissions.
        • For inherited role assignments, include --include-inherited when checking permissions. Without it, inherited Owner or Contributor assignments can appear missing and lead to misdiagnosis.
        • Use the {OBJECT_ID} from the AuthorizationFailed message to verify the exact identity.
        • Required permissions depend on the operation:
          • Create/update: Microsoft.Network/applicationGateways/write, Microsoft.Network/virtualNetworks/subnets/join/action
          • Delete: Microsoft.Network/applicationGateways/delete
          • Read: Microsoft.Network/applicationGateways/read
          • Public IP assignment: Microsoft.Network/publicIPAddresses/join/action
          • Key Vault certificates: Microsoft.KeyVault/vaults/secrets/read, Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
          • Managed identity use: Microsoft.ManagedIdentity/userAssignedIdentities/read
      • ScopeLocked or OperationNotAllowed with a lock reference: a resource lock is blocking the operation.
        • Check for CanNotDelete or ReadOnly locks on the resource, resource group, subscription, or dependent resources such as public IP, VNet, or NSG.
        • CanNotDelete blocks deletion and can block some updates that require re-creation.
        • ReadOnly blocks all write operations, including deployment, scaling, updates, and deletion.
      • SubnetTooSmall or InvalidSubnet: validate the Application Gateway subnet configuration.
      • ApplicationGatewaySubnetInboundTrafficBlockedByNetworkSecurityGroup: an NSG on the Application Gateway subnet is blocking required GatewayManager inbound management traffic on ports 65200–65535 for v2.
      • ApplicationGatewaySubnetUserDefinedRouteNotAllowed: a UDR on the Application Gateway subnet has a 0.0.0.0/0 route whose next hop is not Internet.
        • Application Gateway v2 requires the default route next hop to be the internet.
        • Routing through an NVA or VPN gateway can cause deployment and health probe failures.
      • ResourceProviderNotRegistered: register or verify registration of the Microsoft.Network resource provider.
    4. Validate network dependencies if backend reachability is involved.
      • Check NSGs on both the Application Gateway subnet and backend subnet.
      • Check UDRs to ensure traffic is not redirected away from the backend.
      • Check custom DNS on the VNet. If backend pool members use FQDNs, confirm the configured DNS server resolves them correctly.
      • If backend access is blocked by NSG, UDR, or DNS, probe failures can occur and lead to 502 behavior.
    5. If Key Vault certificates are involved, validate the certificate path. For ApplicationGatewayKeyVaultSecretException or “Problem occurred while accessing and validating KeyVault Secrets associated with Application Gateway”, verify:
      • The user-assigned managed identity has Get permission on Key Vault secrets.
      • If using service endpoints, the Application Gateway VNet and subnet are explicitly allowed in Key Vault firewall and virtual network settings.
      • If using private endpoints, the privatelink.vaultcore.azure.net private DNS zone is linked to the VNet containing the gateway.
      • The private DNS zone contains a valid A record for the Key Vault private endpoint.
      • The managed identity still exists.
      • The Key Vault and certificate object are not deleted or soft-deleted.
      • The referenced secret and certificate are in Enabled state.
    6. Check for orphaned configuration references if updates or scaling fail unexpectedly.
      • Look for path map rules that reference backend pools not present in backendAddressPools.
      • Look for HTTP settings references missing from backendHttpSettingsCollection.
      • Look for routing rules referencing deleted listeners.
      • Look for redirect configurations targeting deleted listeners.
      • If any referenced resource ID returns 404, the gateway still contains a deleted external dependency reference.
    7. Check autoscale configuration if the gateway is healthy but scaling or cost is unexpected.
      • A gateway can show provisioningState: "Succeeded" and still scale beyond expectations if no maximum autoscale capacity is set.
      • Review the sku tier and autoscaleConfiguration minimum and maximum bounds.
    8. Escalate when the error is non-diagnostic.
      • If the failed event shows Internal Server Error, open a support request and provide:
        • the failed operation timestamp
        • the correlationId from the failed activity log event JSON

    This sequence gives an end-to-end way to classify the failure first, then validate the most common blockers: permissions, locks, subnet/NSG/UDR issues, provider registration, Key Vault access, deleted dependencies, and autoscale configuration.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.