TF-Associate-004 - Maintain infrastructure with Terraform (8% of the exam) - Section 7a
Import existing infrastructure into your Terraform workspace.
Import brings an unmanaged resource under Terraform, either with the terraform import command or an import block, after which configuration must match the imported object. Candidates should understand import populates state but does not write configuration for you.
terraform importimport blockimport populates state onlyconfiguration must match imported resource
Practice question for this objective
lock_openFree sampleMaintain infrastructure with Terraformmedium
A practitioner has an S3 bucket named 'reports-archive' that was created by hand in the AWS console. They add an aws_s3_bucket resource block called 'archive' to their configuration and run the command shown. After it completes, they run 'terraform plan' and see that Terraform still wants to make changes to the bucket. What is the most likely reason?
AThe import failed silently because a bucket can only be imported using its full ARN rather than its name.
BThe import wrote the resource into state but the configuration arguments do not yet match the real bucket's settings, so the plan proposes to reconcile them.check_circle Correct
Cterraform import also updates the configuration files, so the leftover changes mean the import command was run against the wrong resource address.
DTerraform always recreates an imported resource on the first apply, so the plan is showing the mandatory replacement step.
Understand that terraform import populates state only and the configuration must be written to match the imported resource. terraform import records the existing resource in Terraform state but does not generate or alter configuration, so until the HCL block's arguments describe the real resource accurately, terraform plan will keep proposing changes to close the gap between configuration and state.
Why A is wrong: This is tempting because ARNs identify AWS resources, but each resource type documents its own import ID format and aws_s3_bucket accepts the bucket name, so the import itself would have succeeded.
Why B is correct: terraform import only populates state; it never writes HCL, so any argument that differs from or is missing against the real bucket shows as a proposed change until the block is edited to match.
Why C is wrong: This misstates how import works: import populates state only and never edits configuration, so a non-empty plan is expected rather than a sign of a wrong address.
Why D is wrong: This sounds plausible to someone who fears import is destructive, but import brings a resource under management without recreating it; the changes come from configuration mismatch, not a forced replacement.
Exam traps in Maintain infrastructure with Terraform
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 generates a matching resource block in the configuration files and records the resource in state.
errorWhy it is wrong: This is tempting because newer tooling can suggest configuration, but the core import mechanism only writes to state; it does not author the configuration block for you.
Run 'terraform import' a second time with the -force flag so the state overrides the mismatched configuration values.
errorWhy it is wrong: This is tempting because re-importing feels corrective, but import populates state from the real resource and cannot make configuration values match; a -force flag for this purpose does not exist.
Terraform imports the instance into state and quietly creates a placeholder resource block in main.tf so future plans stay clean.
errorWhy it is wrong: This assumes import writes configuration, which it never does; the command only manipulates state, so no block would be created on the practitioner's behalf.