diff --git a/docs/TroubleShootingSteps.md b/docs/TroubleShootingSteps.md
index cdafcd8b..974b77b0 100644
--- a/docs/TroubleShootingSteps.md
+++ b/docs/TroubleShootingSteps.md
@@ -58,6 +58,7 @@ Use these as quick reference guides to unblock your deployments.
| Issue/Error Code | Description | Steps to Resolve |
|-----------------|-------------|------------------|
| **InternalSubscriptionIsOverQuotaForSku/
ManagedEnvironmentProvisioningError** | Subscription quota exceeded for the requested SKU | 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 |
+| **ServiceQuotaExceeded** | Free tier service quota limit reached for Azure AI Search | This error occurs when you attempt to deploy an Azure AI Search service but have already reached the **free tier quota limit** for your subscription. Each Azure subscription is limited to **one free tier Search service**.
**Example error message:**
`ServiceQuotaExceeded: Operation would exceed 'free' tier service quota. You are using 1 out of 1 'free' tier service quota.`
**Common causes:**
- Already have a free tier Azure AI Search service in the subscription
- Previous deployment created a free tier Search service that wasn't deleted
- Attempting to deploy multiple environments with free tier Search services
**Resolution:**
- **Option 1: Delete existing free tier Search service:**
`az search service list --query "[?sku.name=='free']" -o table`
`az search service delete --name --resource-group --yes` - **Option 2: Upgrade to a paid SKU:**
Modify your Bicep/ARM template to use `basic`, `standard`, or higher SKU instead of `free` - **Option 3: Use existing Search service:**
Reference the existing free tier Search service in your deployment instead of creating a new one - **Request quota increase:**
Submit a support request with issue type 'Service and subscription limits (quota)' and quota type 'Search' via [Azure Quota Request](https://aka.ms/AddQuotaSubscription)
**Reference:**
- [Azure AI Search service limits](https://learn.microsoft.com/en-us/azure/search/search-limits-quotas-capacity)
- [Azure AI Search pricing tiers](https://learn.microsoft.com/en-us/azure/search/search-sku-tier)
|
| **InsufficientQuota** | Not enough quota available in subscription | - Check if you have sufficient quota available in your subscription before deployment
- To verify, refer to the [quota_check](../docs/quota_check.md) 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
- **Request quota increase** via [Azure Support](https://go.microsoft.com/fwlink/?linkid=2208872)
**Reference:**
- [Azure Container Apps quotas](https://learn.microsoft.com/en-us/azure/container-apps/quotas)
- [Azure subscription and service limits](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits)
|
| **SkuNotAvailable** | Requested SKU not available in selected location or zone | You receive this error in the following scenarios:
- When the resource SKU you've selected, such as VM size, isn't available for a location or zone
- If you're deploying an Azure Spot VM or Spot scale set instance, and there isn't any capacity for Azure Spot in this location. For more information, see Spot error messages
|
@@ -88,7 +89,7 @@ Use these as quick reference guides to unblock your deployments.
| **ServiceUnavailable/ResourceNotFound** | Service unavailable or restricted in selected region | - Regions are restricted to guarantee compatibility with paired regions and replica locations for data redundancy and failover scenarios based on articles [Azure regions list](https://learn.microsoft.com/en-us/azure/reliability/regions-list) and [Azure Database for MySQL Flexible Server - Azure Regions](https://learn.microsoft.com/azure/mysql/flexible-server/overview#azure-regions)
- You can request more quota, refer [Quota Request](https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/create-support-request-quota-increase) 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
- Regions are restricted to guarantee compatibility with paired regions and replica locations for data redundancy and failover scenarios based on articles [Azure regions list](https://learn.microsoft.com/en-us/azure/reliability/regions-list) and [Azure Database for MySQL Flexible Server - Azure Regions](https://learn.microsoft.com/azure/mysql/flexible-server/overview#azure-regions)
- If you need to use the same region, you can request a quota or provisioning exception. Refer [Quota Request](https://docs.microsoft.com/en-us/azure/sql-database/quota-increase-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
- For more details, refer to [Azure Storage redundancy documentation](https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy?utm_source=chatgpt.com)
|
-
+| **NoRegisteredProviderFound** | Unsupported API version for resource type in specified location | This error occurs when you attempt to deploy an Azure resource using an **API version that is not supported** for the specified resource type and location.
**Example error message:**
`NoRegisteredProviderFound: No registered resource provider found for location 'westeurope' and API version '2020-06-30' for type 'searchServices'. The supported api-versions are '2014-07-31-Preview, 2015-02-28, 2015-08-19, 2019-10-01-Preview, 2020-03-13, 2020-08-01, 2020-08-01-Preview, 2021-04-01-Preview, 2021-06-06-Preview, 2022-09-01, 2023-11-01, 2024-03-01-Preview, 2024-06-01-Preview, 2025-02-01-Preview, 2025-05-01'.`
**Common causes:**
- Using an outdated or invalid API version in Bicep/ARM templates
- Referencing an Azure Verified Module (AVM) that uses a deprecated API version
- Copy-pasting old template code with legacy API versions
- The API version was never valid (typo or incorrect version number)
**Resolution:**
- **Update the API version** in your Bicep/ARM template to a supported version listed in the error message. For example, change:
`resource searchService 'Microsoft.Search/searchServices@2020-06-30'`
to:
`resource searchService 'Microsoft.Search/searchServices@2025-05-01'` - **Check supported API versions** for a resource type:
`az provider show --namespace Microsoft.Search --query "resourceTypes[?resourceType=='searchServices'].apiVersions" -o table` - **Use the latest stable API version** when possible (avoid preview versions for production)
- **Update Azure Verified Modules (AVM)** to their latest versions if using external modules
- **Validate your template** before deployment:
`az deployment group validate --resource-group --template-file main.bicep`
**Reference:**
- [Azure Resource Manager API versions](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types)
- [Azure AI Search REST API versions](https://learn.microsoft.com/en-us/azure/search/search-api-versions)
|
--------------------------------
## Resource Naming & Validation
@@ -119,6 +120,9 @@ Use these as quick reference guides to unblock your deployments.
|-----------------|-------------|------------------|
| **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
- For more information refer [ACR Data Loss Prevention](https://learn.microsoft.com/en-us/azure/container-registry/data-loss-prevention) document
|
+| **VMSizeIsNotPermittedToEnableAcceleratedNetworking** | VM size does not support accelerated networking | This error occurs when you attempt to enable accelerated networking on a VM size that does not support it.
**How to reproduce:**
- Create or deploy a VM (e.g., via ARM/Bicep) with size `Standard_A2m_v2`
- In the network interface configuration, set `"enableAcceleratedNetworking": true`
- Submit the request → Azure throws `VMSizeIsNotPermittedToEnableAcceleratedNetworking`
**Resolution:**
- Use a supported VM size that supports accelerated networking
- Check the [Microsoft list of supported VM sizes for accelerated networking](https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview#supported-vm-instances)
- Alternatively, disable accelerated networking if the feature is not required for your workload
|
+**NetworkSecurityGroupNotCompliantForAzureBastionSubnet** / **SecurityRuleParameterContainsUnsupportedValue** | NSG rules blocking required Azure Bastion ports | This error occurs when the Network Security Group (NSG) attached to `AzureBastionSubnet` explicitly denies inbound TCP ports 443 and/or 4443, which Azure Bastion requires for management and tunneling.
**How to reproduce:**
- Deploy the template with `enablePrivateNetworking=true` so the virtualNetwork module creates `AzureBastionSubnet` and a Network Security Group that denies ports 443 and 4443
- Attempt to deploy Azure Bastion into that subnet
- During validation, Bastion detects the deny rules and fails with `NetworkSecurityGroupNotCompliantForAzureBastionSubnet`
**Resolution:**
- Allow inbound TCP 443 and 4443 on `AzureBastionSubnet` by updating or removing the NSG deny rules
- Alternatively, deploy Bastion to a subnet without restrictive NSG rules
- For more details, refer to [Azure Bastion NSG requirements](https://learn.microsoft.com/en-us/azure/bastion/bastion-nsg)
|
+| **RouteTableCannotBeAttachedForAzureBastionSubnet** | Route table attached to Azure Bastion subnet | This error occurs because Azure Bastion subnet (`AzureBastionSubnet`) has a platform restriction that prevents route tables from being attached.
**How to reproduce:**
- In `virtualNetwork.bicep`, add `attachRouteTable: true` to the `AzureBastionSubnet` configuration:
`{ name: 'AzureBastionSubnet', addressPrefixes: ['10.0.10.0/26'], attachRouteTable: true }` - Add a Route Table module to the template
- Update subnet creation to attach route table conditionally:
`routeTableResourceId: subnet.?attachRouteTable == true ? routeTable.outputs.resourceId : null` - Deploy the template → Azure throws `RouteTableCannotBeAttachedForAzureBastionSubnet`
**Resolution:**
- Remove the `attachRouteTable: true` flag from `AzureBastionSubnet` configuration
- Ensure no route table is associated with `AzureBastionSubnet`
- Route tables can only be attached to other subnets, not `AzureBastionSubnet`
- For more details, refer to [Azure Bastion subnet requirements](https://learn.microsoft.com/en-us/azure/bastion/configuration-settings#subnet)
|
---------------------------------
@@ -129,6 +133,9 @@ Use these as quick reference guides to unblock your deployments.
| **InvalidRequestContent** | Deployment contains unrecognized or missing required values | - The deployment values either include values that aren't recognized, or required values are missing. Confirm the values for your resource type
- You can refer [Invalid Request Content error](https://learn.microsoft.com/en-us/azure/azure-resource-manager/troubleshooting/common-deployment-errors#:~:text=InvalidRequestContent,Template%20reference) documentation
|
| **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](https://aka.ms/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
- Migration may be needed if you already have data
- Refer to [Storage Account Update Restrictions](https://aka.ms/storageaccountupdate) for more details
|
+| **Conflict - Local authentication is disabled** | App Configuration store has local authentication disabled but application is using local auth mode | This error occurs when your Azure App Configuration store has **local authentication disabled** (`disableLocalAuth: true`) but your application is trying to access it using **connection strings or access keys** instead of **Azure AD/Managed Identity authentication**.
**Example error message:**
`The operation cannot be performed because the configuration store is using local authentication mode and local authentication is disabled. To enable access to data plane resources while local authentication is disabled, please use pass-through authentication mode.`
**Common causes:**
- App Configuration store deployed with `disableLocalAuth: true` for security compliance
- Application code using connection strings instead of Managed Identity
- SDK client initialized with access keys rather than `DefaultAzureCredential`
**Resolution:**
- **Option 1: Update application to use Managed Identity (Recommended)**
```python
from azure.identity import DefaultAzureCredential
from azure.appconfiguration import AzureAppConfigurationClient
credential = DefaultAzureCredential()
client = AzureAppConfigurationClient(
endpoint="https://your-appconfig.azconfig.io",
credential=credential
)
``` - **Option 2: Re-enable local authentication (Not recommended for production)**
Set `disableLocalAuth: false` in your Bicep/ARM template - **Ensure proper RBAC assignment:** Verify that the Managed Identity has `App Configuration Data Reader` or `App Configuration Data Owner` role assigned
**Reference:**
- [Disable local authentication in Azure App Configuration](https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-disable-access-key-authentication)
- [Use Managed Identities to access App Configuration](https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-integrate-azure-managed-service-identity)
|
+| **PropertyChangeNotAllowed** | Immutable VM property cannot be changed after creation | This error occurs when you attempt to modify an immutable property (such as `osProfile.adminUsername`) on an existing VM.
**Cause (Azure Limitation):**
Once a VM is created, the `osProfile.adminUsername` property is immutable and cannot be changed. If you modify the VM username or password in the template and redeploy, this issue will occur.
**Resolution:**
- Delete the existing deployment and redeploy with new credentials:
`azd down --force --purge` - Set new credentials before redeployment:
`azd env set AZURE_ENV_VM_ADMIN_USERNAME "newusername"`
`azd env set AZURE_ENV_VM_ADMIN_PASSWORD "NewSecurePassword123!"` - Redeploy:
`azd up`
**Note:** Some VM properties are immutable by design. Always plan credential and configuration changes before initial deployment. |
+
----------------------------------
@@ -140,7 +147,8 @@ Use these as quick reference guides to unblock your deployments.
| **AccountProvisioningStateInvalid** | Resource used before provisioning completed | - The AccountProvisioningStateInvalid error occurs when you try to use resources while they are still in the Accepted provisioning state
- This means the deployment has not yet fully completed
- To avoid this error, wait until the provisioning state changes to Succeeded
- Only use the resources once the deployment is fully completed
|
| **BadRequest - DatabaseAccount is in a failed provisioning state because the previous attempt to create it was not successful** | Database account failed to provision previously | - This error occurs when a user attempts to redeploy a resource that previously failed to provision
- To resolve the issue, delete the failed deployment first, then start a new deployment
- For guidance on deleting a resource from a Resource Group, refer to the following link: [Delete an Azure Cosmos DB account](https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/manage-with-powershell#delete-account:~:text=%3A%24enableMultiMaster-,Delete%20an%20Azure%20Cosmos%20DB%20account,-This%20command%20deletes)
|
| **ServiceDeleting** | 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 --resource-group ` - For Bicep deployments, ensure your naming strategy includes unique suffixes to avoid conflicts
- For more details, refer to [Azure Search service limits](https://learn.microsoft.com/en-us/azure/search/search-limits-quotas-capacity)
|
-
+| **FailedIdentityOperation / ManagedEnvironmentScheduledForDelete** | Identity operation failed due to pending delete or resource conflict | This error occurs when you attempt to create or update an Azure Container Apps Managed Environment while it has a **pending delete operation** or the resource already exists in a conflicting state.
**Example error messages:**
`FailedIdentityOperation: Identity operation for resource failed with error 'Failed to perform resource identity operation. Status: 'Conflict'. Response: 'Request specified that resource is new, but resource already exists. This may be due to a pending delete operation, try again later.'`
`ManagedEnvironmentScheduledForDelete: The environment 'cae-xxx' is under deletion. Please retry the creation with new name or wait for the deletion completed.`
**Common causes:**
- Deleting a Container Apps Environment and immediately trying to recreate it with the same name
- Rapid redeployments using `azd up` without waiting for previous cleanup
- Resource group deletion in progress while attempting to redeploy
- Previous deployment failed or was canceled, leaving resources in an inconsistent state
- Concurrent deployments targeting the same resources
**Resolution:**
- **Wait for deletion to complete** (5-15 minutes) before redeploying:
`az containerapp env show --name --resource-group --query "properties.provisioningState"` - **Check environment status:** If status is `ScheduledForDelete` or `Deleting`, wait for it to complete
- **Use a new environment name:** Create a new environment with a different name or use a new resource group:
`azd env new `
`azd up` - **Force delete and wait:** If the environment is stuck, try force deletion:
`az containerapp env delete --name --resource-group --yes`
Wait for deletion to complete before redeploying - **Delete associated Container Apps first:** If the environment has apps, delete them before the environment:
`az containerapp list --environment --resource-group -o table`
`az containerapp delete --name --resource-group --yes` - **Use unique naming:** Implement timestamp or unique suffix in your naming strategy to avoid conflicts
**Reference:**
- [Azure Container Apps troubleshooting](https://learn.microsoft.com/en-us/azure/container-apps/troubleshooting)
- [Manage Container Apps environments](https://learn.microsoft.com/en-us/azure/container-apps/environment)
|
+| **BadRequest - Parent account does not provision correctly** | Parent AI Services/Cognitive Services account failed to provision | This error occurs when a **child resource** (such as an AI project, model deployment, or other dependent resource) attempts to be created on a **parent Cognitive Services/AI Services account** that has **failed to provision** or is in an incomplete state.
**Example error message:**
`Parent account does not provision correctly, please retry creating the account.`
**Common causes:**
- Parent AI Services account provisioning failed due to quota, region, or configuration issues
- Using `restore: true` flag when no soft-deleted resource exists to restore
- Network or transient errors during parent account creation
- Invalid configuration on the parent account (e.g., invalid SKU, unsupported region)
- Previous deployment of the parent account was interrupted or canceled
**Resolution:**
- **Check parent account status:**
`az cognitiveservices account show --name --resource-group --query "properties.provisioningState"` - **Delete failed parent account and redeploy:**
`az cognitiveservices account delete --name --resource-group `
Then run: `azd up` - **If using restore flag incorrectly:** Ensure `restore: false` in your Bicep template unless you specifically need to restore a soft-deleted resource
- **Check for soft-deleted resources:**
`az cognitiveservices account list-deleted` - **Purge soft-deleted resources if needed:**
`az cognitiveservices account purge --name --resource-group --location ` - **Verify quota and region availability:** Ensure you have sufficient quota and the service is available in your selected region
**Reference:**
- [Manage Cognitive Services accounts](https://learn.microsoft.com/en-us/azure/ai-services/manage-resources)
- [Recover deleted Cognitive Services resources](https://learn.microsoft.com/en-us/azure/ai-services/recover-purge-resources)
|
---------------------------------
## Miscellaneous
@@ -150,7 +158,8 @@ Use these as quick reference guides to unblock your deployments.
| **DeploymentModelNotSupported/
ServiceModelDeprecated/
InvalidResourceProperties** | Model not supported or deprecated in selected region | - The updated model may not be supported in the selected region. Please verify its availability in the [Azure AI Foundry models](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/models?tabs=global-standard%2Cstandard-chat-completions) document
|
| **FlagMustBeSetForRestore/
NameUnavailable/
CustomDomainInUse** | 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-group --location ` - For more details, refer to [Soft delete and resource restore](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/delete-resource-group?tabs=azure-powershell)
|
| **ContainerAppOperationError** | Container image build or deployment issue | - The error is likely due to an improperly built container image. For resolution steps, refer to the [Azure Container Registry (ACR) – Build & Push Guide](./ACRBuildAndPushGuide.md)
|
-
+| **LinkedAuthorizationFailed** | Service principal lacks permission to use a linked resource required for deployment | This error occurs when a service principal doesn't have permission to perform an action on a linked resource that is required for the operation (e.g., cluster creation).
**Common causes:**
- The service principal has permission on the primary resource but lacks permission on the linked scope
- Missing role assignment for operations like `Microsoft.Network/ddosProtectionPlans/join/action`
**Resolution:**
- Identify the **service principal**, **resource**, and **operation** from the error message
- Grant the service principal the required permissions on the linked resource
- Use [Assign Azure roles using the Azure portal](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal) to add the role assignment
- For more details, refer to [LinkedAuthorizationFailed error](https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/error-codes/linkedauthorizationfailed-error)
|
+| **ContainerOperationFailure** | Container image or storage resource does not exist | This error occurs when an operation fails because the **specified container resource does not exist**. This can happen with Azure Container Registry images or Azure Storage blob containers.
**Example error message:**
`ContainerOperationFailure: The specified resource does not exist. RequestId:xxxxx Time:xxxxx`
**Common causes:**
- **Invalid container image tag:** The specified image tag does not exist in the container registry
- **Non-existent container registry:** The container registry endpoint is incorrect or inaccessible
- **Missing blob container:** The storage blob container referenced by the application does not exist
- **Incorrect storage account URL:** The storage account endpoint is misconfigured
- **Permission issues:** The managed identity lacks permissions to access the container registry or storage account
**Resolution:**
- **Verify container image exists:**
`az acr repository show-tags --name --repository ` - **Check image tag in deployment:** Ensure the `imageTag` parameter matches an existing tag in the registry
- **Verify storage containers exist:**
`az storage container list --account-name --auth-mode login` - **Check role assignments:** Ensure the Container App's managed identity has `AcrPull` role on the container registry and `Storage Blob Data Contributor` role on the storage account
- **Rebuild and push container images:** If images are missing, follow the [ACR Build & Push Guide](./ACRBuildAndPushGuide.md)
- **Verify storage account URL:** Ensure `APP_STORAGE_BLOB_URL` and `APP_STORAGE_QUEUE_URL` in App Configuration point to the correct storage account
**Reference:**
- [Azure Container Registry troubleshooting](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-troubleshoot-login)
- [Azure Storage troubleshooting](https://learn.microsoft.com/en-us/azure/storage/common/storage-troubleshoot-common-errors)
|
---------------------------------
💡 Note: If you encounter any other issues, you can refer to the [Common Deployment Errors](https://learn.microsoft.com/en-us/azure/azure-resource-manager/troubleshooting/common-deployment-errors) documentation.