Azure Policy mode, All vs Indexed, when to use each

What policy “mode” controls during evaluation

Azure Policy is the built in governance engine for the Azure public cloud. Its evaluation mode tells the engine which resource types to include when checking your rules. Picking the right mode improves accuracy, speeds up evaluation, and avoids confusing results. Microsoft’s guidance is to default to All in most cases, with Indexed used for certain tag and location checks.

The mode property on a policy definition controls what resource types the engine evaluates. All evaluates resource groups and all resource types. Indexed evaluates only resource types that expose tags and location. Some child resource types, such as Microsoft.Network/routeTables/routes, are not included by Indexed because they cannot be tagged. This is why All is the safer default for most policies. The Azure portal creates policies with All by default. Azure PowerShell defaults to All if you omit mode. Azure CLI treats null as Indexed for backward compatibility.

Optionally, there are data specific modes for certain services, for example Microsoft.KeyVault.Data. These are out of scope for this article, but worth knowing about.

When to use All, resource groups and broad resource evaluation

Use All when your policy must evaluate resource groups, subscriptions, or resource types that do not expose tags or location. All is also recommended if you are unsure or your rule involves many different resource types across a platform landing zone. Microsoft’s own tutorial on tag governance calls out that policies targeting resource groups must use All.

Common cases for All:

1. Restricting where resource groups can be created.

2. Enforcing naming or tag rules at the resource group level.

3. Rules that include child resources that lack tags.

When Indexed is appropriate, tags or location checks

Pick Indexed when your rule is strictly about tags or location on normal resources. Indexed limits evaluation to resource types that support tags and location, which keeps compliance results cleaner. Microsoft’s troubleshooting guidance explicitly notes that tag or location checks should use Indexed. For the modify effect that adds or updates tags, Microsoft advises Indexed unless the target is a resource group.

Common cases for Indexed:

1. Require a tag on resources, for example costCenter.

2. Add or replace a tag at create or update time.

3. Allowed locations for resources, not resource groups.

Built in examples and what they imply

You can see the intent of each mode in built ins.

Allowed locations for resources excludes resource groups and uses an Indexed pattern. Its community index shows mode Indexed, which aligns with the location only check. The complementary policy, Allowed locations for resource groups, uses All because it targets resource groups directly.

For tags, the Add or replace a tag on resources built in uses modify and is Indexed, and it explicitly does not modify tags on resource groups. That design nudges you to use a separate All policy if you also want to govern tags on resource groups.

Performance and troubleshooting considerations

Right mode, cleaner results. Indexed reduces the evaluation set, which often means faster compliance scans and fewer misleading non compliant items on resources that do not support tags. If a compliance view shows zero of zero resources, double check whether your scope and mode make the policy applicable at all. Microsoft’s troubleshooting page also reminds you that tag or location checks should be Indexed, and to verify the resource payload against your rule when results look odd.

Tip: if you see child resources marked non compliant in an Indexed tag policy, that is a smell. Switch the rule to All, or narrow the rule to the specific resource types that actually support tags.

Decision checklist and two worked examples

Quick checklist for azure policy mode all vs indexed:

1. Does the policy target resource groups or subscriptions, or child resources that lack tags, choose All.

2. Is the rule only about tags or location on standard resources, choose Indexed.

3. Using modify to set tags, choose Indexed, unless governing resource groups.

Worked example 1, require a CostCenter tag on resource groups, use All.

{

"mode": "All",

"policyRule": {

"if": {

"allOf": [

{ "field": "type", "equals": "Microsoft.Resources/subscriptions/resourceGroups" },

{ "field": "tags['CostCenter']", "exists": false }

]

},

"then": { "effect": "deny" }

}

}

This mirrors Microsoft’s tutorial note that resource group targeting requires All.

Worked example 2, deny resources outside approved regions, use Indexed.

{

"mode": "Indexed",

"parameters": {

"allowedLocations": { "type": "Array" }

},

"policyRule": {

"if": {

"not": {

"field": "location",

"in": "[parameters('allowedLocations')]"

}

},

"then": { "effect": "deny" }

}

}

This follows the same pattern as the Allowed locations built in, which treats resource groups separately.

Worked example 3, add a default Environment tag, use Indexed with modify.

{

"mode": "Indexed",

"policyRule": {

"if": { "field": "tags['Environment']", "exists": false },

"then": {

"effect": "modify",

"details": {

"operations": [

{ "operation": "add", "field": "tags['Environment']", "value": "Prod" }

]

}

}

}

}

Microsoft’s modify guidance recommends Indexed for tag updates on resources, and All only when the target is a resource group.

Next steps

1. Test your policies in a non production subscription. If you are new to evaluation scans, start with our testing walkthrough, including on demand scans and quick checks. See our policy testing post.

2. If you are introducing policy as part of wider governance, read our governance, risk and compliance explainer for a plain language overview, including how Azure Policy supports audits.

3. Troubleshoot azure policy mode issues by re checking scope, mode, and the exact resource payloads. Microsoft’s guidance highlights that using Indexed for tag or location checks avoids false positives, and that All is recommended in most cases.