Accidental deletion of a database server can cause major downtime and data loss. To prevent this, Azure provides a CanNotDelete lock. When applied, this lock ensures the server cannot be deleted from the Azure portal, CLI, ARM, or automation tools — while still allowing configuration updates and normal database operations. 

By default, deletion protection is not enabled. You must explicitly configure it on each instance level or at the resource group level.

Planning for Deletion Protection

When you create a new flexible server, decide whether it should be protected from accidental deletion. For production or business-critical workloads, applying deletion protection is strongly recommended.

If you already have existing instances, you can apply the lock at any time. For environments with multiple servers, consider applying the lock at the resource group level so all servers inside inherit the protection.

Permissions Required

To create or remove locks, your identity must have the following Azure RBAC permissions:

• Microsoft.Authorization/*
• Microsoft.Authorization/locks/*

The Owner and User Access Administrator roles already include these permissions. Some specialized built-in roles also grant this access. You can create a custom role with the required permissions.

Lock Inheritance

• Locks applied at parent scopes (subscription, resource group) automatically flow down to child resources.
• New resources added later also inherit the parent lock.
• The most restrictive lock in the chain always takes precedence.

Example: If a resource group has a CanNotDelete lock, none of the resources in that group (including PostgreSQL servers) can be deleted until the lock is removed.

Limitations of Deletion Protection

Applying a CanNotDelete lock prevents deletion of the server resource, but does not block:

• Stopping or restarting the server
• Scaling compute or storage
• Updating configuration parameters
• Data operations (creating, modifying, or deleting schemas/tables inside the DB)
• Deletion caused by subscription cancellation or resource group deletion (if the group itself is not locked)

Setting Deletion Protection on a new flexible server instance

Azure CLI Example:

- Define Variables

# Define Variables
RG="myResourceGroup"
PG="mypgflexserver"
LOCK="PreventDelete"

- Apply 'CanNotDelete' lock to a New or an Existing instance

az lock create \
--name $LOCK \ 
--lock-type CanNotDelete \ 
--resource-group $RG \ 
--resource-type Microsoft.DBforPostgreSQL/flexibleServers \
--resource-name $PG

- Verifying the Lock

az lock list -g $RG -o table

- Deletion Attempt (Fails)

az postgres flexible-server delete -g $RG -n $PG –-yes
## Fails because server is locked

- Updates Still Work (Succeeds)

az postgres flexible-server update -g $RG -n $PG --sku-name Standard_D4s_v3
## Works, since modification is allowed

- Removing the Lock (Cleanup)

LOCK_ID=$(az lock list -g $RG --query "[?name=='$LOCK'].id" -o tsv)
az lock delete --ids $LOCK_ID

Multi-Tool Support

Besides Azure CLI, locks can be managed using:

PowerShell

New-AzResourceLock

Python SDK

ManagementLockClient

REST API

PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/locks/{lock-name}?api-version=2016-09-01

This makes deletion protection flexible across automation frameworks.

Considerations

There are a lot of these considerations before applying Resource locks. These are documented in the Azure Resource Locks docs. Here are a few key considerations with-respect-to to Azure Database for PostgreSQL flexible server:

• Read replicas do not automatically inherit the lock from the primary flexible server. Each replica must be locked separately, or you can lock the entire resource group.
• Resource group–level locks impact all contained resources. If you apply a CanNotDelete lock at the RG level, it not only blocks server deletion but also prevents deletion of related resources such as private endpoints, firewalls, or backup vaults in that RG.
• Locks do not prevent data loss inside the server. A CanNotDelete lock protects the server resource from being deleted, but users with DB access can still drop databases, schemas, or tables. Always combine locks with proper RBAC and database-level controls.

Key Takeaways

✅ Management locks are an Azure-native safeguard for preventing accidental deletions.
✅ They work at the control plane level (Portal, CLI, ARM, REST).
✅ They don’t block SQL operations inside the database — your apps continue to run normally.
✅ For production PostgreSQL workloads, enabling CanNotDelete is a best practice to reduce risk for accidental deletion.

Conclusion

Azure Resource Manager locks provide a simple but powerful safeguard to prevent accidental deletion of Azure Database for PostgreSQL flexible server instances. By using the CanNotDelete lock, administrators can ensure that critical database servers cannot be removed through portal, CLI, ARM, or automation, while still allowing normal configuration and data operations.

Now that you’ve learned how to apply deletion protection for both new and existing flexible server instances, we recommend reviewing your organization’s governance practices and integrating ARM locks as part of your deployment standards. This small step can save hours of downtime and recovery effort in the event of accidental deletions.

For further technical details on ARM locks, see the official Microsoft Learn documentation: Lock your Azure resources to protect your infrastructure.