Deployment quota behavior when child resource is locked

Hi Eric Hodges,
Greetings! Welcome to Microsoft Q&A Forum. Thanks for posting you query here!
To the deployment history limit of 800 deployments per resource group, the article you mentioned indicates that if a resource group has a delete lock, deployments cannot be automatically deleted from the history, which can cause deployment failures, it doesn't explicitly state that a delete lock on a child resource (like your storage account) would prevent deployment history deletions. Based on your experience, it seems that the delete lock on the storage account might be indirectly affecting the deployment history cleanup process.

1. Protecting Your Storage Resource While Avoiding Deployment Blocks: To protect your storage resource without being blocked by the deployment history limit, you can consider the following approaches:
2. Manually Delete Old Deployments: Regularly clean up old deployments from the deployment history using the Azure CLI or PowerShell. This can help you stay below the 800-deployment limit. For example, you can use the following Azure CLI command to delete deployments older than five days, to delete all deploy

startdate=$(date +%F -d "-5days")
deployments=$(az deployment group list --resource-group exampleGroup --query "[?properties.timestamp<'$startdate'].name" --output tsv)
for deployment in $deployments
do
  az deployment group delete --resource-group exampleGroup --name $deployment
done

You can get the current count in the deployment history with the following command. This example requires a Bash environment. Use Resource Locks Strategically: Instead of a delete lock, consider using a read-only lock on your storage account. This will prevent modifications but still allow deletions if necessary. be cautious as this might impact other operations on the storage account.

Monitor Deployment History: Keep an eye on the number of deployments in your resource group. You can use the Azure CLI to get the current count:
For more information:
https://zcusa.951200.xyz/en-us/azure/azure-resource-manager/troubleshooting/deployment-quota-exceeded?tabs=azure-cli
Please let us know if you have any further queries. I’m happy to assist you further.  

  Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

@Eric Hodges Welcome to Microsoft Q&A Forum, Thank you for posting your query here!

Adding more information to the above response!

There are a lot of these considerations before applying Resource locks. These are documented in the Azure Resource Locks docs. Here are a few excerpts:

• A cannot-delete lock on a resource group prevents Azure Resource Manager from automatically deleting deployments in the history. If you reach 800 deployments in the history, your deployments will fail.

This blog provides detailed information on your requirements : https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/using-resource-locks-to-prevent-accidental-changes-in-azure/3842402

Note:

• Deployment limit per resource group: Each Azure resource group has a limit of 800 deployments in its history. 
• Lock impact: If a child resource within a resource group is locked (like a storage account), any deployment attempting to modify that resource group will fail due to the lock. 
• Lock types: Depending on the lock type ("ReadOnly" or "CanNotDelete"), you may be able to view the locked resource, but not modify or delete it

Expected Behavior with Delete Lock on Child Resource: The issue you're experiencing is related to the deployment history limit of 800 deployments in a Resource Group. According to the information, a CanNotDelete lock on a Resource Group prevents Azure Resource Manager from automatically deleting deployments in the history. However, if the lock is only on a child resource (like your storage account), it should not directly affect the deployment history of the entire Resource Group. The deployment history is managed at the Resource Group level, and locks on individual resources should not interfere with this process.

Protecting Storage Resource Without Blocking Deployments: To protect your storage resource while avoiding deployment issues, you can consider the following approaches:

• Manual Deletion of Deployment History: Regularly delete old deployments from the deployment history to stay below the 800 deployment limit. You can use the Azure CLI or PowerShell commands to delete deployments older than a certain number of days.
• Use Resource Locks Strategically: Apply the CanNotDelete lock only when necessary and remove it temporarily during deployments if needed. This way, you can ensure that the deployment history is managed without interruptions.
• Automate Deployment History Management: Set up automation scripts to periodically clean up the deployment history, ensuring that you do not hit the 800 deployment limit.

For detailed information on Limits, please refer to this article

2. To protect your Azure Storage resource without a full storage account-level soft delete, you can use Azure Resource Locks to prevent accidental deletion, while still allowing deployments by applying a "ReadOnly" lock instead of a "Delete" lock; this will prevent deletion of the storage account while still enabling modifications within it (Protects the storage account against deletion or configuration changes. Doesn't protect containers or blobs in the account from being deleted or overwritten.)

Apply an Azure Resource Manager lock to a storage account

Additional information : Recommendations for basic data protection
If you're looking for basic data protection coverage for your storage account and the data that it contains, then Microsoft recommends taking the following steps to begin with:

Overview of data protection options

• Configure an Azure Resource Manager lock on the storage account to protect the account from deletion or configuration changes. Learn more...
• Enable container soft delete for the storage account to recover a deleted container and its contents. Learn more...
• Save the state of a blob at regular intervals:
  • For Blob Storage workloads, enable blob versioning to automatically save the state of your data each time a blob is overwritten. Learn more...
    • For Azure Data Lake Storage workloads, take manual snapshots to save the state of your data at a particular point in time. Learn more...

These options, as well as other data protection options for other scenarios, are described in more detail in the following section.

For an overview of the costs involved with these features, see Summary of cost considerations.

Please let us know if you have any further queries. I’m happy to assist you further.  

  Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.