• Enable purge protection on your Key Vaults
• Enable soft delete on your Key Vaults
• Enforce network rules on your Key Vaults
• Deny creation of Key Vaults in specific regions
• Enforce the use of private endpoints on your Key Vaults

You are usually very happy with these policies. But now consider the following use case: a Key Vault was deleted by mistake and you want to restore it.

It is very likely that when you try to restore it, you get an error like this:

➜  $removeKeyvault | Undo-AzKeyVaultRemoval
Undo-AzKeyVaultRemoval: Resource 'kvipbd7f00' was disallowed by policy. Policy identifiers: '[{"policyAssignment":{"name":"Deny Key Vaults without IP rules","id":"/subscriptions/subId/resourcegroups/rg-kv-iprules-lab-20260624/providers/Microsoft.Authorization/policyAssignments/assign-keyvault-ip-rule-deny"},"policyDefinition":{"name":"Key Vaults must define at least one IP rule","id":"/subscriptions/subId/providers/Microsoft.Authorization/policyDefinitions/deny-keyvault-without-ip-rules","version":"1.0.0"}}]'.

So you followed Microsoft documentation to restore your Key Vault, but it still fails because of a policy. In this case, the policy checks that at least one IP is configured in the Key Vault network rules.

To work around this issue, the simplest solution is to disable the policy that blocks the Key Vault restoration, restore the Key Vault, and then re-enable the policy. Of course, this only works if you have permissions to disable the policy, and disabling a policy can impact your governance, especially if it affects a large number of resources on a heavily used platform.

There is another solution that is less simple, but more elegant and does not require disabling the policy. It consists of recreating the Key Vault through an ARM or Bicep template. Here I will do it with ARM, but you can convert it to Bicep if you want.

Let’s start by looking at what a deleted Key Vault looks like in JSON.

{
  "Id": "/subscriptions/subId/providers/Microsoft.KeyVault/locations/westeurope/deletedVaults/kvipbd7f00",
  "DeletionDate": "2026-06-24T12:07:06Z",
  "ScheduledPurgeDate": "2026-09-22T12:07:06Z",
  "PublicNetworkAccess": null,
  "VaultUri": null,
  "TenantId": "00000000-0000-0000-0000-000000000000",
  "TenantName": null,
  "Sku": null,
  "EnabledForDeployment": false,
  "EnabledForTemplateDeployment": null,
  "EnabledForDiskEncryption": null,
  "EnableSoftDelete": null,
  "EnablePurgeProtection": true,
  "EnableRbacAuthorization": null,
  "SoftDeleteRetentionInDays": null,
  "AccessPolicies": null,
  "AccessPoliciesText": "",
  "NetworkAcls": null,
  "NetworkAclsText": "",
  "OriginalVault": null,
  "ResourceId": "/subscriptions/subId/resourceGroups/rg-kv-iprules-lab-20260624/providers/Microsoft.KeyVault/vaults/kvipbd7f00",
  "VaultName": "kvipbd7f00",
  "ResourceGroupName": null,
  "Location": "westeurope",
  "Tags": {},
  "TagsTable": null
}

As you can see, there is not much information about the deleted Key Vault. There are no networkAcls and no network rules. Clearly, a lot of information is missing to recreate the Key Vault.

This helps explain why the Key Vault is restored in public mode: that information is lost. Now, if we dig a bit into the API documentation, we find the createMode option, which allows you to create a Key Vault in “Recover” mode.

So we can create a Key Vault using the following ARM template:

{
	"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
	"contentVersion": "1.0.0.0",
	"parameters": {
		"keyVaultName": {
			"type": "string",
			"metadata": {
				"description": "Name of the Azure Key Vault to create or recover."
			}
		},
		"location": {
			"type": "string",
			"defaultValue": "[resourceGroup().location]",
			"metadata": {
				"description": "Location for the Key Vault resource."
			}
		},
		"tenantId": {
			"type": "string",
			"defaultValue": "[subscription().tenantId]",
			"metadata": {
				"description": "Azure AD tenant ID for the Key Vault."
			}
		},
		"skuName": {
			"type": "string",
			"defaultValue": "standard",
			"allowedValues": [
				"standard",
				"premium"
			],
			"metadata": {
				"description": "SKU for the Key Vault."
			}
		},
		"ipRules": {
			"type": "array",
			"defaultValue": [],
			"metadata": {
				"description": "Array of public IPv4 CIDR strings allowed to access the Key Vault (for example: 203.0.113.10/32)."
			}
		},
		"defaultAction": {
			"type": "string",
			"defaultValue": "Deny",
			"allowedValues": [
				"Allow",
				"Deny"
			],
			"metadata": {
				"description": "Default network ACL action."
			}
		},
		"bypass": {
			"type": "string",
			"defaultValue": "AzureServices",
			"allowedValues": [
				"AzureServices",
				"None"
			],
			"metadata": {
				"description": "Traffic that can bypass network ACLs."
			}
		}
	},
	"variables": {
		"ipRuleObjects": "[map(parameters('ipRules'), lambda('ip', createObject('value', lambdaVariables('ip'))))]"
	},
	"resources": [
		{
			"type": "Microsoft.KeyVault/vaults",
			"apiVersion": "2023-07-01",
			"name": "[parameters('keyVaultName')]",
			"location": "[parameters('location')]",
			"properties": {
                "createMode": "recover",
				"tenantId": "[parameters('tenantId')]",
				"sku": {
					"family": "A",
					"name": "[parameters('skuName')]"
				},
				"enabledForDeployment": false,
				"enabledForDiskEncryption": false,
				"enabledForTemplateDeployment": false,
				"publicNetworkAccess": "Enabled",
				"networkAcls": {
					"bypass": "[parameters('bypass')]",
					"defaultAction": "[parameters('defaultAction')]",
					"ipRules": "[variables('ipRuleObjects')]",
				}
			}
		}
	],
	"outputs": {
		"keyVaultResourceId": {
			"type": "string",
			"value": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
		}
	}
}

This template can be called as follows:

New-AzResourceGroupDeployment -name "recover-keyvault" -ResourceGroupName $removekeyvault.ResourceId.split('/')[4] -TemplateFile .\recover-keyvault.json -keyvaultName $removeKeyVault.VaultName  -ipRules @("1.1.1.1/32")

Almost like magic, your Key Vault is properly restored without changing policies. Of course, this template should be adapted to the policies you use.

There is no longer any excuse to disable governance in your production environments. Of course, I recommend testing this template in a test environment before using it in production, especially not as an emergency fix in the middle of the night.

Of course, there is the classic inventory needed to answer simple questions such as:

• How many VMs are currently in use, by OS and SKU?
• How many databases are currently in production?
• How many storage accounts are available?

All of these inventory questions are very easy to answer through Azure Resource Graph.

Now let’s consider the following question:

• What is the total storage capacity across all Azure Storage accounts?

Well, this is where it gets a bit more complicated, because although the metric is available, it is exposed per storage account and, by default, not aggregated.

You can find this answer by looking at each storage account and summing the results of the “Used Capacity” metric.

Otherwise, there is another way through Azure Workbook, which I will show you.

So let’s start by creating a new one (the default one does not suit me in this specific context). We’ll do it through the portal, because building a workbook via infrastructure as code is more of an epic journey than a walk in the park.

Let’s start by adding two filters for subscriptions and resources, as shown below:

For the different resource pickers, make sure to select “Required” and “Allow multiple selection” for both filters, and include the “All” field.

Then it is possible to run a Kusto query to link resources and metrics.

Let’s start by generating a list with all the values for each storage account:

To make it readable, go to the advanced settings and modify the Value field to change the format to Bytes.

And to get an aggregate of the used capacity, simply sum all values using the Stat visualization and select “Sum” in the aggregation options.

There you go! If you would like me to write more articles related to workbooks, feel free to let me know in the comments.

And of course, here is a link to the workbook I created for this use case: Github link

Why, you may ask? For compliance, performance, or latency reasons, it can be crucial to know where your Azure resources are physically located. It can also be important for capacity planning, to verify whether the relevant zones have enough resources to host your infrastructure.

This also helps you manage your CI/CD settings to ensure resources are deployed in zones where capacity is available.

For example, Azure Firewall currently has capacity constraints, as shown here: Azure Documentation

You can find which zone your subscription uses with the following command:

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

This command returns a list of all regions available for your subscription, along with the availability zone mappings for each region. You can then identify the physical zone that matches the logical zone used by your Azure resources.

If you prefer a graphical interface, I recommend App Scout, which lets you visualize different zones and their capacities in real time. It is a very practical tool for managing your Azure resources efficiently. Here is an example for the West Europe region:

A few years ago, I built an Azure Sandbox system that lets me create ephemeral resource groups. With a simple script, I could create a resource group, run my tests, and then deletion would happen automatically based on the date set in a tag. Nothing could be simpler.

Today, to do this, I mainly use a function in my PowerShell profile to create resource groups: the well-known New-AzTestResourceGroup function, which some of you may already have seen in my demos.

Now with AI, it is much faster to tell Copilot: “Create a resource group named demo-rg in France Central and add a storage account.” Great time savings, especially since it can also generate the deployment file for you. However, the resource group does not always include the right tags.

There is a very simple way to add this: just ask Copilot to add the tags you want each time you create a resource group. You can scope this to your workspace, or apply it globally by adding a file in your user directory.

Here is an example of a file you can add in your user directory so Copilot can automatically add tags whenever you create a resource group.

# Azure Resource Group Tagging Convention

## Mandatory Tags for Resource Groups
When creating Azure resource groups, always add the following tags:

- **AutoDelete**: `true`
- **ExpirationDate**: Current date in format `YYYY-MM-DD` (e.g., 2026-03-05)

## Implementation
- Apply these tags when using Bicep, Terraform, ARM templates, or Azure CLI
- Use `resourceGroup()` function in Bicep or equivalent in other IaC tools
- Set tags at resource group creation time, not as an afterthought

And the path is: C:\Users\YourUserName\AppData\Roaming\Code\User\globalStorage\github.copilot-chat\memory-tool\memories

And to finish, here is the article link for the sandbox (in french sorry): https://woivre.fr/blog/2018/11/sandbox-azure-pour-tout-le-monde

That is a small tip so you do not forget to clean up your resources after your tests.

If you have an Azure environment that is fairly standardized and spans multiple subscriptions, you may want to dismiss some recommendations or at least postpone them.

You can do this quickly with a PowerShell script (or another automation approach). To start, you can list the different recommendations with the following command:

Get-AzAdvisorRecommendation -SubscriptionId <SubscriptionId>

Then, you can filter the recommendations you want to dismiss or postpone. For example, if you want to postpone a recommendation for 90 days, you can use the following command:

Disable-AzAdvisorRecommendation -RecommendationName e33855d4-7579-e4d0-c459-23fad3665bd6 -Day 90

And if you simply want to postpone one recommendation type globally, you can use the following command:

get-azAdvisorRecommendation | Where { $_.RecommendationTypeId -eq $recommendationId } | % { $_ | Disable-AzAdvisorRecommendation -Day 120 }

Let’s make 2026 the year we manage recommendations at scale—and leave no active recommendation without a planned action!

For some time now, Microsoft has updated the boot diagnostics configuration for Azure virtual machines. From now on, you can configure boot diagnostics without creating a dedicated storage account. In other words, it is now fully managed by Microsoft.

Here is a Graph query to detect all your VMs that have not yet switched to this new boot diagnostics mode:

resources
| where type =~ "microsoft.compute/virtualMachines"
| where properties.diagnosticsProfile.bootDiagnostics.enabled == true
| where isnotnull(properties.diagnosticsProfile.bootDiagnostics.storageUri)

If this can help you avoid dedicated storage accounts for boot diagnostics, that is one less resource to manage and secure, and it simplifies the configuration of your virtual machines.

So what exactly changes for you? Well, if you’re in an enterprise with Zero Trust and hub & spoke architecture, this concretely changes nothing for you. Because the subnets in your spokes are already private by nature, since they go through your hub to access the Internet.

However, for smaller environments, you’ll need to think carefully about either making your subnets public again or explicitly enabling Internet access via a NAT Gateway, a Firewall, or a Load Balancer with an outbound rule or a static IP on your VMs.

Concretely, your route table—whether implicit or explicit—to the Internet is disabled, so you need to replace it with a direct route. The simplest solution is to set up a NAT Gateway, but be careful about the cost of this service since pricing is also based on data passing through it.

Microsoft provides examples for private subnets, I recommend you take a look: GitHub - Azure Networking Private Subnet Routing

It is very practical, I agree, and I use it regularly, but it can also be dangerous if given to people who shouldn’t have it.

Indeed, the permission on Windows runs as SYSTEM, and can therefore do anything on the virtual machine, including installing malware or stealing sensitive data, or disabling security services. And on Linux, it’s no better as it runs as sudo, and can also do anything.

And to top it off, once you have run a command, it is not possible to stop it, so do not copy commands that you do not understand, or that you have not verified, and do not run them on production machines without having tested them beforehand in a test environment.

So do not give this permission Microsoft.Compute/virtualMachines/runCommand/action to just anyone, and make sure that the people who have it are trustworthy and know what they are doing. Or give it on machines in sandboxes that do not have access to your production environments.

Previously, the answer was often something like “Sorry, it’s not possible to expand a subnet, you have to create a new one and migrate the resources or keep 2 disjoint subnets. You’ll have to specify it every time you open routes, or when you need to modify route tables”.

But now, good news: it’s possible to add a second address prefix to your subnet like this

$vnet = Get-AzVirtualNetwork -ResourceGroupName 'test-rg' -Name 'vnet-1'
Set-AzVirtualNetworkSubnetConfig -Name 'subnet-1' -VirtualNetwork $vnet -AddressPrefix '10.0.0.0/24', '10.0.1.0/24'
$vnet | Set-AzVirtualNetwork

The advantage here is that if you’re lucky enough to have contiguous subnets like in the example above, your route openings simply change from 10.0.0.0/24 to 10.0.0.0/23, which greatly simplifies your operations.

But also your scale set inside your subnet can now scale to 300 nodes without having to move your workload to a new subnet. And this is also possible for GatewaySubnet if you made the mistake of creating it as /29 just for a simple Point to Site, and now you want to do S2S VPN or ExpressRoute.

This is certainly something well known, but I still see many people forget it, or assume they will never be affected by these limitations.

So let’s start with the official Azure documentation that lists the different limits: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

These limits may seem far away compared to your current usage, but you can reach them faster than you might expect.

For example, when you set up Azure Policy bundles for each type of resource and risk, there is a limit on the number of custom definitions per scope. This can become a challenge in your governance architecture: you may need to use initiatives, create multiple scopes, or rely more on built-in policies.

Custom role definitions also have a tenant-level limit. So you cannot let all your users create custom roles without control, otherwise you may hit that limit sooner than expected and lose governance over the existing roles.

For heavy Azure API Management users, be aware that there are limits on the number of operations per instance. This count also includes operations present in revisions. By default, the service does not provide a simple metric to check whether you are close to that limit, so you must calculate it yourself and properly manage unused revisions and obsolete APIs.

The same applies to Azure Firewall: there are limits on how many rules you can create. A rule is roughly counted as 1 source, 1 destination, and 1 port. So if you add the rule Allow TCP 9093 from 10.0.0.0/24 and 10.0.1.0/24 to 10.1.0.0/24, it counts as 2 rules. To reduce this, you can use IP groups or open access more broadly when possible. But managing these rules can quickly become a challenge, especially if multiple teams manage the firewall.

My advice is this: for every new service you enable on your platform, or every new feature you offer as self-service to your users, ask yourself what the limits are and whether they can be reached. And remember: even if these limits can evolve over time, you still need to apply all your governance processes around these resources, such as inventory and rigorous lifecycle management.