Infrastructure as Code (IaC) has transformed the way modern teams provision, manage, and version‑control their cloud environments. Terraform, with its declarative language and provider‑agnostic design, sits at the heart of many advanced DevOps pipelines. In this guide we’ll walk through every critical phase—from installing the binary to wiring Terraform into a CI/CD system—so you can build reliable, repeatable infrastructure that lives in source control and scales with your organization. Whether you’re orchestrating multi‑region VPCs, spinning up Kubernetes clusters, or managing SaaS integrations, the patterns covered here will give you a solid foundation for production‑grade IaC.
What You’ll Need
- A Unix‑like shell (Linux, macOS, or WSL on Windows)
- Terraform 1.6+ installed
- An AWS, Azure, or GCP account with appropriate IAM permissions
- Git and a remote repository (GitHub, GitLab, or Bitbucket)
- Optional: Docker for local testing, and a CI runner (GitHub Actions, GitLab CI, etc.)
Step 1: Install Terraform and Verify the Installation
Download the latest stable release from HashiCorp’s website or use a package manager. For macOS with Homebrew:
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
terraform -versionOn Ubuntu you can use the official apt repository:
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
echo "deb [arch=$(dpkg --print-architecture)] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform
terraform versionConfirm the binary is on your PATH and that the version matches the documentation you plan to follow.
Step 2: Initialise a Git Repository and Set Up Branching
IaC lives in source control just like application code. Create a dedicated repo and enforce a branching strategy (e.g., main for production, dev for ongoing work). Initialise the repo and add a .gitignore that excludes Terraform state files and the .terraform directory:
git init terraform-iac
cd terraform-iac
cat > .gitignore <<EOF
*.tfstate
*.tfstate.backup
.terraform/
crash.log
EOF
git add .gitignore
git commit -m "Add gitignore for Terraform files"This protects sensitive data and keeps your repository clean.
Step 3: Define Provider Configuration and Remote State Backend
Every Terraform project starts with a provider block that tells Terraform which cloud to talk to. In addition, store the state remotely (S3, Azure Blob, GCS) to enable collaboration and avoid lock conflicts.
# providers.tf
terraform {
required_version = ">= 1.6"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
backend "s3" {
bucket = "my-terraform-state"
key = "global/s3/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "terraform-locks"
}
}
provider "aws" {
region = var.aws_region
}
Make sure the S3 bucket and DynamoDB table exist before the first terraform init. You can bootstrap them with a simple one‑off Terraform run or create them manually via the console.
Step 4: Create Reusable Modules for Core Resources
Modules encapsulate best‑practice configurations and make your code DRY. Let’s build a VPC module that can be consumed across environments.
# modules/vpc/main.tf
resource "aws_vpc" "this" {
cidr_block = var.cidr_block
enable_dns_hostnames = true
tags = merge({ Name = var.name }, var.tags)
}
resource "aws_subnet" "public" {
count = length(var.public_subnets)
vpc_id = aws_vpc.this.id
cidr_block = var.public_subnets[count.index]
map_public_ip_on_launch = true
availability_zone = element(var.azs, count.index)
tags = merge({ Name = "${var.name}-public-${count.index}" }, var.tags)
}
# variables.tf
variable "cidr_block" { type = string }
variable "name" { type = string }
variable "azs" { type = list(string) }
variable "public_subnets" { type = list(string) }
variable "tags" { type = map(string), default = {} }
Commit the module directory, then reference it from the root module:
# main.tf
module "vpc" {
source = "./modules/vpc"
name = "prod-vpc"
cidr_block = "10.0.0.0/16"
azs = ["us-east-1a", "us-east-1b", "us-east-1c"]
public_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
tags = { Owner = "infra-team" }
}
Modules keep your codebase maintainable as you add more services (RDS, EKS, IAM, etc.).
Step 5: Initialise the Working Directory and Generate an Execution Plan
Run terraform init to download providers, configure the backend, and initialise the module cache.
terraform init -reconfigureThe -reconfigure flag forces Terraform to re‑evaluate the backend settings, which is handy when you change remote state locations.
Next, validate your configuration and preview the changes Terraform will make:
terraform validate
terraform fmt -check
terraform plan -out=tfplan.outThe -out flag saves the plan for a later apply, ensuring that what you reviewed is exactly what gets executed.
Step 6: Apply the Plan and Verify Resources
With the plan saved, apply it in a controlled manner:
terraform apply "tfplan.out"Terraform will ask for confirmation unless you provide -auto-approve. After the run completes, verify the resources through the cloud console or CLI:
aws ec2 describe-vpcs --vpc-ids $(terraform output -raw vpc_id)Outputs are defined in a dedicated outputs.tf file, making downstream consumption (e.g., for other modules or CI scripts) straightforward.
Step 7: Manage State, Workspaces, and Secrets
For multi‑environment deployments, Terraform workspaces let you reuse the same code with isolated state files.
# Create a workspace for staging
terraform workspace new staging
# Switch back to production
terraform workspace select defaultNever store raw credentials in the repo. Use environment variables or a secrets manager (AWS Secrets Manager, Vault). Example for AWS:
export AWS_ACCESS_KEY_ID=$(aws secretsmanager get-secret-value --secret-id ci/aws-key --query SecretString --output text | jq -r .access_key)
export AWS_SECRET_ACCESS_KEY=$(aws secretsmanager get-secret-value --secret-id ci/aws-key --query SecretString --output text | jq -r .secret_key)
This approach keeps your state secure and complies with least‑privilege principles.
Step 8: Integrate Terraform into a CI/CD Pipeline
Automating Terraform runs reduces human error and speeds up delivery. Below is a minimal GitHub Actions workflow that lints, plans, and applies on merge to main:
# .github/workflows/terraform.yml
name: Terraform CI
on:
push:
branches:
- main
jobs:
terraform:
runs-on: ubuntu-latest
env:
TF_VAR_aws_region: us-east-1
steps:
- uses: actions/checkout@v4
- name: Set up Terraform
uses: hashicorp/setup-terraform@v2
with:
terraform_version: 1.6.0
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ${{ env.TF_VAR_aws_region }}
- name: Terraform Init
run: terraform init -backend-config="bucket=my-terraform-state" -backend-config="key=github/${{ github.sha }}/terraform.tfstate"
- name: Terraform Format Check
run: terraform fmt -check -recursive
- name: Terraform Validate
run: terraform validate
- name: Terraform Plan
id: plan
run: terraform plan -out=plan.out
- name: Terraform Apply
if: github.ref == 'refs/heads/main'
run: terraform apply -auto-approve plan.out
Adjust the workflow to your provider and add manual approval steps for production if needed.
Common Mistakes to Avoid
1 Hard‑coding credentials: Storing keys in .tfvars or the repo leads to leaks. Use environment variables or secret stores.
2 Neglecting state locking: Without DynamoDB (AWS) or equivalent, concurrent runs can corrupt state.
3 Skipping terraform fmt and validate: Inconsistent formatting makes code reviews painful and hidden syntax errors can creep in.
4 Over‑using -auto-approve in production: Always review the plan, especially when destroying resources.
5 Mixing providers in a single module: Keep provider configuration at the root level; modules should be provider‑agnostic whenever possible.
Tips and Tricks
• Use terraform console to experiment with expressions and data sources interactively.
• Leverage for_each and dynamic blocks to generate resources from maps or lists, reducing repetition.
• Version‑pin modules in a versions.tf file to avoid accidental breaking changes.
• Enable detailed logging with TF_LOG=DEBUG when troubleshooting obscure provider errors.
• Adopt Sentinel or OPA policies for policy‑as‑code enforcement in larger organisations.
Frequently Asked Questions
Do I need to use a remote backend for small projects?
While local state works for experiments, a remote backend (S3, Azure Blob, GCS) provides locking, versioning, and team collaboration—features that quickly become essential as your infrastructure grows.
How can I safely destroy an entire environment?
Create a dedicated workspace for the environment, run terraform plan -destroy to review, and apply only after a manual approval gate. Keep the state file in a separate bucket/key prefix to avoid accidental removal of production resources.
Can Terraform manage SaaS resources like GitHub or Datadog?
Yes. Terraform has providers for many SaaS platforms. Add the provider block (e.g., provider "github" { token = var.github_token }) and treat those resources the same way as cloud resources—store secrets securely and version‑control the configuration.
Conclusion
Implementing Infrastructure as Code with Terraform at an advanced level is less about memorising syntax and more about adopting disciplined workflows, secure state management, and automation. By following the eight steps above—installing Terraform, version‑controlling your code, configuring a remote backend, modularising resources, planning before applying, handling state and workspaces, and finally wiring everything into CI/CD—you’ll achieve repeatable, auditable, and scalable infrastructure deployments. Avoid common pitfalls, leverage the tips, and keep learning from the vibrant Terraform community. Your cloud environments will become as reliable as the code that defines them.
