Understand Terraform basics →mediumMultiple ChoiceObjective-mapped

TF-004 Understand Terraform basics Practice Question

Exhibit

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

output "instance_id" {
  value = aws_instance.example.id
}

Refer to the exhibit. After running terraform apply, the output shows:

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

instance_id = "i-1234567890abcdef0"

However, the engineer notices that the instance type is t2.micro, but the expected instance type was t2.medium. What is the most likely reason for this discrepancy?

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 configuration file specified t2.micro, so Terraform created the instance accordingly.

The configuration explicitly sets instance_type to t2.micro, so Terraform will use that value. The engineer may have expected a different value but the configuration is authoritative.

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 configuration file specified t2.micro, so Terraform created the instance accordingly.
Why this is correct
Terraform operates on a declarative model, where the configuration file explicitly defines the desired state of infrastructure. When `terraform apply` is executed, Terraform compares this desired state with the current state and provisions resources to match the configuration. Therefore, if `t2.micro` was specified in the configuration, Terraform's primary function is to ensure the created instance adheres precisely to that explicit instruction, making the configuration the authoritative source.
✗
The engineer applied a different configuration file by mistake.
Why it's wrong here
This option is incorrect because the question explicitly states 'after running terraform apply' and refers to an 'exhibit' showing the applied configuration. Terraform's output, including the instance type, directly reflects the configuration file that was successfully applied. While an engineer *could* mistakenly apply a different file, the premise of the question and the provided context indicate that the exhibit accurately represents the configuration that led to the observed outcome.
✗
Terraform ignored the instance_type argument because it is not supported for the given AMI.
Why it's wrong here
Terraform does not silently ignore unsupported arguments; instead, it performs schema validation against the provider's definition for the resource type. If an argument like `instance_type` were truly unsupported for a given AMI or resource, Terraform would halt the plan or apply operation and return a clear error message. This explicit error handling prevents unexpected behavior and ensures that all specified configuration parameters are either valid or flagged as problematic.
✗
The instance_type was overridden by a default value in the provider.
Why it's wrong here
Provider default values for arguments are only applied when an argument is entirely omitted from the configuration, not when it is explicitly set. When an argument such as `instance_type` is explicitly defined in the Terraform configuration, that explicit value always takes precedence over any potential default value specified by the provider. Terraform prioritizes the user's explicit instructions, ensuring that the desired state is precisely what the configuration declares.

Go deeper

TF-004 Understand Terraform basics Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question