02 Machinery
What this stage buys you: you can look at a plan and say what will happen and why, before running it — including the changes you didn't ask for.
This is the stage that makes the article worth writing. Terraform tutorials are abundant and
uniformly stop at the end of the language: they show you configuration that works, and leave the
question of how it works to the reference documentation, which answers a different question. Almost
nobody writes down what actually happens between terraform plan and the output on your screen.
The practical difference this stage makes is that plan output stops being a wall of text you skim for
the summary line and becomes something you read. Every surprising plan — the replacement you didn't
ask for, the (known after apply) that spreads across resources you didn't touch, the ordering that
seems backwards — has an explanation, and after this stage you can find it yourself rather than
searching for someone with the same symptom.
What you should already know: how to write and apply a multi-resource configuration, what a resource address looks like, and that state exists and maps configuration to real objects. In article terms: The Language, or at minimum Resources & References and Anatomy of a Project.
| # | Topic | What it covers |
|---|---|---|
| 1 | The Plan/Apply Lifecycle | End to end: parse → resolve → refresh → graph → diff → render; plan files and -out; reading + - ~ -/+ <=; what forces replacement rather than in-place update; plan-time versus apply-time evaluation and why unknown values propagate |
| 2 | The Dependency Graph | What creates an edge — implicit reference, explicit depends_on, module boundary, provider; what parallelises and what serialises; -parallelism; walking the graph to explain an ordering surprise |
| 3 | Meta-Arguments | count versus for_each and the addressing consequence; depends_on as a code smell; lifecycle — create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by; per-resource provider |
Read them in order. The dependency graph explains ordering, which the lifecycle page assumes
exists but doesn't detail; and meta-arguments only make sense after the graph, because the property
that matters most about for_each — that the key becomes part of the resource address — is a
statement about graph nodes rather than about loop syntax.
Rough time: two weeks. Longer than Stage 0 for three pages, because this is the material worth slowing down for.