Cannot create Managed DevOps Pool - UnauthorizedAccessToVirtualNetwork despite correct RBAC

Question

Summary

I'm unable to create a Managed DevOps Pool (Microsoft.DevOpsInfrastructure/pools) in West Europe. Creation fails with "UnauthorizedAccessToVirtualNetwork" error despite having correct RBAC assignments on both the VNet and resource group. Both Azure Portal and Terraform (azapi provider) fail with identical errors, proving this is not a tooling issue.

Environment

• Region: West Europe
• API Version: 2024-10-19 (also tested 2025-09-20)
• Subnet: delegated to Microsoft.DevOpsInfrastructure/pools

RBAC Configuration (Verified Correct)

DevOpsInfrastructure service principal (Object ID: f7e562da-1010-4421-b809-72ee4fa196cf) has:

• Reader role on resource group
• Network Contributor role directly on VNet

Confirmed via:

az role assignment list --scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.Network/virtualNetworks/VIRTUAL_NETWORK_NAME"    

Permissions have been stable for 24+ hours.

Error details

Portal error:

{  
  "code": "ResourceDeploymentFailure",  
  "target": "/subscriptions/SUBSCRIPTION_NAME/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.DevOpsInfrastructure/pools/DEVCENTER_POOL_NAME",  
  "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
}

Terraform (azapi) error:

{   
  "status": "Failed",   
  "error": {     
    "code": "UnauthorizedAccessToVirtualNetwork",     
    "message": "DevOpsInfrastructure service principal does not have Read access to virtual network VIRTUAL_NETWORK_NAME in resource group RESOURCE_GROUP_NAME. Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again.",     
    "details": [{       
      "code": "UnauthorizedAccessToVirtualNetwork",       
      "message": "DevOpsInfrastructure service principal does not have Read access to virtual network VIRTUAL_NETWORK_NAME..."     
    }]   
  } 
}

What I've Tried

✅ Verified RBAC assignments exist and are correct (both Azure Portal and CLI)

✅ Waited 24+ hours for RBAC propagation

✅ Added 90-second time_sleep in Terraform between RBAC creation and pool creation

✅ Verified subnet delegation to Microsoft.DevOpsInfrastructure/pools

✅ Confirmed NSG rules allow necessary traffic

✅ Tested with both API versions 2024-10-19 and 2025-09-20

✅ Attempted creation via both Terraform (azapi provider) and Azure Portal

✅ Verified same region for all resources (West Europe)

Analysis

Since both Portal and Terraform fail identically, this appears to be a backend validation bug in the Microsoft.DevOpsInfrastructure resource provider. The async provisioning operation is incorrectly reporting missing permissions despite them being properly configured.The permissions ARE assigned correctly, but the backend validation logic appears to have either:

• A cache sync issue between ARM and the provisioning backendA bug in the permission validation logic
• An issue querying role assignments during async operations

Request

Can Microsoft engineering investigate the backend validation logic for Microsoft.DevOpsInfrastructure/pools? The service principal permissions are correct, but the provisioning operation consistently fails with an incorrect authorization error.

Terraform Configuration (for reference)

resource "azapi_resource" "pool" {  
  type      = "Microsoft.DevOpsInfrastructure/pools@2024-10-19"  
  name      = "DEVCENTER_POOL_NAME"  
  location  = "westeurope"  
  parent_id = "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME"  

  body = {    
    properties = {      
      maximumConcurrency = 2 
     
      organizationProfile = {        
        kind = "AzureDevOps"        
        organizations = [{          
          url = "https://dev.azure.com/DEVOPS_ORGANIZATION_NAME"        
        }]      
      }      

      agentProfile = {        
        kind = "Stateless"      
      }      

      fabricProfile = {        
        kind = "Vmss"        
        sku = { name = "Standard_B2s" }        
        images = [{          
          wellKnownImageName = "ubuntu-22.04/latest"        
        }]        
        networkProfile = {          
          subnetId = "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.Network/virtualNetworks/VIRTUAL_NETWORK_NAME/subnets/snet-runners"        
        }      
      }      

      devCenterProjectResourceId = "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.DevCenter/projects/DEVCENTER_PROJECT_NAME"    
    }  
  }  
  
  depends_on = [azurerm_role_assignment.rbac]
}

Answer 1

Hi @Mallory Brickerd ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here. I was able to reproduce this issue in my own subscription and identified the exact cause. Despite having Network Contributor directly on the VNet, the backend provisioning mechanism for the Microsoft.DevOpsInfrastructure provider is strictly validating the Reader role on the specific Virtual Network resource scope during the async creation operation.

Even if you have the Reader role inherited from the Resource Group, the validation logic often fails to detect it until explicit, direct inheritance is confirmed.

Please try below to resolve the issue and let me know in comments if it works:

1. Apply Explicit RBAC to the VNET You must assign the Reader role explicitly to the DevOpsInfrastructure Service Principal directly on the Virtual Network resource.

      # 1. Get the Service Principal Object ID
      SP_ID=$(az ad sp list --filter "displayname eq 'DevOpsInfrastructure'" --query "[0].id" -o tsv)
      
      # 2. Get the VNet Resource ID
      VNET_ID=$(az network vnet show --resource-group YOUR_RG --name YOUR_VNET --query id -o tsv)
      
      # 3. Assign Reader role directly to the VNet
      az role assignment create \
      --assignee $SP_ID \
      --role "Reader" \
      --scope $VNET_ID
   

2. Verify "Network Contributor" Ensure that the same Service Principal also has the Network Contributor role on the VNet.

      az role assignment create \
      --assignee $SP_ID \
      --role "Network Contributor" \
      --scope $VNET_ID
   

3. After applying the explicit Reader role, re-run your az mdp pool create command (or your Terraform apply). The operation should now succeed.

Answer 2

Hi Mallory Brickerd,

ur rbac setup is correct. The error is real, but the root cause is a service bug. quickest fix is to grant the roles at the resource group level or recreate the subnet. I guess it will work in yours case.

let me to know if u want an tech details what and why it happens..

rgds,

Alex