1.1. What Infrastructure as Code Really Means
💡 First Principle: When you describe infrastructure as text that a tool reads and enforces, the description itself becomes the source of truth — so anything you can do to text (review it, version it, diff it, copy it) you can now do to your infrastructure. IaC is less about automation and more about turning infrastructure into a reviewable, repeatable artifact.
Why care: The first time a teammate provisions a server by hand at 2 a.m. during an incident, and nobody can later reproduce exactly what they did, you feel the cost of not having IaC. Manual changes are invisible, unrepeatable, and impossible to review before they happen. IaC makes every change a deliberate, inspectable event.
The mental model: Think of the difference between giving someone verbal directions to your house versus handing them a GPS coordinate. Verbal directions (manual setup) depend on memory, get stale, and differ each time they're retold. A coordinate (declared infrastructure) is exact, copyable, and produces the same destination every time.
⚠️ Common Misconception: Many people think IaC simply means "writing scripts to build servers." A bash script that runs aws ec2 run-instances is automation, but it lists steps and gives you no way to detect when reality has drifted from intent. True IaC describes the end state and continuously reconciles toward it — that is the leap this phase is about.
