Use Terraform outside the core workflow →easyMultiple Select

TF-004 Use Terraform outside the core workflow Practice Question

Which TWO statements about using Terraform with remote backends are correct?

⚠ Common exam trap

TF-004 often tests the misconception that remote backends require manual state migration or that Terraform Cloud is incompatible with remote backends — both are false, and candidates who don't know 'terraform init -migrate-state' pick the wrong answer.

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

✓

Remote backends store state in a shared location.

Option B is correct because a remote backend (for example, an S3 bucket, Azure Storage Account, GCS bucket, or Terraform Cloud workspace) stores the Terraform state file in a shared, remote location rather than on the local machine, allowing teams to collaborate on the same infrastructure. Option E is correct because most remote backends support state locking — such as S3 with a DynamoDB table, Azure Blob Storage, or Consul — which prevents concurrent runs from corrupting the state file. Option A is incorrect because migrating state to a remote backend is typically handled automatically by running `terraform init` with the new backend configuration, which offers to copy existing local state; manual migration is not a requirement. Option C is incorrect because storing state in the local filesystem describes the default local backend, not a remote backend. Option D is incorrect because Terraform Cloud itself is a supported remote backend (configured via the `cloud` block or `remote` backend), so remote backends can absolutely be used with it.

Answer analysis

Option-by-option breakdown

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

✗
Remote backends require manual state migration.
Why it's wrong here
When transitioning from a local backend to a remote backend, Terraform offers an automated state migration process. The `terraform init -migrate-state` command facilitates this by prompting the user to confirm the migration of the existing local state file to the newly configured remote backend. This built-in functionality eliminates the need for manual file transfers or complex scripting, ensuring a smooth and reliable transition. Therefore, the assertion that manual migration is required is incorrect.
✓
Remote backends store state in a shared location.
Why this is correct
Remote backends are fundamentally designed to store Terraform's state file in a centralized, shared location, such as an S3 bucket, Azure Storage Account, or a dedicated Terraform Cloud workspace. This shared storage ensures that all team members working on the same infrastructure configuration have access to the most current state of the managed resources. This collaborative approach prevents conflicts and ensures consistency across deployments, making it a critical feature for team environments.
✗
Remote backends store state in the local filesystem.
Why it's wrong here
This statement is incorrect because the primary distinction of a remote backend is its capability to store the Terraform state file externally, away from the local machine where `terraform apply` is executed. While a local backend defaults to storing `terraform.tfstate` in the current working directory, remote backends leverage cloud storage services or dedicated state management platforms. This externalization is crucial for collaboration and state consistency across multiple users and CI/CD pipelines.
✗
Remote backends cannot be used with Terraform Cloud.
Why it's wrong here
This statement is entirely false, as Terraform Cloud itself functions as a sophisticated remote backend for managing Terraform state. When using Terraform Cloud, the state files are automatically stored, versioned, and locked within the Terraform Cloud platform, providing a highly reliable and collaborative environment. Users explicitly configure their Terraform configurations to use the `cloud` backend type, which integrates directly with Terraform Cloud's state management capabilities.
✓
Remote backends enable state locking.
Why this is correct
A crucial advantage of remote backends is their ability to enable state locking, which prevents multiple users or automated processes from concurrently modifying the same Terraform state. When an operation like `terraform apply` begins, the remote backend acquires a lock on the state file, releasing it only upon completion. This mechanism is vital for maintaining state integrity, preventing race conditions, and avoiding accidental corruption of the infrastructure configuration in collaborative environments.

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 Use Terraform outside the core workflow Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question