Infrastructure as Code Project (Multi-Environment)
Part of the Cloud Computing Roadmap
In short
Anyone can run terraform apply once. Running the same setup safely in dev, staging and prod, with a change tested in dev before it touches prod, is what real teams pay for.
Extend Phase 10's practice project into a real multi-environment setup (dev/staging/prod) managed entirely through Terraform, showing you can manage the same infrastructure pattern safely across environments.
Think of it like this
One pattern, three sizes
A school tailor doesn't design a new shirt for every child. He has one paper pattern and cuts it in small, medium and large. If he improves the collar, he fixes the pattern once, tries it on a small shirt first, then cuts the rest.
Watch it happen
One change, promoted through three environments
1/6You change the shared module, say to add an alarm, and open a pull request.
The big ideas
What you need to know
One module, many envs
Put the infrastructure in a reusable module. Each environment calls it with its own sizes and names.
Separate remote state
Each environment has its own state file in remote storage with locking, so dev can never overwrite prod.
Pipeline, not laptop
Applies run from CI with plans reviewed on pull requests. Nobody applies prod from their machine.
Separate accounts help
Many teams put prod in its own cloud account, so a dev mistake can't touch prod resources.
See it in code
Walk through the code
1# envs/prod/main.tf (envs/dev and envs/staging look the same)2terraform {3 backend "s3" {4 bucket = "campus-tf-state"5 key = "web/prod.tfstate"6 region = "ap-south-1"7 use_lockfile = true8 }9}10 11module "web" {12 source = "../../modules/web"13 env = "prod"14 instance_type = "t3.medium"15 min_size = 216}1/4Remote state in S3. The key is unique per environment, so states never mix.
A folder per environment, each with its own state key and inputs. Dev would use web/dev.tfstate, t3.micro and min_size 1.
Save yourself the pain
Common mistakes
Oops
Copy-pasting the whole config into three folders and editing each by hand.
Do this instead
Keep the logic in one module. Environment folders should be short files of inputs.
Oops
Using one state file for all environments.
Do this instead
One state per environment. A bad apply in dev should never be able to destroy prod.
Your mission
First milestone: dev and staging
Quick check
Why should dev, staging and prod have separate state files?
Go deeper
- 1Use Terraform workspaces or separate state files to manage 2-3 distinct environments.
- 2Show how configuration (e.g. instance size, replica count) differs sensibly between environments.
- 3Document your promotion process: how a change moves from dev through to prod.
More projects at this stop
Deploy a 3-Tier Web Application on AWS / Azure / GCP
Serverless API Project
Highly Available Architecture Project
Cost-Optimized Migration Case Study
Monitoring & Alerting Setup Project
Portfolio Website or GitHub Showcase
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
