Terraform Plan Risk Assessment Prompt Template

This prompt is built for DevOps and platform engineering teams who need a consistent, auditable risk summary from terraform plan output before approving terraform apply. The primary job-to-be-done is reducing the cognitive load of scanning large infrastructure diffs by transforming raw plan JSON or text into a structured report that categorizes every proposed change by destruction risk, security impact, and blast radius. The ideal user is a human operator in a CI/CD pipeline, ChatOps bot, or manual change-review workflow who must decide whether to approve, reject, or escalate a plan. The prompt is designed to surface the five changes that matter most—such as security group modifications that open public access or database instance replacements that cause data loss—rather than overwhelming the reviewer with fifty low-risk attribute updates.

Use this prompt when the plan output is available as structured JSON from terraform show -json or as a human-readable plan text. It works best when combined with context about the target environment (e.g., [ENVIRONMENT] = production), the affected service tier, and any organizational policies that define what constitutes a high-risk change. The prompt expects a [RISK_LEVEL] parameter to calibrate sensitivity—for example, a plan touching PCI-scoped resources should use a stricter threshold than a development sandbox. Do not use this prompt for real-time incident response where seconds matter; it is a pre-apply review gate, not a runtime diagnostic tool. It is also not a substitute for policy-as-code engines like Open Policy Agent or Sentinel, which provide hard enforcement. Instead, this prompt adds a layer of contextual reasoning that static policy checks miss, such as identifying that a seemingly safe update in-place for an IAM role actually grants unintended cross-account access.

Before integrating this prompt into a production pipeline, ensure you have a human-in-the-loop approval step for any change categorized as destroy or high severity. The prompt's structured output includes a requires_approval boolean field for each finding, but your application harness must enforce that approval gate—the prompt advises, your code decides. Start by running the prompt against a golden dataset of known safe and dangerous plans to calibrate your [RISK_LEVEL] and [CONSTRAINTS] parameters. Common failure modes include false positives on state-only changes (where the plan shows a resource replacement due to a provider upgrade but no actual infrastructure change) and false negatives on multi-resource chains where individual changes appear safe but their combination creates a security gap. The companion eval checks in this playbook address both.

This prompt template is designed to ingest a raw terraform plan output and produce a structured risk report. It categorizes every proposed change by destruction risk, security impact, and blast radius. The template uses square-bracket placeholders for variables you must supply—such as the plan output itself, your organization's risk tolerance, and any environment-specific context. Before using this in a production pipeline, ensure you have a human approval gate wired around any destroy: true findings.

textCopy
You are an infrastructure risk analyst reviewing a Terraform plan for a [ENVIRONMENT_NAME] environment. Your task is to produce a structured risk assessment that categorizes every proposed change before `terraform apply` is executed.

## INPUT
[Terraform Plan Output]

## CONTEXT
- Environment: [ENVIRONMENT_NAME]
- Service/Stack: [SERVICE_NAME]
- Change Requestor: [REQUESTOR]
- Deployment Window: [DEPLOYMENT_WINDOW]
- Organizational Risk Tolerance: [RISK_TOLERANCE: low | medium | high]

## CONSTRAINTS
- Do not recommend `apply` if any resource marked `destroy: true` lacks an explicit recreation or migration plan.
- Flag any security group, IAM policy, or network ACL change as high-severity until proven otherwise.
- Treat state-only changes (e.g., refresh-only updates, data source reads) as informational, not actionable.
- If a resource is being replaced in-place, assess whether downtime is expected and note the estimated duration.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "assessment_summary": {
    "total_changes": <integer>,
    "additions": <integer>,
    "modifications": <integer>,
    "destructions": <integer>,
    "overall_risk_level": "low" | "medium" | "high" | "critical",
    "recommendation": "proceed" | "proceed_with_caution" | "block"
  },
  "findings": [
    {
      "resource_address": "<string>",
      "change_type": "create" | "modify" | "destroy" | "replace",
      "risk_category": "destruction" | "security" | "availability" | "cost" | "drift" | "informational",
      "severity": "low" | "medium" | "high" | "critical",
      "blast_radius": "<string describing affected services or users>",
      "finding": "<concise description of the risk>",
      "requires_approval": <boolean>,
      "mitigation": "<suggested action before apply>"
    }
  ],
  "state_only_changes": [
    {
      "resource_address": "<string>",
      "note": "<explanation of why this is informational>"
    }
  ]
}

## RULES
1. Every resource with `destroy: true` or `force replacement` must have `requires_approval: true`.
2. Security group, IAM, and network ACL changes default to `severity: high` unless the change is purely additive and scoped to least privilege.
3. If `overall_risk_level` is `critical`, `recommendation` must be `block`.
4. Do not fabricate resource addresses. Use the exact addresses from the plan output.
5. If the plan output is empty or unparseable, return `{"error": "Invalid or empty plan output", "recommendation": "block"}`.

To adapt this template, replace the square-bracket placeholders with your actual values. The [Terraform Plan Output] should be the full JSON or human-readable output from terraform plan. For [RISK_TOLERANCE], align with your team's deployment policy—production environments typically use low, while development or staging may accept medium. The [ENVIRONMENT_NAME] and [SERVICE_NAME] fields help the model contextualize blast radius. If you are integrating this into a CI/CD pipeline, pipe the plan output directly into the prompt and parse the JSON response for automated gating. Always log the full prompt and response for auditability, especially when a block recommendation is overridden.

This prompt is designed to sit inside a deployment pipeline or a manual review step before terraform apply is executed. The primary integration point is after terraform plan generates a JSON output file. Your application should read that file, inject it into the [TERRAFORM_PLAN_JSON] placeholder, and send the assembled prompt to the model. The model's structured JSON response becomes the input to your deployment decision logic. Do not treat the model's output as a simple pass/fail signal; instead, parse the risk_level and individual findings to determine the next step in your workflow.

For a production-grade harness, implement a validation layer that checks the model's output against a strict JSON schema before any deployment decision is made. The schema should enforce that risk_level is one of low, medium, high, or critical, and that each finding in the findings array contains a non-empty resource_address, change_type, risk_category, and rationale. If validation fails, implement a single retry with a repair prompt that includes the raw output and the specific schema errors. Log both the initial failure and the retry result for prompt debugging. For model choice, use a model with strong reasoning capabilities and a large context window to handle verbose Terraform plans; a smaller, faster model may miss subtle resource dependency risks.

The most critical part of the harness is the human approval gate. If the model's output contains any finding with change_type equal to destroy or replace, or if the overall risk_level is critical, the pipeline must halt and require an explicit human approval before proceeding. Route these high-risk plans to a review queue with a clear summary of the model's findings, the full plan diff, and a link to the original plan artifact. For lower-risk plans, you can configure the harness to auto-apply, but always log the model's risk assessment as an audit record. A common failure mode is the model flagging state-only changes (like a refresh that updates a data source) as destructive. Mitigate this by cross-referencing the model's findings against a list of known state-only resource types in your validation layer before triggering the human review gate.