HashiCorp Terraform Associate (004) Question 184
Single answer7a Import existing infrastructure into your Terraform workspaceYour team has an existing AWS S3 bucket named company-logs-prod that was created manually and is already in use. You need Terraform to start managing this bucket without recreating or deleting it. A teammate adds the following configuration to the root module:
resource "aws_s3_bucket" "logs" { bucket = "company-logs-prod" }
After running terraform plan, Terraform shows that it wants to create a new bucket. What is the best next step to bring the existing bucket under Terraform management while minimizing risk?
- A
Run terraform import aws_s3_bucket.logs company-logs-prod, then run terraform plan and update the configuration if needed to match the real bucket settings.
- B
Run terraform apply so Terraform creates the bucket in state, then use terraform refresh to detect that the bucket already exists.
- C
Add lifecycle { prevent_destroy = true } to the resource and run terraform apply so Terraform adopts the existing bucket automatically.
- D
Run terraform state add aws_s3_bucket.logs company-logs-prod to register the bucket in state without needing configuration changes.
Show answer and explanation
Correct answer: A
Explanation
When importing existing infrastructure into a Terraform workspace, the safe and supported workflow is: define the resource block in configuration, run terraform import to associate the existing remote object with that resource address in state, and then run terraform plan to reconcile differences between configuration and the actual infrastructure. Terraform does not automatically adopt pre-existing objects during apply, even if the configuration matches. Best practice is to import first, then refine the configuration so the plan is either no-op or only includes intended changes. This aligns with Terraform CLI import behavior and the general guidance that state maps resource addresses to real infrastructure objects.
- A. Correct.
Correct. To manage existing infrastructure, Terraform requires both a resource block in configuration and an import operation that maps the real-world object to that resource address in state. For an S3 bucket, the import ID is the bucket name, so terraform import aws_s3_bucket.logs company-logs-prod is the right action. After import, terraform plan should be reviewed carefully because imported resources often need additional arguments in configuration to match their actual settings and avoid unintended drift or changes.
- B. Incorrect.
Incorrect. terraform apply will attempt to create the bucket because Terraform does not yet know the existing bucket belongs to aws_s3_bucket.logs in state. Since S3 bucket names are globally unique, this would typically fail rather than safely adopt the existing bucket. terraform refresh does not perform adoption of unmanaged infrastructure.
- C. Incorrect.
Incorrect. lifecycle.prevent_destroy only affects destroy behavior for a resource Terraform already manages in state. It does not cause Terraform to discover or adopt an existing object automatically. Terraform still sees aws_s3_bucket.logs as a resource to create until it is imported.
- D. Incorrect.
Incorrect. terraform state add is not the standard command for importing provider-managed existing infrastructure. The supported workflow is to define the resource in configuration and use terraform import to associate the external object with the resource address in state. Direct state manipulation is risky and not the intended solution for this scenario.