100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
HCL

What Is Infrastructure as Code?

Infrastructure as Code (IaC) is the practice of defining and provisioning computing infrastructure through machine-readable configuration files instead of manual processes.

IaC FoundationsBeginner8 min readJul 9, 2026
Analogies

What Is Infrastructure as Code?

Infrastructure as Code (IaC) is the practice of managing and provisioning computing resources — servers, networks, load balancers, databases, DNS records, and more — through versioned configuration files rather than manual point-and-click operations in a console or ad-hoc scripts run by hand. Instead of an engineer logging into a cloud provider's web console to click 'Create VPC' and 'Create Subnet', they write a text file that declares those resources, and a tool reads that file and makes the real infrastructure match it. The configuration becomes the authoritative record of what infrastructure should exist, and that record can be reviewed, tested, versioned in Git, and reused across environments.

🏏

Cricket analogy: IaC is like a groundstaff following a written pitch-preparation spec instead of eyeballing it — the document itself, not memory, defines the exact grass length and moisture level, and it can be reviewed, reused, and repeated for every match at that ground.

Why IaC Emerged

Before IaC, infrastructure was typically hand-built and hand-maintained. Teams called this 'ClickOps' — clicking through a cloud console to create resources — or relied on tribal knowledge and runbooks. This approach does not scale: it is slow, error-prone, hard to audit, and nearly impossible to reproduce exactly. If the engineer who built the production environment leaves the company, the exact steps they took may be lost. IaC solves this by making infrastructure reproducible: the same configuration file, run against the same provider, produces the same result every time, whether it's the first deployment or the hundredth.

🏏

Cricket analogy: Pre-IaC 'ClickOps' is like a groundstaff preparing a pitch purely from an old head groundsman's memory with no written record — if he retires, the exact roller pressure and watering schedule that made that pitch famous may be lost forever.

Core Benefits

IaC delivers four major benefits that manual provisioning cannot. Consistency: the same code produces the same infrastructure, eliminating configuration drift between environments like staging and production. Speed: spinning up an entire environment — dozens of interconnected resources — takes minutes instead of days. Auditability: every change to infrastructure is a Git commit with an author, timestamp, and diff, which is invaluable for compliance and incident investigation. Reusability: a well-written module for 'a highly available web tier' can be parameterized and reused across dozens of applications and teams.

🏏

Cricket analogy: IaC's four benefits map to a franchise's ops: consistency means every home ground is set up identically, speed means a new stadium's facilities are ready in days not months, auditability means every kit change is logged, and reusability means one youth academy blueprint scales to every regional center.

Think of IaC like a recipe versus a memory of cooking. A chef who cooks from memory might produce a slightly different dish every time. A written, versioned recipe — with exact quantities and steps — produces the same dish reliably, and can be handed to another chef (or a whole restaurant chain) to reproduce identically.

Declarative and Imperative Approaches

IaC tools generally fall into two philosophical camps. Declarative tools, such as Terraform, AWS CloudFormation, and Pulumi's declarative mode, let you describe the desired end state — 'I want three web servers behind a load balancer' — and the tool figures out how to get there. Imperative tools, such as raw shell scripts or Ansible playbooks in their more procedural usage, describe the exact sequence of steps to execute. Most modern IaC tooling, including Terraform, favors the declarative model because it is easier to reason about, diff, and keep idempotent.

🏏

Cricket analogy: Declarative IaC like Terraform is like telling a groundstaff 'I want a pitch that will turn from day three' and letting them figure out the preparation steps, whereas imperative scripting is like handing them an exact minute-by-minute rolling and watering schedule to follow.

IaC does not automatically mean 'safe.' A misconfigured or overly permissive IaC pipeline can destroy production infrastructure just as fast as it creates it — often faster than a human clicking through a console, and across many resources at once. Guardrails like code review, plan review, and least-privilege credentials are essential.

hcl
# A minimal example of Infrastructure as Code using Terraform:
# this file declares the DESIRED STATE of an AWS S3 bucket.

resource "aws_s3_bucket" "app_logs" {
  bucket = "acme-app-logs-prod"

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

# Running `terraform apply` reads this file and creates
# (or updates) the bucket to match it -- no manual console clicks.
  • IaC defines infrastructure in machine-readable, version-controlled configuration files instead of manual console operations.
  • It replaces 'ClickOps' with reproducible, auditable, and reviewable processes.
  • Key benefits are consistency, speed, auditability (via Git history), and reusability (via modules).
  • IaC tools are broadly declarative (describe the end state) or imperative (describe the steps).
  • IaC is a discipline, not just a tool — it requires code review and guardrails to be safe.
  • Terraform, CloudFormation, Pulumi, and Ansible are all examples of IaC tooling, each with different tradeoffs.

Practice what you learned

Was this page helpful?

Topics covered

#HCL#TerraformInfrastructureAsCodeStudyNotes#DevOps#WhatIsInfrastructureAsCode#Infrastructure#Code#IaC#Emerged#StudyNotes#SkillVeris