Manage Terraform state and remote backends
Free HashiCorp Certified: Terraform Associate (004) practice — 6 questions on Manage Terraform state and remote backends, with explanations. No sign-up. Full 12-question mixed test →
A team enables state locking for an S3 backend but wants to avoid provisioning a separate DynamoDB table. They are running Terraform 1.10. Which backend configuration argument enables native S3-based locking using conditional writes instead of DynamoDB?
Terraform 1.10 introduced native S3 state locking via S3's conditional write (If-None-Match) support. Setting use_lockfile = true in the s3 backend block enables this without requiring a DynamoDB table.
A resource attribute containing a database password is marked sensitive = true in an output block, but a teammate later opens the raw state file and finds the plaintext value. What is the correct explanation and remediation?
The sensitive attribute only redacts values from plan/apply CLI output and the HCP Terraform UI. The state file itself always stores the real value in plaintext (in the JSON structure), so protecting it requires backend-level encryption at rest plus strict IAM/access control on who can read the state.
A team is renaming a resource across a module used by 12 CI-driven environments (workspaces). They need the change to apply consistently and automatically the next time each environment's pipeline runs terraform plan, without any engineer needing to run a manual command against every workspace. Which approach BEST satisfies this requirement?
The moved block is committed directly to the configuration, so it is version-controlled and automatically applied by Terraform's plan/apply logic in every workspace and CI run — no manual per-environment command is required.
A resource block is deleted from configuration, but the team wants Terraform to stop managing the corresponding real-world infrastructure WITHOUT destroying it, and wants this decision version-controlled so every teammate and CI pipeline applies it consistently. Which approach BEST meets these requirements?
The removed block (introduced in Terraform 1.7) is written directly in configuration and version-controlled. Setting lifecycle { destroy = false } tells Terraform to stop managing the resource and drop it from state without issuing a destroy call against the real infrastructure — and it's consistently applied by every plan/apply, including CI.
What does running terraform plan -refresh-only actually produce?
-refresh-only mode queries real infrastructure and compares it to the state file, surfacing drift (out-of-band changes) as a plan of proposed STATE updates only — it never proposes changes derived from the .tf configuration.
A team runs terraform import aws_instance.web i-0abc123456 against a configuration that has no aws_instance.web resource block defined anywhere in the .tf files. What is the result?
The classic terraform import CLI command only writes to the state file — it requires a resource block with that exact address to already exist in configuration, and errors immediately if it does not find one. Automatic HCL generation is only available via the newer `import` configuration block with the -generate-config-out flag, not the legacy import command.
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
undefined $34.99 with code FREETEST33 — valid through Sep 23.
Get my $34.99 deal →