Infrastructure as Code with Terraform

0 of 18 lessons complete (0%)
Exit Course

Module 1: Infrastructure as Code Foundations

Why Infrastructure as Code, and How Terraform Works

This is a preview lesson

Register or sign in to take this lesson.

The concept

Infrastructure as Code (IaC) means describing servers, networks, databases and permissions in text files that are version controlled, reviewed and applied by a tool, instead of clicking through a cloud console. The files are the source of truth. If the infrastructure drifts, you can see it. If something breaks, you can read the history. If you need a second environment, you apply the same files with different inputs.

Why it matters

  • Repeatability: staging and production are built from the same definitions, so differences are deliberate, not accidental.
  • Review: changes go through pull requests like application code. A reviewer can see that a security group is about to open a port to the world before it happens.
  • Recovery: rebuilding an environment after a disaster is a matter of running the tool, not reconstructing a console session from memory.
  • Documentation: the code is the inventory. Nobody has to maintain a spreadsheet of what exists.

How Terraform works

Terraform is a declarative tool. You write configuration describing the desired end state, such as one virtual network, two subnets and a database. Terraform compares that to what currently exists, computes the set of create, update and delete operations needed to close the gap, shows you that plan, and executes it on approval. It does not run step-by-step scripts; it reconciles state.

Three pieces make this possible.

  • Configuration: files ending in .tf written in HashiCorp Configuration Language (HCL).
  • Providers: plugins that know how to talk to a specific platform. There are providers for the major clouds, DNS services, version control systems, monitoring tools and hundreds more. The same workflow applies to all of them.
  • State: a file in which Terraform records the real-world identifiers of everything it created, so it can map configuration to reality on the next run.

A worked example

A team manages a storage bucket by hand. Someone changes its access policy in the console to debug an issue and forgets to revert it. Months later, data is exposed. With Terraform, the bucket policy is in a file. The manual change shows up as drift on the next plan, and the team either reverts it with apply or deliberately codifies it through a reviewed change. The accidental state cannot persist unnoticed.

resource "aws_s3_bucket" "reports" {
  bucket = "acme-reports-prod"
}

resource "aws_s3_bucket_public_access_block" "reports" {
  bucket                  = aws_s3_bucket.reports.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Terraform compared to alternatives

Cloud-native tools such as CloudFormation or ARM templates are tied to one provider. Configuration management tools such as Ansible excel at configuring software inside servers and can create infrastructure, but Terraform’s planning and state model is purpose-built for provisioning. Many teams use Terraform to create the machines and Ansible or container images to configure what runs on them.

Common mistakes

  • Mixing console changes with Terraform-managed resources. Pick one owner per resource.
  • Treating Terraform as a scripting language. It describes end state; it is not a replacement for a deployment script.
  • Starting with everything at once. Begin with one new, low-risk component.

Action Step

List five pieces of infrastructure your team manages by hand today. For each, write one sentence describing what could go wrong if someone changed it without a record. These are your first candidates for Terraform.

Editorial & AI Disclosure