Infrastructure as Code
Definition → plan → apply → real resources. Declarative desired state against imperative scripts, Terraform's vocabulary, state as the thing that makes it work and the thing that will hurt you, drift between the file and reality, modules that help versus abstraction that hides, and environments that differ on purpose.
Infrastructure defined in files under version control and applied by a tool rather than by a human in a console — so the environment can be rebuilt, diffed, reviewed and explained six months after the person who built it left.
Q · How do I make the infrastructure that runs production reproducible, reviewable and recoverable instead of a shape that exists only inside one account?
Desired state against a sequence of operations. Declarative tools converge and can preview; imperative scripts execute and cannot. Neither is universally right — a one-off operational task is a script, and pretending otherwise produces the worst code in the repository.
Q · Should I describe the infrastructure I want, or the steps that produce it — and when is the sequence actually the better model?
Resource, provider, variable, output, module, state, plan, apply. Seven of these eight words exist in every declarative IaC tool; learn them as concepts and Terraform becomes the worked example rather than the subject.
Q · What are the actual moving parts of a declarative IaC tool, and which of them are Terraform-specific rather than universal?
State is the map from declared resources to real ones. Without it the tool cannot tell "create" from "already exists". With it you own a lock, a backup, a plaintext secret store, and the only artifact whose corruption can make production unmanageable while it is still running.
Q · Why does a declarative tool need a state file at all, what exactly is in it, and what happens when two engineers apply at the same time?
A plan is a contract for what is about to happen to production. Learning to read it — especially the difference between ~ update in place and -/+ destroy and recreate — is the highest-value hour in this module.
Q · What exactly does a plan tell me, and which line in it means production is about to be destroyed and rebuilt?
The configuration says three servers; there are two, because someone deleted one during an incident. Or there are four, because someone added one by hand — and the next apply will delete it. Drift is not an anomaly; it is the normal consequence of production being touchable.
Q · What happens when someone changes infrastructure outside the tool, and how do I detect and reconcile it before the next apply makes the decision for me?
A module is a named boundary with an interface — a web service as load balancer plus compute plus identity plus alarms, instantiated four times. It earns its place when it removes a decision. A module that wraps one resource and exposes twenty variables is worse than the resource.
Q · When does grouping resources behind an interface make infrastructure clearer, and when is it just a second syntax for the same resource?
Environments must match in the ways that make a test meaningful — topology, deployment path, IAM shape, configuration mechanism — and must differ in the ways that make them affordable and safe: size, data, redundancy, access. A staging that is an exact full-scale copy of production is a bill, not a guarantee.
Q · Which properties of production must my lower environments reproduce, and which ones must they deliberately not?