Infrastructure as Code and State
Summary
This note explains the core idea behind infrastructure as code and why state matters. The goal is to understand why IaC is more than writing config files: it is also about disciplined change, repeatability, and knowing what the system believes exists.
Official Terraform workflow diagram showing the basic path from writing configuration to planning and applying managed infrastructure changes.
Why this matters
- infrastructure as code is central to modern cloud and DevOps workflows
- state handling is one of the most important ideas behind safe IaC use
- cloud changes become much easier to review and explain when they are codified
Environment / Scope
| Item | Value |
|---|---|
| Topic | infrastructure as code fundamentals |
| Best use for this note | understanding repeatable cloud change |
| Main focus | desired state, actual state, and controlled updates |
| Safe to practise? | yes |
Key concepts
- Infrastructure as code - defining infrastructure through versioned files rather than manual portal clicking
- Desired state - what the code says should exist
- Actual state - what currently exists in the environment
- State - the record a tool uses to track managed resources
- Drift - when real infrastructure no longer matches the expected definition
Mental model
Think about the workflow like this:
code definition -> plan of change -> apply -> state updateIaC is powerful because it makes infrastructure changes reviewable, repeatable, and easier to troubleshoot later.
Everyday examples
| Situation | Why IaC helps |
|---|---|
| rebuild a lab environment | same setup can be recreated more consistently |
| review cloud changes before applying | plan stage shows intended changes |
| compare expected infra to reality | state and drift become visible |
| collaborate on infra work | code review is easier than portal memory |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”IaC means no more mistakes” | it reduces manual drift, but design and state issues still matter |
| ”The code file is the whole truth” | the state and real environment still need to match |
| ”Portal changes are harmless” | manual changes can create drift and confusion |
| ”If apply worked once, state is healthy forever” | state can still drift or become inconsistent later |
Verification
| Check | Expected result |
|---|---|
| Desired state is readable | code reflects intended architecture |
| Plan is understandable | changes are visible before apply |
| State is healthy | managed resources map correctly |
| Drift is controlled | actual environment matches code closely enough |
Pitfalls / Troubleshooting
| Problem | Likely cause | What to check |
|---|---|---|
| Apply behaves unexpectedly | desired state or state file mismatch | plan output and state |
| Infra differs from code | drift from manual changes | recent portal changes |
| Team is confused about what exists | weak state discipline | current state and code review |
| Fixes are hard to repeat | environment was built manually | IaC coverage |
Key takeaways
- IaC is about controlled, repeatable infrastructure change
- state is a core part of understanding what your tool believes exists
- cloud work gets easier when infrastructure is reviewable instead of remembered