Azure Policy Initiative Builder

What This Tool Does

Build an Azure Policy initiative (policy set) grouping multiple policyDefinitions under a shared groupName, each with its own effect (Audit, Deny, AuditIfNotExists, DeployIfNotExists, Disabled), plus initiative-level parameters that individual member policies can reference so one initiative assignment can configure many policies' behavior consistently rather than needing separate parameter values per policy. The effect field per policy definition reference is a real operational lever distinct from the policy definition itself: the same underlying policy definition (say, 'require a specific tag') can be assigned with effect Audit for visibility-only reporting or Deny for actual enforcement blocking non-compliant resource creation, and initiatives commonly parameterize effect itself so the same initiative can run in Audit mode in a test environment and Deny mode in production without needing two separate initiatives.

Technical Details

Common Use Cases

1. 1Setting effect to Deny for a genuinely non-negotiable security control (like requiring encryption) while using Audit for a softer governance recommendation (like a naming convention), so the initiative's enforcement posture matches each policy's actual criticality rather than treating every included policy identically.
2. 2Grouping related policy definitions under a shared groupName (like Location Governance), so the initiative's structure documents which policies work together toward a specific compliance objective, rather than presenting a flat, undifferentiated list of unrelated policies.
3. 3Parameterizing effect itself as an initiative-level parameter, so the same initiative definition can be assigned twice, once in Audit mode for a pilot subscription and once in Deny mode for production, without maintaining two separate, drifting initiative definitions.
4. 4Defining an Array-type parameter (like allowed locations) once at the initiative level and having multiple member policies reference it, so updating the allowed list in one place (the initiative assignment) consistently updates every policy relying on that same list.

Common Questions

Does changing a policy's effect from Audit to Deny in an initiative retroactively fix already non-compliant resources?

No, Deny only blocks new non-compliant resource creation or updates going forward, it doesn't retroactively remediate or remove existing non-compliant resources created while the policy was in Audit mode (or before the policy existed at all). Switching from Audit to Deny is also operationally risky if you haven't first reviewed the volume of currently non-compliant resources, since Deny then blocks any future update to those same resources until they're brought into compliance.

Can two different member policies in the same initiative reference the same initiative-level parameter?

Yes, this is a primary reason to use initiative-level parameters rather than hardcoding values into each policy definition reference, multiple policies needing the same value (an allowed-locations list, a required tag key) can all reference one shared initiative parameter, so updating that one parameter value at assignment time consistently updates every policy relying on it.

What's the practical difference between Audit and AuditIfNotExists effects?

Audit evaluates a condition directly against the resource itself and flags non-compliance if that condition fails. AuditIfNotExists checks whether a related, secondary resource exists (like confirming a specific extension is installed on a VM) and flags non-compliance if that related resource is missing, they check fundamentally different things, a resource's own properties versus the existence of an associated resource, and picking the wrong one for what you're actually trying to verify produces a policy that doesn't catch the real compliance gap.

Expert Tips

Related Learning Guides

• Cost Management Guide24 min read
• Azure Monitor & Application Insights26 min read