Use Terraform outside the core workflow →mediumMultiple ChoiceObjective-mapped

TF-004 Use Terraform outside the core workflow Practice Question

Exhibit

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Refer to the exhibit. The user runs 'terraform plan' and sees that Terraform wants to create the instance. However, the instance already exists in the AWS account with the same configuration. What is the most likely reason?

⚠ Common exam trap

The Terraform exam often tests the misconception that Terraform automatically detects existing resources in the cloud provider, but in reality Terraform relies entirely on its state file to know what it manages, and any resource not in the state is treated as new regardless of its existence in the cloud.

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

✓

The instance is not in the Terraform state

Terraform determines whether to create, update, or destroy resources by comparing the desired configuration in the .tf files against the current state stored in the state file. If the instance already exists in AWS but is not recorded in the Terraform state, Terraform has no knowledge of it and will plan to create a new resource. This is the most likely reason because the instance is present in the account but absent from the state, causing Terraform to treat it as a new resource.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The instance type has changed
Why it's wrong here
If the instance type specified in the Terraform configuration were different from the type of the existing AWS EC2 instance, Terraform would typically plan an update to that specific resource. Depending on the provider's schema for `aws_instance`, changing the `instance_type` usually results in an in-place modification or, in some cases, a replacement of the existing instance. It would not cause Terraform to plan the creation of an entirely new, duplicate instance while the original is still tracked.
✓
The instance is not in the Terraform state
Why this is correct
Terraform's `plan` command operates by comparing the desired state defined in the configuration files with the actual state recorded in its state file and the real-world infrastructure. If an `aws_instance` resource is defined in the configuration but is entirely absent from the Terraform state file, Terraform will interpret this as a new resource that needs to be provisioned. Consequently, even if an identical instance physically exists in AWS, Terraform will propose to `create` it because it has no record of managing that existing resource.
✗
The AMI ID has changed
Why it's wrong here
Should the AMI ID specified in the Terraform configuration differ from the AMI ID of the existing EC2 instance, Terraform would typically propose a replacement of the `aws_instance` resource. Changing the `ami` attribute for an `aws_instance` almost always forces a new instance to be launched and the old one terminated, rather than modifying the existing one in place. This action would be a `replace` operation on the *existing* resource, not a plan to create a *new*, separate instance.
✗
The provider version is different
Why it's wrong here
A discrepancy in the Terraform provider version, such as upgrading from `aws` provider `v3` to `v4`, primarily influences how Terraform interacts with the cloud API and interprets resource attributes. While significant schema changes in a new provider version *could* potentially trigger a resource replacement if an attribute is marked as forcing new, it would not cause Terraform to plan the creation of an entirely new resource if that resource is already correctly tracked in the state file. The core resource identity in the state would remain, preventing a duplicate creation.

Go deeper

TF-004 Use Terraform outside the core workflow Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question