Read, generate and modify configuration →hardMultiple Choice

TF-004 Read, generate and modify configuration Practice Question

A team has an existing S3 bucket created outside Terraform. They want to manage it with Terraform by importing its state. Which of the following is the correct sequence of commands to read the bucket's configuration and avoid drift?

⚠ Common exam trap

A common misconception is that `terraform import` automatically generates configuration files, when in reality it only populates the state, requiring manual configuration writing and iterative `plan` adjustments to avoid drift.

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

✓

Write a minimal resource configuration, run terraform import, then terraform plan, then adjust configuration to match state.

Importing an existing S3 bucket into Terraform requires first writing a minimal resource configuration (e.g., `resource "aws_s3_bucket" "example" { bucket = "existing-bucket-name" }`), then running `terraform import` to link the real-world bucket to the state file. After import, running `terraform plan` reveals any configuration-to-state mismatches, allowing you to adjust the resource block (e.g., adding `acl`, `versioning`, or `tags`) to match the actual bucket configuration, thereby avoiding drift. This workflow ensures the Terraform configuration accurately reflects the existing infrastructure before making changes.

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 refresh, then terraform state pull to generate configuration.
Why it's wrong here
`terraform refresh` and `terraform state pull` only read state and remote objects; neither writes HCL configuration, so drift persists. It is tempting because refresh reconciles state with reality, but generating configuration requires `terraform import` followed by `terraform state show`.
✗
Run terraform plan, note the resource address, then run terraform import.
Why it's wrong here
`terraform plan` reads remote state and configuration, not the existing bucket's real attributes, so it cannot supply the resource address for import. It is tempting because plan is the standard pre-change review step, but import requires the address from the configuration block, not from plan output.
✗
Run terraform import, then terraform state show to generate configuration.
Why it's wrong here
`terraform import` writes the bucket into state, and `terraform state show` prints its attributes, but neither generates HCL configuration, so drift remains until the config block is written manually. It is tempting because state show reveals attributes, but it does not produce configuration.
✓
Write a minimal resource configuration, run terraform import, then terraform plan, then adjust configuration to match state.
Why this is correct
Writing a minimal resource block first gives Terraform a matching address to import into; terraform import then populates state from the real bucket, and terraform plan reveals differences, which you reconcile by editing configuration until it matches state, eliminating drift.

Visual reference

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

TF-004 Read, generate and modify configuration Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question