Azure Container Apps environment fails during ManagedCluster initialization with UDR and Azure Firewall

Question

Azure Container Apps environment fails during ManagedCluster initialization with UDR and Azure Firewall

Stas Popov 0

An isolated Azure Container Apps workload-profile environment in West Europe failed during provisioning. It used a Consumption workload profile, a dedicated delegated subnet and a user-defined default route through Azure Firewall. The network and firewall deployment operations succeeded; the managed environment progressed from Waiting to Failed.

The provider error was ManagedEnvironmentProvisioningError. The failed activity-log event reported: "Error when initializing components on ManagedCluster". The retained records do not identify a component, failed destination or underlying cause. Application qualification never started.

We compared the reviewed configuration with Microsoft's Container Apps/Azure Firewall guidance: https://learn.microsoft.com/en-us/azure/container-apps/use-azure-firewall

The four documented general bootstrap FQDNs are present in the allow rules: mcr.microsoft.com, *.data.mcr.microsoft.com, packages.aks.azure.com and acs-mirror.azureedge.net. Registry/login and managed-identity dependencies were also included. One deliberate restriction is that the ACR Blob allowance is a pinned regional Blob hostname, rather than the documented *.blob.core.windows.net wildcard. There is no retained evidence that attributes the failure to that restriction.

A prior attempt with the same reviewed ARM bodies reached application qualification, but this does not prove the later failure was transient or service-side.

The failed temporary environment and network have since been deleted. A subsequent GET of its environment-diagnostics endpoint returned 404 ResourceGroupNotFound. We have retained the original error and activity records privately. We have not recreated the environment, broadened outbound access or retried the failed deployment.

What supported diagnostic evidence can distinguish a required outbound bootstrap dependency failure from a service-side managed-cluster initialization failure in this situation, especially after the failed environment has been deleted? We want to identify a specific cause before approving another isolated attempt or changing the egress policy.

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-08T02:48:35.26+00:00
Likely cause: this failure pattern is commonly due to one or more outbound bootstrap dependencies being blocked or not resolvable during ACA managed-cluster initialization, even when core firewall rules appear mostly correct.

Re-run in a controlled test while collecting full deployment operation details (including nested operations) and Activity Log correlation IDs.

Validate all required egress endpoints/FQDNs for ACA + managed AKS bootstrap are allowed from the delegated subnet path (DNS + firewall + UDR path).

Temporarily test with the documented broader blob allowance (*.blob.core.windows.net) to rule out ACR/artifact bootstrap fetch failures.

Verify Azure Firewall application rules, DNS proxy settings, and route table next-hop behavior are consistent for control-plane bootstrap traffic.

If repro persists after confirmed allow rules, open support with correlation IDs + UTC timestamps so the service team can separate dependency-block from service-side initialization fault.

Notes:

Deleting the failed environment removes some diagnostic endpoints, so correlation IDs and deployment operation logs are critical evidence.

The retained 404 after deletion is expected and does not identify root cause by itself.

References:

Use Azure Firewall with Azure Container Apps: https://learn.microsoft.com/azure/container-apps/use-azure-firewall

Network concepts for Azure Container Apps: https://learn.microsoft.com/azure/container-apps/networking

Troubleshoot Azure Container Apps: https://learn.microsoft.com/azure/container-apps/troubleshooting

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

1 answer

Your answer

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-08T02:48:35.26+00:00

Likely cause: this failure pattern is commonly due to one or more outbound bootstrap dependencies being blocked or not resolvable during ACA managed-cluster initialization, even when core firewall rules appear mostly correct.

Re-run in a controlled test while collecting full deployment operation details (including nested operations) and Activity Log correlation IDs.

Validate all required egress endpoints/FQDNs for ACA + managed AKS bootstrap are allowed from the delegated subnet path (DNS + firewall + UDR path).

Temporarily test with the documented broader blob allowance (*.blob.core.windows.net) to rule out ACR/artifact bootstrap fetch failures.

Verify Azure Firewall application rules, DNS proxy settings, and route table next-hop behavior are consistent for control-plane bootstrap traffic.

If repro persists after confirmed allow rules, open support with correlation IDs + UTC timestamps so the service team can separate dependency-block from service-side initialization fault.

Notes:

Deleting the failed environment removes some diagnostic endpoints, so correlation IDs and deployment operation logs are critical evidence.

The retained 404 after deletion is expected and does not identify root cause by itself.

References:

Use Azure Firewall with Azure Container Apps: https://learn.microsoft.com/azure/container-apps/use-azure-firewall

Network concepts for Azure Container Apps: https://learn.microsoft.com/azure/container-apps/networking

Troubleshoot Azure Container Apps: https://learn.microsoft.com/azure/container-apps/troubleshooting

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

Answer 1

Hi @Stas Popov

To answer your main question directly: the evidence that separates "blocked bootstrap dependency" from "platform failure" is the firewall's own deny log. The Container Apps error itself won't name the destination, but Azure Firewall records every denied flow. Since you've deleted the environment, that log is only useful on the next attempt, so it's worth setting up before you retry:

Enable structured firewall logs. On the firewall, add a diagnostic setting that sends Azure Firewall Application Rule, Network Rule and DNS proxy logs to Log Analytics in resource-specific mode.
Redeploy the environment once, unchanged. Then query the application and network rule log tables (AZFWApplicationRule and AZFWNetworkRule) for Deny actions from the Container Apps subnet's address range during the deployment window.
Read the result. If denies show up, they name the exact FQDN or IP and port the bootstrap needed, which is documented proof of a missing dependency. If there are no denies and it still fails with ManagedEnvironmentProvisioningError, you have solid evidence of a service-side problem to take to support.

On your one known deviation: Microsoft's Container Apps firewall guide lists *.blob.core.windows.net as a wildcard. Pinning a single regional Blob hostname is the most likely candidate, because platform components can pull from storage accounts other than your ACR's. If you need to keep it narrow, let the deny log tell you which extra Blob hostnames were requested rather than guessing.

Do you want to keep the Blob rule pinned for compliance reasons, or is the wildcard acceptable if the logs show it's needed?

If the deny log identifies the blocked dependency, please consider accepting it as the answer. If it shows no denies, let me know and I'll be happy to keep helping.

Reference: