Introduction
Infrastructure as Code (IaC) is the practice of defining and provisioning cloud infrastructure—servers, networks, storage, and more—through machine-readable configuration files rather than manual console clicks or ad hoc scripts. Those files live in version control, so infrastructure changes go through the same review, diff, and audit process as application code.
Cricket analogy: Instead of a groundstaff member verbally instructing where to place each boundary rope, a franchise writes the stadium layout into a documented plan that's reviewed and archived, the same way IaC replaces manual console clicks with version-controlled configuration files.
Explanation
IaC tools fall into two broad approaches. A declarative approach (used by tools like Terraform, AWS CloudFormation, and Pulumi in declarative mode) lets you describe the desired end state of your infrastructure—'I want one virtual machine of this size, with this network'—and the tool figures out the steps needed to reach that state, including what to create, update, or destroy. An imperative approach (used by shell scripts or the AWS CLI) instead lists the exact sequence of commands to run—'create a VM, then attach a disk, then open a port'—and it is up to the author to keep that sequence correct as infrastructure evolves. Declarative IaC is generally preferred at scale because the tool can compute a plan, detect drift between the actual and desired state, and safely reconcile the two without the author tracking every prior action.
Cricket analogy: A declarative team-selection sheet just states 'field this XI with this batting order' and lets the support staff sort out logistics, while an imperative approach dictates each exact step of who arrives when and in what order, requiring constant manual tracking as plans change.
Example
resource "cloud_virtual_machine" "web_server" {
name = "web-01"
instance_type = "small"
region = "us-east-1"
image = "ubuntu-22.04"
network {
vpc_id = cloud_vpc.main.id
subnet_id = cloud_subnet.public.id
}
tags = {
environment = "production"
managed_by = "terraform"
}
}Analysis
In the example above, the configuration states what the virtual machine should look like, not the individual API calls needed to create it. Running the tool a second time with the same file produces no changes, because the actual infrastructure already matches the desired state—this property is called idempotency. If someone manually resizes the VM in the console, the next run detects that drift and offers to correct it. This declarative, version-controlled workflow is what makes IaC repeatable across environments (dev, staging, production) and safe to review through pull requests before anything is applied.
Cricket analogy: The team sheet states the desired batting order, not the exact walk-out choreography; submitting the same sheet twice changes nothing since the order's already set, but if a captain quietly swaps two batters without updating the sheet, the next review catches the discrepancy and flags it for correction.
Key Takeaways
- IaC defines infrastructure in version-controlled, machine-readable configuration files instead of manual console actions.
- Declarative IaC describes the desired end state; the tool computes how to get there and can detect drift.
- Imperative IaC describes the exact steps to run, requiring the author to track state changes manually.
- Declarative tools like Terraform are idempotent: re-running them with no changes produces no changes.
Practice what you learned
1. What best describes the declarative approach to Infrastructure as Code?
2. Why is version-controlling infrastructure configuration valuable?
3. What happens when a declarative IaC tool is run again with an unchanged configuration and no manual drift?
4. Which is a characteristic of an imperative IaC approach?
Was this page helpful?
You May Also Like
CI/CD in the Cloud
Understand how cloud-native continuous integration and delivery pipelines automate building, testing, and deploying applications.
Cloud Migration Strategies
Learn the '6 Rs' framework for migrating workloads to the cloud: Rehost, Replatform, Repurchase, Refactor, Retire, and Retain.
Compliance and Governance
Get a conceptual overview of common compliance frameworks like SOC 2, GDPR, and HIPAA in the cloud.
High-Availability Design
Design systems that stay up through redundancy and automatic failover, and understand what each additional 'nine' of uptime really costs.