Infrastructure as Code and Why Terraform?

Infrastructure changes are easy to make and surprisingly hard to remember. A command run in a console, a setting changed in a dashboard, or a resource created during an incident can quietly become part of production. Months later, nobody may know exactly what was changed, why it exists, or how to reproduce it.

Infrastructure as Code (IaC) changes that relationship. Instead of treating infrastructure as something you manually build and maintain, you describe it as code and let a tool turn that description into real infrastructure. Terraform is one of the most widely used tools for this approach.

The Problem With Manually Managed Infrastructure

Imagine a small application running on a cloud provider. It needs a network, a server, some storage, firewall rules, and DNS.

At first, manually creating these resources feels reasonable. You open the provider’s console, click through a few screens, and the application is running.

The problem appears when the infrastructure starts changing.

Someone adds a firewall rule during troubleshooting. Another person changes a server size. A third person creates a second server but forgets to document it. Later, someone manually changes a DNS record.

The infrastructure now contains decisions that exist only in people’s memories and in the provider’s current configuration.

This creates several problems.

Repetition

If you need another environment, you have to repeat the same manual work. The second environment may look similar to the first, but it is very easy to miss one setting.

Human Error

A person can select the wrong region, instance size, network, or security setting. Manual procedures depend on people performing the same sequence correctly every time.

Lack of Review

A change made through a web console can happen without the normal code-review process used for application code. It may be difficult to answer who changed something and whether the change was intentional.

Configuration Drift

Configuration drift occurs when the real infrastructure gradually becomes different from the configuration you intended to have.

For example, suppose you originally decide that three servers should have the same configuration:

Server A ──┐
Server B ──┼── intended configuration
Server C ──┘

Over time, somebody changes Server B manually:

Server A ── intended
Server B ── manually changed
Server C ── intended

Nothing necessarily breaks immediately. That is what makes drift dangerous. The infrastructure can continue working while becoming increasingly difficult to reason about.

Infrastructure as Code

Infrastructure as Code means representing infrastructure configuration in machine-readable files that can be stored, reviewed, versioned, and repeatedly applied.

Instead of saying:

“Create a network, then create two servers inside it.”

you describe the desired infrastructure.

A simplified mental model is:

       Infrastructure as Code

       Configuration files
               │
               ▼
       ┌─────────────────┐
       │   IaC Tool      │
       └────────┬────────┘
                │
                ▼
       Real infrastructure

The important change is not simply that the configuration is written in a file. The important change is that the infrastructure becomes something you can manage using the same engineering practices used for software:

• version control
• code review
• repeatable changes
• documentation through code
• automation
• collaboration

The files become a durable description of what you intend to build.

Imperative vs Declarative Infrastructure

There are two useful ways to think about describing infrastructure: imperative and declarative.

An imperative approach focuses on how to perform the work.

For example:

1. Create a network.
2. Create a subnet.
3. Create a server.
4. Attach the server to the subnet.
5. Configure the firewall.

A declarative approach focuses on what the final result should look like:

I want:
- one network
- one subnet
- one server
- the server attached to the subnet
- these firewall rules

Terraform is primarily declarative.

You describe the desired infrastructure, and Terraform determines the actions required to make reality match that description.

That distinction is fundamental.

You generally do not write a Terraform configuration saying:

First call this API.
Then wait.
Then call another API.
Then update this resource.

Instead, you describe resources and their relationships. Terraform works out the operations needed to reach the desired result.

Desired State

The phrase desired state is central to understanding Terraform.

Suppose your configuration describes one server:

Desired state:
    1 server

If there is no server yet, Terraform needs to create one.

Later, you change the configuration:

Desired state:
    2 servers

Terraform can compare the desired configuration with what it knows about the infrastructure and determine that another server needs to be created.

If you change the desired state again:

Desired state:
    1 server

Terraform can determine that one of the servers needs to be removed.

The important mental model is therefore not:

Terraform executes my file from top to bottom.

It is:

        Desired configuration
                │
                ▼
        Terraform evaluates
                │
                ▼
       What needs to change?
                │
                ▼
        Real infrastructure

This is why Terraform can make a plan before making changes.

What Terraform Does

Terraform is an Infrastructure as Code tool for building, changing, and versioning infrastructure. It can manage resources exposed by many different systems through providers. A provider is Terraform’s interface to an external platform or service.

For example, a provider can allow Terraform to work with a cloud platform, DNS service, monitoring system, or another API. A Terraform configuration might conceptually contain:

Terraform configuration
        │
        ├── Provider
        │      │
        │      └── connects Terraform to an external system
        │
        └── Resources
               │
               ├── network
               ├── server
               └── storage

The provider knows how to communicate with the external system. The resource describes something Terraform should manage there.

This separation is one of the most important ideas in Terraform.

Terraform and Configuration Management

Terraform is sometimes compared directly with configuration-management tools. They overlap in some areas, but their primary concerns are different.

Terraform is particularly well suited to provisioning and managing infrastructure resources.

A configuration-management tool is generally focused on configuring machines and software that already exist.

For example:

Terraform
    │
    ├── network
    ├── server
    ├── disk
    └── load balancer
             │
             ▼
Configuration management
    │
    ├── install packages
    ├── edit configuration files
    ├── create users
    └── start services

This is not an absolute boundary. Modern infrastructure tools can overlap, and Terraform can manage many kinds of services beyond virtual machines.

The useful distinction is the mental model:

Terraform describes and manages infrastructure resources. Configuration-management tools traditionally focus more on the configuration of systems and software running on those resources.

You will often encounter both approaches in the same organization.

Terraform’s Plan and Apply Model

One of Terraform’s most useful features is that it can show you a proposed change before making it.

A simplified workflow looks like this:

    flowchart LR
    A[Terraform configuration] --> B[Terraform]
    B --> C[Compare desired and current state]
    C --> D[Plan]
    D --> E[Review changes]
    E --> F[Apply]
    F --> G[Real infrastructure]
  

You write or modify configuration.

Terraform evaluates it and produces a plan describing what it expects to change.

You can review that plan before allowing Terraform to apply it.

This is valuable because infrastructure changes can have significant consequences. A change that looks like one line in a configuration file might result in a resource being replaced rather than updated in place.

The plan gives you an opportunity to catch that before the change happens.

Terraform State: The High-Level Idea

Terraform also maintains information called state.

At a high level, state lets Terraform keep track of the infrastructure it manages and associate real infrastructure with the resources represented in your configuration.

Think of the relationship like this:

Configuration
     │
     │ describes what you want
     ▼
 Terraform
     │
     │ tracks managed infrastructure
     ▼
   State
     │
     │ corresponds to
     ▼
Real infrastructure

State is important enough to deserve much deeper treatment, including how it is stored, shared, locked, and changed safely. Those topics belong later in the course.

For now, remember only this:

Terraform is not simply a parser that reads .tf files and sends API calls. It uses configuration, state, and information from providers to determine how infrastructure should change.

Why Terraform Is Useful

Terraform becomes especially valuable when infrastructure is larger than a person can comfortably remember and reproduce.

It gives you:

Repeatability. The same configuration can be used repeatedly.

Reviewability. Infrastructure changes can be reviewed as code before they are applied.

Versioning. You can store configuration in version control and see how infrastructure definitions changed over time.

Automation. Terraform can perform infrastructure changes without requiring someone to manually click through a provider’s console.

Consistency. Environments can be created from the same underlying configuration patterns.

Planning. You can inspect proposed changes before applying them.

These benefits are not magic properties of Terraform itself. They come from treating infrastructure as code and building a disciplined workflow around that code.

Where Terraform Fits

Terraform usually sits at the infrastructure layer of a broader delivery workflow.

A simplified organization might look like:

    flowchart TD
    A[Application code] --> B[Build and test]
    B --> C[Deploy application]
    D[Terraform configuration] --> E[Infrastructure]
    E --> C
  

Terraform can create or modify the infrastructure required by an application. Other tools can then build and deploy the application onto that infrastructure.

As you progress through the course, you will learn the Terraform language, providers, resources, variables, expressions, state, modules, and eventually more advanced ways of operating Terraform.

For now, the most important idea is simple:

Terraform lets you describe infrastructure as code and use that description to make real infrastructure converge toward the desired state.

That mental model will make the commands and syntax you learn next much easier to understand.