Module 1: IaC Foundations

Why Infrastructure as Code

Imagine your company's servers, databases and networks were set up by one engineer clicking through a cloud console over several months. Nobody wrote down every setting. Then that engineer leaves, a production server fails, and you need an identical replacement by tonight. This is the situation infrastructure as code (IaC) is designed to prevent.

What infrastructure as code means

Infrastructure as code means describing your infrastructure (servers, networks, databases, DNS records, permissions) in text files, and using a tool to create and update the real resources from those files. The files become the single source of truth. Instead of "Kamau set up the database last March", you have a file that says exactly what the database looks like, stored in version control with a history of every change.

There are two broad styles:

• Imperative: you write the steps. "Create a server. Then attach a disk. Then open port 443." Shell scripts calling a cloud CLI work this way.
• Declarative: you describe the end state. "There should be one server of this size with this disk and this port open." The tool works out what steps are needed to get there from whatever exists now. Terraform is declarative.

The declarative style matters because running the same file twice is safe. If the server already matches the description, Terraform changes nothing. This property is called idempotence.

The problems IaC solves

How IaC fits into a team's workflow

Once infrastructure lives in code, you can treat it like application code:

1. An engineer changes a configuration file on a branch.
2. The tool shows a plan: exactly what it will create, change or destroy.
3. A colleague reviews the code and the plan in a pull request.
4. After approval, the change is applied, often by an automated pipeline.
5. The history is kept in Git, so you can see and, if needed, reverse any change.

This brings the discipline of software engineering (review, testing, versioning) to infrastructure.

Worked example: a payments start-up

A Nairobi payments start-up runs its platform on AWS. Initially, its two engineers created everything in the console. Problems appeared quickly:

• A staging database was accidentally created without encryption, while production had it.
• A security group was opened to the whole internet "for testing" and never closed.
• When an auditor asked for evidence of how access was controlled, nobody could produce a clear record.

The team moved to Terraform. They wrote code describing the network, the databases (with encryption required), and the security groups. Every change now goes through a pull request where the second engineer reviews the plan. When they needed a second environment for a bank partner's integration testing, they created it in an afternoon from the same code. When the auditor returned, the Git history showed who changed each rule, when and why.

Here is a small taste of what that code looks like:

resource "aws_s3_bucket" "statements" {
  bucket = "paystart-customer-statements"

  tags = {
    Environment = "production"
    Owner       = "platform-team"
  }
}

Even without knowing Terraform yet, you can read this: there should be an S3 bucket with this name and these tags.

Common mistakes to avoid

• Mixing code and manual changes. If people keep editing resources in the console, the code stops matching reality. Agree that all changes go through code.
• Treating IaC files as private scripts. Keep them in a shared repository with review, or you lose most of the benefits.
• Trying to codify everything on day one. Start with one well-understood component, such as a storage bucket or a network, and expand.
• Storing passwords in the code. You will learn safe ways to handle secrets later in this course.