Why Your Terraform State Is More Sensitive Than Your .env File
Terraform state can contain passwords, access keys, and a map of your infrastructure. Here is how I keep it out of Git, lock it in S3, and limit who can read it.
Infrastructure as Code
Need to change AWS infrastructure without guessing what Terraform will touch? I can help review the current stack, make the change, and check the plan before it is applied.
Where I can help with Terraform
Changes to an existing stack
Add or change AWS resources in your Terraform code. Start with the modules, state, account, and region you already use.
Plan and IAM review
Read the Terraform plan for replacements, downtime, and unexpected cost. Check generated IAM policies before a change reaches production.
Checks in the delivery pipeline
Add validation and plan checks to the pull request workflow so reviewers can see what will change before an apply.
What the work includes
Your existing conventions
I read the repository and its deployment rules before editing. Resource names, state location, account boundaries, and cost limits matter more than a generic template.
A reviewable plan
The change comes with a Terraform plan and a short explanation of additions, replacements, and anything that needs a human decision.
Checks before apply
Validation catches syntax and provider errors. The full plan catches changes validation cannot see, including resource replacement and drift.
A usable handoff
I document the commands, state assumptions, and review steps so your team can make the next change without rediscovering them.
How an engagement starts
1. Read the stack
I look at the repository, state backend, AWS accounts, deployment path, and the change you need to make.
2. Agree on the change
You and I identify the affected resources and decide what needs review or should stay out of scope.
3. Code and plan
I make the change, run validation, and review the plan with you before anything is applied.
4. Hand over
You get the code, the plan review notes, and the steps needed to maintain the change.
See the workflow before we talk
I wrote up how I use Claude Code with Terraform on AWS, including the context file, validation hooks, plan review, and the places where I still check everything myself.
Read my AWS and Terraform workflowSituations I get called in for
The state no longer matches the account
Someone fixed an incident in the AWS console. Now every plan shows changes nobody wrote, and the team is afraid to apply anything.
A small edit wants to replace the database
A rename or a changed attribute shows up as destroy and create on an RDS instance. I find out why before anyone types yes.
Resources Terraform has never seen
Part of the account was built by hand. I bring it under Terraform with import blocks and check that the next plan is empty.
One state file holds everything
Network, databases, and app services share one state. Every plan is slow, and every apply puts unrelated parts at risk. I split it along the lines that change at different speeds.
What I check first
The state backend and its lock
Where state lives, whether the S3 bucket has versioning on, and how locking works. Older setups lock with a DynamoDB table. Newer Terraform versions can lock in S3 itself with use_lockfile.
Every line that says must be replaced
On a stateful resource, forces replacement is where data loss starts. Sometimes the fix is a moved block. Sometimes it is prevent_destroy and a different change.
Version pins and the lock file
I check that the AWS provider and modules are pinned and that .terraform.lock.hcl is committed. A new major provider version can change defaults under you.
Drift before the change
I run terraform plan -refresh-only first. It shows what changed outside Terraform without proposing to touch real infrastructure. If the drift was intended, it goes into the code. If not, the next apply puts it back.
IAM inside the plan
Wildcard actions, iam:PassRole on every resource, and trust policies that let too many principals assume a role. These pass validation and still fail a review.