All mode is an Azure Policy setting that tells a policy definition to evaluate broadly across Azure resources and supported scopes. It is different from Indexed mode, which mainly targets resources that support tags and location. Microsoft recommends All mode in most cases because governance teams usually want policies to apply beyond only regional, taggable resources. In plain English, All mode is the safer default when a policy should not quietly miss resource types, child resources, or subscription-level behavior.
All mode is an Azure Policy definition mode that evaluates all resource types and relevant scopes supported by the policy rule, and Microsoft recommends using all mode in most cases.
Technically, mode appears in the policy definition JSON and affects which resource types Azure Policy evaluates. All mode is used by policy definitions created in the Azure portal and can be specified through CLI or PowerShell. If a CLI-created policy omits mode, null behaves like Indexed for backward compatibility. All mode matters when rules inspect resource type, child resources, subscription properties, or scopes that may not have tags and location. It pairs with effects such as audit, deny, modify, and deployIfNotExists.
Why it matters
All mode matters because a policy that looks correct can still leave gaps if it evaluates too narrowly. A governance team might believe it is restricting risky resources, enforcing configuration, or auditing drift, while Indexed mode skips objects that lack tags and location. That creates false confidence. All mode gives architects a broader enforcement surface and makes custom policies easier to reason about. Learners should connect this term to deployment failures, compliance reports, and the question every policy author must ask: what exactly is being evaluated? It also gives learners a concrete way to connect architecture diagrams, deployed resources, and operator decisions.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
You see it in Azure Policy definitions when the rule evaluates resource types beyond resource-group children, including subscription-level and extension resources. during governed production operations
Signal 02
It appears during governance design when policy authors choose whether a definition should evaluate every relevant resource or only indexed resource properties. during governed production operations
Signal 03
It shows up in compliance investigations when a policy unexpectedly targets resources outside the team’s assumed deployment scope because mode is all. during governed production operations
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Evaluate governance rules across broad Azure scopes instead of only taggable, regional resources.
Author custom policies that inspect resource types, child resources, or subscription-level behavior.
Avoid Indexed-mode surprises when a policy must cover more than resources with tags and location.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Subscription-wide tagging policy coverage
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
GreenRiver Energy wanted cost-center tags enforced across resource groups and subscription-level resources. Earlier policies missed some scopes because they were written only for indexed resource types.
🎯Business/Technical Objectives
Evaluate both resource groups and supported resources for tag compliance.
Prevent new untagged production assets from bypassing governance.
Improve FinOps reporting accuracy before budget reviews.
Give platform teams a repeatable way to inspect policy mode.
✅Solution Using All mode
The governance team rewrote the tagging policy with Azure Policy mode set to all. That mode allowed evaluation beyond only indexed resource types, including resource groups, which were central to the company’s ownership model. The policy definition used parameters for required tag names, an initiative grouped related tag controls, and assignments targeted production subscriptions first. Operators used Azure CLI to export the policy definition and confirm the mode, effect, assignment scope, and compliance state. Remediation tasks updated eligible existing resources, while deny behavior prevented new drift. The team documented why all mode was required so future editors would not accidentally switch the definition back and reduce coverage.
📈Results & Business Impact
Tag coverage improved from 68 percent to 96 percent across production subscriptions.
Monthly cost-allocation exceptions fell by 54 percent.
Resource groups became visible in compliance reports instead of being handled manually.
Policy review time dropped because mode and assignment scope were clear in exported evidence.
💡Key Takeaway for Glossary Readers
All mode helps Azure Policy evaluate broader resource scopes, which is essential when governance must cover more than indexed resource properties.
Case study 02
Public-sector governance for extension resources
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
CivicCloud Services needed policy coverage for diagnostic settings and other extension-style resources. Compliance teams were concerned that resource-only checks would miss controls attached outside the normal resource shape.
🎯Business/Technical Objectives
Evaluate governance controls that involve extension resources.
Expose policy gaps before the annual compliance assessment.
Standardize policy definition review across departments.
Avoid creating separate manual checklists for unsupported scopes.
✅Solution Using All mode
Architects reviewed existing custom policy definitions and found several using indexed mode by habit. For controls that needed broader evaluation, they switched to all mode and retested assignments in a sandbox subscription. The policy initiative included diagnostic logging, location, and naming controls, while exemptions documented cases where a service did not support the required behavior. Azure CLI queries listed policy definitions by mode, assignment scope, and compliance state, giving reviewers a fast inventory of which controls were broad-scope and which were resource-property-only. The team also added a pull-request check requiring authors to justify mode selection before a policy definition could be published.
📈Results & Business Impact
The governance inventory found 14 policies whose mode did not match their intent.
Manual compliance sampling dropped by 40 percent after extension-resource checks were automated.
Reviewers gained a clear distinction between all-mode and indexed-mode controls.
No unsupported policy assignments were promoted to production without documented exceptions.
💡Key Takeaway for Glossary Readers
Choosing all mode is a governance design decision: it widens evaluation so policies match the real boundary they are meant to control.
Case study 03
Enterprise landing-zone policy cleanup
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
BlueRidge Manufacturing inherited dozens of custom Azure policies across acquired subscriptions. Some definitions appeared compliant but failed to evaluate management or grouping resources important to the new landing-zone standard.
🎯Business/Technical Objectives
Classify every custom policy by intended evaluation scope.
Correct policies that needed all mode for full coverage.
Retire duplicate definitions before assigning the new initiative.
Create evidence that policy behavior matched the landing-zone design.
✅Solution Using All mode
The cloud governance team exported all policy definitions and grouped them by mode, effect, and assignment. They compared each definition against the landing-zone control it supported. Policies that checked only taggable indexed resources remained indexed, while broader controls moved to all mode with tests in a staging management group. Compliance output was reviewed before production assignment so teams could see which resources became newly evaluated. The team built a CLI-driven report listing policy name, mode, version, and assignment scope. This report went into the acquisition integration playbook, preventing future policy edits from weakening coverage silently.
📈Results & Business Impact
The cleanup retired 23 duplicate policies and corrected 9 definitions with the wrong mode.
Landing-zone compliance reports became consistent across four acquired subscriptions.
Governance review meetings shortened from two hours to 45 minutes.
Newly evaluated resource groups revealed 31 missing ownership tags before production rollout.
💡Key Takeaway for Glossary Readers
All mode prevents hidden governance gaps when a policy’s real target includes scopes or resource shapes beyond indexed resources.
Why use Azure CLI for this?
Azure CLI is useful for All mode because it turns a portal setting into repeatable evidence. Operators can inspect scope, status, parameters, and effective configuration from scripts, compare environments, and save output for change control. For this term, CLI is especially helpful when troubleshooting across subscriptions or proving that the deployed resource matches the runbook.
CLI use cases
Inventory the current All mode configuration and export it for review evidence.
Compare portal-visible settings with command output before a production change.
Troubleshoot deployment, policy, identity, monitoring, cost, or scaling symptoms from a repeatable shell.
Automate recurring checks so the All mode standard does not depend on manual portal clicks.
Before you run CLI
Confirm the active tenant, subscription, resource group, and target scope before running commands.
Verify that your account has read permissions, and use contributor-level access only for approved changes.
Choose an output format such as table for review or json for scripts, evidence, and automation.
Check whether the command is read-only, mutating, security-impacting, or cost-impacting before execution.
What output tells you
Names, IDs, scopes, regions, modes, or status fields identify which All mode resource the command actually inspected.
Configuration fields reveal whether the deployed setting matches the intended architecture or governance baseline.
Missing, null, disabled, or empty values usually point to an unconfigured feature, wrong scope, or stale assumption.
JSON output can be saved as change evidence and compared against previous releases or policy reviews.
Mapped Azure CLI commands
All mode operational checks
diagnostic
az policy definition show --name <definition-name> --query "properties.mode"
az policy definitiondiscoverManagement and Governance
az policy definition create --name <definition-name> --mode All --rules policy-rule.json --params parameters.json
az policy definitionsecureManagement and Governance
az policy definition list --query "[?properties.mode=='All'].[name,properties.displayName]" --output table
az policy definitiondiscoverManagement and Governance
Architecture context
Technically, mode appears in the policy definition JSON and affects which resource types Azure Policy evaluates. All mode is used by policy definitions created in the Azure portal and can be specified through CLI or PowerShell. If a CLI-created policy omits mode, null behaves like Indexed for backward compatibility. All mode matters when rules inspect resource type, child resources, subscription properties, or scopes that may not have tags and location. It pairs with effects such as audit, deny, modify, and deployIfNotExists.
Security
Security improves when All mode prevents sensitive resources, child resources, or subscription-level settings from slipping past a policy definition. For example, policies that inspect resource type, network exposure, diagnostic settings, or identity behavior may need a broader evaluation surface than Indexed mode provides. Access to author definitions should still be restricted because an overly broad deny policy can block legitimate deployments. Security review should include effect, scope, parameters, exemptions, and whether All mode is required to close the intended control gap. Reviewers should confirm permissions, scopes, logs, and exception paths before trusting the control in production. Reviewers should confirm permissions, scopes, logs, and exception paths before trusting the control in production.
Cost
All mode has indirect cost implications. Better coverage can prevent expensive or unsupported resources from being created, but overly broad deny policies can delay projects if exceptions are not planned. Audit results can also create remediation work that costs time. FinOps teams should care because resource-type, region, SKU, and diagnostic policies often influence spend. A well-tested All mode policy helps enforce cost guardrails consistently; a poorly tested one can create deployment friction that teams bypass through exemptions or shadow processes. FinOps review should separate direct platform charges from indirect labor, delivery delay, and risk-reduction value. FinOps review should separate direct platform charges from indirect labor, delivery delay, and risk-reduction value.
Reliability
Reliability depends on predictable policy evaluation. All mode can make governance behavior more consistent because teams are less likely to discover skipped resource types during production deployment. However, broader evaluation can also deny or audit resources that a team did not expect, so policies should be tested with doNotEnforce, audit, or limited scopes before wide rollout. Change plans should include exemption handling and rollback. The reliable pattern is to prove the mode in a sandbox, then assign carefully at management group or subscription scope. The safest pattern is tested change windows, documented rollback, and monitoring that proves the expected behavior.
Performance
All mode does not make applications faster or slower at runtime. Its performance impact is operational: policy evaluation and compliance reporting become broader, which can improve governance search and reduce investigation time when teams trust the results. Poorly designed policies can slow deployments through unexpected denies or confusing compliance noise. Performance-minded platform teams keep policy rules simple, use parameters carefully, test alias behavior, and document evaluation intent so policy checks support delivery instead of becoming another bottleneck. Performance review should measure real latency, throughput, startup time, or response effort instead of assuming impact. Performance review should measure real latency, throughput, startup time, or response effort instead of assuming impact.
Operations
Operations work includes checking policy definition mode, reviewing compliance results, explaining denied deployments, and converting custom policies that accidentally used null or Indexed mode. CLI can list definitions, show mode, and export JSON for review. Platform teams should document why a policy uses All mode and what resources are intentionally included. When troubleshooting, operators should compare the target resource type, alias availability, assignment scope, exemptions, and effect to determine whether the policy is behaving broadly by design or blocking unexpectedly. Good operations practice records owner, scope, command evidence, and the first troubleshooting steps in the runbook. Good operations practice records owner, scope, command evidence, and the first troubleshooting steps in the runbook.
Common mistakes
Assuming the All mode setting exists at every scope or plan tier without checking the actual deployed resource.
Running commands in the wrong subscription because Azure CLI context was not confirmed first.
Treating portal labels as enough evidence instead of validating resource IDs, parameters, and effective state.
Changing production configuration without checking blast radius, rollback path, and dependent services.