HashiCorp Terraform Associate (004) Question 185
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 want Terraform to start managing this bucket without recreating it. A teammate writes the following configuration:
resource "aws_s3_bucket" "logs" {
bucket = "company-logs-prod"
}
After running terraform init, what is the most appropriate next step to bring the existing bucket under Terraform management while minimizing the risk of accidental replacement?
- A
Run
terraform applyso Terraform can detect the existing bucket and automatically adopt it into state. - B
Run
terraform import aws_s3_bucket.logs company-logs-prod, then review the plan and update the configuration to match the imported resource's settings. - C
Run
terraform state add aws_s3_bucket.logs company-logs-prod, then apply to populate the missing bucket arguments. - D
Delete the bucket in AWS and run
terraform applyso Terraform can recreate it from configuration and manage it cleanly.
Show answer and explanation
Correct answer: B
Explanation
The correct import workflow is: create a resource block in configuration, run terraform import to map the existing remote object to that resource address in state, then run terraform plan and refine the configuration until it accurately represents the imported resource. Terraform does not automatically discover and adopt existing infrastructure during apply. This behavior is documented in Terraform's import workflow: the CLI import operation associates an existing remote object with a resource address in state, but you still need configuration that matches the resource to avoid unexpected drift or planned updates. Best practice after import is to review the plan carefully, because import populates state but does not automatically generate complete configuration for all resource arguments.
- A. Incorrect.
Incorrect.
terraform applydoes not automatically adopt existing infrastructure simply because a matching resource block exists in configuration. Terraform will compare configuration with state, and because the bucket is not yet in state, it will attempt to create a new resource. For globally unique resources such as S3 buckets, this usually results in an error because the bucket name already exists. A common misconception is that Terraform discovers existing resources from the provider automatically; in reality, Terraform primarily manages what is recorded in state. - B. Correct.
Correct. To bring an existing resource under Terraform management, you define the corresponding resource block and then import the real-world object into the Terraform state with
terraform import <ADDRESS> <ID>. For an S3 bucket, the import ID is the bucket name. After import, you should runterraform planand adjust the configuration so it matches the actual bucket settings, reducing the chance of Terraform proposing unwanted changes or replacement later. This is the standard workflow for importing existing infrastructure. - C. Incorrect.
Incorrect.
terraform state addis not the correct workflow for importing provider-managed infrastructure. Terraform state subcommands are intended for advanced state manipulation, but they do not query the provider and import live resource attributes the wayterraform importdoes. Someone might choose this option because it sounds similar to adding a resource to state, but it bypasses the supported import mechanism. - D. Incorrect.
Incorrect. Deleting a production bucket that is already in use is risky and unnecessary. Import exists specifically so Terraform can begin managing existing infrastructure without destroying and recreating it. In a real environment, deleting a shared or production S3 bucket could cause data loss or service interruption. This option reflects an unsafe anti-pattern rather than a best practice.