Terraform State Explained for the Exam — Remote Backends, Locking, and State Traps

Terraform state is one of the most misunderstood topics on the Associate exam. Candidates who use Terraform daily still answer state questions incorrectly because the exam tests conceptual understanding, not operational familiarity.

Many wrong answers come from assumptions that feel reasonable but don’t match Terraform’s actual behavior. This article gives you a clear, exam-focused mental model for state, remote backends, and locking—the concepts that decide whether you pass or fail state-related scenarios.

What Terraform State Really Is

Terraform state is the mapping between your configuration and real infrastructure. It’s not optional. It’s not a convenience feature. It’s how Terraform knows what exists and what needs to change.

Why state exists:

Terraform cannot query all cloud resources to find “yours”—state tracks ownership
State enables Terraform to calculate the diff between desired and current configuration
Without state, Terraform would recreate everything on every apply

What Terraform stores in state:

Stored in State	Purpose	Resource IDs
Maps config resources to real infrastructure	Attribute values	Current values of all resource attributes
Dependencies	Implicit and explicit resource relationships	Provider metadata
Which provider manages each resource	Terraform version	Version that last wrote the state

Exam Insight

“Terraform plan compares configuration to state, not configuration to real infrastructure.” This is the most important state concept for the exam. Terraform reads state first, optionally refreshes it, then calculates changes.

Local State vs Remote State

By default, Terraform stores state in a local file called terraform.tfstate. This works for individual use but creates problems for teams.

Local state (default):

Stored in terraform.tfstate in the working directory
No automatic locking
No built-in sharing mechanism
Risk of state loss if file is deleted

Remote state:

State stored in a remote backend (S3, Azure Blob, GCS, Terraform Cloud, etc.)
Enables team collaboration—everyone works from the same state
Supports state locking (backend-dependent)
Enables encryption at rest

Exam Scenario Pattern

Question signal: “A team needs to collaborate on Terraform…”

Answer direction: Remote backend. The exam frequently presents team scenarios where remote state is the correct choice for consistency and preventing concurrent modification conflicts.

Remote Backends — What the Exam Expects You to Know

The exam tests backend concepts, not detailed configuration syntax. You need to understand what backends do, not how to write every backend block.

Key backend concepts:

Backend is defined in the terraform block

terraform { backend “s3” }

terraform init is required after backend changes

Changing backend configuration requires re-running terraform init. Terraform will offer to migrate existing state to the new backend.

Backend is NOT a provider

This distinction is heavily tested. Backends store state. Providers create resources. You can use an S3 backend without the AWS provider if you only need state storage.

Common backend types (conceptual):

Backend	State Storage	Locking
local	Local filesystem	No
s3	AWS S3 bucket	Yes (with DynamoDB)
azurerm	Azure Blob Storage	Yes (built-in)
gcs	Google Cloud Storage	Yes (built-in)
remote	Terraform Cloud/Enterprise	Yes (built-in)

Classic Exam Trap

Wrong assumption: “S3 backend automatically locks state.”
Reality: S3 backend requires a separate DynamoDB table for locking. Without DynamoDB configuration, S3 backend has no locking.

State Locking — Why It Matters

State locking prevents concurrent operations that could corrupt state or cause conflicting infrastructure changes.

What state locking prevents:

Two users running terraform apply simultaneously
State corruption from overlapping writes
Conflicting resource modifications
Race conditions in CI/CD pipelines

How locking works:

Before any state-modifying operation, Terraform attempts to acquire a lock
If lock is held by another process, Terraform waits or fails
After operation completes, Terraform releases the lock

Exam Signal

When a question mentions “team environment” or “CI/CD pipeline” with Terraform, state locking is almost always part of the correct answer. The exam expects you to know that collaboration requires both remote state AND locking.

Sensitive Data and State

This is a security-focused exam topic. Terraform state can contain sensitive data, and the exam tests whether you understand the implications.

What appears in state:

Database passwords if passed to resources
API keys and secrets used in configuration
Private IP addresses and internal resource identifiers
Any attribute value Terraform manages

What Terraform does NOT automatically do:

Encrypt local state files
Redact sensitive values from state
Prevent secrets from appearing in plan output (without explicit marking)

Security Best Practice (Exam-Relevant)

Remote backends with encryption at rest (S3 with SSE, Azure Blob with encryption) protect state from unauthorized access. The exam may present scenarios where “state contains secrets” leads to “use encrypted remote backend” as the answer.

terraform state Commands (Exam-Level Only)

You don’t need to memorize every terraform state subcommand, but you should recognize the core operations.

Command	Purpose	Exam Relevance
terraform state list	List all resources in state	Frequently tested
terraform state show	Show details of a specific resource	Frequently tested
terraform state rm	Remove resource from state (not infrastructure)	Conceptually tested
terraform state mv	Move/rename resources in state	Occasionally tested

Key concept: terraform state rm removes a resource from Terraform’s tracking without destroying the actual infrastructure. This is useful for “unmanaging” resources—the exam may test this distinction.

Common Terraform State Exam Traps

These are the specific misconceptions the exam exploits:

Trap 1: “State is optional”

Reality: State is mandatory. Without state, Terraform cannot track resources or calculate changes. There is no “stateless” Terraform mode.

Trap 2: “Plan works without state”

Reality: Plan reads state to calculate the diff. On a fresh project, state is empty (no resources tracked), but state still exists and is used.

Trap 3: “Backend = Provider”

Reality: Backends store state. Providers manage resources. You can use an S3 backend while provisioning Azure resources—they’re independent.

Trap 4: “Changed backend? Just run apply”

Reality: Backend changes require terraform init. Running apply without re-initializing will fail or use the old backend.

Trap 5: “Remote state is only for enterprises”

Reality: Any team collaboration benefits from remote state. The exam presents scenarios with 2-3 person teams where remote state is correct.

If You See This in a Question, Think This

Use these mental shortcuts for state-related questions:

State Decision Framework

→ “Where does Terraform track resources?” = State file

→ “Backend stores…” = State (not resources, not configuration)

→ “Provider creates…” = Resources (not state, not backend)

→ “Team collaboration” = Remote backend + locking

→ “Backend configuration changed” = Run terraform init

→ “S3 backend locking” = Requires DynamoDB

→ “Secrets in state” = Use encrypted remote backend

→ “Remove from state, keep infrastructure” = terraform state rm

Frequently Asked Questions

Is terraform.tfstate required?

Yes. State is mandatory for Terraform to function. Whether stored locally or remotely, Terraform always uses state to track managed resources. There is no way to disable state—without it, Terraform cannot plan or apply changes.

Does remote state change how resources are created?

No. Remote state only changes where state is stored. Providers still create resources the same way. An S3 backend doesn’t affect how AWS resources are provisioned—it only stores the state file in S3 instead of locally.

Do I need to commit state to Git?

No—and you shouldn’t. State often contains sensitive data. Instead, use a remote backend. Git is for configuration (.tf files), not state. The exam may present scenarios where “commit state to Git” is a wrong answer due to security concerns.

Can two people apply at the same time?

Not safely without state locking. If your backend supports locking (and it’s configured), the second apply will wait or fail. Without locking, concurrent applies can corrupt state or create conflicting resources.

What’s the difference between backend and provider?

Backend determines where state is stored (S3, Azure Blob, local file). Provider determines which cloud APIs Terraform calls to create resources (AWS, Azure, GCP). You can use an S3 backend while provisioning Azure resources—they are completely independent concepts.

Reframe and Prepare

Think of state as Terraform’s memory. Configuration tells Terraform what you want. State tells Terraform what exists. Backends decide where that memory is stored. Providers decide how resources are created.

The backend vs provider distinction is the single most important concept for state questions. If you internalize that backends store state while providers create resources, you’ll avoid the most common exam traps.

Structured practice helps cement these concepts. Platforms like Certsqill present state scenarios that force you to distinguish between backend configuration and provider behavior—training you to think like the exam expects.