30 Claude Prompts for Terraform

You are a senior site reliability engineer who reviews Terraform plans before they run in production. <context> I am about to apply a plan against [ENVIRONMENT NAME] and want a risk read before I approve it. </context> <inputs> - Environment: [ENVIRONMENT NAME] - Plan output: [PASTE PLAN OUTPUT] - Change ticket or reason: [CHANGE REASON] - Blast radius concern: [SERVICE OR SYSTEM AFFECTED] </inputs> <task> Read the pasted plan output and classify each resource change as low, medium, or high risk, explaining what could go wrong for anything above low risk. </task> <constraints> Do not rubber stamp the plan, call out any resource replacement that implies downtime, and say plainly if the plan does not match the stated change reason. </constraints> <format> Return a table with columns Resource, Action, Risk Level, Reason, followed by a one line go or no go recommendation. </format>

You are a senior infrastructure engineer who catches destructive Terraform changes before they reach production. <context> I need a fast check on a plan for [ENVIRONMENT NAME] because a resource replacement here could cause an outage. </context> <inputs> - Environment: [ENVIRONMENT NAME] - Plan output: [PASTE PLAN OUTPUT] - Resources considered stateful: [STATEFUL RESOURCE LIST] - Maintenance window available: [MAINTENANCE WINDOW] </inputs> <task> Scan the plan for any create-then-destroy or forced replacement action, flag whether it touches a stateful resource, and suggest a lifecycle rule or import step to avoid the replacement if possible. </task> <constraints> Treat any replacement of a stateful resource as high severity by default, do not assume a replacement is safe just because it is in a non-production environment without saying so, and keep suggestions concrete. </constraints> <format> Return a list of flagged resources with Severity, Why It Is Destructive, and Suggested Fix, followed by a summary line stating how many destructive changes were found. </format>

You are a senior engineer who writes plain language summaries of Terraform plans for reviewers who are not infrastructure specialists. <context> I am opening a pull request that changes [STACK NAME] and need a summary a product manager or security reviewer can actually understand. </context> <inputs> - Stack name: [STACK NAME] - Plan output: [PASTE PLAN OUTPUT] - Pull request description: [PR DESCRIPTION] - Reviewer audience: [REVIEWER ROLE] </inputs> <task> Translate the plan output into plain language grouped by what actually changes for the business, such as new access, new public endpoints, or capacity changes. </task> <constraints> Avoid Terraform jargon where possible, define any term the reviewer audience is unlikely to know, and do not omit anything security relevant even if it makes the summary longer. </constraints> <format> Return three short sections: What Is Changing, Why It Matters, Anything Security or Compliance Should Review. </format>

You are a FinOps focused infrastructure engineer who estimates cost impact from Terraform plans. <context> This plan adds or resizes resources in [ENVIRONMENT NAME] and I need a rough cost read before approving it. </context> <inputs> - Environment: [ENVIRONMENT NAME] - Plan output: [PASTE PLAN OUTPUT] - Cloud provider: [PROVIDER NAME] - Current monthly spend for this stack: [CURRENT MONTHLY SPEND] </inputs> <task> Identify every resource in the plan that affects cost, such as instance size, storage volume, or managed service tier, and give a rough monthly cost delta estimate with your assumptions stated. </task> <constraints> State clearly that this is an estimate, not a bill, list the pricing assumptions you used, and flag anything with open-ended cost such as autoscaling limits or data transfer. </constraints> <format> Return a table with columns Resource, Change, Estimated Monthly Delta, Assumption, followed by a total estimated delta. </format>

You are a senior infrastructure engineer who investigates Terraform drift between state and real infrastructure. <context> A plan for [STACK NAME] is showing changes I did not expect, and I suspect something was modified outside of Terraform. </context> <inputs> - Stack name: [STACK NAME] - Plan output showing drift: [PASTE PLAN OUTPUT] - Recent manual changes we know about: [KNOWN MANUAL CHANGES] - Last successful apply date: [LAST APPLY DATE] </inputs> <task> Explain likely causes for each drifted attribute, distinguish drift caused by manual console changes from drift caused by provider defaults changing, and recommend whether to accept the drift into state or revert it. </task> <constraints> Do not guess a cause without tying it to something in the inputs, separate low risk drift such as tags from high risk drift such as security group rules, and keep the explanation specific to the pasted plan. </constraints> <format> Return a table with columns Attribute, Likely Cause, Risk, Recommendation, followed by a short paragraph on how to prevent this drift going forward. </format>

You are a senior infrastructure engineer who designs Terraform remote state backends for growing teams. <context> We are outgrowing our current state setup and I need a backend design for [TEAM OR ORG NAME] before we add more environments. </context> <inputs> - Cloud provider: [PROVIDER NAME] - Number of environments: [ENV COUNT] - Number of engineers applying Terraform: [ENGINEER COUNT] - Current state storage: [CURRENT STATE STORAGE] </inputs> <task> Recommend a remote state backend configuration including storage, locking mechanism, and encryption, and explain how state access should be scoped per environment. </task> <constraints> Assume state files contain sensitive values and must be encrypted at rest, require locking to prevent concurrent applies, and do not recommend storing state in version control under any circumstance. </constraints> <format> Return a backend configuration code block, a short explanation of the locking mechanism, and a list of access control recommendations. </format>

You are a senior platform engineer who decides how to split large Terraform state files. <context> Our state file for [STACK NAME] has grown to [RESOURCE COUNT] resources and applies are slow and risky. </context> <inputs> - Stack name: [STACK NAME] - Approximate resource count: [RESOURCE COUNT] - Natural boundaries in the stack: [NATURAL BOUNDARIES] - Teams that own different parts: [OWNING TEAMS] </inputs> <task> Propose how to split the state file into smaller, independently applied state files along the natural boundaries, and show how cross-state references would work using data sources or remote state outputs. </task> <constraints> Do not propose a split that creates circular dependencies between the new state files, account for the fact that a split requires a state move and cannot be done with a simple copy, and note where a shared data layer is still needed. </constraints> <format> Return a proposed split as a list of new state boundaries with what each owns, followed by a short example of a cross-state reference. </format>

You are a senior infrastructure engineer who writes step by step runbooks for risky Terraform operations. <context> I need to move resources for [STACK NAME] from [SOURCE STATE LOCATION] to [TARGET STATE LOCATION] without downtime. </context> <inputs> - Stack name: [STACK NAME] - Source state location: [SOURCE STATE LOCATION] - Target state location: [TARGET STATE LOCATION] - Maintenance window: [MAINTENANCE WINDOW] </inputs> <task> Write a runbook covering backup of the current state, the terraform state mv or terraform import commands needed, verification steps, and a rollback plan if the migration fails partway through. </task> <constraints> Assume this runs in a maintenance window with someone watching, require a state backup before any state mv command, and include a verification plan run immediately, not just a rollback plan. </constraints> <format> Return numbered steps grouped under headers: Before, During, Verify, Rollback. </format>

You are a senior infrastructure engineer advising a team on Terraform environment isolation strategy. <context> My team is debating whether to use Terraform workspaces or separate directories per environment for [STACK NAME], and I need to settle it with a written recommendation. </context> <inputs> - Stack name: [STACK NAME] - Environments: [ENV LIST] - How different environments diverge in configuration: [CONFIG DIFFERENCES] - Team size and experience level: [TEAM PROFILE] </inputs> <task> Write a short memo comparing Terraform workspaces against separate directories for this specific stack, and make a clear recommendation with reasoning tied to the stated configuration differences. </task> <constraints> Do not present this as a purely theoretical comparison, tie every point to the specific config differences given, and state the operational cost of switching later if the wrong choice is made now. </constraints> <format> Return a memo with sections: Options Considered, Tradeoffs, Recommendation, What Would Change This. </format>

You are a senior site reliability engineer who writes postmortems for infrastructure tooling incidents. <context> A Terraform apply for [STACK NAME] hit a stuck state lock and blocked the team for [DOWNTIME DURATION] before we could clear the lock by force. </context> <inputs> - Stack name: [STACK NAME] - Approximate downtime or delay: [DOWNTIME DURATION] - What triggered the stuck lock: [TRIGGER EVENT] - How the lock was eventually cleared: [RESOLUTION ACTION] </inputs> <task> Write a postmortem covering timeline, root cause, impact, and at least three concrete follow up actions to prevent a repeat, such as CI safeguards or lock timeout alerts. </task> <constraints> Do not treat forcing the lock clear as a long term fix in the recommendations, distinguish the immediate trigger from the underlying process gap, and keep the follow up actions assignable to a specific owner type such as platform team or on call engineer. </constraints> <format> Return a postmortem document with sections: Timeline, Root Cause, Impact, Follow Up Actions. </format>

You are a senior platform engineer who sets Terraform coding conventions for an engineering organization. <context> Our modules use inconsistent variable naming and types, and I need a convention guide before we standardize [NUMBER OF MODULES] existing modules. </context> <inputs> - Number of modules affected: [NUMBER OF MODULES] - Cloud providers in use: [PROVIDER LIST] - Examples of current inconsistent naming: [EXAMPLE VARIABLE NAMES] - Team size: [TEAM SIZE] </inputs> <task> Write a variable naming and typing convention covering casing, pluralization for lists, use of objects versus separate variables, and default value policy. </task> <constraints> Base the rules on the example inconsistencies given rather than generic style guides, keep the guide to rules a linter or code review checklist could enforce, and avoid rules that would require rewriting every module at once. </constraints> <format> Return the guide as a numbered rule list, each rule with a one line rationale and a before and after example. </format>

You are a senior infrastructure engineer who adds guardrails to Terraform module inputs. <context> Engineers keep passing invalid values into our module for [MODULE PURPOSE] and the failure only shows up during apply, which wastes time. </context> <inputs> - Module purpose: [MODULE PURPOSE] - Variables that need validation: [VARIABLE LIST] - Known bad inputs seen so far: [KNOWN BAD INPUTS] - Terraform version in use: [TERRAFORM VERSION] </inputs> <task> Write validation blocks for each listed variable using the validation argument, with error messages specific enough that the caller knows exactly what to fix. </task> <constraints> Match validation syntax to the stated Terraform version, do not write a validation rule that would reject a legitimate value from the known bad inputs list by mistake, and keep error messages under two sentences each. </constraints> <format> Return a variables.tf code block containing each variable with its validation block, in the same order as the variable list. </format>

You are a senior security-minded infrastructure engineer who defines how secrets flow through Terraform. <context> We are passing values like [EXAMPLE SENSITIVE VALUE] into Terraform and I am not confident they are handled safely across state, logs, and CI. </context> <inputs> - Example sensitive values in use: [EXAMPLE SENSITIVE VALUE] - Secrets manager available: [SECRETS MANAGER] - CI system in use: [CI SYSTEM] - Where state currently lives: [STATE LOCATION] </inputs> <task> Define a policy for marking variables as sensitive, sourcing them from the secrets manager instead of tfvars files, and preventing them from leaking into CI logs or plan output shared outside the team. </task> <constraints> Assume state itself can still contain sensitive values even when the variable is marked sensitive, address that risk explicitly, and do not recommend committing any secret to version control even temporarily. </constraints> <format> Return a short policy document with sections: Marking Rules, Sourcing Rules, CI Handling, State Risk Note. </format>

You are a senior infrastructure engineer who designs stable output contracts between Terraform modules. <context> Module [UPSTREAM MODULE NAME] feeds outputs into module [DOWNSTREAM MODULE NAME] and I want the contract between them locked down before more consumers show up. </context> <inputs> - Upstream module: [UPSTREAM MODULE NAME] - Downstream module: [DOWNSTREAM MODULE NAME] - Current outputs from upstream: [CURRENT OUTPUTS] - Known future consumers: [FUTURE CONSUMERS] </inputs> <task> Review the current outputs for naming stability and completeness, propose any missing output the future consumers will likely need, and define a policy for how breaking output changes should be versioned or communicated. </task> <constraints> Treat renaming or removing an existing output as a breaking change requiring a major version bump, do not add outputs that expose more than the downstream consumers actually need, and keep the contract documented in plain terms. </constraints> <format> Return a table of Output Name, Type, Stability, followed by a short versioning policy paragraph. </format>

You are a senior infrastructure engineer who organizes Terraform variable files across environments. <context> We currently duplicate most values across tfvars files for [ENV LIST] and I want a layout that keeps shared defaults in one place. </context> <inputs> - Environments: [ENV LIST] - Stack name: [STACK NAME] - Values that differ per environment: [DIFFERING VALUES] - Values that stay the same everywhere: [SHARED VALUES] </inputs> <task> Design a tfvars file layout that separates shared defaults from per-environment overrides, and show the terraform plan or apply command that loads both files correctly. </task> <constraints> Do not rely on variable precedence rules that are easy to get wrong, make the override behavior obvious from the file names alone, and keep secrets out of any tfvars file even in this layout. </constraints> <format> Return a file tree, one example shared tfvars file, one example environment override file, and the exact CLI command to apply one environment. </format>

You are a senior infrastructure engineer who breaks up monolithic Terraform configurations into modules. <context> Our root module for [STACK NAME] has grown to a single large file with [RESOURCE COUNT] resources and no reuse, and I need a phased plan to modularize it without a risky big bang rewrite. </context> <inputs> - Stack name: [STACK NAME] - Approximate resource count: [RESOURCE COUNT] - Groups of resources that belong together: [RESOURCE GROUPS] - Apply frequency for this stack: [APPLY FREQUENCY] </inputs> <task> Propose a phased refactor plan that extracts one resource group into a module at a time, using terraform state mv to avoid resource recreation, with each phase independently testable. </task> <constraints> Never suggest a refactor approach that would destroy and recreate existing resources, sequence phases so the riskiest group is not first, and keep each phase small enough to review in one pull request. </constraints> <format> Return a numbered list of phases, each with What Moves, State Commands Needed, and Verification Step. </format>

You are a senior infrastructure engineer who assesses Terraform provider upgrades before they ship. <context> We are considering upgrading the [PROVIDER NAME] provider from [CURRENT PROVIDER VERSION] to [TARGET PROVIDER VERSION] and I need to know what will break. </context> <inputs> - Provider name: [PROVIDER NAME] - Current version: [CURRENT PROVIDER VERSION] - Target version: [TARGET PROVIDER VERSION] - Resources we use heavily from this provider: [HEAVILY USED RESOURCES] </inputs> <task> List the categories of changes to check for in a provider major version bump, such as renamed arguments, removed resources, and changed default behaviors, and how to verify each against the heavily used resources listed. </task> <constraints> Do not claim to know the exact changelog contents, instead give a checklist approach the engineer can run against the real changelog and a plan diff, and flag that a plan-only dry run in a non-production workspace should happen first. </constraints> <format> Return a checklist with columns Check, Why It Matters, How To Verify, followed by a recommended rollout order. </format>

You are a senior infrastructure engineer who brings existing cloud resources under Terraform management. <context> Resources for [RESOURCE TYPE] in [ENVIRONMENT NAME] were created manually and now need to be imported into Terraform state without changing them. </context> <inputs> - Resource type: [RESOURCE TYPE] - Environment: [ENVIRONMENT NAME] - Resource identifiers to import: [RESOURCE IDENTIFIER LIST] - Current Terraform config coverage: [CURRENT CONFIG COVERAGE] </inputs> <task> Write a runbook for writing the matching resource blocks, running terraform import for each identifier, and running a plan afterward to confirm zero unexpected changes. </task> <constraints> Treat any non-empty plan diff after import as a signal that the resource block does not match reality and must be fixed before proceeding, do not skip the post-import plan check, and import one resource at a time rather than in bulk. </constraints> <format> Return numbered steps grouped under headers: Prepare Config, Import Commands, Verify, If Plan Shows Drift. </format>

You are a senior infrastructure engineer who cleans up aging Terraform configurations before a team takes them over. <context> I am inheriting a Terraform codebase for [STACK NAME] that has not been actively maintained and want a checklist to find the risky parts before I touch it. </context> <inputs> - Stack name: [STACK NAME] - Terraform version pinned in the code: [PINNED TERRAFORM VERSION] - Known pain points reported by the previous owner: [KNOWN PAIN POINTS] - Approximate age of the codebase: [CODEBASE AGE] </inputs> <task> Produce a checklist to audit the codebase for hardcoded values, unpinned provider versions, unused variables, and any resource using deprecated arguments. </task> <constraints> Prioritize findings that could cause a production incident over purely cosmetic issues, tie the checklist to the stated pain points where relevant, and do not recommend a full rewrite as the first step. </constraints> <format> Return a checklist grouped by severity: Fix Before Touching, Fix Soon, Fix When Convenient. </format>

You are a senior infrastructure engineer who plans Terraform migrations between cloud providers. <context> We are moving [WORKLOAD NAME] from [SOURCE PROVIDER] to [TARGET PROVIDER] and I need to know what in our current Terraform config has no direct equivalent. </context> <inputs> - Workload name: [WORKLOAD NAME] - Source provider: [SOURCE PROVIDER] - Target provider: [TARGET PROVIDER] - Current resource types in use: [CURRENT RESOURCE TYPES] </inputs> <task> Identify which current resource types have a close equivalent on the target provider, which require a different architecture entirely, and which have no managed equivalent and would need a custom solution. </task> <constraints> Do not assume feature parity between providers by default, call out any managed service with meaningfully different limits or pricing model on the target provider, and separate infrastructure gaps from application level changes that are out of Terraform's scope. </constraints> <format> Return a table with columns Current Resource, Target Equivalent, Gap Level, Notes. </format>

You are a senior DevOps engineer who designs CI pipelines for Terraform changes. <context> We currently apply Terraform manually from laptops for [STACK NAME] and I need to move this into a CI pipeline with proper gates. </context> <inputs> - Stack name: [STACK NAME] - CI system: [CI SYSTEM] - Environments needing separate approval: [ENV LIST] - Current apply process: [CURRENT APPLY PROCESS] </inputs> <task> Design a pipeline with stages for format check, validate, plan, a human approval gate before production apply, and apply, including what artifact carries the plan between stages. </task> <constraints> Never apply directly to production without a human approval step, pass the exact plan file between the plan and apply stages instead of re-planning at apply time, and keep credentials scoped per environment rather than one shared credential. </constraints> <format> Return a pipeline stage list with the command run at each stage and what gates it, followed by a short note on credential scoping. </format>

You are a senior platform engineer who writes policy as code rules to enforce Terraform standards automatically. <context> We keep merging Terraform changes that violate our standards for [POLICY AREA] because reviewers miss them by hand, and I want automated rules instead. </context> <inputs> - Policy area: [POLICY AREA] - Policy tool in use: [POLICY TOOL] - Specific standard being violated: [SPECIFIC STANDARD] - Environments the policy should apply to: [ENV LIST] </inputs> <task> Draft policy rules that check the specific standard against plan or configuration data, with a clear pass and fail example for each rule. </task> <constraints> Write rules that fail closed on missing data rather than silently passing, keep each rule scoped to one standard rather than one giant rule, and note which environments should warn only versus hard fail. </constraints> <format> Return each rule as a code block in the stated policy tool's syntax, followed by one pass example and one fail example per rule. </format>

You are a senior infrastructure engineer who standardizes Terraform pull request reviews. <context> Reviews for Terraform changes to [STACK NAME] are inconsistent, some reviewers check the plan and some only read the diff, and I want one checklist everyone uses. </context> <inputs> - Stack name: [STACK NAME] - Common mistakes seen in past pull requests: [COMMON MISTAKES] - Required approvers for production changes: [REQUIRED APPROVERS] - Where the plan output is posted for review: [PLAN OUTPUT LOCATION] </inputs> <task> Write a pull request review checklist covering what to check in the diff, what to check in the plan output, and when a second approver is required. </task> <constraints> Base at least half the checklist items on the stated common mistakes, keep each item phrased as a yes or no question a reviewer can actually answer, and do not require more approvers than the stated policy. </constraints> <format> Return the checklist as a markdown list grouped under headers: Diff Review, Plan Review, Approval Requirements. </format>

You are a senior infrastructure engineer who enforces resource tagging and naming standards across Terraform code. <context> Resources deployed by [TEAM OR ORG NAME] are inconsistently tagged, which breaks our cost allocation reports, and I need a way to enforce the standard going forward. </context> <inputs> - Team or org name: [TEAM OR ORG NAME] - Required tags: [REQUIRED TAG LIST] - Naming pattern required: [NAMING PATTERN] - Enforcement point available: [ENFORCEMENT POINT] </inputs> <task> Design a way to enforce the required tags and naming pattern at the stated enforcement point, such as a provider default_tags block, a policy check, or a module wrapper, and show a concrete example. </task> <constraints> Prefer enforcing at the earliest possible point such as default_tags over catching violations after the fact, account for resources that do not support all standard tags, and keep the example specific to the required tags and pattern given. </constraints> <format> Return a short recommendation, one code example implementing it, and a note on what happens when a resource cannot take all required tags. </format>

You are a senior infrastructure security engineer who designs access control for who can run Terraform against which environment. <context> Right now anyone with cloud credentials can apply Terraform changes to [ENVIRONMENT NAME], and I need a model that restricts this properly. </context> <inputs> - Environment: [ENVIRONMENT NAME] - CI or execution platform: [EXECUTION PLATFORM] - Roles that need some level of access: [ROLE LIST] - Compliance requirement driving this: [COMPLIANCE REQUIREMENT] </inputs> <task> Design an access model mapping each listed role to what it can do, such as propose a plan, approve an apply, or apply directly, and how that maps to actual permissions on the execution platform. </task> <constraints> Assume no individual should be able to both write the Terraform code and approve its own production apply, tie the model back to the stated compliance requirement, and note any role that currently has more access than this model would allow. </constraints> <format> Return a table with columns Role, Allowed Actions, Platform Permission, followed by a short gap note comparing this model to current access. </format>