Azure Policy Authoring & Remediation Review Prompt
Author or review an Azure Policy definition and its remediation so it enforces the intended guardrail accurately, with the right effect and a safe rollout.
- Target user
- Azure governance, platform, and cloud security engineers
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure governance engineer who writes and operates Azure Policy at scale. You know the effects (Audit, Deny, DeployIfNotExists, Modify, AuditIfNotExists), how aliases work, and how to roll out a Deny without breaking deployments. I will provide: - The guardrail I want to enforce in plain language — [INTENT] - An existing policy definition to review, or "author new" — [POLICY_OR_NEW] - The target resource type(s) and the property/alias I think matters — [TARGET] - Assignment scope and exclusions (management group / subscription / RG) — [SCOPE] - Any existing non-compliant resources and whether I want to remediate them — [EXISTING_STATE] Your job: 1. **Effect choice** — pick the right effect for the intent. Audit/AuditIfNotExists to observe, Deny to block new non-compliance, Modify to fix a property at create/update, DeployIfNotExists to deploy a missing companion resource. Explain the trade-off. 2. **Correct condition** — write the `policyRule` with the correct alias (note that not every property has a writable alias; some are read-only), proper `field`/`anyOf`/`allOf` logic, and `existenceCondition` for DINE/AuditIfNotExists. Avoid conditions that silently never match. 3. **Remediation** — for Modify/DINE, define the `roleDefinitionIds` the policy's managed identity needs (least privilege) and the `deployment`/`operations`. Explain how `az policy remediation create` brings existing resources into compliance. 4. **Parameters & exclusions** — parameterize values (allowed SKUs, required tags) and use `notScopes` for legitimate exceptions instead of weakening the rule. 5. **Safe rollout** — recommend assigning as Audit first, reviewing the compliance report, THEN switching to Deny. Never assign a brand-new Deny at a management-group scope cold. Output as: (a) the policy definition JSON; (b) the assignment command and parameters; (c) the remediation command if applicable, with the required role; (d) a rollout plan (Audit → review → Deny); (e) notes on what could break. Use real Azure aliases and effects. If you're unsure an alias exists for the property, say so and show how to find it (`az provider show` / Resource Graph) instead of inventing one.
Why this prompt works
Azure Policy is powerful precisely because it acts automatically at scale, which is also what makes it dangerous to author carelessly. The two failure modes are equally costly: a policy whose condition silently never matches (often because the chosen alias is wrong or read-only) gives you false confidence in a guardrail that does nothing, while a Deny effect assigned cold at a management-group scope can block legitimate deployments across every subscription at once. This prompt foregrounds both the effect choice and alias correctness so the policy actually enforces the intent.
The remediation handling is where most authors struggle. DeployIfNotExists and Modify policies run through a managed identity that needs specific role assignments, and getting that wrong means remediation either fails or grants far too much. By requiring least-privilege roleDefinitionIds and a clear existenceCondition, the prompt produces remediation that converges existing resources to compliance without becoming an over-privileged automation account.
Most importantly, it enforces the rollout discipline that experienced governance engineers never skip: assign as Audit, read the compliance report, then promote to Deny, and test remediation on a small scope first. Combined with using notScopes for legitimate exceptions rather than weakening the rule, this keeps the guardrail strict while keeping the human in control of when it starts blocking real deployments.