TF-004 Read, generate and modify configuration Practice Question
An organization has a policy that all AWS S3 buckets must have versioning enabled. They want to ensure that even if someone removes the `versioning` block from the configuration, the bucket still has versioning enabled after `terraform apply`. Which lifecycle configuration should they add to the `aws_s3_bucket` resource?
⚠ Common exam trap
Terraform often tests the distinction between lifecycle meta-arguments that prevent resource destruction (like `prevent_destroy`) versus those that prevent configuration drift (like `ignore_changes`), and the trap here is that candidates confuse `prevent_destroy` with protecting individual attributes from being overwritten.
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
✓
`ignore_changes = [versioning]`
`ignore_changes = [versioning]` tells Terraform to disregard any changes to the `versioning` block in the configuration during `terraform apply`. This ensures that even if someone removes the `versioning` block from the HCL, the existing versioning state on the S3 bucket (enabled) remains unchanged, enforcing the organization's policy.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
`ignore_changes = [versioning]`
Why this is correct
The `ignore_changes` lifecycle meta-argument instructs Terraform to disregard any differences detected for the specified attributes between the configuration and the real-world state during a plan. By setting `ignore_changes = [versioning]`, Terraform will not attempt to revert or modify the `versioning` configuration of the S3 bucket, even if it has been changed outside of Terraform. This is the correct approach to prevent Terraform from undoing an out-of-band modification to a specific attribute, ensuring the external change persists.
- ✗
`replace_triggered_by = [aws_s3_bucket_versioning.this]`
Why it's wrong here
The `replace_triggered_by` lifecycle meta-argument forces a resource to be replaced if any of the specified dependencies change. This mechanism is designed to trigger a full recreation of the resource itself, not to selectively ignore changes to a particular attribute within that resource. Therefore, it would not prevent Terraform from attempting to revert an out-of-band modification to the `versioning` attribute, as its purpose is resource replacement, not attribute drift management.
- ✗
`prevent_destroy`
Why it's wrong here
The `prevent_destroy` lifecycle meta-argument is a safety mechanism that prohibits Terraform from destroying the entire resource it is applied to. If set to `true`, Terraform will error out if an `apply` operation would result in the destruction of that resource, safeguarding against accidental deletion. However, this meta-argument does not address changes to individual attributes within a resource, nor does it instruct Terraform to ignore drift on specific properties like `versioning`.
- ✗
`create_before_destroy`
Why it's wrong here
The `create_before_destroy` lifecycle meta-argument modifies the default replacement behavior for a resource. When a resource needs to be replaced, this setting ensures that the new resource is created and fully operational before the old resource is destroyed, minimizing downtime. This meta-argument is concerned with the order of operations during a resource replacement cycle and has no functionality to ignore or prevent Terraform from managing specific attribute changes or drift.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.