Prompt

Terraform Plan Output Analysis Prompt

A practical prompt playbook for using Terraform Plan Output Analysis Prompt in production AI workflows to classify changes, assess blast radius, and evaluate rollback feasibility before apply.

Get in touch Learn more

Developer doing prompt engineering on laptop, prompt variations visible on screen, casual coding session.

PROMPT PLAYBOOK

When to Use This Prompt

A practical guide for infrastructure engineers to transform raw terraform plan JSON into a structured, human-readable change summary with risk classification before applying changes.

This prompt is designed for infrastructure engineers and platform teams who need to quickly interpret the output of terraform plan before applying changes to production or critical environments. The job-to-be-done is converting verbose, machine-readable plan JSON into a structured summary that classifies every resource action as safe, risky, or destructive. Ideal users are on-call engineers reviewing a plan during an incident, CI/CD pipeline operators validating a deployment gate, or platform engineers conducting a pre-apply review. The required context is a terraform plan output that has been converted to JSON using terraform show -json plan.out. Without this structured input, the prompt cannot produce a reliable classification.

Do not use this prompt when you need real-time drift detection against live cloud state—this prompt analyzes a static plan file, not the running environment. It is also unsuitable for generating the exact terraform apply command or for making the final approval decision in fully automated pipelines without a human review step. The prompt assumes the plan JSON is complete and uncorrupted; partial or truncated plan files will produce incomplete or misleading summaries. For high-risk environments, always pair this prompt's output with a manual review step and consider implementing a secondary validation check that confirms the resource count and action types match the raw plan before the summary is trusted.

After using this prompt, you should have a clear, actionable change summary that can be attached to a change request, posted in an incident channel, or used as a pre-apply review gate. The next step is to route the output to the appropriate approval workflow: safe changes can proceed automatically, risky changes require a senior engineer's review, and destructive changes should trigger a blocking gate with a mandatory rollback plan. Avoid using this prompt's risk classification as the sole decision-maker for apply/destroy actions without additional context about the environment's blast radius and business criticality.

PRACTICAL GUARDRAILS

Use Case Fit

Where this prompt works, where it fails, and what you must provide before using it in a production harness.

Good Fit: Structured Plan Review

Use when: you have a complete terraform plan output in machine-readable JSON format and need a human-readable summary. The prompt excels at classifying resource changes as safe (in-place update), risky (recreate with data loss), or destructive (force replacement). Guardrail: always feed the raw plan JSON, not a truncated terminal view, to preserve full resource detail.

Bad Fit: Real-Time Apply Decisions

Avoid when: you need sub-second latency for automated apply pipelines. This prompt is designed for pre-apply review by a human operator, not for inline approval in CI/CD. Guardrail: use a lightweight policy-as-code engine (OPA, Sentinel) for automated gates; reserve this prompt for the human review step before manual applies.

Required Input: Plan JSON + State Context

Risk: without the full plan JSON and current state file, the model cannot distinguish between a new resource creation and a recreation due to a changed immutable attribute. Guardrail: always provide the plan JSON, the prior state file, and a brief note about the change intent (e.g., 'upgrading RDS instance class').

Operational Risk: Blast Radius Underestimation

Risk: the model may correctly classify a single resource change as 'safe' but miss that it triggers a cascade (e.g., an ASG launch template change rolling all instances). Guardrail: add a post-prompt validation step that checks for dependent resources in the plan graph and flags any change touching load balancers, auto-scaling groups, or databases for mandatory human review.

Operational Risk: Rollback Feasibility Overstatement

Risk: the model may claim rollback is 'simple' for changes that involve data plane operations (e.g., database schema migrations) where Terraform revert does not undo data changes. Guardrail: require the prompt output to separate control-plane rollback (Terraform state) from data-plane rollback (application-level migration revert) and flag the latter as 'requires manual verification'.

Harness Concern: Sensitive Value Leakage

Risk: plan outputs often contain sensitive values (passwords, tokens, connection strings) that should not be sent to external model APIs. Guardrail: pre-process the plan JSON to redact or hash all values in sensitive blocks and outputs before passing to the prompt. Use a local model or a private deployment if redaction is insufficient for your compliance boundary.

PROMPT PLAYBOOK

Copy-Ready Prompt Template

A reusable prompt template for classifying Terraform plan output into safe, risky, and destructive changes with blast radius assessment.

This prompt template is designed to be pasted directly into your AI harness. It expects a raw Terraform plan output (typically from terraform plan -out=plan.binary followed by terraform show -json plan.binary or the human-readable terraform plan output) and produces a structured change classification. Replace every square-bracket placeholder with the actual values for your environment and risk tolerance before execution. The template includes placeholders for the plan output itself, your organization's risk definitions, the desired output schema, and any specific constraints like resource ignore patterns or compliance boundaries.

text
You are an infrastructure change classifier. Analyze the following Terraform plan output and classify every proposed change into one of three categories: SAFE, RISKY, or DESTRUCTIVE.

## INPUT
[Terraform Plan Output]

## CLASSIFICATION RULES
- SAFE: Changes that add new resources, update tags, modify non-disruptive attributes, or perform in-place updates that do not require resource recreation and have no downtime risk.
- RISKY: Changes that modify security groups, IAM policies, network ACLs, database instance types, or any attribute where a mistake could cause an outage but the change itself is an in-place update.
- DESTRUCTIVE: Changes that force resource recreation (marked `forces replacement` in the plan), delete resources, destroy data volumes, or modify resources where rollback is complex or impossible.

## BLAST RADIUS ASSESSMENT
For each RISKY or DESTRUCTIVE change, estimate the blast radius:
- SINGLE_RESOURCE: Only the changed resource is affected.
- SERVICE_IMPACT: Multiple resources within the same service or application are affected.
- CROSS_SERVICE: Resources across multiple services, environments, or accounts are affected.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "summary": {
    "total_changes": <number>,
    "safe_count": <number>,
    "risky_count": <number>,
    "destructive_count": <number>
  },
  "changes": [
    {
      "resource_address": "<string>",
      "action": "create|update|delete|replace",
      "classification": "SAFE|RISKY|DESTRUCTIVE",
      "reason": "<one-sentence explanation>",
      "blast_radius": "SINGLE_RESOURCE|SERVICE_IMPACT|CROSS_SERVICE",
      "forces_replacement": <boolean>,
      "rollback_feasible": "<yes|no|partial>",
      "rollback_notes": "<brief rollback guidance or why rollback is difficult>"
    }
  ],
  "pre_apply_recommendations": [
    "<actionable recommendation>"
  ]
}

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, start by replacing [Terraform Plan Output] with the actual plan text or JSON. The [CONSTRAINTS] placeholder should be replaced with environment-specific rules such as "ignore changes to resources tagged with environment:dev" or "flag any change to aws_iam_role as RISKY regardless of the diff." The [RISK_LEVEL] placeholder controls the classification sensitivity—use values like LOW (only flag force-replacement as destructive), MEDIUM (flag IAM and security group changes as risky), or HIGH (flag any change to production databases as destructive). The [EXAMPLES] placeholder should contain one or two few-shot examples showing correct classification for your most common resource types. After generating the output, always validate the JSON structure before surfacing it to a human reviewer. For production use, pair this prompt with a post-processing step that checks for missing resources in the plan output and flags any plan that contains no changes at all as a potential harness error.

IMPLEMENTATION TABLE

Prompt Variables

Required and optional inputs for the Terraform Plan Output Analysis Prompt. Each placeholder must be populated before the prompt is sent to the model. Validation notes describe how to verify the input is well-formed before execution.

Placeholder	Purpose	Example	Validation Notes
[PLAN_OUTPUT]	Raw terraform plan JSON or human-readable output to analyze	{"resource_changes":[{"address":"aws_instance.web","change":{"actions":["update"]}}]}	Must be valid JSON if using machine-readable format. Check for non-empty resource_changes array. Reject if plan contains only no-op changes without explicit flag.
[STATE_CONTEXT]	Current terraform state file for resource attribute comparison	{"resources":[{"instances":[{"attributes":{"id":"i-abc123"}}]}]}	Must parse as valid JSON. Validate that resource addresses in state match plan references. Null allowed if state is unavailable but must flag reduced accuracy.
[CHANGE_CLASSIFICATION_RULES]	Custom rules for classifying changes as safe, risky, or destructive	Destructive: any action containing 'delete' or 'force_new'. Risky: update to 'security_group' or 'iam_role'.	Must be a non-empty string with clear category definitions. Validate that each category has at least one rule. Missing rules default to built-in heuristics but reduce precision.
[BLAST_RADIUS_SCOPE]	List of dependent resources or services to include in blast radius assessment	["aws_lb.target_group", "aws_route53_record.app"]	Must be a valid JSON array of resource addresses. Each address should match terraform address format. Empty array means blast radius assessment is skipped.
[ROLLBACK_PLAN_TEMPLATE]	Template or steps for rollback procedure generation	terraform state rm [RESOURCE]; terraform import [RESOURCE] [ID]	Must be a non-empty string with rollback command patterns. Validate that template references match available tooling. Null allowed if rollback guidance should be generated freeform.
[OUTPUT_FORMAT]	Desired output structure: summary, detailed, or json	json	Must be one of: summary, detailed, json. Default to detailed if not specified. Invalid values should cause pre-flight rejection with supported format list.
[SEVERITY_THRESHOLD]	Minimum severity level for including a change in the report	medium	Must be one of: low, medium, high, critical. Changes below threshold are omitted from output. Validate against allowed enum before prompt assembly.
[APPROVAL_REQUIRED_FLAG]	Whether the output should include explicit approval gates for destructive changes		Must be boolean true or false. When true, output must include approval gate section. When false, approval language is omitted. Default to true for safety.

PROMPT PLAYBOOK

Implementation Harness Notes

How to wire the Terraform plan analysis prompt into a CI/CD pipeline or approval workflow with validation, retries, and human review gates.

This prompt is designed to sit between terraform plan -out and terraform apply in a deployment pipeline. The model receives the full plan output as [PLAN_OUTPUT] and returns a structured classification of every resource change. The harness is responsible for extracting the plan text, injecting it into the prompt template, parsing the model's JSON response, and enforcing policy based on the risk classifications returned. Do not send the binary plan file; always use terraform show -no-color or the JSON plan output (terraform show -json) converted to a readable text representation that the model can parse.

The implementation should include a validation layer that checks the model's output against the actual plan resource count. If the model reports fewer resources than exist in the plan, the harness must flag a coverage gap and either retry with a more explicit instruction or escalate for human review. A retry loop with exponential backoff (max 3 attempts) is appropriate for malformed JSON responses. For destructive changes classified as DESTRUCTIVE or HIGH_RISK, the harness should block automatic apply and route the summary to a human approval queue—Slack, PagerDuty, or a CI pipeline manual approval step. Log every analysis result with the plan checksum, model version, and classification counts for auditability.

Model choice matters here. Use a model with strong JSON mode and long-context handling, such as claude-3-5-sonnet or gpt-4o, because plan outputs can exceed 20k tokens for large infrastructures. Enable structured output mode if available, and provide the expected JSON schema as part of the API call rather than relying solely on the prompt's [OUTPUT_SCHEMA] instructions. For very large plans, consider chunking by resource module and running parallel analyses, then merging results with a final synthesis call. Avoid sending secrets or sensitive resource arguments in the plan text; use terraform plan with -var-file redaction or post-process the plan output to mask sensitive fields before it reaches the model.

IMPLEMENTATION TABLE

Expected Output Contract

Fields, types, and validation rules for the JSON response produced by the Terraform Plan Output Analysis Prompt. Use this contract to parse, validate, and route the model's output in your application harness.

Field or Element	Type or Format	Validation Rule
change_summary	object	Schema check: must contain total_changes, safe_changes, risky_changes, destructive_changes as integers. Sum of safe + risky + destructive must equal total_changes.
change_summary.total_changes	integer	Parse check: non-negative integer. Must match count of items in resource_changes array.
change_summary.safe_changes	integer	Parse check: non-negative integer. Must be <= total_changes. Each corresponding resource_changes entry must have classification 'safe'.
change_summary.risky_changes	integer	Parse check: non-negative integer. Must be <= total_changes. Each corresponding resource_changes entry must have classification 'risky'.
change_summary.destructive_changes	integer	Parse check: non-negative integer. Must be <= total_changes. Each corresponding resource_changes entry must have classification 'destructive'.
resource_changes	array	Schema check: must be an array. Minimum 0 items. Each item must match the resource_change object schema.
resource_changes[].resource_address	string	Parse check: non-empty string matching Terraform resource address pattern (e.g., 'aws_instance.web', 'module.vpc.aws_subnet.private[0]').
resource_changes[].action	string	Enum check: must be one of 'create', 'read', 'update', 'delete', 'update-replace', 'no-op'.
resource_changes[].classification	string	Enum check: must be one of 'safe', 'risky', 'destructive'. Must be consistent with action field (e.g., 'delete' on a stateful resource should not be 'safe').
resource_changes[].change_description	string	Parse check: non-empty string. Must describe the specific change in plain language, referencing the resource type and key attributes being modified.
resource_changes[].blast_radius	object	Schema check: must contain affected_resources (array of strings) and impact_scope (string). affected_resources must list resource addresses that could be impacted.
resource_changes[].blast_radius.impact_scope	string	Enum check: must be one of 'none', 'single-resource', 'dependent-resources', 'service-wide', 'cross-service'.
resource_changes[].rollback_feasibility	string	Enum check: must be one of 'trivial', 'straightforward', 'complex', 'impossible'. 'impossible' requires a rollback_notes field explaining why.
resource_changes[].rollback_notes	string or null	Null check: required when rollback_feasibility is 'complex' or 'impossible'. Must explain the rollback challenge. Null allowed otherwise.
resource_changes[].requires_approval	boolean	Type check: must be true or false. Must be true when classification is 'destructive' or when blast_radius.impact_scope is 'service-wide' or 'cross-service'.
overall_assessment	object	Schema check: must contain risk_level (string), recommended_action (string), and approval_required (boolean).
overall_assessment.risk_level	string	Enum check: must be one of 'low', 'medium', 'high', 'critical'. Must be consistent with the proportion of destructive and risky changes.
overall_assessment.recommended_action	string	Enum check: must be one of 'safe-to-apply', 'review-then-apply', 'approval-required', 'do-not-apply'. 'do-not-apply' requires at least one destructive change with rollback_feasibility 'impossible'.
overall_assessment.approval_required	boolean	Type check: must be true or false. Must be true if any resource_changes entry has requires_approval true. Must be consistent with recommended_action.
overall_assessment.assessment_notes	string	Parse check: non-empty string. Must summarize the key risks, blast radius concerns, and reasoning behind the risk_level and recommended_action.

PRACTICAL GUARDRAILS

Common Failure Modes

What breaks first when analyzing Terraform plan output and how to guard against it in production.

Resource Recreation Misclassification

Risk: The model classifies a destroy-and-recreate action as an in-place update, masking data loss or downtime. This often happens when the plan shows forces replacement but the prompt doesn't explicitly require flagging that attribute. Guardrail: Add a hard rule in the prompt to scan for forces replacement in the raw plan and always surface those resources in a dedicated 'Destructive Changes' section with a warning icon.

Blast Radius Underestimation

Risk: The model reports a change as low-risk because it only analyzes the single resource, ignoring dependent resources that will be cascaded or interrupted. Databases, load balancers, and IAM roles are common culprits. Guardrail: Require the prompt to cross-reference depends_on relationships and module outputs before assigning a final risk score. Include a 'Downstream Impact' field in the output schema.

Sensitive Value Leakage in Summaries

Risk: The raw plan output contains sensitive values in plaintext (passwords, tokens, connection strings), and the model reproduces them in the human-readable summary. Guardrail: Pre-process the plan input to redact values marked as sensitive in the Terraform state before passing them to the model. Add a post-generation check that scans the output for common secret patterns.

State Drift Confusion

Risk: The model interprets a legitimate drift correction as a risky new change, or worse, ignores a dangerous drift that the plan is about to codify. Guardrail: Instruct the prompt to distinguish between 'changes made to reconcile drift' and 'changes introducing new desired state.' Require explicit labeling of drift-only modifications so reviewers can validate them separately.

Rollback Feasibility Overstatement

Risk: The model claims a change is easily rollback-able without verifying that the previous state is still valid or that a rollback won't cause its own destructive cascade. Guardrail: The prompt must condition rollback feasibility on resource type. Data-plane operations (e.g., deleting an RDS instance) should never be marked as trivially rollback-able. Require a specific 'Rollback Constraints' note for each destructive change.

Ignoring No-Op and Drift-Only Changes

Risk: The model wastes the reviewer's attention by flagging every line of the plan, including no-op changes and inconsequential attribute ordering diffs, leading to alert fatigue. Guardrail: Add a pre-classification step in the prompt to filter out changes where all attributes are known after apply or where diffs are purely cosmetic (e.g., JSON key ordering). Group these into a collapsed 'Informational' section.

IMPLEMENTATION TABLE

Evaluation Rubric

Criteria for testing the quality and safety of the Terraform Plan Output Analysis Prompt before integrating it into a CI/CD pipeline or review workflow.

Criterion	Pass Standard	Failure Signal	Test Method
Change Classification Accuracy	All 'destroy/recreate' actions are classified as 'destructive'. In-place updates are classified as 'safe' or 'risky' based on the resource type and blast radius.	A 'force recreate' on a stateful resource like a database is misclassified as 'safe'.	Run the prompt against a curated set of 10 Terraform plan JSON outputs with known, labeled changes. Assert classification matches the label for each resource action.
Blast Radius Assessment	The summary explicitly lists dependent resources that will be impacted by a destructive change, identified by Terraform's dependency graph.	A destructive change to a security group is reported with no mention of the compute instances or load balancers referencing it.	Provide a plan output where a shared module or resource is being recreated. Check the output for a list of all resources that reference the recreated resource's address.
Rollback Feasibility Statement	For each destructive change, the output includes a boolean `rollback_feasible` field and a brief justification referencing state backup or resource recreation time.	The output states a database deletion is easily rollbackable without mentioning the need for a pre-existing snapshot.	Parse the output JSON. Assert the `rollback_feasible` field is `true`, `false`, or `null` with a non-empty justification string for every destructive change.
Human-Readable Summary Completeness	The summary contains a count of total, safe, risky, and destructive changes. It highlights the single most dangerous change.	The summary is a verbatim copy of the first few lines of the raw Terraform plan output without any synthesis or counting.	Use an LLM-as-judge to score the summary on a 1-5 scale for conciseness and actionability. A passing score is 4 or above. Also, assert the presence of the four change-count integers.
Output Schema Adherence	The output is valid JSON that strictly conforms to the defined [OUTPUT_SCHEMA] with all required fields present.	The output is a Markdown block with a JSON snippet inside, or a required field like `change_id` is missing from a resource action.	Parse the entire model response with a JSON validator. Assert it is a single JSON object. Assert no required fields are null unless explicitly allowed by the schema.
No-Change Plan Handling	When the Terraform plan shows zero changes, the output is a valid summary stating 'No changes. Infrastructure matches configuration.' with empty arrays for changes.	The model hallucinates a generic warning about potential drift or fails to produce valid JSON when the plan is empty.	Provide a plan JSON with `resource_changes: []`. Assert the output JSON has `total_changes: 0` and empty `safe_changes`, `risky_changes`, and `destructive_changes` arrays.
Sensitive Value Redaction	The output summary and change descriptions do not contain any plaintext values from sensitive Terraform variables or outputs marked as sensitive.	A database password or API key from a sensitive output change appears in the human-readable summary.	Provide a plan output where a `random_password` resource is being updated with a new sensitive value. Scan the entire model output string for any 16+ character alphanumeric string that could be a password.
Handling of Large Plans	The prompt processes a plan with over 50 resource changes without truncating the summary or omitting destructive changes from the analysis.	The model output ends mid-sentence, or the JSON is truncated, or destructive changes beyond the 20th resource are simply not listed.	Provide a synthetically generated large plan JSON with 75 changes, including 5 destructive ones scattered throughout. Assert the output JSON contains exactly 5 items in the `destructive_changes` array.

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

ADAPTATION OPTIONS

Adapt This Prompt

How to adapt

Start with the base prompt and a single terraform plan output file. Remove strict output schema requirements initially—accept a free-text summary with sections for safe changes, risky changes, and destructive changes. Use a lightweight eval: manually spot-check 5 resources against the plan JSON.

code
Analyze this terraform plan output and classify each change as safe, risky, or destructive. Group your findings by category and explain your reasoning for each classification.

[PLAN_OUTPUT]

Watch for

Misclassification of update in-place vs force recreation when the plan output is truncated
Overlooking NoOp changes that appear in the plan but have no effect
Missing blast radius assessment when dependencies aren't explicitly listed in the plan summary

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.

Talk to Us

Terraform Plan Output Analysis Prompt

When to Use This Prompt

Use Case Fit

Good Fit: Structured Plan Review

Bad Fit: Real-Time Apply Decisions

Required Input: Plan JSON + State Context

Operational Risk: Blast Radius Underestimation

Operational Risk: Rollback Feasibility Overstatement

Harness Concern: Sensitive Value Leakage

Copy-Ready Prompt Template

Prompt Variables

Implementation Harness Notes

Expected Output Contract

Common Failure Modes

Resource Recreation Misclassification

Blast Radius Underestimation

Sensitive Value Leakage in Summaries

State Drift Confusion

Rollback Feasibility Overstatement

Ignoring No-Op and Drift-Only Changes

Evaluation Rubric

Intelligent Analysis, Decision & Execution

Search across company data

Automate internal workflows

Add AI to products and internal tools

Adapt This Prompt

How to adapt

Watch for

Prasad Kumkar

Partnered with leading AI, data, and software stack.

Custom AI workflows for your Business

Review the use case

Pick the right approach

Build the first useful version

Improve from there