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?
terraform import aws_s3_bucket.archive reports-archive- 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. 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.
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.