Azure Policy: 5 Must-Have Rules for Every Environment

5 Indispensable Azure Policies for every environment  

1. Require tags on resources 

Enforcing tags on resources ensures that specific tags (e.g. environment owner or department) are applied to all resources during deployment. It’s one of those things that makes a big difference when managing large environments. Tags are invaluable for cost tracking, resource ownership, and environment segregation.

For example, enforcing an environment tag (dev, test, prod) keeps reports and dashboards organised.

Let’s look at a simple example: 

You can set this policy to either deny deployment if tags are missing or automatically add default values.  

Configuration: 

az policy definition create --name "require-tags-on-resources" --display-name "Require Tags on Resources" --description "This policy requires that specific tags are assigned to all resources." --rules '{ 
    "if": { 
        "field": "tags", 
        "exists": "false" 
    }, 
    "then": { 
        "effect": "deny" 
    } 
}' --mode All 

Assigning the policy 

You can assign this policy at any scope (management group, subscription, or resource group).  

For example, apply it to a specific resource group named SpecificResource: 

az policy assignment create \ 
  --name "allowed-resource-types" \ 
  --policy "allowed-resource-types" \ 
  --scope "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}" 

If a user tries to deploy a resource that isn’t on the allowed list, the policy will immediately block it.

2. Inherit tags 

The Inherit tags policy helps you keep tags consistent across your Azure environment by automatically applying tags from parent resources (e.g. subscriptions or resource groups) to their underlying resources.  

This is especially useful if you’ve split your subscriptions into environments such as dev, test, and prod, and want every resource to inherit a predefined tag like Environment. 

If you already have existing resources that were deployed before you started using Azure policy, then these will inherit whatever you set at the subscription level. 

Benefits: 

• Keep tag values consistent across environments. 
• Reduces manual tagging and the risk of human error. 
• Simplifies ongoing resource management and reporting. 

After defining the policy, assign it to your subscription or resource group. Existing resources missing that tag will automatically inherit it from the parent scope. 

Configuration: 

This policy definition uses the parameter tagName to determine which tag’s value to inherit from the parent resource group. 

{ 
    "properties": { 
        "displayName": "Inherit a tag from the resource group", 
        "mode": "Indexed", 
        "description": "Adds or replaces the specified tag and value from the parent resource group when any resource is created or updated. Existing resources can be remediated by triggering a remediation task.", 
        "metadata": { 
            "category": "Tags" 
        }, 
        "parameters": { 
            "tagName": { 
                "type": "String", 
                "metadata": { 
                    "displayName": "Tag Name", 
                    "description": "Name of the tag, such as 'environment'" 
                } 
            } 
        }, 
        "policyRule": { 
            "if": { 
                "allOf": [{ 
                        "field": "[concat('tags[', parameters('tagName'), ']')]", 
                        "notEquals": "[resourceGroup().tags[parameters('tagName')]]" 
                    }, 
                    { 
                        "value": "[resourceGroup().tags[parameters('tagName')]]", 
                        "notEquals": "" 
                    } 
                ] 
            }, 
            "then": { 
                "effect": "modify", 
                "details": { 
                    "roleDefinitionIds": [ 
                        "/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c" 
                    ], 
                    "operations": [{ 
                        "operation": "addOrReplace", 
                        "field": "[concat('tags[', parameters('tagName'), ']')]", 
                        "value": "[resourceGroup().tags[parameters('tagName')]]" 
                    }] 
                } 
            } 
        } 
    } 
} 

Assign the policy to your subscription or management group, specify the tag name (like environment), and any resource without that tag will automatically inherit it from its parent resource group. 

3. Disable public storage accounts (require private endpoints) 

Publicly accessible storage accounts are often one of the most exploited security loopholes in Azure environments. They open the door widely for data exposure if credentials are leaked or misconfigured. Hence, they should be avoided at all costs. 

In Azure policy, you can enforce a rule that blocks public access and requires all storage accounts to use private endpoints. This ensures data traffic stays within your VNet and can’t bypass the internet. 

Benefits: 

• Keeps data private and limits exposure to the public internet. 
• Reduces risk of unauthorised access and misconfiguration. 
• Strengthens compliance and governance across storage resources. 

Configuration: Bicep example 

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = { 
  name: name 
  location: location 
  sku: { 
    name: 'Standard_GRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    allowBlobPublicAccess: false 
    supportsHttpsTrafficOnly: true 
    minimumTlsVersion: 'TLS1_2' 
    networkAcls: { 
      defaultAction: 'Deny' 
    } 
  } 
} 

To address this at runtime, use the built-in policy from Microsoft that disallows public access to storage accounts. 

4. Restrict resources  

This controls the types of Azure resources that can be created by defining an allow list of permitted resource types. Typical entries include virtual machines (VMs) or storage accounts. This helps standardise your architecture, manage costs, and keep deployments aligned with organisational standards. 

Benefits: 

• Ensures compliance with organisational standards. 
• Prevents costly or unauthorised resource deployments.  

For example, you might choose not to allow VMs if you’re moving toward PaaS services.

Blocking VM creation removes the temptation to deploy them and keeps teams focused on modernised solutions. 

Configuration: 

az policy definition create --name "allowed-resource-types" --display-name "Allowed Resource Types" --description "This policy restricts the types of resources that can be deployed." --rules '{ 
    "if": { 
        "allOf": [ 
            { 
                "field": "type", 
                "notIn": [ 
                    "Microsoft.Compute/virtualMachines", 
                    "Microsoft.Storage/storageAccounts" 
                ] 
            } 
        ] 
    }, 
    "then": { 
        "effect": "deny" 
    } 
}' --mode All 

Assigning the Policy 

Once the policy is defined, assign it to a scope. For example, a management group, subscription, or resource group.  
 
Here’s how you’d apply it to a specific resource group named SpecificResource: 

az policy assignment create --name "allowed-resource-types" --policy "allowed-resource-types" --scope "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}" 

If you attempt to deploy a resource type that’s not on the allowed list, you’ll notice it fails immediately.  

That’s by design; as the policy blocks anything outside your approved set. 

5. Restrict locations 

Last, but not least, restricting which regions resources can be deployed to. It’s common for organisations that must meet data residency, sovereignty, or performance requirements (latency). For example, you might only allow West Europe to stay compliant and avoid unnecessary sprawl. 

That’s when this policy comes in: limiting the Azure regions where you can deploy resources and preventing accidental or non-compliant use of regions outside your approved list.  

Benefits: 

• Keeps data in approved regions to meet regulatory or legal requirements. 
• Prevents accidental deployments in unapproved or costly regions. 
• Simplifies management and improves governance across environments. 

az policy definition create --name "allowed-locations" --display-name "Allowed Locations" --description "This policy restricts resource deployment to specified Azure regions." --rules '{ 
    "if": { 
        "not": { 
            "field": "location", 
            "in": [ 
                "eastus", 
                "westeurope" 
            ] 
        } 
    }, 
    "then": { 
        "effect": "deny" 
    } 
}' --mode All 

After defining the policy, assign it to a scope such as a management group, subscription, or resource group: 

az policy assignment create --name "assign-allowed-locations" --policy "allowed-locations" --scope "/subscriptions/{subscriptionId}" 

Replace {subscriptionId} with your actual subscription ID.

Then, when someone tries to deploy a resource in a region that’s not listed, the deployment will fail.

Closing thoughts 

As you can see, Azure Policy is a valuable tool for maturing your cloud governance and maintaining consistent and compliant Azure environments. 

Whether you're securing your environment, controlling costs, or staying compliant, Azure policy puts you in control. Many environments will have numerous policies in place (some with over 200), and these examples are just the tip of the iceberg. 

Azure Policy can also handle automated remediation, regulatory compliance, and custom policies. 

Start by implementing the five policies we covered: require tags on resources, inherit tags, disable public storage accounts, restrict access to resources and locations. And if you want to check out all policies you can implement in Azure, have a look at all built-in policy definitions defined by Microsoft.