Courseiva
Read, generate and modify configurationhardMultiple ChoiceObjective-mapped

TF-004 Read, generate and modify configuration Practice Question

You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. Each environment has its own state file stored in an S3 backend with DynamoDB locking. The team recently adopted a policy of running 'terraform plan' in CI/CD pipelines to review changes before applying. However, developers have reported that sometimes the plan output shows that Terraform wants to destroy and recreate resources that were not modified in their code changes. For example, a developer added a new tag to an S3 bucket in the staging environment, but the plan also showed that an unrelated EC2 instance would be replaced. Upon investigation, you notice that the state file for staging was last modified two days ago, but the developer's branch is based on a commit from one week ago. Which action is most likely to resolve the issue and ensure that plans only reflect changes from the current configuration changes?

⚠ Common exam trap

HashiCorp often tests the misconception that `terraform plan -refresh=true` (or the default refresh) is sufficient to synchronize state, when in fact it only updates the state against live infrastructure without re-downloading the remote state file, leaving stale local state intact.

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

Run 'terraform init -reconfigure' to ensure the local state is synchronized with the remote backend before planning.

`terraform init -reconfigure` forces Terraform to reinitialize the backend and re-download the latest state file from the remote S3 backend, discarding any stale local copy. The developer's local state was based on a week-old commit, while the actual remote state had been updated two days ago, causing Terraform to detect spurious differences (e.g., an unrelated EC2 instance) due to state drift. This command ensures the local state matches the remote state before planning, so the plan only reflects changes from the current configuration.

Answer analysis

Option-by-option breakdown

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

  • Run 'terraform init -reconfigure' to ensure the local state is synchronized with the remote backend before planning.

    Why this is correct

    Running 'terraform init -reconfigure' forces Terraform to re-initialize its backend configuration, which includes re-downloading the latest authoritative state file from the configured remote backend. This action is essential when the local state cache is stale or missing, ensuring that subsequent 'terraform plan' operations accurately compare the desired configuration against the actual infrastructure reflected in the most current remote state. It effectively resolves discrepancies arising from out-of-band changes or state updates by other team members, providing a synchronized baseline.

  • Set the 'skip_metadata_api_check' option in the provider to avoid changes.

    Why it's wrong here

    The 'skip_metadata_api_check' option is a provider-specific setting, typically found in cloud providers like AWS, designed to bypass checks against the instance metadata service. Its primary purpose is to prevent network calls or errors in environments where the metadata API is inaccessible or undesired, such as when running Terraform outside of an EC2 instance or in a restricted network. This setting has no functional relationship to synchronizing Terraform's state file with the actual infrastructure or resolving state drift issues.

  • Use 'terraform plan -target=aws_s3_bucket.bucket' to limit the plan to only the S3 bucket.

    Why it's wrong here

    Using the '-target' flag with 'terraform plan' instructs Terraform to limit its operations to only the specified resource or module, ignoring all others in the configuration. While this might prevent the EC2 instance's discrepancy from appearing in the *current* plan, it merely defers the underlying issue of state drift or an outdated local state for that resource. The EC2 instance's unmanaged changes or state discrepancy would still exist and manifest in any future plan executed without the '-target' flag.

  • Run 'terraform plan -refresh=true' to refresh the state before planning.

    Why it's wrong here

    The 'terraform plan' command inherently performs a refresh operation by default, comparing the remote infrastructure's current state with the state recorded in the *local* state file. While '-refresh=true' explicitly enables this behavior, it does not address situations where the local state file itself is outdated or corrupted relative to the authoritative remote state backend. The problem isn't that a refresh isn't happening, but rather that the baseline for the refresh (the local state) is incorrect or stale, leading to inaccurate plan outputs.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

Quick reference

AWS S3 Storage Class Comparison

Storage ClassMin DurationRetrievalUse Case
S3 StandardNoneImmediateFrequently accessed data
S3 Standard-IA30 daysImmediateInfrequent access, rapid retrieval
S3 One Zone-IA30 daysImmediateNon-critical infrequent data
S3 Intelligent-TieringNoneImmediate–hoursUnknown or changing access patterns
S3 Glacier Instant90 daysMillisecondsArchive with instant retrieval
S3 Glacier Flexible90 daysMinutes–hoursArchive, flexible retrieval
S3 Glacier Deep Archive180 daysHoursLong-term compliance archive

About these practice questions

This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.