How I Approach Learning and Onboarding Engineers to Terraform

Whenever I mentor engineers who are picking up Terraform for the first time, I see the same pattern. Most tutorials teach you how to put a whole cloud environment into a single main.tf file and run terraform apply from your laptop. That works for a weekend lab, but it is the exact opposite of how we run Infrastructure as Code in production.

Here is the approach I used to learn Terraform deeply and how I onboard teammates onto shared infrastructure repositories today.

1. Read the Provider Schema and API Docs Together

Terraform is really a declarative wrapper around cloud REST APIs. When you are learning a new resource in azurerm or aws, do not just copy a snippet from a blog post. Open the official provider documentation alongside the cloud provider's API docs.

Understanding which properties force a resource replacement (destroy and recreate) versus an in-place update is one of the most important skills in SRE. Catching a forced replacement on a stateful database or virtual network during terraform plan saves you from a very bad afternoon.

2. Keep State Files Small to Limit Blast Radius

One of the biggest mistakes teams make early on is putting networking, Kubernetes clusters, databases, and application settings into one giant Terraform state file. When everything lives in one state:

• terraform plan takes ten minutes to refresh.
• A broken state lock blocks every team at once.
• A bad apply can impact core networking while someone was just trying to update an app setting.

Split your infrastructure by lifecycle. Core networking and shared AKS clusters belong in their own state layers, separate from fast-moving application resources.

3. Treat terraform plan as a CI Gate, Not a Local Command

When you are practicing in a sandbox subscription, running terraform plan and terraform apply locally is fine, as long as you run terraform destroy when you finish so you do not rack up surprise cloud bills.

In a team environment, local applies should not happen. Every change should go through a pull request where CI runs terraform fmt -check, terraform validate, tflint, and posts the terraform plan output directly on the PR. Reading a plan output carefully is just as important as reviewing application code.

4. Build Modules for Standards, Not Just to Wrap Resources

Once you are comfortable provisioning raw resources, practice grouping related resources into modules. Good modules bake in your security and operational defaults, like enforcing TLS 1.2, turning on diagnostic logs, and attaching required cost tags, while keeping the input variables simple for the developer calling the module.

If a module has 60 input variables that just pass values straight through to a single resource, it is adding complexity without adding value. Keep modules focused on repeatable patterns that make the secure path the easiest path for your team.