Terraform is unforgiving about confident-sounding nonsense. An LLM will happily generate a security group that opens port 22 to the world, or a provider argument that existed two major versions ago. The trick is not asking it to "write my infrastructure" — it's asking it for the exact artifact you can verify before anything touches apply.
This roundup collects prompts that treat the model as an infrastructure engineer's assistant: it drafts reusable modules, explains terraform plan line by line, hunts drift, and audits state and backends. Every prompt here is followed by what to expect, where the model breaks, and how to catch it. The rule throughout: the LLM writes text, Terraform decides truth.
Module Authoring With Variables and Outputs
1. The reusable module skeleton
This is the workhorse. You want a module with a clean interface, not a pile of resources.
Act as a Terraform module author. Build a reusable module for an
AWS S3 bucket with versioning, SSE-KMS encryption, and a
block-public-access setting. Requirements:
- variables.tf: every variable typed, described, with validation
blocks where sensible (e.g. bucket name regex)
- outputs.tf: bucket id and arn
- main.tf: resources only, no hardcoded names — use var.* and
local.* prefixes
- no provider block inside the module
- target Terraform >= 1.6 and AWS provider >= 5.0
Return four files in separate fenced blocks.
Expect a module you can drop into modules/s3/. The validation blocks are the valuable part — a good model writes validation { condition = can(regex(...)) } correctly.
Where it fails: it invents arguments. Ask for aws_s3_bucket_versioning and it may still produce the deprecated versioning block from provider v3. Always run terraform init -backend=false then terraform validate on the module directory before trusting it.
terraform validate is syntactically and schema-correct for the pinned provider version. It says nothing about whether the design is right — that's still your call.
2. Interface review for an existing module
Paste your variables.tf and ask: "Which variables should be required vs optional? Which have no defaults and no validation? Rewrite the interface so a caller cannot pass an invalid value without an error." The model reads intent well here — it spots a cidr_block variable with no cidrnetmask() check in seconds.
3. Migrating hand-built resources into a module
Give it your flat main.tf from a real project and the target module shape. Prompt: "Refactor these resources into a module call, list every moved block needed to avoid destroy/recreate, and flag any attribute that changes force-new." The moved blocks are the payoff — they let terraform state mv-free refactors pass plan cleanly.
Reading the Plan Before You Apply
4. Line-by-line plan explainer
Here is my `terraform plan` output. For every resource marked
for replacement (forces replacement), tell me:
1. which attribute triggered the replacement
2. what data is lost and whether it is recoverable
3. a safe alternative (lifecycle create_before_destroy, ignore_changes,
or a two-step apply)
Do not summarize the whole plan — only the destroys and replaces.
A plan with 40 changes usually has 3 that matter. This prompt surfaces them. Expect a table of resource → attribute → risk.
5. The "what will break at 3 a.m." prompt
"Given this plan, which changes are irreversible on rollback? Rank by blast radius." Models are decent at reasoning about force_destroy on buckets, replaced RDS instances with no snapshot, and destroyed NAT gateways taking egress with them. Treat the output as a checklist, not gospel.
terraform plan -no-color output. ANSI codes and the spinner noise confuse the model and it starts hallucinating resource names that aren't in the diff.
Drift Detection and State Hygiene
6. Drift interrogation
When terraform plan shows changes you didn't make, paste the diff and ask: "Is this drift (real infra changed) or config drift (someone edited code)? What external actor most likely caused each change?" A changed security_group rule often means a console edit; a changed tag often means an automation policy.
7. State file review
Review this terraform.tfstate (redacted). Flag:
- resources with no corresponding config (orphans)
- resources whose provider version differs from the lock file
- sensitive values stored in plaintext
- any resource with a serial/lineage anomaly
Do not modify anything — just report.
Models are weak on lineage math but strong on spotting orphans and plaintext secrets. Cross-check the orphan list against terraform state list yourself.
8. Backend and locking audit
Point the model at your backend.tf and ask it to verify: remote state configured, DynamoDB (or equivalent) lock table present, encryption on, versioning on the bucket. It will catch a missing dynamodb_table argument that lets two engineers race a lock.
apply locally.
Where the LLM Actually Saves Time
It is fastest at text-shaped work: drafting module interfaces, explaining a diff, converting a flat config into a parameterized one, writing moved blocks. It is slowest and most dangerous at judgment calls about live infrastructure — which is exactly where apply must stay human-gated.
The honest division of labor:
| Task | LLM useful? | Human required? |
|---|---|---|
| Module skeleton | Yes, fast | Validate + review |
| Plan explanation | Yes, high value | Confirm blast radius |
| Drift cause guess | Sometimes | Investigate logs |
apply |
Never | Always |
If you're building the surrounding automation, the same discipline as AI automation and agents applies: let the model draft, keep the irreversible step manual.
Terraform rewards paranoia. Use these prompts to move faster on the parts that are just text — and keep your hands on the wheel for the parts that touch production. Run validate, read the plan, then decide.