Infrastructure as Code Review Prompt

This prompt is designed for DevOps engineers, platform teams, and cloud architects who need a structured, automated first pass at reviewing Infrastructure as Code (IaC) before it reaches a human reviewer or a CI/CD merge gate. It targets Terraform, Pulumi, and CloudFormation configurations. The primary job-to-be-done is catching architectural and operational risks that static analysis tools like terraform validate or cfn-lint cannot express—such as hardcoded secrets, missing dependency ordering, state management risks, and module reuse violations. Use it when you want a design-level review that reasons about intent, blast radius, and operational fragility, not just syntax errors.

The ideal user provides the full IaC file or module as [INPUT] and optionally a [CONTEXT] block describing the deployment environment, team standards, or known constraints. The prompt works best in a pre-commit hook, a PR review workflow, or a CI pipeline stage where a language model can reason about architectural intent before human review begins. It is not a replacement for terraform plan, pulumi preview, or cfn-lint; those tools should still run and pass before this prompt is invoked. The prompt adds a layer of semantic reasoning on top of syntactically valid code.

Do not use this prompt for real-time production configuration changes, for generating IaC from scratch, or for enforcing compliance with regulatory frameworks that require certified auditors. It is a review assistant, not an approval authority. The output should always be treated as findings for a human to verify, prioritize, and act on. In high-risk environments—such as those managing PII, financial data, or healthcare infrastructure—require human sign-off on every finding before merging. The prompt is most effective when paired with a validation harness that checks the output schema, logs findings for auditability, and blocks merges only when combined with human review gates.

This is the core prompt template for an Infrastructure as Code review. It is designed to be pasted directly into your AI system, with square-bracket placeholders replaced by the actual values for your specific review task. The prompt instructs the model to act as a principal cloud architect and systematically evaluate an IaC configuration against a defined set of criteria, producing a structured, actionable report. The template is self-contained; you can use it without the rest of this playbook, but the surrounding sections will help you integrate it reliably into a production workflow.

codeCopy
You are a principal cloud architect reviewing an Infrastructure as Code (IaC) configuration. Your goal is to identify risks, bugs, and deviations from best practices before deployment.

## Review Context
- **IaC Tool:** [IAC_TOOL]
- **Cloud Provider(s):** [CLOUD_PROVIDER]
- **Primary Service(s) Under Review:** [SERVICE_LIST]
- **Risk Profile:** [RISK_LEVEL] (e.g., Low, Medium, High, Critical)

## IaC Configuration to Review
```[IAC_TOOL]
[IAC_CODE_BLOCK]

Review Criteria

Analyze the configuration against the following dimensions. For each finding, provide a severity (CRITICAL, HIGH, MEDIUM, LOW), a clear description, the exact resource and line reference, and a concrete, actionable remediation.

1. State Management: Check for misconfigured remote backends, missing state locking, or sensitive data in state files.
2. Drift Risk: Identify resources susceptible to configuration drift due to manual changes or missing lifecycle policies (e.g., prevent_destroy).
3. Security & Secrets: Flag hardcoded secrets, overly permissive IAM roles/policies, unencrypted data stores, and public exposure of private resources.
4. Module Reuse & Design: Assess if the code follows the principle of least repetition. Identify monolithic templates that should be refactored into reusable modules.
5. Plan Determinism: Identify any dynamic or unpredictable values that could cause unexpected changes on the next plan or apply.
6. Dependency Ordering: Check for missing explicit dependencies (depends_on or equivalent) that could lead to race conditions or creation failures.
7. Hardcoded Values & Parameterization: Flag any hardcoded names, IDs, AMIs, or regions that should be variables or data source lookups.
8. Naming & Tagging Convention: Evaluate resource naming and tagging strategy for consistency, sortability, and cost allocation.

Output Schema

Return your findings as a single JSON object matching this exact schema. Do not include any text outside the JSON object. { "summary": "A 2-3 sentence executive summary of the overall configuration quality and top risks.", "findings": [ { "id": "F-001", "severity": "CRITICAL|HIGH|MEDIUM|LOW", "dimension": "The review criterion from the list above.", "resource": "The specific resource address (e.g., aws_s3_bucket.data).", "line_reference": "Approximate line number or block name.", "description": "A clear, specific explanation of the problem.", "remediation": "A concrete, actionable fix." } ], "score": { "overall": "PASS|FAIL|WARN", "security_posture": "PASS|FAIL|WARN", "operational_maturity": "PASS|FAIL|WARN" } }

Constraints

• Do not hallucinate resource types or provider features.
• If you are uncertain about a finding, flag it as LOW severity and note the uncertainty.
• If the configuration is empty or unparseable, return a single CRITICAL finding explaining this.
• Prioritize findings that could cause an outage, security breach, or data loss.

To adapt this template, replace the placeholders with your specific context. For [IAC_TOOL], use terraform, pulumi-python, cloudformation, etc. The [RISK_LEVEL] input should influence the model's scrutiny; for a production database, you might set it to CRITICAL to encourage a stricter review. The most critical part of the template is the Output Schema. By demanding a strict JSON structure, you can parse the findings programmatically, post them as comments on a pull request, or feed them into a ticketing system. If you are using a model that supports it, you can convert the Output Schema into a JSON Schema for guaranteed structured output via the API.

This prompt is designed to operate as a blocking quality gate in a deployment pipeline, not as an advisory chatbot. The primary integration point is a pull request check that runs against terraform plan output, CloudFormation change sets, or Pulumi preview diffs before apply is permitted. The harness must capture the full plan artifact—not just a diff summary—because the prompt requires resource-level detail to detect drift risk, missing dependency ordering, and hardcoded values. Wire the prompt into a GitHub Actions workflow, GitLab CI job, or Jenkins stage that executes after plan generation and before any approval step. The model call should be synchronous within the pipeline; a response time of 15–45 seconds is acceptable for a blocking review, but set a hard timeout of 90 seconds with a fallback to pass with warning to avoid pipeline stalls.

Validation and retry logic is critical because the output schema is strict JSON with enumerated severity levels (BLOCKER, CRITICAL, WARNING, INFO). After receiving the model response, run a JSON schema validator against the expected structure: an array of finding objects, each with id, severity, resource_address, title, description, remediation, and rule_id fields. If parsing fails or required fields are missing, retry once with the same input plus the validation error message appended as a [REPAIR_INSTRUCTION]. If the second attempt also fails, fail the pipeline check open with a diagnostic log—never block a deployment on an unparseable model output. For high-risk environments, add a post-processing step that cross-references each BLOCKER finding against a human approval queue: if any blocker references aws_iam_role, aws_kms_key, or google_project_iam_member, route the finding to a designated security reviewer before the pipeline can proceed.

Model choice and tool use should favor models with strong structured output support and long context windows. Use gpt-4o or claude-3-5-sonnet with the response_format parameter set to json_object and the system prompt instructing strict schema adherence. The plan artifact can exceed 20,000 tokens for large infrastructures; if the plan exceeds the model's context window, preprocess it by extracting only create, update, and delete actions, stripping unchanged resource blocks, and summarizing repetitive resource arrays. Do not use RAG for this workflow—the plan is the single source of truth and must be reviewed in full. If the IaC tool supports machine-readable plan output (e.g., Terraform's JSON plan format), prefer that over human-readable text to reduce token waste on formatting characters. Log the full prompt, response, and validation result to your observability platform with trace IDs that link back to the specific commit SHA and plan artifact version.

Failure modes to instrument: the most common production failures are (1) plan artifacts exceeding context windows, causing truncated reviews that miss resources at the end; (2) the model hallucinating resource addresses that don't exist in the plan, producing false positives that erode trust; (3) severity inflation where every finding is marked BLOCKER, causing pipeline fatigue and manual override habits; and (4) secret detection false negatives where hardcoded values in locals blocks or variable defaults are missed because the model only scans resource arguments. Mitigate these by adding a pre-flight context-length check that fails the pipeline if the plan exceeds 80% of the model's context window, a post-processing deduplication step that removes findings referencing nonexistent resource addresses, a severity distribution monitor that alerts if BLOCKER findings exceed 30% of total findings, and a complementary static analysis tool (e.g., tfsec, checkov) that runs alongside the LLM review to catch deterministic secret and policy violations the model might miss.