The model
Infrastructure as code describes resources and their relationships in versioned files. A planning step compares the declared target with provider state and proposes changes. This makes infrastructure reviewable alongside application changes, but the plan is only as trustworthy as its inputs and state handling.
A concrete walk-through
A change that adds a database replica can be reviewed for cost, networking, and failover consequences before apply. State records resource identities so the tool can update existing resources rather than create duplicates. Remote state storage and locking help teams coordinate concurrent changes.
Costs and failure cases
Drift occurs when real infrastructure changes outside the declared workflow or provider state becomes stale. Applying a broad plan can replace resources or expose secrets if review misses destructive effects. Secrets should not be committed in plain text, and state files often contain sensitive values.
Check your understanding
A plan proposes replacing a production database after a naming change. What should reviewers check before applying it, and how can resource identity be preserved?