Skip to content
tezvyn:

IaC State: The Map Between Your Code and the Cloud

Source: developer.hashicorp.comHardHow cards are made

IaC State: The Map Between Your Code and the Cloud

IaC state is the source of truth mapping your code to real-world resources, acting as your tool's memory. Terraform uses a state file to plan updates, while other tools use a service backend. The footgun: never commit state files to Git; they lack locking and.

Why it exists

Declarative IaC tools need to know the difference between the desired state (your code) and the current state (the cloud). A state file is the mechanism for tracking this relationship. It stores the unique IDs of created resources, allowing the tool to update or destroy them in the future.

The mental model

Think of the state file as a detailed receipt and inventory list for your cloud infrastructure. Your code is the shopping list. Before making changes, the tool compares the inventory (state) against the shopping list (code) to see what to buy, return, or modify. Without this inventory, it would have no idea what it's already responsible for.

How it works

When you run a tool like Terraform, it first refreshes its state by querying the cloud provider for the current status of managed resources. It then compares this refreshed state to your configuration files to generate a plan of changes (create, update, delete). After you apply the plan, the tool records the new resource IDs and attributes in the state file.

When to use it

State management is not optional; it's a core part of how declarative IaC tools function. The key decision is how to store it. For any team project, use a remote backend that provides locking (to prevent simultaneous runs from corrupting state), encryption, and access control. Local state is only suitable for solo experiments.

When not to use it

Do not store state in a generic version control system like Git. These systems cannot lock the state file, creating a high risk of race conditions where two engineers applying changes at the same time overwrite each other's work and corrupt the state. State files can also contain secrets in plain text, which should never be committed to version control. You should also never edit the state file directly; use the tool's CLI commands (e.g., terraform state) for safe modifications.

One canonical example

A team uses Terraform to manage an AWS S3 bucket. The state is stored in an S3 bucket backend, which is configured to lock state using a DynamoDB table. When an engineer runs terraform apply, Terraform first acquires a lock from DynamoDB. This prevents anyone else from running an apply. It then reads the state from the S3 bucket, plans the changes, applies them, and writes the updated state back before releasing the lock.

Interview question

For a team managing Infrastructure as Code, what is the primary risk of storing IaC state files directly in a Git repository?

  • a.Concurrent infrastructure changes by multiple engineers can lead to state file corruption due to a lack of locking mechanisms.Correct
  • b.The state file could contain sensitive credentials, making them vulnerable to exposure.
  • c.Git's distributed nature makes it difficult to ensure all team members have the most current state.
  • d.The state file's size can become unmanageable, leading to performance issues for Git operations.
Why?

The card explicitly states that Git cannot lock the state file, leading to a high risk of race conditions where concurrent changes corrupt the state. While exposing secrets is a valid concern, the lack of locking and subsequent data corruption is highlighted as the primary operational risk for team-based state management in Git.

Just read this? Test yourself on what you have been reading.

Read the original → developer.hashicorp.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on iac — each one lists the topics its interview covers.

See open roles