The Resource Lifecycle and Dependencies — Terraform & Infrastructure as Code

Every resource in Terraform has a lifecycle: it is created, potentially modified over time, and eventually destroyed. Understanding how Terraform decides when to create vs update vs destroy-and-recreate a resource is critical for avoiding unexpected downtime. Some attribute changes can be applied in place (updating an EC2 instance's tags), others require destroying and recreating the resource entirely (changing an EC2 instance's AMI — you can't change the base image of a running instance). Terraform marks forced-recreate changes with `-/+` in the plan output, which is the signal that the operation will cause downtime. The `lifecycle` meta-argument provides control over this behaviour: preventing destruction, creating a replacement before destroying the original, and ignoring specific attribute changes that external systems manage. Dependencies — both implicit (from attribute references) and explicit (`depends_on`) — determine the order in which resources are created, updated, and destroyed.

Analogy🏏Cricket

🏏 Think of it like cricket: Before standardised cricket rulebooks existed, every ground played by its own local customs — different LBW interpretations, different wide-ball rules, inconsistent DRS protocols. A touring team playing in a new city had to learn an entirely different set of rules. The standardised ICC rulebook is IaC: a version-controlled document that specifies exactly how cricket is played anywhere in the world. When any ground host asks 'how should this match be set up?', they apply the rulebook — not their memory, not local tradition, not a wiki page from 2019. Every ground becomes reproducible because they're all applying the same version-controlled specification. The insight is that codifying rules enables consistency at scale — you can run a thousand simultaneous cricket matches and every one follows the same rules because they all reference the same canonical document.