Terraform Roadmap: Learn Terraform for a Cloud Career

Why Terraform is worth learning for your cloud career

Infrastructure as code has moved from a “nice to have” to a baseline expectation in cloud engineering roles. Of all the IaC tools — CloudFormation, Pulumi, CDK, Bicep — Terraform is the most employer-neutral. It is not tied to a single cloud provider, which means Terraform experience transfers across AWS, GCP, and Azure jobs. This makes it a high-value investment relative to provider-specific alternatives.

The salary impact of Terraform knowledge is real. Engineers who can demonstrate genuine Terraform competency — meaning they have structured a real project, not just run a tutorial — are compensated differently from those who list it as a skill without backing it up. Interviewers probe for this distinction, and this roadmap will help you be on the right side of it.

Terraform is also a prerequisite for several advanced practices covered in the DevOps engineer roadmap, including GitOps workflows and CI/CD-driven infrastructure deployment.

Stage 1: HCL fundamentals — deploy something real (week 1–2)

Terraform’s configuration language is HCL (HashiCorp Configuration Language). It is declarative: you describe what you want, and Terraform figures out how to create, update, or delete resources to match your description.

Core HCL concepts to learn at Stage 1:

• Providers — plugins that let Terraform talk to a specific API (e.g., hashicorp/aws, hashicorp/google, hashicorp/azurerm). Configure a provider block with your credentials and region.
• Resources — the fundamental building block. A resource block declares one piece of infrastructure: an S3 bucket, a GCS bucket, a virtual machine. Learn the pattern: resource “provider_type” “local_name” { … }.
• Variables — parameterise your configuration using variable blocks. Pass values via terraform.tfvars files or -var flags. Understand type constraints (string, number, bool, list, map).
• Outputs — expose values from your configuration using output blocks. Useful for referencing resource attributes (e.g., the IP address of a created VM) and for module composition.
• The Terraform workflow — terraform init (downloads providers), terraform plan (shows what will change), terraform apply (makes it so), terraform destroy (removes everything).
• State — Terraform tracks what it has created in a state file (terraform.tfstate). Do not edit this file manually. Understand conceptually that state is how Terraform knows the difference between “resource already exists” and “resource needs to be created.”

Do not stop at a tutorial VM. Deploy something that has at least two connected resources — for example, a storage bucket and an IAM policy that grants access to it, or a virtual network and a VM running inside it. This forces you to understand resource dependencies and Terraform’s dependency graph.

At Stage 1, keep state local (the default). You will fix this in Stage 2.

Stage 2: Modules, remote state, and real project structure (week 3–6)

This is the stage where most self-taught learners stall, and it is the most important stage for your career. Learning HCL syntax is the easy part. Learning how to structure a Terraform project that a team can actually use is what separates candidates who “know Terraform” from those who can be trusted with it.

The most common Terraform career mistake is learning the syntax without ever learning how to organise a real project. If your Terraform knowledge is limited to a single flat directory with a main.tf and local state, you will struggle in interviews and on the job. The patterns below are what teams actually use.

Modules

A Terraform module is a directory of .tf files with a defined interface (variables in, outputs out). Modules let you package reusable infrastructure patterns and call them from multiple places. The module pattern looks like this:

• Create a modules/ directory. Inside it, create subdirectories for each logical component: modules/vpc/, modules/compute/, modules/database/.
• Each module directory contains main.tf, variables.tf, and outputs.tf.
• Call modules from a root configuration using module “name” { source = ”./modules/vpc” … }.

Practice writing a module for something you have already built in Stage 1. The act of extracting it into a module forces you to think about what the interface should be.

Remote state

Local state (terraform.tfstate on your laptop) does not work for teams. Remote state stores the state file in a shared location — an S3 bucket, a GCS bucket, or Terraform Cloud. Configure a remote backend using the terraform { backend “s3” { … } } block. Enable state locking to prevent concurrent modifications.

State locking on S3 uses a DynamoDB table. On GCS, locking is built in. Learn how to configure both so you understand the pattern regardless of cloud provider.

Workspaces and environment separation

Terraform workspaces let you manage multiple instances of the same configuration (e.g., dev, staging, prod) without duplicating code. Use terraform workspace new dev and terraform workspace select prod. The current workspace name is available as terraform.workspace inside your configuration.

Note: many teams prefer separate directories or separate state files per environment over workspaces, because workspaces share the same backend configuration and can cause confusion at scale. Learn workspaces, but understand why teams sometimes choose the directory-per-environment pattern instead.

Data sources

Data sources let you query existing infrastructure that Terraform did not create. For example, look up the ID of an existing VPC: data “aws_vpc” “existing” { filter { … } }. This is how you reference resources managed by other teams or other Terraform configurations.

Stage 3: CI/CD integration, team patterns, and importing resources (week 7–12)

Stage 3 is about using Terraform in a team context with automated pipelines. This is the standard in any company with mature engineering practices, and it is what mid-level cloud engineering interviews often probe.

CI/CD for Terraform

The pattern is consistent regardless of CI system: on a pull request, run terraform plan and post the plan output as a comment. On merge to main, run terraform apply automatically or with a manual approval gate. Implement this using GitHub Actions, GitLab CI, or Cloud Build.

A minimal GitHub Actions workflow for Terraform runs these steps: checkout, terraform init, terraform fmt —check (fails if formatting is wrong), terraform validate, terraform plan. Store cloud credentials as GitHub Actions secrets, not in your .tf files.

Importing existing resources

In real jobs, you will often need to bring existing manually-created infrastructure under Terraform management. Use terraform import resource_type.name resource_id to import a resource into state. After importing, write the corresponding HCL configuration to match the existing resource. This is a common task that many tutorials skip.

Terragrunt basics

Terragrunt is a thin wrapper around Terraform that adds DRY (Don’t Repeat Yourself) patterns for large codebases — particularly for managing many environments and accounts. It handles remote state configuration inheritance and module composition across a directory tree. You do not need deep Terragrunt expertise at Stage 3, but understand what problem it solves and be able to explain it.

Collaboration patterns

Learn about the .terraform.lock.hcl file (commit it to version control — it locks provider versions). Understand why you should pin provider versions in the required_providers block. Practice code review for Terraform changes — what to look for in a terraform plan output.

Stage 4: HashiCorp Terraform Associate certification and advanced HCL (month 4–5)

The HashiCorp Terraform Associate certification validates foundational Terraform knowledge. It is a multiple-choice exam covering HCL syntax, the Terraform workflow, state management, modules, and Terraform Cloud features. It is not a hands-on exam like the CKA, which makes it less demanding — but it is a credible signal to employers, particularly in the AWS ecosystem where it is widely recognised.

Prepare using the official HashiCorp study guide and Udemy courses from recognised instructors (Bryan Kransen’s course is well regarded). Expect 2–3 weeks of preparation if you are already at Stage 3.

Advanced HCL patterns to learn alongside certification preparation:

• Dynamic blocks — generate nested configuration blocks programmatically. Useful when the number of blocks is determined at runtime (e.g., dynamic security group rules from a variable list).
• for_each and count — create multiple instances of a resource. Prefer for_each over count when the instances have distinct identities, because count-based resources are indexed by number and can behave unexpectedly when items are removed from the middle of a list.
• Conditional expressions — condition ? true_val : false_val. Used to make resource creation optional or to switch between configurations based on a variable.
• Local values — locals { … } blocks for intermediate computed values. Avoid duplicating expressions across your configuration.
• depends_on — explicitly declare dependencies when Terraform cannot infer them from resource references alone. Use sparingly — if you need it often, your module boundaries may be wrong.

Stage 5: Terraform Cloud, Enterprise, and policy as code (ongoing)

Stage 5 covers the enterprise patterns that appear in larger organisations. These are not required for most individual contributor roles, but are relevant for senior engineers and those working in regulated industries.

Terraform Cloud provides remote state, remote plan/apply execution, team access controls, and a UI for viewing run history. The free tier supports small teams. The paid tiers add Sentinel policy enforcement, audit logging, and SSO. In interviews, knowing the difference between the free and paid feature sets signals familiarity with real-world constraints.

Policy as code — Sentinel (HashiCorp’s policy language) and OPA (Open Policy Agent) both let you enforce rules on Terraform plans before they are applied. For example, “deny any plan that creates a public S3 bucket” or “require all resources to have a cost-centre tag.” Sentinel is Terraform Cloud-native; OPA with the conftest tool works in any CI pipeline. Learn the concept and write at least one policy in whichever tool you choose. This overlaps with the cloud security roadmap skill of enforcing compliance via automation.

Terraform CDK (CDKTF) — lets you write Terraform configurations in TypeScript, Python, Go, or Java instead of HCL. Relevant if you are joining a team with strong programming language skills and less appetite for HCL. Not required for most roles.

What Terraform interviews actually test

Terraform interview questions follow predictable patterns. Being prepared for these is more efficient than reading every page of the Terraform documentation.

”Explain the Terraform workflow.” This is a screening question. The expected answer covers init, plan, apply, and destroy, with a clear explanation of what each does. Add: plan shows a diff, apply makes changes, and state is how Terraform tracks what exists.

”How do you manage multiple environments in Terraform?” There are multiple valid answers — workspaces, directory-per-environment, or separate state files. The interviewer is checking that you have thought about this and can explain trade-offs. A candidate who says “I use a different folder for dev, staging, and prod with separate backends” demonstrates more real-world experience than one who says “workspaces” without qualification.

”What is Terraform state and why does it matter?” Explain that state is Terraform’s record of what infrastructure it manages. Without state, Terraform cannot know the difference between existing resources and new ones. Explain why remote state matters for teams. Mention state locking.

”How do you structure Terraform for a team?” This is where Stage 2 knowledge pays off. Describe the module pattern, remote state backend, CI/CD integration, and environment separation. Candidates who can answer this in detail stand out from those who have only done tutorials.

”Have you used Terraform in a CI/CD pipeline?” If you have built the Stage 3 project, yes. Describe the workflow: PR triggers plan, merge triggers apply. Mention how credentials are handled (environment variables or OIDC, not hardcoded).