Hi all, An Azure Databricks workspace (Premium, VNet-injected, public network access disabled, Unity Catalog enabled) is stuck in "Deleting" status, and I can't remove it. What happened: I deleted the workspace with Terraform (azurerm 4.81). The delete

This indicates that Azure already considers a deletion operation to be in progress. Therefore, this is unlikely to be a Terraform azurerm 4.81 issue or an Azure CLI syntax problem. The --force-deletion request is effectively encountering the existing deletion state rather than starting a fresh deletion.

Check:

az databricks workspace show
  --resource-group <resource-group>
  --name <workspace-name>
  --query provisioningState
  -o tsv

If this continues to return Deleting, check the Azure Activity Log around the timestamp when Terraform originally initiated the deletion. Look specifically at the Microsoft.Databricks/workspaces/delete operation and capture the failure/status details and correlation ID.

I would also inspect, but not modify, the Databricks managed resource group.

Azure Databricks protects its managed resource group using a system-managed deny assignment. Directly deleting the VNet, NAT Gateway, storage account, public IP or other managed resources is therefore not a reliable way to recover a stuck workspace deletion. The managed resource group is intended to be cleaned up through the workspace lifecycle rather than dismantled manually. Microsoft Q&A documentation on Databricks managed resource groups confirms this behaviour. [learn.microsoft.com], [learn.microsoft.com]

Why --force-deletion is not fixing this particular state?

Microsoft documents --force-deletion as part of the supported workspace deletion path. However, in this case the screenshot shows that Azure rejects that command with ApplianceBeingDeleted. Repeatedly issuing the same delete through Terraform, CLI, Portal or Resource Explorer is therefore unlikely to unblock the existing operation. [learn.microsoft.com], [learn.microsoft.com]

There are also documented Microsoft Q&A cases with essentially the same symptom where the workspace remained in Deleting, --force-deletion returned ApplianceBeingDeleted, and the workspace state subsequently had to transition from Deleting to Failed before deletion could be retried successfully. [learn.microsoft.com], [learn.microsoft.com]

So, if the original ARM delete operation has clearly stopped progressing, I would avoid further Terraform applies/destroys or manual managed-resource deletion attempts. Preserve the Activity Log/correlation information and wait for the existing control-plane operation to leave Deleting. If the state changes to Failed, retry the supported workspace deletion at that point.

One other distinction is important here: Azure Databricks documents a seven-day soft-delete period after workspace deletion. That retention behaviour should not be confused with the Azure resource remaining indefinitely with its ARM provisioning state set to Deleting. [learn.microsoft.com]

Reference: Delete an Azure Databricks workspace

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution