Way to lock manual addition at resource group level which was created throught terraform

Question

Way to lock manual addition at resource group level which was created throught terraform

Varma 1,620

I created Resource group and storage account in the azure cloud , i have done using terraform

someone manually delted resource group from cloud

any way to restrict deletion manually both at resource group level and at storage account level

Bharath Y P 10,180 Microsoft External Staff Moderator

Hello Varma, you can prevent manual deletion by applying Azure Resource Manager locks to both your resource group and storage account. Locks come in two flavors:

• CanNotDelete – authorized users can read and modify a resource but can’t delete it.

• ReadOnly – authorized users can only read a resource, they can’t update or delete it.

Here’s how you can put a “CanNotDelete” lock in place:

Azure CLI • Lock the resource group:


     az lock create \

       --name PreventDeleteRG \

       --lock-type CanNotDelete \

       --resource-group yourResourceGroupName

• Lock the storage account inside that group:


     az lock create \

       --name PreventDeleteStorage \

       --lock-type CanNotDelete \

       --resource-group yourResourceGroupName \

       --resource-name yourStorageAccountName \

       --resource-type Microsoft.Storage/storageAccounts

Azure PowerShell • Lock the resource group:


     New-AzResourceLock -LockName PreventDeleteRG `

       -LockLevel CanNotDelete `

       -ResourceGroupName yourResourceGroupName

• Lock the storage account:


     New-AzResourceLock -LockName PreventDeleteStorage `

       -LockLevel CanNotDelete `

       -ResourceName yourStorageAccountName `

       -ResourceType Microsoft.Storage/storageAccounts `

       -ResourceGroupName yourResourceGroupName

Terraform (using azapi_resource)


   resource "azapi_resource" "rg_lock" {

     type      = "Microsoft.Authorization/locks@2017-04-01"

     name      = "PreventDeleteRG"

     parent_id = azurerm_resource_group.rg.id

     body = {

       properties = {

         level = "CanNotDelete"

         notes = "Protect RG from manual deletion"

       }

     }

   }

   resource "azapi_resource" "sa_lock" {

     type      = "Microsoft.Authorization/locks@2017-04-01"

     name      = "PreventDeleteStorage"

     parent_id = azurerm_storage_account.sa.id

     body = {

       properties = {

         level = "CanNotDelete"

         notes = "Protect storage account from manual deletion"

       }

     }

   }

Once these locks are in place, anyone (including you!) will need to remove the lock before they can delete the resource. Only users with Microsoft.Authorization/* permissions (Owner or User Access Administrator roles) can create or delete locks, so make sure your team’s RBAC roles are tight.

“Locks applied at the resource group level automatically protect all child resources (inheritance).”
“Even subscription Owners must remove the lock before deletion.”

Reference list:

Hope that helps! If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.

Varma 1,620 Reputation points

2026-05-16T04:09:35.7733333+00:00

HI Bharat,

In my lab environment, the CanNotDelete lock prevents the Resource Group from being deleted.

What is the practical use case for this type of lock in real-world environments?

Also, instead of only preventing deletion, are there other ways to restrict users from manually modifying or accessing a Resource Group or Storage Account?

If yes, how can this be implemented?
Varma 1,620 Reputation points

2026-05-18T11:15:21.91+00:00

HI Bharat

Any update on this?
Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-05-20T19:31:12.5666667+00:00

Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

3 answers

Your answer

Varma 1,620 Reputation points

2026-05-16T04:09:35.7733333+00:00

HI Bharat,

In my lab environment, the CanNotDelete lock prevents the Resource Group from being deleted.

What is the practical use case for this type of lock in real-world environments?

Also, instead of only preventing deletion, are there other ways to restrict users from manually modifying or accessing a Resource Group or Storage Account?

If yes, how can this be implemented?
Varma 1,620 Reputation points

2026-05-18T11:15:21.91+00:00

HI Bharat

Any update on this?
Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-05-20T19:31:12.5666667+00:00

Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

Answer 1

The primary goal of a CanNotDelete lock is to prevent accidental or unauthorized deletion of critical resources, even by users with elevated permissions.

Production databases (Azure SQL, Cosmos DB, PostgreSQL) contain critical business data. A single accidental deletion (e.g., az group delete) can result in irreversible data loss. A resource lock enforces an additional safeguard before deletion.
Core networking components such as VNets, VPN Gateways, DNS Zones and ExpressRoute circuits are often shared across multiple workloads. Deleting them impacts multiple applications simultaneously. A lock ensures shared infrastructure is not accidentally removed.
Recovery Services Vaults store Backup data and Restore points. Deleting the vault can lead to permanent loss of recovery capability. A lock ensures business continuity and disaster recovery posture.
Critical services such as Azure Key Vault, Container Registry and Service Bus are dependencies for automation pipelines. Their deletion breaks deployment pipelines and platform operations. Locks ensure this foundation components remain stable.
Industries under HIPAA, PCI-DSS, SOC2, or GDPR have legal data retention requirements. A CanNotDelete lock technically enforces what policy mandates auditors love seeing it in place.

When someone does need to delete a locked resource, they must first manually remove the lock — and that action is recorded in the Azure Activity Log. This gives you a full audit trail of who unlocked what and when, which is invaluable for security and compliance reviews.

Beyond just preventing deletion, here are all the ways you can control what users can do with a Resource Group or Storage Account. Azure to restrict access, modification, and deletion, including:

Resource Locks (ReadOnly / CanNotDelete): The simplest upgrade from CanNotDelete. Nobody can change or delete anything. Freeze infrastructure during an audit window so auditors see a stable, unchanged environment.
RBAC (role-based permissions) : Assign built-in roles or create custom roles to surgically control permissions.
Azure Policy (governance enforcement): Prevents users from creating or modifying resources in a way that violates your rules. Even if a user has Contributor access, they cannot misconfigure a storage account to expose data publicly.
Network-level restrictions: Lock down the storage account so only trusted networks or IPs can reach it. Even if someone has the storage key, they cannot access data from outside your corporate network or VNet.
Authentication model hardening (disable shared keys): Removes the ability to access storage via keys or SAS tokens forces proper identity-based access.

To implement, you can refer the below reference document:

Azure Resource Locks: Lock resources to prevent changes
Azure RBAC (Role-Based Access Control): Built-in Roles Reference and Create Custom Roles
Azure Policy: Policy Definition Structure and Built-in Policy Definitions
Azure Storage Account Security: Storage Account Security Guide, Configure Network Rules and Disable Shared Key Access

Answer 2

kagiyama yutaka 3,925

I think using a CanNotDelete lock on the RG and the storage account, and restricting who can change that lock via RBAC; Terraform keeps it enforced with azurerm_management_lock.

0 comments

Answer 3

Use Azure Resource Manager locks to prevent accidental manual deletion of both the resource group and the storage account.

To protect the resource group (and all resources inside it):

In the Azure portal
- Go to the resource group.
- Under Settings, select Locks.
- Select Add.
- Give the lock a name, set Lock type to CanNotDelete, and save.
- This prevents delete operations on the resource group and its resources unless the lock is removed.

With Azure CLI

   az group lock create \
     --name "Cannot delete resource group" \
     --lock-type CanNotDelete \
     --resource-group <your-rg-name>

Requires at least Contributor on the resource group.

With PowerShell

   New-AzResourceLock -LockName LockGroup -LockLevel CanNotDelete -ResourceGroupName <your-rg-name>

To additionally protect the storage account itself:

In the Azure portal
- Go to the storage account.
- Under Settings, select Locks.
- Add a lock with type CanNotDelete.

With PowerShell

   New-AzResourceLock -LockName LockStorage -LockLevel CanNotDelete `
     -ResourceGroupName <your-rg-name> `
     -ResourceName <your-storage-account-name> `
     -ResourceType Microsoft.Storage/storageAccounts

With Azure CLI

   az lock create \
     --name LockStorage \
     --resource-group <your-rg-name> \
     --resource <your-storage-account-name> \
     --lock-type CanNotDelete \
     --resource-type Microsoft.Storage/storageAccounts

From Terraform, define these locks as separate azurerm_management_lock (or equivalent) resources targeting the resource group and the storage account so that every terraform apply ensures the locks exist. Note that users with sufficient permissions (e.g., Owner) can still remove the locks first and then delete the resources; locks mainly protect against accidental or low-privilege deletions.

References: