TF-004 Understand Terraform basics Practice Question
A DevOps engineer is writing a Terraform configuration to provision an AWS EC2 instance. They want to ensure that the instance is replaced if the AMI ID changes, but not if the instance type changes. Which lifecycle meta-argument should be used?
⚠ Common exam trap
HashiCorp often tests the misconception that `create_before_destroy` alone controls replacement behavior, when in fact it only controls the order of operations and must be combined with `ignore_changes` to selectively prevent replacement on specific attributes.
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
✓
Set `create_before_destroy = true` and add `instance_type` to `ignore_changes`
`create_before_destroy = true` ensures the new instance is created before the old one is destroyed, which is a best practice for zero-downtime deployments when the AMI changes. Adding `instance_type` to `ignore_changes` tells Terraform to ignore changes to the instance type attribute during plan/apply, so the instance is not replaced when only the instance type changes. This combination precisely meets the requirement: replacement on AMI change, no replacement on instance type change.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set `prevent_destroy = true`
Why it's wrong here
This `lifecycle` rule completely blocks Terraform from destroying the resource, regardless of any configuration changes. While it would prevent an `instance_type` change from forcing a replacement, it would also indiscriminately prevent *any* other update that necessitates resource destruction (such as an AMI update) from being applied. This makes the resource unmanageable for necessary updates that require recreation, which is overly restrictive for typical operational needs.
- ✗
Set `ignore_changes = all`
Why it's wrong here
Setting `ignore_changes = all` within the `lifecycle` block instructs Terraform to disregard *any* attribute differences detected between the configuration and the real-world state for that specific resource. While this would prevent an `instance_type` change from triggering a replacement, it critically prevents *all* other desired updates, including essential ones like a new AMI ID, from being applied, as Terraform would simply ignore the change and not attempt any update or replacement.
- ✓
Set `create_before_destroy = true` and add `instance_type` to `ignore_changes`
Why this is correct
This solution effectively combines two distinct `lifecycle` rules to achieve the desired outcome. `create_before_destroy = true` ensures that when a change *does* necessitate a resource replacement (e.g., an AMI update), the new instance is fully provisioned and operational before the old one is terminated, minimizing service disruption. Concurrently, adding `instance_type` to `ignore_changes` specifically instructs Terraform to disregard modifications to this attribute, preventing it from triggering an unintended resource replacement solely due to an `instance_type` modification.
- ✗
Set `create_before_destroy = true` only
Why it's wrong here
While `create_before_destroy = true` is a valuable `lifecycle` rule for minimizing downtime during necessary resource replacements, it does not alter Terraform's fundamental plan to replace a resource when a non-updatable attribute, like `instance_type`, is modified. If the `instance_type` attribute is changed in the configuration, Terraform would still plan to destroy the old instance and create a new one, albeit in a "create-before-destroy" order, which fails to meet the requirement of preventing replacement for this specific attribute.
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.