HashiCorp 004: Terraform state management Practice Questions

Options B and C are correct. The sensitive = true flag in Terraform only redacts values from CLI output and plan displays — it does NOT encrypt or exclude the value from the state file. The state file always stores all resource attributes in plaintext JSON. Therefore, encrypting the state file at rest (e.g., using S3 SSE, GCS encryption, or Azure Storage encryption) is the correct mechanism to protect sensitive data. Option D is wrong — sensitive = true does not perform any encryption; it is purely a display control. Option A is wrong — sensitive outputs are written to state; they are just redacted in terminal output. Option E is wrong — sensitive does not prevent writing to state; it only controls display behavior.

The Terraform state file (terraform.tfstate) maps real-world infrastructure to the configuration, allowing Terraform to know which cloud resources correspond to which resource blocks. This is how Terraform tracks resource identity, detects drift, and manages updates. Option D is wrong: provider binaries are stored in the .terraform directory, not in state. Option B is wrong: terraform plan always re-evaluates the configuration against current state and the real infrastructure; state is not a plan cache. Option A is wrong: credentials are configured via environment variables, provider blocks, or credential files — never stored in the state file (though sensitive resource attributes may appear in state).

Option A is correct. When real infrastructure exists but is not tracked in the Terraform state file, this is called configuration drift (or state drift). The state file no longer accurately reflects the actual infrastructure. Option B is incorrect — a missing resource in state does not mean the file is corrupted; it may simply never have been imported or may have been manually created. Option C is incorrect — Terraform does NOT automatically reconcile resources it doesn't know about; untracked resources are ignored unless imported. Option D is incorrect — a backend misconfiguration would typically cause errors reading or writing state, not silently omit resources.

Terraform's S3 backend requires the DynamoDB table to have a partition key named exactly LockID (case-sensitive) of type String. Terraform writes a lock entry using this key when a state-modifying operation begins. Option A (lock_id) is wrong: the casing does not match; Terraform will fail to acquire or release locks if the key name differs. Option C (StateFile) is a plausible-sounding but incorrect name. Option D (TerraformLock) is also incorrect; Terraform does not recognize this key name.

Option A is correct. terraform state mv moves an existing state entry from one address to another. After updating the configuration code and running this command, Terraform will associate the existing infrastructure with the new resource address, avoiding destruction and recreation. Option D is incorrect — terraform state show is a read-only command used to display attributes of a resource in state; it cannot rename or move resources. Option C is incorrect — terraform import is used to bring an existing resource under Terraform management that has no state entry; using it here would require removing the old entry first and risks a plan that wants to destroy the old resource. Option B is incorrect — terraform apply -replace forces the resource to be destroyed and recreated, which is the opposite of the desired outcome.