A Terraform Drift Detection Prompt That Categorizes and Remediates

Someone fixed a production issue by bumping an autoscaling limit in the AWS console at midnight. Three weeks later a routine terraform apply quietly reverts it, and the incident comes back. That's infrastructure drift, and the gap between detecting it and safely fixing it is where a terraform drift detection prompt earns its keep: it reads the plan output, explains why each resource drifted, and tells you whether to import, apply, or leave it alone.

What ranks for this query is mostly vendor academy content pushing a drift-management platform, plus one generic prompt list with no structure. The platforms work if you buy in. A reusable prompt does the interpretation layer on whatever plan output you paste, in any model, without a new tool in the stack.

Drift detection versus drift interpretation

A clarifying point that the vendor posts blur: terraform plan already detects drift. It tells you what differs between state and reality. What it doesn't tell you is why, or what to safely do about it. A 600-line plan with 40 changed resources is detection. Knowing that 35 of those are harmless autoscaling noise and five are a console change you need to import is interpretation.

The prompt does interpretation. It categorizes each drifted resource by likely source, then routes it to a remediation action. That categorization is the whole value, because the remediation depends entirely on the cause.

Strong opinion: never let a drift prompt recommend apply by default. The safe default for unexplained drift is investigate, not reconcile. A prompt that cheerfully says "run apply to fix" on a resource someone changed by hand to mitigate an outage is how you re-break production. Make apply the exception the prompt has to justify, not the reflex.

What you can do with this prompt

• Read raw terraform plan output and rank drifted resources by risk
• Categorize each drift: console change, autoscaling, external automation, or unknown
• Recommend a remediation per resource: import, apply, ignore, or investigate
• Flag any diff containing a deletion so it never gets an auto-apply verdict
• Summarize a noisy plan into a short "what actually changed" brief
• Draft the change-ticket description for the resources you choose to remediate

Anatomy of the drift prompt

Variables → Prompt → Output

{{plan_output}}        raw `terraform plan` text
{{known_automation}}   systems allowed to change infra (autoscaler, etc.)
{{environment}}        prod / staging
{{change_window}}      recent manual changes the team is aware of

→ Categorization rubric + remediation refusal boundary →

→ Output contract (per resource):
   Resource: <address>
   Drift category: console | autoscaling | automation | unknown
   Risk: high | medium | low
   Remediation: import | apply | ignore | investigate
   Why: <one line>

The contract is per-resource and capped at a line each, so a 40-resource plan comes back as a scannable table instead of an essay. The remediation field is constrained to four values on purpose. A free-text recommendation invites the model to suggest something clever and wrong.

Step-by-step usage

1. Gather inputs

Run terraform plan and capture the full output. Paste it into {{plan_output}} raw. List the systems allowed to mutate infra in {{known_automation}} so the prompt can tell legitimate autoscaling from a real surprise.

2. Fill variables

Set {{environment}}. Prod drift and staging drift get different risk weights, and the prompt should know which it's reading. Add any manual changes the team made recently to {{change_window}} so they're categorized as console changes, not unknowns.

3. Run the prompt

Low temperature. Drift categorization is a classification task, and you want the same plan to produce the same verdicts so two engineers reading it agree.

4. Post-process

Read every resource the prompt marked "unknown" or "investigate". Those are the real findings. The autoscaling and known-automation rows are noise you can skim. Inverting that attention is the common mistake.

5. Iterate

If too much lands as "unknown", your {{known_automation}} list is incomplete. Add the systems that legitimately touch infra and rerun. You're teaching the prompt your environment, not rewriting it.

Prompt-craft patterns that matter here

The deletion guardrail. This is the refusal boundary that keeps the prompt safe.

Never recommend "apply" on a resource whose diff includes a destroy or
replace action, or whose drift category is "unknown". Route both to
"investigate" with a one-line reason. Apply is only valid for low-risk
drift with a known, benign category.

The category-before-risk ordering. Categorize the drift source first, then assign risk, because risk depends on category. Autoscaling drift in prod is low risk; an unknown console change in prod is high. If the model grades risk before it figures out the cause, the risk scores are guesses.

Variables you'll set

Getting started

1. Run terraform plan and copy the full output.
2. Paste it into {{plan_output}} and set {{environment}}.
3. List your known automation systems so legit drift is categorized.
4. Run the prompt at a low temperature.
5. Read the "unknown" and "investigate" rows first; skim the rest.
6. Remediate only the resources with a justified verdict.
7. For ongoing drift checks, start from the Infrastructure Drift Detection Harness.

A one-off drift read is a copied prompt. A weekly drift sweep across several state files is where the harness pays off, because the categorization rubric and the deletion guardrail are already enforced and don't drift themselves.

Drift that caused an outage feeds straight into a writeup, so this pairs with the blameless incident postmortem prompt. Instrumenting the services where drift bites is the next layer, covered in the observability instrumentation prompt, and the Observability Instrumentation Harness ships that contract ready to run.