Blog
Thoughts on engineering, design, and building great products.
Reading Another State and Refactoring: remote_state, moved, removed
When you split infrastructure across multiple states, terraform_remote_state lets one config read the output of another. And when reorganizing code, the moved block renames a resource without destroy-recreate, the removed block drops a resource from state without destroying it — both declared right in the configuration instead of the manual state mv/rm commands from Article 7.
Multiple Environments: Workspaces and Directory Layout
Dev, staging, prod need separate state. There are two ways: workspaces keep multiple states in the same backend, and directory layout splits each environment into its own directory with its own backend. This article demos both, and shows clearly why workspaces are NOT a good fit for strong separation between prod and dev — exactly the docs' warning.
Secrets: sensitive, ephemeral, and Write-Only Arguments
State stores secrets in plaintext — this article tackles exactly that. sensitive only hides output but still writes to state; ephemeral resources and write-only arguments (Terraform 1.10/1.11) actually keep secrets out of state. Live demo: with the same password, the old way leaks into state while write-only does not.
State Operations: import Block, state mv, state rm
Working with state day to day: bring existing infrastructure under management with the import block and auto-generate configuration with -generate-config-out, rename a resource in state with state mv, and remove a resource from management without deleting it with state rm. All run live against a bucket built by hand beforehand.
Remote State on S3 With use_lockfile
State sitting on your personal machine can't be shared, isn't safe, and two people running at once will overwrite each other. This article moves state to S3: bootstrap a bucket with versioning and encryption, configure the backend, and enable state locking with use_lockfile — the current approach replacing the deprecated DynamoDB. With a real lock-conflict demo.
The Dependency Graph: Implicit, depends_on, and -target
Terraform infers the order of creating and deleting resources from a dependency graph. This article dissects that graph: implicit dependencies arise from references, viewing it directly with the graph command, why destroy reverses the order, when you need depends_on, and why -target is only an escape hatch.
State: What Terraform Stores, Why It's Needed, and Drift
Dig into the state file: why Terraform needs it instead of asking AWS directly each time, what exactly it stores, and the refresh mechanism that compares config, state and reality three ways. Create drift by hand with the AWS CLI then watch Terraform detect it, and the difference between a normal plan and plan -refresh-only.