Infrastructure as Code (IaC) Basics

Imagine rebuilding your entire college lab network by clicking through a web portal for six hours — then forgetting one firewall rule. Infrastructure as Code (IaC) replaces that nightmare with a text file you commit to Git, review in a pull request, and apply with one command.

What Is Infrastructure as Code?

IaC means you describe what infrastructure you want — a storage account, a web app, a database — in declarative files. A tool reads those files and creates or updates cloud resources to match.

Think of it like a recipe card for cloud setup. Instead of the chef improvising each night, everyone follows the same card and gets the same dish.

Why Do We Need IaC?

Manual portals create configuration drift — servers that slowly become unique snowflakes nobody fully understands. IaC gives you:

• Repeatable dev, test, and prod environments.
• Peer review before changes go live.
• Documentation that never goes stale (the code is the doc).

How Does IaC Work?

IaC file (Bicep / Terraform)
      ↓
Plan / Preview (show changes)
      ↓
Apply (create or update resources)
      ↓
Cloud matches declared state

Step-by-Step: Simple Bicep Mindset

Even before mastering syntax, follow this workflow:

Step 1: Define a resource group and one App Service in a .bicep file.

Step 2: Run preview:

az deployment group what-if \
  --resource-group rg-student-demo \
  --template-file main.bicep

Step 3: Review output with a teammate — like a pull request for servers.

Step 4: Apply only after approval.

Real-World Example

A health-tech startup must prove every production change was reviewed. IaC files in Git show exactly when a database firewall rule widened and who approved the pull request — auditors smile, engineers sleep better.

Common Misconceptions

"IaC is only for huge clouds." A single student project can use IaC to spin up and tear down resources cheaply.

"Apply equals instant magic." Some resources take minutes to create. Pipelines should wait and verify health checks.

Terraform vs Bicep — Which Name Should You Know?

Bicep is Microsoft's DSL for Azure resources — concise syntax, first-class Azure support. Terraform by HashiCorp is cloud-agnostic; one language for Azure, AWS, and GCP. Both are IaC. Learn the workflow (define, plan, apply) first; syntax second.

Student tip: if your course uses Azure credits, start with Bicep or ARM. If you want portable skills across clouds, explore Terraform after grasping concepts.

IaC Best Practices

• Store templates in Git with pull request review.
• Use separate parameter files for dev vs prod — same template, different sizes.
• Never commit secrets; reference Key Vault or pipeline secrets.
• Tag every resource with owner, environment, and cost center for cleanup.

IaC turns "only Rahul knows how the server was configured" into "the repo shows every setting since day one."

Understanding State

IaC tools track state — a record of what they created. Terraform stores state in a file or remote backend. Never commit sensitive state casually; use remote backends with locking so two engineers do not apply conflicting changes simultaneously. State is the inventory list of your cloud furniture.

Start your IaC journey by reproducing a resource you already created manually in the portal. Compare costs and settings line by line. Then delete the manual resource and deploy via template — confidence comes from matching what you know works before automating new environments.

Parameter Files Pattern

Keep one Bicep template and multiple parameter files: dev.bicepparam, staging.bicepparam, prod.bicepparam. Dev might use Basic SKU App Service; prod uses Premium with autoscale. Same template enforces consistency; parameters express environment differences explicitly.

During code review, diff parameter files carefully — accidentally pointing prod parameters at dev subscription has deleted the wrong resources before. Naming conventions and colored portal banners reduce human error when tired students deploy at midnight before deadlines.

Summary

IaC makes infrastructure predictable, reviewable, and recoverable. Start by codifying one small environment — a resource group and one web app — before touching production.