Welcome to Part III, where you will learn Terraform and Infrastructure as Code (IaC). But before touching Terraform, you need to understand what problem it solves. And for that, let's talk about "manual provisioning": the traditional way of creating infrastructure, with all its pains. When you understand these problems, you will truly appreciate why IaC has changed the rules of the game.

Provisioning infrastructure means creating and configuring the resources your application needs: servers, networks, databases, permissions...

Manual provisioning is doing it by hand, clicking in the AWS web console. You go to the website, click "create instance," fill out forms, configure networks by hand, adjust permissions one by one... It's how you've been imagining doing things in the previous chapters.

It works for learning or for a quick test. But for real projects, it has serious problems.

Creating a complete environment by hand (network, subnets, servers, database, permissions...) can take hours of clicking through dozens of screens. And if you need another identical environment (for example, a test environment identical to production), you have to repeat the whole process from scratch.

Example: Your boss asks you to set up a test environment identical to production. By hand, that means meticulously recreating each resource, trying to remember exactly how you configured the original three months ago. Hours of tedious and error-prone work.

When you configure dozens of resources by hand, it's easy to make mistakes: you forget to check a box, mistype a value, configure a permission incorrectly. And errors in infrastructure can cause outages or security holes.

Real example: You configure the test environment and, by mistake, open the SSH port to the entire internet (the error from Chapter 4). In production you did it right, but in testing you forgot. Now you have a vulnerability... and you don't even know it, because you "thought" you did it the same.

When everything is done by hand, it's impossible to guarantee that two environments are identical. Over time, someone makes a quick change in production "to fix something" and doesn't replicate it in testing. The environments silently diverge.

This causes the classic: "it works in testing, but fails in production" (or vice versa). The reason is that, in reality, they weren't the same, even if no one knew it. This divergence is called drift (configuration drift).

With manual provisioning, no one knows for sure what's deployed, who created it, when, or why. The knowledge lives in the head of whoever set it up (or in scattered notes).

Example: You find a running server that costs money every month. No one remembers what it's for or if it can be turned off. Do you turn it off and risk breaking something, or do you keep paying "just in case"? Without documentation, you're flying blind.

• No review: a change made by hand doesn't go through any control. A person can modify production without anyone reviewing it.
• No history: there's no record of "what changed and when," as there is with code.
• No easy rollback: if a change breaks something, there's no "undo" button. You have to remember and revert each step by hand.

When there are several people, manual provisioning becomes chaos:

• Two people can change the same thing at the same time and overwrite each other.
• No one knows what each person touched.
• The "expert who set it up" becomes a bottleneck (and a risk if they leave the company).

If you notice, all these pains share a cause: the infrastructure is not written or recorded anywhere reliable. It's "done by hand" and exists only in the AWS console and in people's memory.

What if we could describe all our infrastructure in text files, as if it were code? Then we could:

• Reuse it (create identical environments instantly).
• Version it (change history, like in Git).
• Review it (have someone else validate before applying).
• Revert it (go back to a previous version).
• Automatically document it (the code IS the documentation).

That idea is exactly Infrastructure as Code, and that's what we'll see in the rest of Part III.

• Manual provisioning (creating infrastructure by clicking in the console) is good for learning, but not for serious projects.
• Its problems: it's slow and repetitive, prone to errors, causes drift (diverging environments), leaves no record of what exists, and doesn't scale with a team.
• The root cause: the infrastructure is not written anywhere reliable, only in the console and in people's memory.
• The solution is to describe the infrastructure in text files (code): reusable, versionable, reviewable, and reversible. That's Infrastructure as Code.

In the next subchapter, we'll see a key nuance of IaC: the difference between the declarative and imperative approach, and why Terraform chooses the declarative one.