TF-004 Use Terraform outside the core workflow Practice Question

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.

Go deeper

Related to this question