Terraform Cert Guide Chapter 6: How Teams Actually Use Terraform Workflows

Chapter 6 is where the book stops talking about individual commands and starts showing you how they all fit together. If the previous chapters were about learning the notes, this one is about playing the song.

The core idea here is the Terraform lifecycle: init, plan, apply, destroy. Four steps. That’s it. But understanding how they connect and when to use each one is what separates someone who knows Terraform from someone who actually uses it well.

The Terraform Lifecycle: Write, Plan, Apply

Every Terraform workflow follows the same basic loop. You write your config files, you preview what’s going to happen, and then you make it happen. Simple enough on paper.

Here’s how each step works.

terraform init

This is always step one. Every single time. You run terraform init and it does a few things:

• Downloads provider plugins (like the Azure, AWS, or GCP provider)
• Sets up the backend where your state file lives
• Downloads any modules your config references

You need to re-run init when you add a new provider, change a module version, or switch backends. The good news is that it’s safe to run as many times as you want. It won’t delete your config or state. Worst case, you get an error message telling you something’s wrong.

After init runs, you’ll see a .terraform folder in your working directory. That’s where all the downloaded plugins live. You’ll also get a .terraform.lock.hcl file that locks your provider versions. Commit that lock file to version control so everyone on your team uses the same versions.

terraform validate

Before you plan or apply anything, you can run terraform validate to check for syntax errors. It catches stuff like typos in argument names or missing required fields.

Here’s the thing though: you don’t technically need to run it manually. Both terraform plan and terraform apply run validation automatically. But it’s nice to have as a quick sanity check, especially in CI pipelines where you want fast feedback.

One thing validate does NOT check: formatting. If your tabs and spaces are messy, use terraform fmt for that.

terraform plan

This is where you see what Terraform wants to do before it does it. Think of it as a dry run.

When you run terraform plan, Terraform looks at your config files, checks the current state, and tells you exactly what it’s going to create, modify, or destroy. You’ll see output like:

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

That’s Terraform saying “I’m going to create one thing, change nothing, and delete nothing.”

A few useful flags for plan:

• -out=plan.txt saves the plan to a file. You can then pass that file to terraform apply "plan.txt" to apply exactly what was planned. This is important for CI/CD pipelines because it guarantees nothing changes between plan and apply.
• -var 'key=value' lets you pass variable values directly
• -var-file="filename" reads variables from a file
• -target=resource limits the plan to a specific resource and its dependencies
• -destroy generates a plan that would destroy everything (without actually destroying it)

About variables: Terraform looks for values in a specific order. CLI flags override everything, then .tfvars or .auto.tfvars files, then default values in the variable declaration. Keep that priority order in mind.

terraform apply

Once you’re happy with the plan, terraform apply makes it real. It provisions, updates, or deletes resources to match your config.

By default, apply shows you the plan again and asks for confirmation. You type “yes” and it goes to work. If you want to skip the confirmation (for automation), you can use -auto-approve. But the book warns against using that casually. Always review what Terraform is about to do, especially in production.

You can also feed a saved plan file to apply: terraform apply "plan.txt". This is the recommended approach for pipelines because the plan you reviewed is exactly what gets executed.

terraform destroy

Sometimes you need to tear everything down. Maybe it’s a test environment, maybe you’re cleaning up after a demo. terraform destroy deletes all the resources in your state file.

It’s a serious command. It shows you what it’s going to delete and asks for confirmation. Once it runs, there’s no undo button.

The book also shows a less obvious way to destroy things: run terraform plan -destroy -out delete.txt to create a destroy plan, then terraform apply "delete.txt" to execute it. Same result, different approach. This can be useful when you want to review a destroy plan the same way you review a create plan.

One detail worth remembering: Terraform locks the state file during any of these operations. That prevents two people from running apply at the same time and stepping on each other’s changes.

Bringing in CI/CD

Using Terraform from your laptop is fine for learning. But real teams don’t work that way. Chapter 6 walks through setting up Terraform with Azure DevOps as an example of how CI/CD pipelines work with infrastructure code.

The workflow looks like this:

1. Store your Terraform code in a repo (Azure Repos, GitHub, whatever)
2. Create a CI pipeline that runs on every push. It runs terraform init, terraform validate, and terraform plan to make sure things look correct
3. Create a CD/release pipeline that runs terraform apply to actually provision resources

The book uses Azure DevOps specifically. You create a project, set up a service connection to your Azure subscription (so the pipeline has permissions to create resources), push your Terraform files to the repo, and define your pipeline in YAML.

The key steps in the pipeline are the same commands you’d run locally: init, plan, apply. The difference is that a pipeline runs them automatically, consistently, and with proper access controls.

This pattern isn’t unique to Azure DevOps. You can do the same thing with GitHub Actions, GitLab CI, Jenkins, CircleCI, or whatever your team uses. The Terraform commands stay the same. Only the pipeline syntax changes.

Why This Matters for Teams

When you’re working alone, the workflow is straightforward. You write code, plan, apply, done. But when multiple people are working on the same infrastructure, things get complicated fast.

That’s where remote backends and state locking become critical. If two people run terraform apply at the same time with a local state file, one of them is going to overwrite the other’s changes. Remote backends (like Azure Blob Storage or S3) with state locking prevent that.

CI/CD pipelines add another layer of safety. Instead of everyone running apply from their laptops, you funnel all changes through a pipeline. Code gets reviewed in a pull request, the pipeline runs plan so everyone can see what’s changing, and only after approval does apply run. It’s the same workflow developers use for application code, just applied to infrastructure.

My Take

Chapter 6 is a short chapter but an important one. It takes the individual commands from Chapter 5 and shows you the bigger picture of how they work together.

The lifecycle itself is simple. The real value is understanding how to use it in a team context. Saving plan outputs, using remote backends, running through CI/CD pipelines. That’s what separates “I know the commands” from “I can work on a team that manages infrastructure with Terraform.”

If you’re studying for the certification exam, make sure you know the order of operations (init, validate, plan, apply, destroy), the key flags for each command, and how variable precedence works. Those are the kinds of things that show up on the test.

Previous: Chapter 5: Terraform CLI

Next: Chapter 7 Part 1: Terraform Modules

This is part of a series retelling “HashiCorp Infrastructure Automation Certification Guide” by Ravi Mishra (Packt, 2021). For the full text, grab the book - ISBN: 978-1-80056-597-5.