Further Reading: Infrastructure as Code

Sources are tagged Tier 1 (confident it exists, recommended without reservation) or Tier 2 (real and worth seeking, but confirm the current edition, version, or URL yourself).

This is a well-served topic with one gap, and the gap is the whole reason this chapter exists: the literature is written for application infrastructure, where resources are cattle and replacement is routine. A data platform's resources contain data, which changes the calculus on almost every recommendation — most sharply on §28.3's -/+.

Books

Kief Morris, Infrastructure as Code (2nd ed., O'Reilly, 2020). The standard reference and the one to read first. The chapters on testing infrastructure and on managing state are the relevant ones, and Morris is unusually good on why the practices exist rather than what they are. What he does not address — because it is not a general problem — is the stateful-resource question in §28.3. Tier 1.
Yevgeniy Brikman, Terraform: Up & Running (3rd ed., O'Reilly, 2022). The practical companion. Chapter 3 on state and Chapter 8 on production-grade code are the two that matter, and the state-splitting discussion is the careful version of §28.8. Brikman is also honest about Terraform's rough edges in a way vendor material is not. Tier 1 — confirm the edition; Terraform has changed substantially since the 2nd.
Nickolas Means and the "how they built it" genre, plus Google's Site Reliability Engineering on release engineering and configuration management. The SRE chapters are the source of the argument in §28.10 that convergence systems need a notification path, though they do not put it that way. Tier 1.

The primary sources

The Terraform documentation on lifecycle, import, moved, and check blocks. Four short pages, and between them they cover §28.3's prevent_destroy, §28.7's adoption strategy, the rename problem, and post-apply assertions. The moved block page in particular is worth reading if you have ever renamed a resource, because it addresses the most common trigger for Case Study 1's failure. Tier 1 — versioned; import blocks are 1.5+, check is 1.5+, test is 1.6+.
Your provider's documentation on which attributes are ForceNew. This is not a general document — it is per-resource, in the "Argument Reference" section, usually as a note saying "Changing this forces a new resource to be created." Read it for every stateful resource you manage, once, and write the list down. It is the information Case Study 1's review could not see. Tier 1.
The Docker documentation on multi-stage builds and on content-addressable image identifiers. §28.4, from the source. Tier 1.
The OpenTofu documentation, if that is what your organization uses. The divergence from Terraform is small today and growing, and §28.12's 🧭 note is the summary. Tier 2 — an active fork.

On the specific failures

Anything on "the summary line problem" in tooling output. There is no canonical source and the phenomenon is general: a tool that reports a count trains its reader to read the count. The closest useful literature is on cockpit and alarm design — the same body Chapter 23 and Chapter 25 point at — where the finding that a summary indicator degrades attention to the detail it summarizes is well established. Tier 2 — human-factors literature.
The idempotence and convergence literature from configuration management — Puppet's and Chef's design documents, and Mark Burgess's work on promise theory behind CFEngine. Case Study 2's "convergence without notification is the defect" is a statement inside that tradition, and Burgess in particular is precise about what a converging system does and does not promise. Tier 2 — the academic work is heavy going; the design documents are readable.
Anything careful on cloud cost attribution and tagging. The vendor documentation is adequate and the practice is mostly discipline. The one thing worth reading properly is your provider's documentation on tag propagation — which resources inherit tags, which do not, and which apply them only at creation — because the exceptions are where the untagged resources come from. Tier 1 for the provider docs.

On the honest Kubernetes question

The Kubernetes documentation on operational overhead, and more usefully, any postmortem literature from teams that adopted and then abandoned it. These are mostly blog posts and are worth reading precisely because the successful adoptions are far more visible. §28.5's list of three genuine reasons comes from noticing that the abandonment stories almost never cite any of them. Tier 2 — scattered; search for "we moved off Kubernetes."
The Airflow documentation on executors, comparing LocalExecutor, CeleryExecutor, and KubernetesExecutor. Read the resource-isolation discussion, which is the strongest argument for the third and is stated more carefully there than in most advocacy. Tier 1.

Practice

code/plan_review.py in this chapter. Parses terraform show -json and blocks on stateful destroys and replacements, widened IAM, lifecycle-rule changes, and reversions — with no Terraform, no cloud account, and no network. --demo reproduces both case studies' plans.
Run terraform plan -refresh-only today. Exercise 28.15. Write down your prediction first, because the gap between the prediction and the result is the finding. Kestrel's first run found four things in a week, none of them related.
Look up one stateful resource's ForceNew attributes and check whether any of them is something you would plausibly change. For a Snowflake database that attribute is name, and Case Study 1 is what happens.

A note on what to be skeptical of

Any infrastructure-as-code guidance that treats resources as replaceable. Most of it does, implicitly, because most of it is about application infrastructure where a replaced instance is a non-event. §28.3's boundary and prevent_destroy exist because that assumption is false for exactly the resources a data platform cares about, and a guide that does not distinguish them will lead you into Case Study 1.

And "manage everything as code" as an unqualified goal. §28.1's ordering is deliberate: the value varies by two orders of magnitude across resource types, and the teams that encode their BI tool's dashboard layouts are usually the ones whose IAM is still in a console.