Terraform Roadmap: What to Learn and What to Skip

Why Terraform comes after AWS

At the last step, you built your setup by clicking, then rebuilt it from notes. It was slow, and you probably missed a setting. Terraform solves that problem. You describe what you want in text files, and it works out what to create, change or delete.

You had to do it by hand first. A Terraform file full of subnets and route tables means little if you have never built one. When a plan looks wrong, your AWS knowledge is how you can tell.

What to learn, in order

1. The core loop. Learn terraform init, plan and apply from the AWS tutorials. Start with one S3 bucket, so that an error has only one possible cause.
2. Reading a plan. This is the most important skill on this page. + creates, ~ changes in place, - deletes, and -/+ deletes and then creates. Read that last one twice when it is on a database.
3. Variables and outputs. Variables let you change a value without editing the code. Outputs show useful values such as your load balancer's address.
4. State. State is the file where Terraform records what it created. It is how Terraform knows what to change, so losing it causes real pain.
5. Remote state with locking. Move state to the S3 backend with use_lockfile = true and bucket versioning on. Locking stops two runs from changing state at the same time. Older tutorials use DynamoDB for this, but the docs now mark that as deprecated.
6. Rebuild your AWS setup. Work from your notes, one piece at a time: network, then server, then database. Run a plan after each piece.
7. One module. A module is a reusable folder of Terraform code. Write one for something you repeat, such as your network. One is enough to learn the idea.
8. Importing and drift. Drift is when someone changes a resource by hand, so it no longer matches your code. Change something in the console, then see what the plan says. Learn terraform import for resources made by hand.
9. Plan in CI. Run terraform plan on each pull request, in the pipeline you built. Give it AWS access with OIDC (short-lived logins with no stored keys).

What to skip for now

• Terragrunt and Pulumi. Learn the plain tool first.
• Complex workspaces and setups with many environments.
• Writing your own providers (the plugins that talk to services like AWS).
• Testing frameworks, beyond running terraform validate and terraform fmt.

Common mistakes

• Committing state to Git. State can hold secrets in plain text, and Git gives you no locking. Add *.tfstate* and .terraform/ to .gitignore before your first commit.
• Applying without reading the plan. -auto-approve is how databases get deleted. On anything you care about, read each line. terraform plan -out=tfplan followed by terraform apply tfplan makes sure you apply what you read.
• Fixing things in the console. The next plan will try to undo your fix. Change the code, or update the code to match.
• Being surprised by a failed destroy. An RDS instance needs skip_final_snapshot = true to delete with no final backup. A bucket with files in it needs force_destroy = true. Use these in your practice setup only. They are risky on real data.
• Expecting Terraform to manage its own state bucket. Create that bucket by hand or in a small separate setup. Otherwise destroy is trying to delete the place its own records live.

OpenTofu in one minute

In August 2023, HashiCorp moved Terraform's future releases from an open source license to the Business Source License. OpenTofu is a fork (a separate copy of the code) that came out of that change. It sits under the Linux Foundation and describes itself as a drop-in replacement. You run tofu plan instead of terraform plan. Learn either one, and you can pick up the other quickly. Do not spend study time on this choice.

Jobs to apply for after this stage

You now have Linux, a pipeline, one cloud and infrastructure code. In our judgment, cloud support, junior cloud engineer and junior platform roles are realistic to apply for from here. "DevOps engineer" is rarely a first job title. You can keep working through this roadmap while you apply, and paid time on real systems teaches things a study project cannot.

Your project

Turn your AWS notes into Terraform, so that one command builds everything and one command removes it. Then run this test: terraform destroy, terraform apply, and check that the app works. You may need to restore the database from your S3 backup, which is good practice. Run destroy at the end of each session as well, since it saves you money. Keep the code in Git, with every change going through a pull request.