Infrastructure as Code
Describing infrastructure so it can be reviewed, reproduced and changed safely — plans, state, drift, and the destructive changes a rename can hide.
Describing infrastructure in reviewed, versioned files so it can be reproduced and changed with the same evidence as application code.
Describing the end state and letting a tool derive the steps, versus writing the steps yourself — and the cases where writing the steps is still correct.
A plan is a diff between what the code says and what exists, classified into create, update, replace and delete — and every destructive line in it needs a human.
The mapping between configuration addresses and real resources — why it must exist, why it goes stale, why it holds secrets, and what concurrent applies do to it.
Reality diverging from what the code says — how it happens, which of it is legitimate, and why the next apply is the dangerous moment.
Replacing servers instead of modifying them, so that what is running is a known function of an artifact rather than the sum of its history.
A useful metaphor about replaceability that becomes dangerous when treated as a rule — because some infrastructure genuinely is irreplaceable, and a database treated as cattle is a data loss event.
Renaming a resource in configuration is read as delete-then-create, because the tool identifies resources by their address — and on a database that is the end of the data.