Use the core Terraform workflow →mediumMultiple ChoiceObjective-mapped

TF-004 Use the core Terraform workflow Practice Question

A user wants to import an existing AWS EC2 instance into Terraform state so it can be managed. After writing the resource block matching the instance, what is the correct next step?

⚠ Common exam trap

HashiCorp often tests the misconception that 'terraform apply' or 'terraform refresh' can automatically discover and import existing resources, when in fact only 'terraform import' explicitly maps external resources into state.

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

✓

Run 'terraform import' with the resource address and ID of the instance.

After writing the resource block that matches the existing EC2 instance, the correct next step is to run 'terraform import' with the resource address and the instance ID. This command maps the real-world infrastructure to the Terraform state, allowing Terraform to manage the resource without destroying or recreating it. Without this explicit import, Terraform has no knowledge of the existing instance in its state file.

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 import' with the resource address and ID of the instance.
Why this is correct
The `terraform import` command is the designated tool for bringing pre-existing infrastructure resources, like an AWS EC2 instance, under Terraform's management. It requires both the resource's address as defined in the Terraform configuration (e.g., `aws_instance.my_server`) and its unique ID from the cloud provider (e.g., `i-0123456789abcdef0`). Upon successful execution, Terraform records the resource's current state into the `terraform.tfstate` file, allowing subsequent `terraform plan` and `apply` operations to manage it.
✗
Run 'terraform plan' to see if the import is necessary.
Why it's wrong here
The `terraform plan` command generates an execution plan, detailing the actions Terraform *would* take to reconcile the desired state defined in your configuration with the current state in the cloud and the Terraform state file. If an `aws_instance` resource is defined in the configuration but does not exist in the state file, `terraform plan` will propose to *create* a new EC2 instance, not detect and import an existing one. It serves as a dry run for changes, not a mechanism for discovering or importing unmanaged resources.
✗
Run 'terraform refresh' to sync state with the existing resource.
Why it's wrong here
The `terraform refresh` command, or the refresh phase within `terraform plan` and `apply`, is designed to reconcile the attributes of resources *already tracked within the Terraform state* with their actual, current state in the cloud provider. It updates the state file with any out-of-band changes made to managed resources. However, `refresh` cannot discover or add resources that are not yet present in the state file, making it unsuitable for importing new, unmanaged infrastructure.
✗
Run 'terraform apply' directly; Terraform will detect the existing resource and import it.
Why it's wrong here
Running `terraform apply` directly when an `aws_instance` resource is defined in configuration but not in state will cause Terraform to attempt to *create* a brand new EC2 instance in the AWS account. Terraform does not possess an inherent capability to automatically detect existing cloud resources and associate them with corresponding resource blocks in configuration files for import purposes. Without a prior `terraform import` operation, `apply` would provision a duplicate resource rather than managing the existing one.

Go deeper

TF-004 Use the core Terraform workflow Practice Question

Why each option matters

Option-by-option breakdown

Related to this question