Unable to delete Azure SQL Database + Server due to RBAC — how to disable network access as a workaround?

You could try to connect to the master database on the logical server and run DROP DATABASE to get ride of the database. That approach will not help you to delete the server as such, though.

If that does not work out, the normal way to go would be to find out which person(s) in your organisation who has the appropriate permissions. Particularly, there has to be someone who is the owner of the subscription.

To delete an Azure SQL logical server and its databases you need permissions that include the management-plane delete actions on those resource types. The required actions are Microsoft.Sql/servers/delete for the logical server and Microsoft.Sql/servers/databases/delete for individual databases. Built-in roles that include these actions are Owner and Contributor at the appropriate scope (subscription, resource group, or the specific resources). SQL Server Contributor also works for the server and its child databases, but more limited roles like Reader or SQL DB Contributor do not include delete. If everyone on your team is blocked, it usually means there is either no assignment of one of those roles at or above that scope, or there is a deny assignment in place (for example from Azure Blueprints or a managed application) that explicitly prevents deletion regardless of role.

If granting delete permissions is not possible, to minimize risk, you can remove all network paths and authentication access. For Azure SQL, the main control surface is firewall rules and connectivity settings. Setting “Deny public network access” on the logical server immediately blocks all public endpoints. If private endpoints exist, they must be removed or their corresponding private endpoint connections rejected, otherwise traffic can still flow internally. You can also delete or tighten all firewall rules so no IP ranges are allowed. In CLI, this looks like:

az sql server update \
  --name <server-name> \
  --resource-group <rg-name> \
  --set publicNetworkAccess=Disabled

and to remove firewall rules:

az sql server firewall-rule delete \
  --resource-group <rg-name> \
  --server <server-name> \
  --name <rule-name>

If there are private endpoints:

az network private-endpoint-connection delete \
  --id <private-endpoint-connection-id>

or reject them via the SQL server resource.

To further reduce risk, you can disable or remove Azure AD admin and SQL logins so no one can authenticate even if networking were restored. At the database level you can also pause compute if it is a serverless database, which reduces cost:

az sql db update \
  --resource-group <rg-name> \
  --server <server-name> \
  --name <db-name> \
  --compute-model Serverless \
  --auto-pause-delay 60

For provisioned tiers, there is no true “stop,” but you can scale down to the minimum service objective to limit cost:

az sql db update \
  --resource-group <rg-name> \
  --server <server-name> \
  --name <db-name> \
  --service-objective S0

If deletion is being blocked by a governance control rather than missing RBAC, you will need someone with higher privilege (subscription Owner or a management group-level administrator) to either assign a role that includes the delete actions or remove the deny assignment or lock. Resource locks are another common cause; a “CanNotDelete” lock must be removed before deletion is allowed:

az lock list --resource-group <rg-name>

az lock delete --ids <lock-id>

If none of your team has the ability to change RBAC, locks, or policies, the only path forward is escalation to whoever owns the subscription or the Entra ID tenant, since those controls override everything else.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin