Stop 09 · Infrastructure as CodeTopics · 1/9

IaC Concepts & Benefits

Part of the DevOps Roadmap

In short

Clicking through a cloud console works once. Then someone asks for the same setup in another region, and nobody remembers the steps. Infrastructure as Code writes them down as files.

Defining infrastructure (servers, networks, databases) in version-controlled configuration files rather than manually clicking through a cloud console — enabling repeatability, review, and rollback for infrastructure changes.

The mascot unrolls a big blue blueprint next to two identical finished houses.

Think of it like this

The architect's blueprint

No builder puts up a house from memory. The architect draws a blueprint, the client approves it, and any contractor can build an identical house from it. Infrastructure as Code is the blueprint for your servers, networks and databases, stored in Git.

Watch it happen

ClickOps vs Infrastructure as Code

Console clicks

  • Steps live in one person's memory
  • No review before changes go live
  • Rebuilding takes days of guessing

IaC in Git

  • Every change is a reviewed commit
  • Plan shows impact before applying
  • Same files rebuild any environment

Use the console to explore and learn. Use code for anything you'll need to repeat, review or recover.

The big ideas

What you need to know

Repeatable

Dev, staging and prod come from the same code, so 'works in staging' actually means something.

Reviewable

Infrastructure changes go through pull requests, just like app code. A teammate can spot the mistake first.

Traceable

Git history shows who changed what and why. Rolling back means reverting a commit and applying again.

Declarative style

Most tools let you describe the end state you want. The tool works out the steps to get there.

How it works

How a change ships with IaC

  1. 1

    Edit the code

    Change a file, for example raise an instance size, on a branch.

  2. 2

    Open a pull request

    CI runs format checks, validation and a plan that shows exactly what will change.

  3. 3

    Review the plan

    A teammate reads the plan. One resource to update is fine; '12 to destroy' needs questions.

  4. 4

    Merge and apply

    The pipeline applies the reviewed plan, and the new state is recorded.

See it in code

Walk through the code

hcl
1# main.tf: one storage bucket, described as code2terraform {3  required_providers {4    aws = { source = "hashicorp/aws", version = "~> 6.0" }5  }6}7provider "aws" { region = "ap-south-1" }8 9resource "aws_s3_bucket" "notes" {10  bucket = "riya-notes-demo-2026"11}

1/2Declare which provider plugin you need and which region to work in.

Bucket names are global across all of AWS, so pick your own unique name. ap-south-1 is the Mumbai region.

Save yourself the pain

Common mistakes

Oops

Writing IaC, then quickly fixing things in the console during an incident.

Do this instead

If you must, copy the change back into code straight after. Otherwise the next apply undoes your fix.

Oops

Thinking IaC is only worth it for big companies.

Do this instead

Even one small project benefits: you can tear it down to save money and rebuild it the same way later.

Your mission

Recreate something you clicked

~30 min

Quick check

What's the biggest benefit of a declarative IaC tool over a script of create commands?

Go deeper

  1. 1List 3 problems IaC solves compared to manually configuring infrastructure via a console.
  2. 2Learn the difference between declarative IaC (describe the end state) and imperative (describe the steps).
  3. 3Understand why 'infrastructure drift' (manual changes outside of code) undermines IaC's value.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge