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

Question

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.

Answer 1

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.

Answer 2

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:

• Quickstart: Create an Azure Managed Instance for Apache Cassandra cluster by using the Azure CLI
• Use the Azure portal to add Azure Cosmos DB service principal
• Quickstart: Configure a hybrid cluster with Azure Managed Instance for Apache Cassandra
• Customer-managed keys in Azure Managed Instance for Apache Cassandra