Title: Azure Managed Instance for Apache Cassandra Deployment Failing with InternalServerError

The error ResourceDeploymentFailure with terminal state Failed is a generic deployment failure. From the provided information, the most likely causes in this scenario are missing/incorrect network permissions for the Azure Cosmos DB service principal on the virtual network, or general Azure deployment issues (including quota or regional capacity), rather than a simple name conflict.

Key checks and actions:

1. Validate required VNet permissions for Managed Instance for Apache Cassandra

Azure Managed Instance for Apache Cassandra requires that the Azure Cosmos DB service principal has a role that allows Microsoft.Network/virtualNetworks/subnets/join/action on the virtual network (or subnet scope). If this is missing or mis-scoped, deployments can fail with generic InternalServerError / ResourceDeploymentFailure.

Required role assignment (CLI example):

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>

Important points:

• assignee must be a232010e-820c-4083-83bb-3ace5fc29d0b (Azure Cosmos DB service principal).
• role must be 4d97b98b-1d4f-4787-a291-c67834d212e7 (Network Contributor built‑in role ID used in the docs).
• Scope should be the VNet (or at least the VNet that contains the subnet used for the cluster), not just the resource group.
• If the CLI command fails (for example, due to permission issues), the role can be assigned via the Azure portal:
  • Go to the VNet → Access control (IAM) → Add role assignment.
  • Select Network Contributor.
  • Under Members, select the Azure Cosmos DB service principal.

If the role was assigned only at the subnet or only at the resource group, re‑check that the scope matches the guidance above. Mis-scoped or missing permissions are a common cause of deployment failures.

2. Confirm outbound network access requirements

Deployment of Azure Managed Instance for Apache Cassandra requires internet access from the VNet/subnet. If outbound access is restricted (firewalls, NSGs, custom routes, or forced tunneling), deployment can fail with generic internal errors.

Ensure the VNet/subnet used for the cluster is not blocking outbound access to these services:

• Azure Storage
• Azure Key Vault
• Azure Virtual Machine Scale Sets
• Azure Monitor
• Microsoft Entra ID
• Microsoft Defender for Cloud

If using custom NSGs or route tables, verify that outbound rules allow required traffic and that there is no forced tunneling that blocks these services.

3. Re-validate subscription and provider state

From the context, common deployment errors include authorization and provider registration issues. Even though Microsoft.DocumentDB is registered and CassandraClusters is visible, confirm:

• The deploying identity has sufficient permissions at the subscription/resource group level (no AuthorizationFailed in the detailed deployment error).
• No other ARM error codes (such as AllocationFailed, SubscriptionNotRegistered, or quota-related errors) are present in the deployment operation details.

Use the deployment’s Operation details in the portal or CLI to check for nested error codes beyond ResourceDeploymentFailure.

4. Consider quota/region issues and retry

The context shows that some deployment failures are region-specific or quota-related and may not clearly state the region issue in the top-level error. Since deployments previously worked and started failing “today,” a transient platform or regional capacity issue is possible.

Actions:

• Retry deployment after some time in one of the previously working regions.
• If the failure persists across multiple regions and subscriptions are otherwise healthy, open an Azure support request and include the full deployment error details and correlation IDs.

5. When to contact support

If all of the following are true:

• Azure Cosmos DB service principal has the correct Network Contributor role on the VNet (as shown above).
• Outbound network access to the required Azure services is confirmed.
• No obvious RBAC or provider registration errors appear in deployment operation details.
• The issue persists across multiple regions and cluster names.

Then the failure is likely due to a backend/platform issue or a subscription-specific condition that requires direct Azure support investigation.

References:

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