Infrastructure as Code for Beginners

Here is an abridged plan for a worked example. It is illustrative, and the values are made up. Somebody changed the name of a database in a Terraform file, ran terraform plan, and got this.

Terraform will perform the following actions:

  # aws_db_instance.main must be replaced
-/+ resource "aws_db_instance" "main" {
      ~ identifier = "shop-db" -> "shop-database" # forces replacement
      ~ endpoint   = "shop-db.example.rds.amazonaws.com" -> (known after apply)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

The whole point of infrastructure as code is in the last line. One to add and one to destroy is not a rename. It is a new empty database and the death of the old one. The name change looked harmless in the file. The plan shows what it really does.

That covers the idea. Instead of clicking a server, a database and a load balancer into existence in a cloud console, you write a file that says what should exist. A tool compares the file with what is running and makes the two match.

Automation is a side effect. The real gain is that your infrastructure becomes reviewable. A change is a pull request. A diff shows what will happen. Six months later, the history says who changed what and why, and it does not depend on anyone remembering a click.

Three names cover most beginner questions. They work the same way underneath. You describe the state you want, the tool plans the difference, and applying the plan changes real things. What differs is how you write it and who looks after it.

For a beginner the language matters less than the community. Pick the one whose examples you keep finding when you search for your problem. If your team lives in TypeScript, Pulumi will feel natural. If you want the widest set of examples, Terraform or OpenTofu is the safer bet. We compare the two head to head in Terraform vs Pulumi.

That preview is most of the safety in the whole practice. It turns "I hope this is fine" into a list somebody else can review. Three habits make it work.

• Read every line marked - or -/+ each time, not only when you remember. Most incidents come from a replace nobody spotted.
• Save the plan and apply that exact file. terraform plan -out writes it, and terraform apply takes it, so what you approved is what runs. Treat the file as sensitive: HashiCorp warns that sensitive values are saved in cleartext inside it.
• Guard the things you cannot lose. Setting prevent_destroy to true makes Terraform reject any plan that would destroy that resource. It is not a lock, though. The docs note that removing the resource's configuration bypasses it.

Two more pitfalls catch beginners. The first is drift. Somebody fixes something by hand during an incident, and the file no longer matches reality. Terraform has a refresh-only plan for this. It updates state to match changes made to remote objects outside of Terraform, so you see the difference before you decide which side is right. The second is the replace itself. The create_before_destroy rule tells Terraform to build the replacement first and remove the old resource afterwards. It suits things like a server behind a load balancer. The docs add a caveat: it stops a destroy-time provisioner from running. It also does not rescue a database, because a new empty database is still empty.

1. 1Pick one low-stakes resourceA storage bucket, a DNS record or a small test server. Not your production database. You are learning the loop, not migrating.
2. 2Write it, then run init and planterraform init downloads the provider. terraform plan shows a single + line. Read it aloud to a colleague if you can.
3. 3Apply, then change one argument and plan againRename a tag and watch a ~ appear. Then change something that forces replacement and watch -/+. Seeing both in a safe place is worth an hour.
4. 4Move state somewhere sharedA local state file is fine for one person on day one. The moment a second person joins, use a remote backend with locking.
5. 5Put plan in your pull requestsRun terraform plan with -detailed-exitcode in CI. Exit code 0 means no changes, 1 means an error, and 2 means there are changes to review.
6. 6Import what already exists, slowlyBring hand-made resources under management one at a time. Importing the whole estate in one go is how people end up with a plan nobody trusts.

The state file is how Terraform remembers what it built. HashiCorp describes it as a source of truth for your environment, and the tool uses it to work out the changes needed to match your configuration. Lose it or corrupt it, and the tool no longer knows what exists.

That is the whole case for a remote backend. Shared state means everyone plans against the same picture, and state locking stops two people applying at once. Set it up early. Moving state later is possible but fiddly.

Honestly, sometimes. One app on one platform, changed twice a month by one person, can live happily on a dashboard. The file starts to pay off when you have several environments, several people, or changes you want reviewed.

There is a middle path. Some platforms build the plan into the platform, so you get the preview without owning a Terraform project. The team-level version of the same idea is covered in what an internal developer platform is.

Helm7 applies the plan habit to its own API. Every operation that changes infrastructure takes dry_run set to true and returns the ordered changes, a monthly cost band, the largest cost by name, and a plain list of anything that could not be undone. Destructive operations refuse to run until confirm is set. It works the same for a person at a terminal and for an AI agent. See how agents use it and the dry-run deployment plan for the detail.