Understand Terraform basics →mediumMultiple ChoiceObjective-mapped

TF-004 Understand Terraform basics Practice Question

Exhibit

Error: creating EC2 Instance: InvalidParameterValue: Value (ami-0c55b159cbfafe1f0) for parameter ami is invalid. Expected: 'ami-...'.

  on main.tf line 22, in resource "aws_instance" "web":
  22:   ami = "ami-0c55b159cbfafe1f0"

Refer to the exhibit. Which change to the configuration would prevent this error in the future?

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

✓

Use a data source to fetch the AMI dynamically.

Using a data source to dynamically fetch the correct AMI avoids hardcoding invalid IDs and ensures the AMI exists in the region.

Answer analysis

Option-by-option breakdown

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

✗
Hardcode a different AMI ID.
Why it's wrong here
Hardcoding a different AMI ID is a poor practice because it only provides a temporary fix. While a newly hardcoded ID might be valid at the moment of configuration, AMI IDs are frequently updated or deprecated by cloud providers, especially for managed images. This approach does not prevent future `InvalidAMIID.NotFound` errors, as the hardcoded value will eventually become stale and invalid, requiring manual intervention and code changes each time.
✗
Set the AMI to null.
Why it's wrong here
Setting the AMI to `null` would not resolve the issue and would likely introduce a different type of error. The `ami` argument for an AWS EC2 instance resource expects a string value representing a valid AMI ID. Providing `null` would violate this type constraint, causing Terraform to fail during the plan validation phase, or the AWS provider to reject the configuration, stating that a non-null string is required. This would prevent any infrastructure changes from being applied.
✗
Add a lifecycle rule to ignore changes.
Why it's wrong here
Adding a `lifecycle` rule to `ignore_changes` is ineffective for addressing an invalid AMI ID. The `ignore_changes` lifecycle block instructs Terraform to disregard drift for specified attributes *after* the resource has been created and is in a valid state. It does not help in resolving an initial `InvalidAMIID.NotFound` error during resource creation or update, as the problem lies in fetching a valid ID, not in ignoring subsequent modifications to an already valid one.
✓
Use a data source to fetch the AMI dynamically.
Why this is correct
Using a data source to fetch the AMI dynamically is the correct and most robust solution. A data source, such as `aws_ami`, queries the AWS API at `terraform plan` time, using filters (e.g., owner, name patterns, tags) to retrieve the most current and valid AMI ID that matches the specified criteria. This ensures that the EC2 instance is always provisioned with an existing and up-to-date image, effectively preventing `InvalidAMIID.NotFound` errors caused by stale or hardcoded values.

Go deeper

TF-004 Understand Terraform basics Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question