You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When deploying Azure resources, you may come across different error codes that stop or delay the deployment process. This section lists some of the most common errors along with possible causes and step-by-step resolutions.
Use these as quick reference guides to unblock your deployments.
Before deploying the resources, you may need to enable the Bring Your Own Public IP Address feature in Azure. This is required only once per subscription.
Steps:
Run the following command to register the feature: az feature register --namespace Microsoft.Network --name AllowBringYourOwnPublicIpAddress
Wait for the registration to complete. Check the status using: az feature show --namespace Microsoft.Network --name AllowBringYourOwnPublicIpAddress --query properties.state
The output should show: "Registered"
Once the feature is registered, refresh the provider: az provider register --namespace Microsoft.Network
💡 Note: Feature registration may take several minutes to complete. This needs to be done only once per Azure subscription.
Unauthorized - Operation cannot be completed without additional quota
Insufficient quota for requested operation
Check your quota usage using: az vm list-usage --location "<Location>" -o table
Deployment across different Azure AD tenants not allowed
Check tenant match: Ensure your deployment identity (user/SP) and the target resource group are in the same tenant: az account show az group show --name <RG_NAME>
Verify pipeline/service principal: If using CI/CD, confirm the service principal belongs to the same tenant and has permissions on the resource group
Avoid cross-tenant references: Make sure your Bicep doesn't reference subscriptions, resource groups, or resources in another tenant
Test minimal deployment: Deploy a simple resource to the same resource group to confirm identity and tenant are correct
Guest/external accounts: Avoid using guest users from other tenants; use native accounts or SPs in the tenant
RequestDisallowedByPolicy
Azure Policy blocking the requested operation
This typically indicates that an Azure Policy is preventing the requested action due to policy restrictions in your subscription
Subscription lacks access to specific Azure OpenAI models
This error occurs when your subscription does not have access to certain Azure OpenAI models.
Example error message: SpecialFeatureOrQuotaIdRequired: The current subscription does not have access to this model 'Format:OpenAI,Name:o3,Version:2025-04-16'.
Quotas are applied per resource group, subscriptions, accounts, and other scopes. For example, your subscription might be configured to limit the number of vCPUs for a region. If you attempt to deploy a virtual machine with more vCPUs than the permitted amount, you receive an error that the quota was exceeded.
For PowerShell, use the Get-AzVMUsage cmdlet to find virtual machine quotas: Get-AzVMUsage -Location "West US"
Based on available quota you can deploy application otherwise, you can request for more quota
InsufficientQuota
Not enough quota available in subscription
Check if you have sufficient quota available in your subscription before deployment
To verify, refer to the QuotaCheck file for details
MaxNumberOfRegionalEnvironmentsInSubExceeded
Maximum Container App Environments limit reached for region
This error occurs when you attempt to create more Azure Container App Environments than the regional quota limit allows for your subscription. Each Azure region has a specific limit on the number of Container App Environments that can be created per subscription.
Common Causes:
Deploying to regions with low quota limits (e.g., Sweden Central allows only 1 environment)
Multiple deployments without cleaning up previous environments
Exceeding the standard limit of 15 environments in most major regions
Resolution:
Delete unused environments in the target region, OR
Deploy to a different region with available capacity, OR
Requested SKU not available in selected location or zone
This error occurs when the resource SKU you've selected (such as VM size) isn't available for the target location or availability zone.
In this deployment, the jumpbox VM defaults to Standard_D2s_v5. While this size is available in most regions, certain regions or zones may not support it.
Resolution:
Check SKU availability for your target region: az vm list-skus --location <region> --size Standard_D2s --output table
Override the VM size if the default isn't available in your region: azd env set AZURE_ENV_JUMPBOX_SIZE Standard_D2s_v4
Recommended alternatives (all support accelerated networking + Premium SSD): - Standard_D2s_v4 — previous gen, identical pricing - Standard_D2as_v5 — AMD-based, similar pricing - Standard_D2s_v3 — older gen, widely available
Avoid A-series VMs (e.g., Standard_A2m_v2) — they do not support accelerated networking or Premium SSD, which are required by this deployment
Conflict - No available instances to satisfy this request
Azure App Service has insufficient capacity in the region
This error occurs when Azure App Service doesn't have enough available compute instances in the selected region to provision or scale your app.
Common Causes:
High demand in the selected region (e.g., East US, West Europe)
Specific SKUs experiencing capacity constraints (Free, Shared, or certain Premium tiers)
Multiple rapid deployments in the same region
Resolution:
Wait and Retry (15-30 minutes): azd up
Deploy to a New Resource Group (Recommended for urgent cases): <br>azd down --force --purge<br>azd up<br>
Try a Different Region: Update region in main.bicep or azure.yaml to a less congested region (e.g., westus2, centralus, northeurope)
Use a Different SKU/Tier: If using Free/Shared tier, upgrade to Basic or Standard Check SKU availability: az appservice list-locations --sku <sku-name>
Go to resource group option and search for targeted resource group
If the resource group is being deleted, you cannot use it. Create a new one or use a different resource group
DeploymentActive
Another deployment is already in progress in this resource group
This occurs when a deployment is already in progress and another deployment is triggered in the same resource group
Cancel the ongoing deployment before starting a new one
Do not initiate a new deployment until the previous one is completed
DeploymentCanceled
Deployment was canceled before completion
Check deployment history: Go to Azure Portal → Resource Group → Deployments Review the detailed error message
Identify the root cause: Dependent resource failed to deploy Validation error occurred Manual cancellation was triggered
Validate template: az deployment group validate --resource-group <rg-name> --template-file main.bicep
Check resource limits/quotas
Fix the failed dependency
Retry deployment: az deployment group create --resource-group <rg-name> --template-file main.bicep
💡 Note: DeploymentCanceled is a wrapper error — check inner errors in deployment logs
DeploymentCanceled(user.canceled)
User manually canceled the deployment
Deployment was manually canceled by the user (Portal, CLI, or pipeline)
Check deployment history and logs to confirm who/when it was canceled
If accidental, retry the deployment
For pipelines, ensure no automation or timeout is triggering cancellation
Use deployment locks or retry logic to prevent accidental cancellations
DeploymentNotFound
Deployment record not found or was deleted
This occurs when the user deletes a previous deployment along with the resource group, then redeploys the same RG with the same environment name but in a different location
Do not change the location when redeploying a deleted RG, OR
Use new names for the RG and environment during redeployment
ResourceGroupDeletionTimeout
Resource group deletion exceeded timeout limit
Some resources may be stuck deleting or have dependencies; check RG resources and status
Ensure no resource locks or Azure Policies are blocking deletion
Retry deletion via CLI/PowerShell: az group delete --name <RG_NAME> --yes --no-wait
Check Activity Log to identify failing resources
Escalate to Azure Support if deletion is stuck
Regional & Location Issues
Issue/Error Code
Description
Steps to Resolve
LocationNotAvailableForResourceType
Resource type not supported in selected region
This error occurs when you attempt to deploy a resource to a region that does not support that specific resource type or SKU.
Resolution:
Verify resource availability by region: az provider show --namespace <provider-namespace> --query "resourceTypes[?resourceType=='<resource-type>'].locations" -o table
Cannot change region for already deployed resources
This error occurs when you attempt to modify the location/region of a resource that has already been deployed. Azure resources cannot change regions after creation.
Resolution:
Option 1: Delete and Redeploy: azd down --force --purge after purge redeploy app azd up
Option 2: Create new environment with different region: azd env new <new-env-name> azd env set AZURE_LOCATION <new-region> azd up
Option 3: Keep existing deployment: Revert configuration files to use the original region
⚠️Important: Backup critical data before deleting resources.
You can request more quota, refer Quota Request Documentation
ResourceOperationFailure/ ProvisioningDisabled
Resource provisioning restricted or disabled in region
This error occurs when provisioning of a resource is restricted in the selected region. It usually happens because the service is not available in that region or provisioning has been temporarily disabled
If you need to use the same region, you can request a quota or provisioning exception. Refer Quota Request for more details
RedundancyConfigurationNotAvailableInRegion
Redundancy configuration not supported in selected region
This issue happens when you try to create a Storage Account with a redundancy configuration (e.g., Standard_GRS) that is not supported in the selected Azure region
Example: Creating a storage account with GRS in italynorth will fail with error: az storage account create -n mystorageacct123 -g myResourceGroup -l italynorth --sku Standard_GRS --kind StorageV2
To check supported SKUs for your region: az storage account list-skus -l italynorth -o table
Use a supported redundancy option (e.g., Standard_LRS) in the same region or deploy the Storage Account in a region that supports your chosen redundancy
Ensure the resource name is within the allowed length and naming rules defined for that specific resource type, you can refer Resource Naming Convention document
Workspace Name - InvalidParameter
Workspace name does not meet required format
To avoid this errors in workspace ID follow below rules:
Must start and end with an alphanumeric character (letter or number)
Allowed characters: a–z, 0–9, - (hyphen)
Cannot start or end with a hyphen -
No spaces, underscores (_), periods (.), or special characters
Must be unique within the Azure region & subscription
Length: 3–33 characters (for AML workspaces)
VaultNameNotValid
Key Vault name does not meet naming requirements
In this template Vault name will be unique everytime, but if you trying to hard code the name then please make sure below points:
Check name length - Ensure the Key Vault name is between 3 and 24 characters
Validate allowed characters - The name can only contain letters (a–z, A–Z) and numbers (0–9). Hyphens are allowed, but not at the beginning or end, and not consecutive (--)
Ensure proper start and end - The name must start with a letter. The name must end with a letter or digit (not a hyphen)
Test with a new name - Example of a valid vault name: ✅ cartersaikeyvault1, ✅ securevaultdemo, ✅ kv-project123
BadRequest: Dns record under zone Document is already taken
DNS record name already in use
This error can occur only when user hardcoding the CosmosDB Service name. To avoid this you can try few below suggestions:
Verify resource names are globally unique
If you already created an account/resource with same name in another subscription or resource group, check and delete it before reusing the name
By default in this template we are using unique prefix with every resource/account name to avoid this kind for errors
Resource Identification & References
Issue/Error Code
Description
Steps to Resolve
LinkedInvalidPropertyId/ ResourceNotFound/ DeploymentOutputEvaluationFailed/ CanNotRestoreANonExistingResource/ The language expression property array index is out of bounds
Invalid or non-existent resource ID reference
Before using any resource ID, ensure it follows the correct format
Verify that the resource ID you are passing actually exists
Make sure there are no typos in the resource ID
Verify that the provisioning state of the existing resource is Succeeded by running the following command to avoid this error while deployment or restoring the resource: az resource show --ids <Resource ID> --query "properties.provisioningState"
You may encounter the error The language expression property array index '8' is out of bounds if the resource ID is incomplete. Please ensure your resource ID is correct and contains all required information, as shown in sample resource IDs
This error occurs when the principal ID (Service Principal, User, or Group) specified in a role assignment or deployment does not exist in the Azure Active Directory tenant. It can also happen due to replication delays right after creating a new principal.
Example causes:
The specified Object ID is invalid or belongs to another tenant
The principal was recently created but Azure AD has not yet replicated it
Attempting to assign a role to a non-existing or deleted Service Principal/User/Group
How to fix:
Verify that the principal ID is correct and exists in the same directory/tenant: az ad sp show --id <object-id>
If the principal was just created, wait a few minutes and retry
Explicitly set the principalType property (ServicePrincipal, User, or Group) in your ARM/Bicep template to avoid replication delays
If the principal does not exist, create it again before assigning roles
Referenced SQL Server does not exist in subscription
This issue happens when you try to reference an Azure SQL Server (Microsoft.Sql/servers) that does not exist in the selected subscription.
It can occur if:
The SQL server name is typed incorrectly
The SQL server was deleted but is still being referenced
You are working in the wrong subscription context
The server exists in a different subscription/tenant where you don't have access
Reproduce: Run an Azure CLI command with a non-existent server name: az sql db list --server sql-doesnotexist --resource-group myResourceGroup or az sql server show --name sql-caqfrhxr4i3hyj --resource-group myResourceGroup
Resolution:
Verify the SQL Server name exists in your subscription: az sql server list --output table
Make sure you are targeting the correct subscription: az account show az account set --subscription <subscription-id>
If the server was deleted, either restore it (if possible) or update references to use a valid existing server
Network & Infrastructure Configuration
Issue/Error Code
Description
Steps to Resolve
NetcfgSubnetRangeOutsideVnet
Subnet IP range outside virtual network address space
Ensure the subnet's IP address range falls within the virtual network's address space
Always validate that the subnet CIDR block is a subset of the VNet range
For Azure Bastion, the AzureBastionSubnet must be at least /27
Confirm that the AzureBastionSubnet is deployed inside the VNet
DisableExport_PublicNetworkAccessMustBeDisabled
Public network access must be disabled when export is disabled
Check container source: Confirm whether the deployment is using a Docker image or Azure Container Registry (ACR)
Verify ACR configuration: If ACR is included, review its settings to ensure they comply with Azure requirements
Check export settings: If export is disabled in ACR, make sure public network access is also disabled
Redeploy after fix: Correct the configuration and redeploy. This will prevent the Conflict error during deployment
Conflict - Cannot use the SKU Basic with File Change Audit for site
File Change Audit not supported on Basic SKU
This error happens because File Change Audit logs aren't supported on Basic SKU App Service Plans
Upgrading to Premium/Isolated SKU (supports File Change Audit), or
Disabling File Change Audit in Diagnostic Settings if you must stay on Basic
Always cross-check the supported log types before adding diagnostic logs to your Bicep templates
AccountPropertyCannotBeUpdated
Read-only property cannot be modified after creation
The property isHnsEnabled (Hierarchical Namespace for Data Lake Gen2) is read-only and can only be set during storage account creation. Once a storage account is created, this property cannot be updated. Trying to update it via ARM template, Bicep, CLI, or Portal will fail.
Resolution:
Create a new storage account with isHnsEnabled=true if you require hierarchical namespace
Cannot provision service because deletion is still in progress
This error occurs when you attempt to create an Azure Search service with the same name as one that is currently being deleted. Azure Search services have a soft-delete period during which the service name remains reserved.
Common causes:
Deleting a Search service and immediately trying to recreate it with the same name
Rapid redeployments using the same service name in Bicep/ARM templates
The deletion operation is asynchronous and takes several minutes to complete
Resolution:
Wait for deletion to complete (10-15 minutes) before redeploying
Use a different service name - append timestamp or unique identifier to the name
Implement retry logic with exponential backoff as suggested in the error message
Check deletion status before recreating: az search service show --name <service-name> --resource-group <rg-name>
For Bicep deployments, ensure your naming strategy includes unique suffixes to avoid conflicts
Soft-deleted resource requires restore flag or purge
This error occurs when you try to deploy a Cognitive Services resource that was soft-deleted earlier. Azure requires you to explicitly set the restore flag to true if you want to recover the soft-deleted resource. If you don't want to restore the resource, you must purge the deleted resource first before redeploying.
Example causes:
Trying to redeploy a Cognitive Services account with the same name as a previously deleted one
The deleted resource still exists in a soft-delete retention state
How to fix:
If you want to restore → add "restore": true in your template properties
If you want a fresh deployment → purge the resource using: az cognitiveservices account purge --name <resource-name> --resource-group <resource-group> --location <location>
💡 Note: If you encounter any other issues, you can refer to the Common Deployment Errors documentation.
If the problem persists, you can also raise an bug in our CWYD Github Issues for further support.
