Cannot create Azure Managed Instance for Apache Cassandra — persistent BadRequest error claiming Cosmos DB SP lacks Network Contributor role, even though role is assigned

Govind Prasad Pandia (HCL TECHNOLOGIES) 0 Reputation points • Microsoft Employee

I am trying to create an Azure Managed Instance for Apache Cassandra cluster in East US 2 using az managed-cassandra cluster create. The operation consistently fails with:

"Please make sure that the service principal Azure Cosmos DB (Application ID: a232010e-820c-4083-83bb-3ace5fc29d0b) is assigned a role on subnet ... such as Network Contributor (Role ID: 4d97b98b-1d4f-4787-a291-c67834d212e7), that authorizes the action 'Microsoft.Network/virtualNetworks/subnets/join/action'."

What I've done:

  1. Created a new resource group, VNet, and subnet with Microsoft.DocumentDB/cassandraClusters delegation
  2. Assigned the Network Contributor role to the Azure Cosmos DB service principal at three scopes: subnet, VNet, and resource group
  3. Used both App ID and Object ID with --assignee-principal-type ServicePrincipal
  4. Used the exact Role ID (4d97b98b-1d4f-4787-a291-c67834d212e7) from the error message
  5. Verified all role assignments exist via az role assignment list
  6. Waited over 10 minutes between role assignment and cluster creation for RBAC propagation

Despite all role assignments being confirmed present, the Cassandra cluster creation continues to fail with the same error. This is in an AME corporate tenant. Multiple Activity IDs available for investigation.

Expected: Cluster creation should succeed since the Cosmos DB SP has Network Contributor on the VNet and subnet.

Actual: BadRequest error persists regardless of role assignment scope or method.

  1. SAI JAGADEESH KUDIPUDI 3,470 Reputation points • Microsoft External Staff • Moderator

    Hi Govind Prasad Pandia (HCL TECHNOLOGIES),
    Currently, due to capacity issues in the East US region,
    Could you please try using a different region and let us know the result? Also, please confirm if the issue is resolved after changing the region.
    Could you please share requested details in private message?

Sign in to comment

2 answers

  1. Dio Xavier 287K Reputation points • Volunteer Moderator

    Hello

    Welcome to the Microsoft Azure Community

    Good evening. This failure scenario commonly indicates a problem with RBAC permission propagation in the control plane of the Cassandra managed service and/or a limitation/policy applied in the corporate tenant, even if you have performed the assignments correctly.

    Validate these items:

    1. Confirm that the provider “Microsoft.DocumentDB” is properly registered in the subscription.

    2. Verify that the subnet has the correct delegation.

    3. I recommend waiting longer for RBAC propagation, 20 to 60 minutes is recommended.

    If after all assignments the system and the creation of the Cassandra cluster still report an error, the best course of action at this point is to open a support ticket with Azure with the Activity IDs for backend investigation of the Cosmos DB service authorization.

    Recommended technical reference documentation:

    https://learn.microsoft.com/en-us/azure/managed-instance-apache-cassandra/introduction

    If the answer helped solve the problem, please mark it as a Helpful Answer. This action closes the thread, indicates the correct solution, and helps others with the same question find the answer more easily. If you still need support or have new questions, feel free to use this same post.

    1. Govind Prasad Pandia (HCL TECHNOLOGIES) 0 Reputation points • Microsoft Employee

      Yes . Confirmed I have provider register with subscription and subnet has the deligation. I have enable the outbound traffic to internet to check if its blocker but still same issue.

      Microsoft.DocumentDB: Registered

      subnet has the correct delegation

      "delegations": [

      {

 "actions": [

 "Microsoft.Network/virtualNetworks/subnets/join/action"

 ],

 

 "id": "/subscriptions/subid/resourceGroups/rgname/providers/Microsoft.Network/virtualNetworks/vnetname/subnets/default/delegations/0",

 "name": "0",

 "provisioningState": "Succeeded",

 "resourceGroup": "rgname",

 "serviceName": "Microsoft.DocumentDB/cassandraClusters",

 "type": "Microsoft.Network/virtualNetworks/subnets/delegations"

}
    2. Dio Xavier 287K Reputation points • Volunteer Moderator

      Hi

      Thank you for the information. In this scenario, the error tends to indicate an effective authorization problem for the main Cosmos DB service in the Azure backend. I suggest you additionally validate:

      az role assignment list --all \

      --assignee a232010e-820c-4083-83b-3ac5fc29d0b \

      --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/subnets/<subnet>

      And then check if there are any "deny assignments":

      az role assignment list --include-inherited --all

      If the error persists, since all the main configuration has already been validated, the next most appropriate step is to open an Azure Support ticket with the Activity IDs, as the failure appears to occur in the internal authorization plane of the Managed Cassandra service.

    Sign in to comment

  2. AI answer

    The error indicates that Azure Managed Instance for Apache Cassandra cannot see the required role assignment for the Azure Cosmos DB service principal on the virtual network/subnet at deployment time. The documented, supported way to fix this is:

    1. Ensure the role assignment is exactly as required
      • Use the documented fixed values for the Cosmos DB service principal and role: 
         az role assignment create \
 --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
 --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
 --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>
      • The assignee and role values must be exactly as above. Using different IDs or a different principal will cause deployment errors.
      • The documented scope is the virtual network. Assigning at VNet scope is sufficient; additional scopes (subnet, resource group) are not required for the service to work.
    2. If the CLI-based role assignment fails or is unreliable
      • Use the Azure portal to add the role assignment instead of the CLI:
        1. Go to the target virtual network → Access control (IAM) → Add role assignment.
        2. Select the Network Contributor role.
        3. Under Assign access to, choose User, group, or service principal.
        4. Select the Azure Cosmos DB service principal.
        5. Complete Review + assign.
      • This ensures the Cosmos DB service principal has a role that allows Microsoft.Network/virtualNetworks/subnets/join/action on the VNet.
    3. Confirm network prerequisites
      • The deployment requires outbound internet access from the VNet to these Azure services:
        • Azure Storage
        • Azure Key Vault
        • Azure Virtual Machine Scale Sets
        • Azure Monitor
        • Microsoft Entra ID
        • Microsoft Defender for Cloud
      • If the corporate environment restricts internet access (firewalls, NSGs, custom routes), the deployment can fail even when RBAC is correct.
    4. If the error persists after confirming the above
      • The documentation explicitly notes that if errors occur when applying permissions with CLI, the same permission can be applied manually in the portal and that the Cosmos DB role assignment is used only for deployment.
      • Given that role assignments are present and the tenant is a corporate/managed environment, the remaining step is to open a support request with Azure Support and provide the Activity IDs from the failed deployments so the backend can be checked for:
        • RBAC propagation issues in the tenant
        • Region-specific or platform issues with the managed Cassandra service

    In summary, use the exact documented service principal and role at VNet scope (preferably via the portal), verify required outbound access from the VNet, and if the same BadRequest persists, escalate via an Azure support request with the Activity IDs for backend investigation.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer