HashiCorp Terraform Associate (004) Question 186
Single answer7a Import existing infrastructure into your Terraform workspaceYour team has been manually managing an AWS S3 bucket named company-logs for several months. You now want Terraform to manage this existing bucket without recreating it. A developer adds the following configuration to the root module:
resource "aws_s3_bucket" "logs" { bucket = "company-logs" }
When they run terraform plan, Terraform proposes creating a new bucket and the run would fail because the bucket name is already in use. What is the best next step to bring this existing bucket under Terraform management in this workspace?
- A
Run terraform import aws_s3_bucket.logs company-logs so the existing bucket is associated with the resource address in state, then run terraform plan to verify the configuration matches the real infrastructure.
- B
Run terraform apply -refresh-only so Terraform discovers the existing bucket automatically and adds it to state without changing infrastructure.
- C
Run terraform state rm aws_s3_bucket.logs and then terraform apply so Terraform stops trying to create the bucket and starts managing the existing one.
- D
Add a data "aws_s3_bucket" "logs" block instead of a resource block, then run terraform apply to convert the existing bucket into a managed resource.
Show answer and explanation
Correct answer: A
Explanation
To manage existing infrastructure with Terraform, you must define the resource in configuration and then import the existing remote object into the Terraform state using the correct resource address and import ID. In this scenario, aws_s3_bucket.logs is the resource address and company-logs is the import identifier. After import, best practice is to run terraform plan and reconcile any differences between the configuration and the actual bucket settings. This reflects Terraform's core model: configuration describes desired state, and state tracks the binding between resource addresses and real infrastructure. Refresh-only operations do not discover unmanaged resources, state rm does not adopt resources, and data sources are read-only. HashiCorp documentation for resource import and state management supports this workflow.
- A. Correct.
Correct. Importing is the proper workflow when infrastructure already exists but is not yet tracked in the current Terraform state. The command maps the real object, identified by its provider-specific import ID (for an S3 bucket, typically the bucket name), to the configured resource address aws_s3_bucket.logs. After import, terraform plan should be run to identify any drift between configuration and the actual bucket settings so the configuration can be updated as needed.
- B. Incorrect.
Incorrect. terraform apply -refresh-only updates state for resources that are already tracked in state; it does not discover unmanaged infrastructure and import it automatically. A common misconception is that refresh can 'find' existing resources, but Terraform requires an explicit import step for unmanaged objects.
- C. Incorrect.
Incorrect. terraform state rm removes an object from state if it is already tracked. In this scenario, the bucket is not yet in state, so this does not solve the problem. Even if it were tracked, removing it from state would make Terraform forget it, not adopt it. The next apply would still attempt to create a resource unless an import is performed.
- D. Incorrect.
Incorrect. A data source can read information about existing infrastructure, but it does not make Terraform manage that object's lifecycle. Replacing the resource block with a data block would allow references to the bucket, but Terraform still would not own or manage the bucket as a resource in state.