Infrastructure as Code (IaC) has revolutionized the way we manage cloud infrastructure, and Terraform stands tall as a leading tool in this space. But beyond its declarative syntax and CLI commands lies a critical yet often misunderstood component—Terraform State Management. This article dives deep into what happens under the hood during a typical Terraform run, inspired by a visual walkthrough of adding a single EC2 instance.
🎬 Scene: An IaC Developer’s First Terraform Commit
- Commit & Push
- A developer makes a change—say, adding a new virtual machine (VM)—and commits it to version control (
Git Commit V1
).
- A developer makes a change—say, adding a new virtual machine (VM)—and commits it to version control (
- Terraform CLI Execution
- The developer runs Terraform CLI commands:
terraform init
: Initializes the directory and downloads provider plugins via the Terraform API.terraform plan
: Creates an execution plan that outlines what Terraform will do to achieve the desired state.
- The developer runs Terraform CLI commands:
- Plan Output
- The plan clearly states: “I will add 1 EC2 instance,” highlighting the difference between the current infrastructure and the desired configuration.

🧠 The State Decision Gate: “Shall I?”
Before any action is taken, the developer (or CI/CD system) makes a conscious decision:
- If NO, the process halts—no changes are made.
- If YES, Terraform proceeds with the
terraform apply
command.
⚙️ Behind the Scenes: Terraform Apply & State Transition
When apply
is confirmed:
- API Interactions
- Terraform communicates with the AWS API (or any other cloud provider’s API) to provision the new EC2 instance.
- Terraform State Update
- After successful provisioning, the internal Terraform State is updated to reflect the new infrastructure.
- Remote State Management
- This state is then uploaded to a remote backend, commonly an S3 bucket (
S2 Remote Backend V1
). This remote state acts as the source of truth for future plans and applies.
- This state is then uploaded to a remote backend, commonly an S3 bucket (
🔄 Result: Synchronized Desired and Actual State
By the end of the flow:
- A new EC2 instance exists.
- The state file (
Statefile V1
) reflects this addition. - It is safely stored in a remote backend for future collaboration, drift detection, and disaster recovery.
📈 Why This Matters for Tech Teams and Recruiters
For technical professionals, understanding Terraform’s internal state flow ensures more reliable infrastructure deployments and fewer surprises during CI/CD pipeline executions.
For recruiters, this highlights:
- A candidate’s real-world IaC expertise
- Their understanding of state consistency, drift management, and collaboration best practices
- The ability to build reliable, repeatable infrastructure at scale
🧠 Pro Tip: State is Sacred
Never manually edit Terraform state files unless you know exactly what you’re doing. Use terraform state
commands and trust the remote backend to keep your infrastructure reproducible and safe.
🙌 Many thanks to Armon Dadgar & Anton Babenko ☁ for consistently sharing their insights and contributions to the Terraform ecosystem. Their efforts are building a global community centered on automation, reliability, and best practices in Infrastructure as Code.
💬 While in my forthcoming parts I will discuss more on the drift detection and drift management.
If you’re working with Terraform, how do you manage your remote state and avoid drift? Let’s share strategies in the comments 👇
#Terraform #DevOps #IaC #CloudComputing #AWS #InfrastructureAsCode #Hiring #Recruiters #SRE #DevOpsEngineers #PlatformEngineering
Comments
Add a comment…
No comments, yet.
Be the first to comment.