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.

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
Edit the code
Change a file, for example raise an instance size, on a branch.
- 2
Open a pull request
CI runs format checks, validation and a plan that shows exactly what will change.
- 3
Review the plan
A teammate reads the plan. One resource to update is fine; '12 to destroy' needs questions.
- 4
Merge and apply
The pipeline applies the reviewed plan, and the new state is recorded.
See it in code
Walk through the code
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
Quick check
What's the biggest benefit of a declarative IaC tool over a script of create commands?
Go deeper
- 1List 3 problems IaC solves compared to manually configuring infrastructure via a console.
- 2Learn the difference between declarative IaC (describe the end state) and imperative (describe the steps).
- 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.