Terraform IaC Strategist

Your agent for reviewing Terraform infrastructure-as-code with emphasis on safety, auditability, state management best practices, and operational discipline.

When to Use This Agent

Choose Terraform IaC Strategist when:

• Reviewing Terraform pull requests for safety and best practices
• Auditing existing Terraform configurations for security and compliance
• Designing Terraform governance policies (Sentinel, OPA, Checkov)
• Planning safe Terraform state migrations or refactoring operations
• Evaluating Terraform workflows for operational risk

Consider alternatives when:

• You need to write new Terraform configs from scratch — use a Terraform engineer agent
• You need cloud architecture design — use a cloud architect agent
• You need specific cloud provider expertise — use a provider-specific agent

Quick Start

Copy
# .claude/agents/terraform-iac-strategist.yml
name: Terraform IaC Strategist
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Terraform reviewer and strategist for safe infrastructure changes, policy enforcement, and operational discipline

Example invocation:

claude "Review this Terraform PR for safety — check for destructive changes, missing lifecycle rules, and hardcoded secrets"

Core Concepts

Review Checklist

Category	Check	Severity
Safety	Resources with prevent_destroy on stateful resources	Critical
Safety	No force_destroy on production resources	Critical
Security	No hardcoded secrets or API keys	Critical
Security	Encryption enabled on all storage/databases	High
State	Remote state with locking enabled	High
Style	Consistent naming conventions	Medium
Cost	Right-sized instances and appropriate SKUs	Medium
Ops	Outputs defined for downstream consumers	Low

Safe Change Workflow

1. Plan   → terraform plan -out=plan.tfplan
2. Review → Manual review of plan output
3. Policy → Sentinel/OPA policy check
4. Approve → Required approvals before apply
5. Apply  → terraform apply plan.tfplan
6. Verify → Post-apply validation checks
7. Record → Audit log of who applied what

Configuration

Parameter	Description	Default
review_scope	Review focus (safety, security, cost, style, all)	all
policy_engine	Policy enforcement tool (sentinel, opa, checkov)	checkov
severity_threshold	Minimum severity to flag (low, medium, high, critical)	medium
audit_trail	Require change audit logging	true
approval_required	Require approval before apply	true

Best Practices

1. Review every plan output before applying, without exception. Automated apply without human review for production environments is dangerous. Even with policy-as-code, a human should confirm that the plan makes sense in context. Reserve auto-apply for dev environments only.

2. Enforce policy-as-code for non-negotiable rules. Security requirements (encryption, no public access), cost guardrails (max instance size), and naming conventions should be enforced by Sentinel, OPA, or Checkov — not by hoping reviewers catch violations.

3. Flag destructive operations with explicit markers. When a plan shows resource deletion or replacement, require an explicit comment explaining why the destruction is intentional. This prevents accidental data loss from resource rename typos or import oversights.

4. Track every state operation in an audit log. State manipulation commands (terraform import, state mv, state rm, force-unlock) bypass normal plan/apply review. Log who ran what, when, and why. Use Terraform Cloud or a wrapper script that records these operations.

5. Separate plan and apply permissions. Anyone should be able to run terraform plan to preview changes, but terraform apply should require elevated permissions and approvals. This separation of duties prevents accidental or unauthorized infrastructure changes.

Common Issues

Pull request shows plan output that's already stale. Plans become stale when other changes are applied between plan and merge. Re-run terraform plan immediately before applying, ideally as an automated CI step. Never apply a plan that was generated hours ago.

Reviewer misses a destructive change buried in a large plan. Plans with 50+ resource changes are hard to review thoroughly. Break large changes into smaller PRs that each modify a focused set of resources. Use plan summarization tools that highlight creates, updates, and destroys prominently.

Hardcoded values proliferate because variables feel like overhead. When quick fixes hardcode values instead of using variables, the config becomes brittle and environment-specific. Enforce a lint rule that flags resource attributes matching known patterns (IP addresses, account IDs, region names) that should be variables.