Terraform Policy Compliance Instructions

Terraform Policy Compliance Instructions

First Principle: Azure Policy always wins. Current Azure Policy implementation cannot be changed. Code MUST adapt to policy, never the reverse.

Mandate

ALL Terraform code generation MUST cross-reference 04-governance-constraints.md and 04-governance-constraints.json before writing templates. These artifacts contain the discovered Azure Policy constraints for the target subscription.

Dynamic Tag List

Tags MUST come from governance constraints, not hardcoded defaults. The 4 baseline defaults in terraform-code-best-practices.instructions.md (Environment, ManagedBy, Project, Owner) are a MINIMUM — discovered policies always win. If governance constraints specify 9 tags, the Terraform code MUST include all 9.

Example

Defaults (azure-defaults skill):  4 tags
Governance constraints discovered: 9 tags (environment, owner,
  costcenter, application, workload, sla, backup-policy,
  maint-window, tech-contact)
Required in Terraform code:       9 tags (governance wins)

# locals.tf — all 9 tags when governance requires them
locals {
  tags = merge(var.tags, {
    environment      = var.environment
    owner            = var.owner
    costcenter       = var.costcenter
    application      = var.application
    workload         = var.workload
    sla              = var.sla
    backup-policy    = var.backup_policy
    maint-window     = var.maint_window
    tech-contact     = var.tech_contact
  })
}

azurePropertyPath Translation

For each Deny or Modify policy in 04-governance-constraints.json, read the azurePropertyPath field and translate it to the corresponding azurerm_* resource argument:

Translation Pattern

1. Split azurePropertyPath on . → [resourceType, "properties", ...rest]
2. Map resourceType to the correponding azurerm_* resource using the table below
3. Map the properties. path to the Terraform argument name (snake_case)

Resource Type Mapping

Property Path Mapping Examples

Policy Compliance Checklist

For every policy in 04-governance-constraints.json:

Deny Policies

• Read azurePropertyPath and requiredValue from JSON
• Translate azurePropertyPath to azurerm_* resource argument using the table above
• Verify the generated Terraform code sets the argument to the required value
• If the argument is missing, add it
• If the argument value conflicts, change it to match policy

Modify Policies

• Document expected auto-modifications in the implementation reference
• Do NOT set values that Modify policies auto-apply (avoid conflicts)

DeployIfNotExists Policies

• Document auto-deployed resources in the implementation reference
• Include expected resources in cost estimates

Audit Policies

• Add a comment in the resource block for awareness
• Set compliant values where feasible (best effort)

Audit Policy Comment Pattern

resource "azurerm_storage_account" "this" {
  # AUDIT: Policy "Require diagnostic settings" — compliant if Log Analytics configured
  # ...
}

Enforcement Rule

[!CAUTION] Azure Policy always wins. Current Azure Policy implementation cannot be changed. Code MUST adapt to policy, never the reverse. A governance compliance failure is a HARD GATE — the Terraform Code Generator MUST NOT proceed past Phase 1.5 with unresolved policy violations.

HCP Terraform Cloud Guardrail

[!CAUTION] NEVER use HCP Terraform Cloud (terraform { cloud {} }) or reference TFE_TOKEN in generated code. State backend MUST be Azure Storage Account. See terraform-code-best-practices.instructions.md § State Backend.

Anti-Patterns

Cross-References

• Governance constraints artifact: agent-output/{project}/04-governance-constraints.md
• Governance constraints JSON: agent-output/{project}/04-governance-constraints.json
• Governance discovery instructions: .github/instructions/governance-discovery.instructions.md
• Azure defaults (baseline tags): .github/skills/azure-defaults/SKILL.md
• Terraform best practices: .github/instructions/terraform-code-best-practices.instructions.md