HashiCorp 004: Terraform fundamentals Practice Questions

Correct: C. terraform fmt rewrites Terraform configuration files in the current directory to the canonical HCL style (indentation, alignment, spacing) without altering the logical meaning of the configuration. A is wrong — terraform validate checks configuration syntax and internal consistency but does NOT reformat files. B is wrong — terraform lint is not a built-in Terraform command; third-party tools like tflint exist but are not part of the core CLI. D is wrong — terraform refresh updates the Terraform state file to match the real-world infrastructure state; it does not touch source files.

Option D is correct: Terraform automatically loads terraform.tfvars (and terraform.tfvars.json) first, then any *.auto.tfvars files in lexicographic order. Files that are neither named terraform.tfvars nor suffixed .auto.tfvars — such as overrides.tfvars — are NOT loaded automatically and must be explicitly passed with -var-file=overrides.tfvars. Therefore terraform.tfvars is loaded first, then staging.auto.tfvars, and overrides.tfvars is ignored unless explicitly specified. Option A is wrong — there is no 'overrides' special file in Terraform's auto-loading rules. Option B is wrong — overrides.tfvars is not auto-loaded at all. Option C is wrong — terraform.tfvars is always loaded before *.auto.tfvars files.

Correct: A. terraform init -upgrade instructs Terraform to ignore the currently recorded versions in .terraform.lock.hcl and re-resolve all provider and module version constraints, potentially selecting newer versions and updating the lock file. C is wrong: Running terraform init without -upgrade respects the existing .terraform.lock.hcl and will not upgrade already-installed providers. B is wrong: terraform providers lock updates the lock file's cryptographic hashes for additional platforms but does not upgrade provider versions. D is wrong: terraform apply -refresh-only reconciles state with actual infrastructure; it has no effect on provider versions or the lock file.

Options A and C are correct. A: Since Terraform 0.15+, terraform destroy is an alias for terraform apply -destroy; the two commands are functionally identical. C: The -target flag works with terraform destroy just as with terraform apply, allowing scoped destruction of a single resource. Option B is wrong — terraform destroy never touches configuration files. Option D is wrong — like terraform apply, terraform destroy requires interactive approval unless -auto-approve is supplied. Option E is wrong — terraform destroy both removes resources from the provider AND updates the state file; terraform state rm removes from state only.

Correct: The -replace flag (introduced in Terraform 0.15.2) is the modern replacement for terraform taint. Running terraform apply -replace=aws_instance.app forces Terraform to destroy and re-create the specified resource in a single step. HashiCorp deprecated terraform taint in favor of this approach. — Distractor A is wrong because -taint is not a valid flag for terraform apply. — Distractor B is partially correct in concept (you CAN run terraform plan -replace=... and save the plan), but the question asks for the recommended single-step approach, which uses -replace directly with apply. — Distractor D is wrong because terraform state mark-replace is not a valid subcommand.