TF-Associate-004 - Terraform fundamentals (11% of the exam) - Section 2d
Explain how Terraform uses and manages state.
State maps configuration to real-world resources, records metadata and dependencies, and lets Terraform plan by comparing configuration against last-known state. Candidates should understand why state is authoritative for what Terraform manages and why it must not be hand-edited casually.
state as source of managed resourcesresource-to-real-world mappingstate metadataplan diff against state
Practice question for this objective
lock_openFree sampleTerraform fundamentalsmedium
An engineer imports an existing S3 bucket into Terraform, then runs terraform plan without changing the configuration. Terraform reports one attribute that differs from the configuration. Why can Terraform detect this difference at all?
terraform import aws_s3_bucket.assets my-existing-bucket
terraform plan
ABecause Terraform queries the provider's live API on every plan and never relies on stored data.
BBecause import also generates the matching resource block, so plan compares two generated files.
CBecause the import wrote a resource-to-real-world mapping into state, which plan then compares against the configuration.check_circle Correct
DBecause the S3 bucket stores its own Terraform metadata that plan reads back on each run.
Import populates the resource-to-real-world mapping in state, which plan diffs against configuration to detect drift. Terraform can only report a difference when it holds a mapping from a configuration address to a real resource; import creates that mapping in state, so a subsequent plan compares recorded attributes with the configuration and surfaces the mismatch.
Why A is wrong: Terraform does refresh against the provider, but the comparison that surfaces a diff is made between configuration and the mapping recorded in state, not the live API alone.
Why B is wrong: Classic import does not author the configuration block for you; the mapping lands in state and the practitioner still writes the HCL, so this misstates how import works.
Why C is correct: Import records the real bucket under the resource address in state, giving Terraform a stored mapping it can diff against the configuration to reveal the mismatched attribute.
Why D is wrong: Managed resources do not carry Terraform metadata in the cloud; the mapping and metadata that plan needs live in the state file, not on the bucket itself.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
It is a cache of provider documentation that Terraform downloads so plans can run without network access.
errorWhy it is wrong: Provider schemas and documentation are supplied by the installed provider plugins, not by state, so this confuses two separate mechanisms.
Against the previous version of the .tf files stored in the local Git history for the working directory.
errorWhy it is wrong: Terraform has no awareness of version control; it compares configuration with state, not with earlier commits of the source files.
A local cache of provider binaries kept under the .terraform directory for reuse between runs.
errorWhy it is wrong: Cached provider plugins speed up initialisation, but they hold no record of resource attributes, so they cannot be the basis for computing a diff.