ACR Agent Pool creation with VNet subnet fails with generic "Deployment failed" error in managed subscription

Michael Vivet 40 Reputation points
2026-06-27T15:33:48.6633333+00:00

Summary: Creating an ACR agent pool with a VNet subnet consistently fails with a deployment error in Azure's managed subscription. Creation without a subnet succeeds, but without a subnet the agent pool uses public IPs and cannot reach a registry with publicNetworkAccess: Disabled.

Environment:

  • Azure CLI: 2.87.0
  • ACR SKU: Premium
  • Region: North Europe
  • Subnet delegation: Microsoft.ContainerInstance/containerGroups
  • Subnet has no NSG, no route table

Command:

az acr agentpool create \
    -n buildpool \
    -r <myregistry> \
    --tier S1 \
    --count 1 \
    --subnet-id <subnet-resource-id>

Error:

(Runtime failure) The status for Agent Pool buildpool is Failed.
Deployment with id '/subscriptions/<managed-subscription>/resourceGroups/ap-<registry>-buildpool-977/providers/Microsoft.Resources/deployments/<deployment-id>' failed.
CorrelationId: 95689626-2a77-4b30-951e-0c63aebe9987

Key observations:

  • Creation without --subnet-id succeeds
  • Creation with --subnet-id fails consistently
  • The deployment fails in Azure's internal managed subscription which we have no visibility into
  • Subnet is in a different resource group than the ACR but both are in the same subscription
  • The VNet is shared with a private AKS cluster (--network-plugin azure, --enable-private-cluster)

Context:

The agent pool with VNet is required because publicNetworkAccess is set to Disabled on the registry (private endpoint only). Without the subnet the agent pool uses public IPs which are blocked. networkRuleBypassAllowedForTasks=true is set but does not work when publicNetworkAccess: Disabled as confirmed by others (https://learn.microsoft.com/en-us/answers/questions/5815015).

Questions:

  • Is there a requirement that the subnet must be in the same resource group as the ACR?
  • Is a specific role assignment needed on the subnet for ACR's managed subscription to deploy into it?
  • Is this a known issue in North Europe?
Azure Container Registry
Azure Container Registry

An Azure service that provides a registry of Docker and Open Container Initiative images.

0 comments
Answer accepted by question author
Manasa Akula 775 Reputation points Microsoft External Staff Moderator
2026-07-14T01:05:00.5266667+00:00

Hello Michael Vivet,

 

I hope you are doing well.

 

I would like to share the update received from our Backend PG team regarding the issue.

 

The subnet currently being used for the ACR agent pool is delegated to Azure Container Instances (ACI) (Microsoft.ContainerInstance/containerGroups). However, Azure Container Registry (ACR) agent pools are based on Virtual Machine Scale Sets (VMSS) and therefore require a standard subnet without any delegation. Reusing an ACI-delegated subnet is the reason for the deployment failure.

 

Recommended Resolution Options:

Create a dedicated subnet for the ACR agent pool with no delegation configured (recommended). The existing Microsoft Container Registry service endpoint or private endpoint configuration can still be retained to allow the agents to access the registry.

Remove the ACI delegation from the current subnet, provided that no services are actively using it.

 

If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

Thanks.
Manasa.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Jubin Soni 160 Reputation points
    2026-06-27T23:48:26.97+00:00

    Hi @Michael Vivet , thanks for the detailed writeup, makes it much easier to dig into.

    The most likely culprit here is a missing role assignment. When ACR deploys the agent pool into its managed subscription, it needs to inject NICs into your subnet. That requires the ACR service principal (or the Microsoft.ContainerRegistry resource provider) to have Network Contributor (or at minimum Microsoft.Network/virtualNetworks/subnets/join/action) on your subnet. Without it, the deployment fails silently in the managed subscription with no useful error surfaced to you.

    I'd check and fix this first:

    # Get the ACR service principal / managed identity
az acr show -n <myregistry> --query identity

# Grant Network Contributor on the subnet to ACR's identity
az role assignment create \
  --role "Network Contributor" \
  --assignee <acr-principal-id> \
  --scope <subnet-resource-id>

    To answer your specific questions:

    The subnet does not strictly need to be in the same resource group as the ACR, but the cross-RG scenario makes the permission issue more likely to be missed since the role assignment doesn't inherit automatically.

    The VNet being shared with a private AKS cluster is worth a second look too. AKS with --network-plugin azure manages subnet IP allocations tightly and may be exhausting the available IPs or conflicting with the subnet delegation for Microsoft.ContainerInstance/containerGroups. I'd verify the subnet has enough free IPs and that the delegation isn't being overridden by AKS.

    The correlation ID 95689626-2a77-4b30-951e-0c63aebe9987 is your best asset here. Open a support ticket with that ID and ask them to trace the deployment in the managed subscription — that's the only way to get the real error since you have no visibility into it from your side.

    Please upvote and accept the answer if it helps!

    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.