Understand IaC concepts →easyMultiple ChoiceObjective-mapped

TF-004 Understand IaC concepts Practice Question

Exhibit

# backend.tf
terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

A team uses the backend configuration above. What is the primary benefit of storing state remotely in S3?

⚠ Common exam trap

HashiCorp often tests the misconception that remote state is about performance (faster execution) or security (automatic encryption), when the actual core purpose is enabling safe, concurrent team collaboration through state sharing and locking.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enabling state sharing and locking across the team

Storing Terraform state remotely in S3 is the standard practice for team collaboration because it allows multiple team members to access and modify the same state file, preventing conflicts. Combined with DynamoDB for state locking, it ensures that only one person runs `terraform apply` at a time, avoiding race conditions and state corruption. This is the primary benefit over local state storage, which is single-user by design.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Automatic encryption of state files
Why it's wrong here
While many remote backends, such as AWS S3, offer server-side encryption capabilities for data at rest, this feature is typically configured at the backend service level and is not automatically enforced by Terraform itself simply by enabling a remote backend. Users must explicitly configure encryption settings (e.g., SSE-S3, KMS) for their chosen backend. Therefore, automatic encryption is not an inherent or primary benefit provided by Terraform's remote state configuration.
✗
Reducing the number of API calls to AWS
Why it's wrong here
Utilizing a remote backend for Terraform state storage, such as an S3 bucket, actually introduces additional API calls to the chosen backend service. During `terraform plan` and `terraform apply` operations, Terraform must make network requests to read the current state and then write the updated state. These calls are distinct from, and in addition to, the API calls Terraform makes to provision resources with the cloud provider, meaning remote state does not reduce overall API interactions.
✓
Enabling state sharing and locking across the team
Why this is correct
The paramount benefit of a remote backend is enabling seamless collaboration among multiple team members by centralizing the Terraform state file in a shared, persistent location. This ensures everyone operates against the same authoritative infrastructure definition. Furthermore, remote backends provide crucial state locking mechanisms, which prevent concurrent `terraform apply` operations from simultaneously modifying and potentially corrupting the state file, thereby maintaining state integrity and consistency.
✗
Faster Terraform execution times
Why it's wrong here
Storing the Terraform state file in a remote backend inherently introduces network latency into the execution process. Each `terraform plan` or `terraform apply` command requires Terraform to perform network I/O operations to fetch the current state and then persist the updated state back to the remote location. This overhead typically results in slightly slower execution times compared to reading and writing a state file directly from a local filesystem, making faster execution an incorrect expectation.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

TF-004 Understand IaC concepts Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question