An Apache Spark-based analytics platform optimized for Azure.
Azure Databricks workspace and managed resource group deletion issues that remain stuck for multiple days require backend intervention from the Azure/Databricks service teams; this cannot be resolved solely from the portal, CLI, or PowerShell.
From the documented behavior:
- Deleting an Azure Databricks workspace:
- Deleting the workspace from the Azure portal should clean up most compute resources automatically.
- The managed resource group and DBFS storage/access connector can be retained depending on whether force deletion is used and whether Unity Catalog is enabled.
- If the workspace deployment or deletion fails, the workspace can remain in a failed or partially deleted state, and the managed resource group may persist.
- Soft-delete and retention behavior:
- After a workspace is deleted, it enters a soft-deleted state for 7 days before permanent deletion.
- During this period, Azure Databricks-managed metadata may be recoverable, but Azure resources (VMs, disks, networking) are cleaned up immediately.
- This retention applies to workspace metadata, not to Azure resource groups themselves.
- Force deletion options (for future or when the control plane is responsive):
- To fully remove the workspace catalog and managed resource group, use force deletion:
- Azure Portal: when deleting the workspace, select the option to delete the workspace along with its managed resource group.
- Azure PowerShell:
Remove-AzDatabricksWorkspace -ForceDeletion -Name <NameOfWorkspace> -ResourceGroupName <NameOfResourceGroup> - Azure CLI:
az databricks workspace delete --force-deletion --name <NameOfWorkspace> --resource-group <NameOfResourceGroup>
- Alternatively, delete the parent resource group with force deletion types:
- Azure CLI:
az group delete --name <NameOfResourceGroup> --force-deletion-types Microsoft.Databricks/workspaces - Azure PowerShell:
Remove-AzResourceGroup -Name <NameOfResourceGroup> -ForceDeletionType Microsoft.Databricks/workspaces -Force
- Azure CLI:
- To fully remove the workspace catalog and managed resource group, use force deletion:
- Unity Catalog retention behavior (if enabled by default):
- If Unity Catalog is auto-enabled, the default workspace catalog and its storage container are intentionally retained even after workspace deletion.
- The managed resource group is converted to a regular resource group and kept, along with the access connector and storage container.
- To completely remove this catalog and all associated data, force deletion of the workspace catalog is required as described above.
Given that the workspace and managed resource group have been stuck in deleting for 4+ days and multiple delete attempts via portal and CLI have failed, this matches a backend/control-plane issue pattern similar to other Azure resources stuck in creating/deleting states, which in practice has been resolved only by the product team from the backend.
Actionable steps based on the documented options:
- If not yet attempted with force flags, try a forced workspace deletion:
- Using Azure CLI (from a context with appropriate permissions):
az databricks workspace delete --force-deletion --name adbwaewdev --resource-group RG_WAEW_DEVELOP - Or using PowerShell:
Remove-AzDatabricksWorkspace -ForceDeletion -Name adbwaewdev -ResourceGroupName RG_WAEW_DEVELOP
- Using Azure CLI (from a context with appropriate permissions):
- If the entire parent resource group can be removed and is not needed for other resources, attempt forced RG deletion:
- Azure CLI:
az group delete --name RG_WAEW_DEVELOP --force-deletion-types Microsoft.Databricks/workspaces - Azure PowerShell:
Remove-AzResourceGroup -Name RG_WAEW_DEVELOP -ForceDeletionType Microsoft.Databricks/workspaces -Force - This is destructive and permanently removes all resources in the resource group.
- Azure CLI:
- If these forced deletion options still fail or the workspace remains stuck in Deleting, backend intervention by Azure/Databricks support is required to clear the stuck control-plane state and remove the managed resource group. This is consistent with other Azure cases where resources stuck in Creating/Deleting were ultimately resolved only by the service team.
References: