What Is Infrastructure as Code? A Visual Beginner’s Guide

I once spent an entire Friday afternoon clicking through the AWS console setting up a production environment. VPC, subnets, security groups, an RDS instance, a load balancer, two EC2 instances. Took me about four hours. I felt accomplished. Documented nothing.

Three weeks later, the client needed an identical staging environment. I opened the console and realized I couldn’t remember half the settings I’d picked. Subnet CIDR ranges? Gone. Security group rules? Vaguely. The RDS parameter group? Not a chance.

So I spent another four hours rebuilding it from scratch, guessing at half the config. The staging environment was “close enough” to production. You can probably guess how that story ends.

Before and After: Manual vs Code

Here’s what infrastructure management looks like without IaC:

Open the cloud console
Click through fifteen screens
Pick settings from memory (or a half-outdated wiki page)
Hope you didn’t forget a security group rule
Repeat for every environment, every time
Pray nobody changes something manually without telling anyone

And here’s the same thing with Infrastructure as Code:

Write a configuration file describing what you want
Run a command
Your entire environment appears, identical every time
Store the file in Git like any other code
Review changes in pull requests before they hit production
Sleep at night

That’s it. That’s the pitch. You describe your infrastructure in text files, and a tool builds it for you. Same input, same output, every time.

What Infrastructure as Code Actually Is

Infrastructure as Code means managing servers, networks, databases, and cloud resources through machine-readable configuration files instead of manual processes. Instead of clicking buttons in a web console, you write code that describes the desired state of your infrastructure.

The key word there is state. You don’t write “create a server.” You write “there should be a server with these properties.” The tool figures out the steps. If the server already exists and matches, it does nothing. If something drifted, it fixes it.

This is called declarative configuration — you describe the what, not the how. It’s the difference between telling a GPS “take me to the airport” versus giving turn-by-turn directions from memory.

There’s also an imperative approach, where you write step-by-step instructions. Ansible leans this way. Both work. Declarative tends to be easier to reason about at scale.

Why does any of this matter? Three reasons:

Reproducibility. Same code, same infrastructure. Dev, staging, production — all identical. No more “works on my machine” but for servers.

Version control. Your infrastructure lives in Git. You can see who changed what, when, and why. You can roll back. You can review changes before they go live.

Speed. Spinning up a new environment goes from “a day of clicking” to “run this command.” Tearing it down is just as fast. That changes how you think about infrastructure entirely.

The Big Tools (And What They’re Good At)

Four names dominate this space. They’re not all doing the same thing, even though they get lumped together constantly.

Terraform

The most popular general-purpose IaC tool. Made by HashiCorp. Works with AWS, Azure, GCP, and hundreds of other providers. You write .tf files in a language called HCL (HashiCorp Configuration Language), and Terraform figures out how to create, update, or destroy resources.

Terraform is declarative and cloud-agnostic. That second part matters — you can manage AWS and Cloudflare and Datadog from the same codebase.

Best for: provisioning cloud infrastructure. Servers, networks, databases, DNS, CDNs. The structural stuff.

Ansible

Made by Red Hat. Ansible is primarily a configuration management and automation tool. It connects to your servers via SSH and runs tasks in order. No agent needed on the target machines.

Ansible uses YAML playbooks and leans imperative — you define steps, not just end states. It’s great for installing software, configuring services, deploying applications.

Best for: configuring servers after they exist. Installing packages, setting up services, running deployments.

AWS CloudFormation

AWS’s native IaC tool. JSON or YAML templates that describe AWS resources. Deep integration with every AWS service, often supporting new features on day one.

The catch: it only works with AWS. If you’re all-in on AWS and plan to stay, CloudFormation is solid. If you might use multiple clouds, you’ll hit a wall.

Best for: AWS-only shops that want tight integration with the AWS ecosystem.

Pulumi

The newer challenger. Instead of a custom language, you write IaC in real programming languages — TypeScript, Python, Go, C#. Same declarative model as Terraform under the hood, but with the full power of a programming language.

Best for: teams that want loops, conditionals, and abstractions without learning HCL. Also great if your team already lives in TypeScript or Python.

When to Use What

Here’s a mental model that’s served me well:

Need to create cloud resources (servers, databases, networks)? Terraform or CloudFormation.
Need to configure what’s on those servers (install software, edit config files)? Ansible.
AWS only and want native integration? CloudFormation.
Want to use a real programming language? Pulumi.
Just starting out and want the biggest job market? Terraform. Not close.

Many teams use Terraform and Ansible together — Terraform creates the infrastructure, Ansible configures it. They’re complementary, not competing.

If you’re still building your cloud fundamentals, our guide to learning cloud computing from scratch covers the foundational concepts you’ll want before diving into IaC tools.

Your First Terraform File

Here’s a complete Terraform configuration that creates an S3 bucket on AWS. It’s about as simple as IaC gets:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "my_first_bucket" {
  bucket = "my-first-iac-bucket-12345"

  tags = {
    Environment = "learning"
    ManagedBy   = "terraform"
  }
}

What’s happening here:

The terraform block says “I need the AWS provider.”
The provider block says “connect to AWS in us-east-1.”
The resource block says “there should be an S3 bucket with this name and these tags.”

To run it:

terraform init      # Download the AWS provider
terraform plan      # Preview what will be created
terraform apply     # Actually create it

terraform plan is your safety net. It shows you exactly what will happen before anything changes. Get in the habit of reading the plan output. Every time. No exceptions.

When you’re done experimenting:

terraform destroy   # Remove everything Terraform created

That’s real IaC. Fifteen lines, one command, and you’ve got infrastructure that’s versioned, reproducible, and destroyable. Try doing that by clicking through the console.

Common Beginner Mistakes

I’ve made all of these. Some more than once.

Not using remote state. Terraform stores state in a local file by default. That’s fine for learning. In a team, it’s a disaster — two people running Terraform at once will corrupt the state. Use an S3 backend (or equivalent) from the start of any real project.

Hardcoding everything. Your first instinct will be to put values directly in resource blocks. Region names, instance sizes, bucket names. Use variables instead. Future you will be grateful when you need the same config for three environments.

Skipping terraform plan. Running apply without reading the plan is like pushing to main without reading the diff. It’ll work fine until it doesn’t, and when it doesn’t, it’s usually something getting destroyed.

Trying to learn everything at once. IaC has a lot of surface area. Don’t try to learn Terraform, Ansible, Docker, Kubernetes, and CI/CD simultaneously. Pick one tool, build something real with it, then expand. Fifteen minutes a day beats a weekend marathon — we’ve written about why.

Editing infrastructure manually after deploying with code. This is called “drift,” and it’s the IaC equivalent of editing production databases directly. The tool thinks infrastructure is in one state; reality says otherwise. Everything breaks on the next apply. If it’s managed by code, only change it through code.

FAQ

Do I need to know programming to learn Infrastructure as Code?

Not really. Terraform’s HCL is closer to a configuration format than a programming language. If you can write JSON or YAML, you can write HCL. Ansible uses YAML, which is even simpler. You don’t need to know Python or JavaScript to get started. That said, understanding basic concepts like variables, loops, and conditionals will help once your configurations grow.

Is Terraform free?

The Terraform CLI is open-source and free. You can use it for everything described in this article without paying anything. HashiCorp offers Terraform Cloud with team features (remote state, collaboration, policy enforcement), which has a free tier and paid plans. Most individuals and small teams do fine with the CLI and an S3 backend for state.

Should I learn Terraform or Ansible first?

Terraform, if you’re getting into cloud infrastructure. It solves the more fundamental problem — creating the resources. Ansible is more useful once you have servers to configure. If your work is mostly “set up AWS environments,” Terraform is the answer. If it’s mostly “deploy and configure applications on existing servers,” start with Ansible.

How long does it take to get productive with IaC?

You can create real cloud resources with Terraform in an afternoon. Getting comfortable takes two to four weeks of regular practice. Feeling confident with modules, state management, and multi-environment setups takes a few months. The learning curve is front-loaded — the first week is the hardest. After that, it’s mostly learning new resource types, which follows the same patterns you already know.

Ready to build real cloud skills from scratch? Start with SkillRealm Learn —>

What Is Infrastructure as Code? A Visual Beginner's Guide