Skip to content
CloudOps
Prompts Newsletter
All prompts
AI for Terraform Difficulty: Intermediate ClaudeChatGPTCursor

Terraform Module Review Prompt

Get a senior-engineer review of a Terraform module — variable hygiene, state safety, security defaults, drift resistance.

Target user
Cloud engineers reviewing Terraform modules before they hit production
Difficulty
Intermediate
Tools
Claude, ChatGPT, Cursor

The prompt

You are a senior cloud infrastructure engineer who has shipped Terraform modules to production for years across AWS, GCP, and Azure. You know where modules silently break in real environments.

Review the Terraform module I share. Apply this checklist:

1. **Variables & types**
   - Every variable has `type`, `description`, and `default` (or is documented as required)?
   - `validation` blocks on inputs that have constraints (CIDR ranges, region names, instance sizes)?
   - No untyped `variable "foo" {}` ambiguity?

2. **Outputs**
   - Every output has a `description`?
   - Sensitive outputs marked `sensitive = true`?
   - Outputs are stable identifiers (ARNs, IDs), not transient values?

3. **Resource defaults**
   - Encryption-at-rest enabled by default for storage resources (S3, RDS, EBS, etc.)?
   - Logging/audit defaults sensible (CloudTrail, VPC flow logs, RDS performance insights)?
   - Public access disabled by default (S3 block public access, RDS publicly_accessible = false)?

4. **Tags & naming**
   - `tags` merged with a `var.tags` to allow consumer override?
   - Resource names use a consistent prefix from `var.name_prefix`?

5. **State safety**
   - `lifecycle { prevent_destroy = true }` on stateful resources (RDS, DynamoDB, S3 with data)?
   - `ignore_changes` on fields that drift naturally (tags managed by other systems, autoscaled counts)?
   - Provider versions pinned with `required_providers` and minimum constraint?

6. **Security**
   - IAM roles use least privilege — no `Action: "*"` or `Resource: "*"` unless documented?
   - Secrets passed via `aws_secretsmanager_secret` or `data` sources, not literal values?
   - Default security groups don't allow 0.0.0.0/0 unless explicitly intended?

7. **Drift resistance**
   - `count` and `for_each` are stable across runs (don't depend on changing keys)?
   - No use of `random_*` resources without `keepers` to control regeneration?
   - Resources that the cloud provider mutates aren't fighting Terraform on every plan?

For each finding: **severity** (critical / warning / nit), **file:line**, **issue**, **HCL diff**.

Module structure (paste `ls -R` and the file contents):
```
[PASTE]
```

Why this prompt works

Most Terraform modules look fine on terraform plan and then bite you in production: missing encryption, no prevent_destroy, public access by default, drift fights. This prompt enforces a real production-grade checklist.

How to use it

  1. Paste the module structure first (ls -R modules/foo), then individual .tf files. Don’t drop the entire module in one massive paste — the model loses fidelity.
  2. After the review, ask: “rewrite the variables.tf and main.tf applying every critical and warning finding.”
  3. Run terraform fmt, terraform validate, tflint, and tfsec/checkov on the rewritten module.

Pair this with

What good review output looks like

CRITICAL — main.tf:42: aws_s3_bucket.this has no server_side_encryption_configuration. Add:

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

WARNING — variables.tf:12: var.instance_type has no type or validation. Consumers can pass "t3.huge" (invalid) and only discover at apply time. Add type = string and a validation block listing allowed sizes.

Related prompts

Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.