Resource Lifecycle Management practice questions

replace_triggered_by

Why it fails: replace_triggered_by forces replacement of a resource when a referenced resource or attribute changes; it does not control how the ASG replaces instances during a launch template change. It is tempting because it sounds like it triggers the right replacement, but the requirement is instance refresh behaviour, handled by create_before_destroy.

ignore_changes

Why it fails: ignore_changes tells Terraform to disregard changes to specified attributes, so the launch template update would never be applied to the ASG. It is tempting because it prevents disruptive diffs, but here the change must take effect while capacity is maintained, which create_before_destroy achieves.

prevent_destroy

Why it fails: prevent_destroy blocks destruction of a resource entirely, causing an error rather than maintaining capacity during a launch template change. It is tempting because it sounds like it protects the ASG, but it stops the update instead of orchestrating a graceful replacement, which create_before_destroy provides.

Use lifecycle { force_replace = true }

Why it fails: This is not a valid lifecycle meta-argument.

Use create_before_destroy.

Why it fails: create_before_destroy only changes the order in which a replacement is created relative to destroying the old resource; it does not detect that the S3 object key changed. It is tempting because it governs replacement behaviour, and it would be correct when a resource must stay available during recreation to avoid downtime.

Use ignore_changes = [source_code_hash]

Why it fails: ignore_changes suppresses updates to the named attribute, so Terraform would never react to a changed source_code_hash and no replacement would occur. It is tempting because it silences unwanted diffs, and it would be correct when an attribute is managed externally and should not trigger changes.

To delete orphaned resources.

Why it fails: Terraform doesn't have a 'refresh to delete' command.

To apply changes to the cloud provider.

Why it fails: Use terraform apply.

To upgrade the Terraform version.

Why it fails: Use terraform init -upgrade.

ignore_changes = [ingress[0].cidr_blocks]

Why it fails: ignore_changes accepts attribute names, not indexed expressions; ingress[0].cidr_blocks is invalid syntax there. It is tempting because indexing works elsewhere in HCL, but ignore_changes matches whole attributes only. To ignore one rule, use a dynamic block or filter the list before assignment.

ignore_changes = [ingress.0]

Why it fails: HCL's ignore_changes takes a list of attribute references, so ingress.0 is parsed as an attribute named '0' on ingress, not the first element; the correct syntax is ingress[0]. It tempts because dotted numeric paths appear elsewhere in Terraform, but list indices require bracket notation.

ignore_changes = { ingress = [0] }

Why it fails: ignore_changes expects a list of attribute references, not a map keyed by attribute name, so this object literal is invalid syntax. It tempts because maps with numeric lists resemble index targeting, yet only bracket notation such as ingress[0] selects a list element.

force_keep

Why it fails: No force_keep meta-argument exists in Terraform; replacement is governed by lifecycle blocks, specifically prevent_destroy and create_before_destroy, or by ignore_changes. It tempts because the name suggests retaining an existing object, which is what prevent_destroy genuinely accomplishes during destroy operations.

keep_alive

Why it fails: Terraform has no keep_alive meta-argument; lifecycle blocks offer create_before_destroy, prevent_destroy, ignore_changes and replace_triggered_by, none of which block replacement on configuration change. The genuine mechanism is the lifecycle replace_triggered_by attribute controlling what forces replacement, not a keep_alive flag.

prevent_replace

Why it fails: prevent_replace is not a Terraform meta-argument; no such lifecycle setting exists. Replacement on configuration change is governed by the provider's ForceNew attributes and the lifecycle replace_triggered_by meta-argument. prevent_destroy merely blocks destruction of an existing object, which is a different concern entirely.

The resource is destroyed as well.

Why it fails: Deleting the referenced resource does not cascade destruction; replace_triggered_by only forces replacement when the referenced attribute changes, and a deleted reference simply yields no trigger. It is tempting because dependency chains can propagate destruction, but that behaviour belongs to explicit depends_on or reference-based graph edges, not to this lifecycle argument.

The resource is kept as is.

Why it fails: A deleted referenced resource produces no attribute value to compare, so no replacement is triggered; the resource is not simply left untouched as a rule. It is tempting because replace_triggered_by never destroys anything by itself, but the accurate outcome is that the trigger evaluates against a null or absent value and no action occurs.

The trigger is ignored.

Why it fails: Terraform treats it as a dependency failure.

version_pin

Why it fails: Not a lifecycle meta-argument.

allow_replace

Why it fails: Invalid meta-argument.

To force the creation of a new resource.

Why it fails: ignore_changes suppresses diffs on existing attributes; it never triggers replacement, and no lifecycle argument can force resource creation. It tempts because lifecycle blocks do govern create/destroy behaviour, but create_before_destroy or replace_triggered_by handle recreation, not ignore_changes.

To prevent Terraform from destroying a database.

Why it fails: ignore_changes only filters attribute differences during planning; it cannot stop destruction, which requires prevent_destroy = true. It tempts because both are lifecycle meta-arguments guarding a database, yet prevent_destroy blocks deletion while ignore_changes merely ignores drift on chosen attributes.

prevent_destroy

Why it fails: prevent_destroy is a lifecycle meta-argument that protects a resource from accidental destruction. It does not initiate replacement; it only blocks Terraform from destroying the resource. If you set this, Terraform would error out when attempting to replace the RDS instance, which is the opposite of what you need.

ignore_changes

Why it fails: The ignore_changes meta-argument tells Terraform to ignore changes to specified attributes when planning updates. It does not trigger replacement; instead, it prevents Terraform from reacting to changes in those attributes. Using it here would not cause the RDS instance to be replaced when subnet IDs change, and would actually suppress the desired behavior.

create_before_destroy

Why it fails: create_before_destroy changes the order of operations during replacement by creating the new resource before destroying the old one. It does not trigger replacement based on changes to other resources or attributes. While it can be used in conjunction with replacement triggers, it alone does not satisfy the requirement to replace when subnet IDs change.

The error occurs because the KMS key is missing; you need to specify a `kms_key_id` in the configuration and then apply.

Why it fails: While a KMS key is required for encryption, the error is not about a missing key. The fundamental issue is that encryption cannot be enabled on an existing unencrypted instance. Adding a KMS key alone will not bypass the immutability of the attribute.

The `storage_encrypted` attribute can be modified in place, but only if the instance is stopped first; you should stop the instance, apply, then start it again.

Why it fails: AWS RDS does not support modifying the encryption setting of an existing instance, even when stopped. Stopping the instance does not change the underlying storage encryption. This option suggests an unsupported workaround that will not resolve the error.

You must manually enable encryption in the AWS Console, then run `terraform refresh` to update the state.

Why it fails: AWS does not allow enabling encryption on an existing RDS instance via the console either. The only way is to create a new encrypted instance and migrate. Manually changing it is not possible, and `terraform refresh` would not help because the attribute cannot be changed.

create_before_destroy on the ASG

Why it fails: While create_before_destroy on the ASG might seem helpful, it would attempt to create a new ASG before destroying the old one. However, ASGs often have unique names or other constraints that prevent two instances from coexisting. Moreover, the primary need is to replace the ASG when the launch configuration changes, which is handled by replace_triggered_by. Using create_before_destroy on the ASG alone does not address the launch configuration change.

ignore_changes on the ASG for the launch_configuration attribute

Why it fails: Ignoring changes to the launch_configuration attribute would cause Terraform to ignore any updates to the launch configuration reference, meaning the ASG would never be updated. This defeats the purpose of rolling out a new launch configuration. It is used to suppress diffs, not to trigger updates.

prevent_destroy on the launch configuration

Why it fails: prevent_destroy would block Terraform from destroying the old launch configuration, which is required when replacing it. This would cause Terraform to error during apply, preventing the update. It does not facilitate the desired update; instead, it protects the resource from deletion, which is counterproductive here.

ignore_changes = all

Why it fails: Using ignore_changes = all would cause Terraform to ignore all attribute changes for the resource, including instance_class and storage_type. That would prevent reverting the manual instance class change and also ignore any other drift. This does not satisfy the requirement to revert the instance class change while only ignoring storage_type.

ignore_changes = [instance_class]

Why it fails: Ignoring instance_class would prevent Terraform from reverting the manual change, which is the opposite of what is needed. The requirement is to revert instance_class changes and avoid touching storage_type. This option fails because it would leave the manually altered instance class in place and not enforce the desired configuration.

ignore_changes = [storage_type, instance_class]

Why it fails: This would ignore both storage_type and instance_class changes, meaning the manual instance class modification would not be reverted. The goal is to revert instance_class changes, so including it in ignore_changes is incorrect. Only storage_type should be ignored to meet the stated requirement.

Configure `termination_policies` to `OldestInstance` on the Auto Scaling group.

Why it fails: termination_policies control which instances are chosen for termination during scale-in, not whether lifecycle hooks block deletion. Changing this does not affect the terminating:wait behavior. The group destroy would still wait for the hook to complete or time out, so this does not meet the requirement.

Add `lifecycle { prevent_destroy = true }` to the Auto Scaling group.

Why it fails: prevent_destroy prevents Terraform from destroying the resource at all, which directly conflicts with the requirement to destroy the group. It does not address the lifecycle hook waiting period. This would cause an error on destroy rather than allowing it to proceed, so it is the opposite of what is needed.

Set `lifecycle { create_before_destroy = true }` on the Auto Scaling group.

Why it fails: create_before_destroy changes the order of creation and destruction for replacement, but it does not affect lifecycle hooks on the Auto Scaling group. During destroy, the hook would still hold instances in terminating:wait, potentially causing a timeout. This setting is unrelated to the hook behavior and would not solve the hanging destroy.

Use a `null_resource` with a `triggers` map that references the launch template version, and add a `depends_on` to the Auto Scaling group.

Why it fails: A `null_resource` with triggers can run provisioners when the version changes, but it does not force replacement of the Auto Scaling group. `depends_on` only establishes ordering, not replacement. This approach would not achieve the desired effect of replacing the Auto Scaling group when the launch template version changes.

Set `create_before_destroy = true` on the Auto Scaling group and rely on Terraform to detect changes automatically.

Why it fails: `create_before_destroy` only controls the order of operations during replacement; it does not trigger replacement based on a specific attribute change. Terraform would still detect changes to the launch template version if the attribute is not ignored, but it would not limit replacement to only that change. The requirement is to replace only when the version changes, not on other attribute changes.

Use `lifecycle { ignore_changes = [launch_template] }` on the Auto Scaling group and manually update the launch template version.

Why it fails: `ignore_changes` would prevent Terraform from detecting any changes to the launch template attribute, including version changes. This would not trigger replacement when the version changes; instead, it would ignore the change entirely, leading to drift. It is the opposite of what is needed.

The AWS provider does not support create_before_destroy on aws_db_instance because RDS requires a unique identifier and cannot run two instances with the same name.

Why it fails: The AWS provider fully supports create_before_destroy on aws_db_instance. The replacement instance is created with a temporary identifier and later renamed, so a unique identifier collision is not the cause. This distractor confuses a provider limitation with a lifecycle propagation issue that actually stems from the dependent resource's configuration.

create_before_destroy requires the resource to also set prevent_destroy = true, and the missing combination causes the apply to fail on the dependent record.

Why it fails: prevent_destroy and create_before_destroy are independent meta-arguments and are not mutually required. Setting prevent_destroy = true would actually block the destroy phase entirely, causing a different error. The failure here is specifically about the dependent aws_route53_record lacking the lifecycle setting needed to coexist with the old database during replacement.

The failure occurs because aws_route53_record must use replace_triggered_by referencing the database's id attribute to allow replacement.

Why it fails: replace_triggered_by forces replacement when a referenced attribute changes; it does not resolve ordering conflicts during create_before_destroy. The route53 record failure is caused by the dependent resource lacking create_before_destroy, not by a missing trigger. Using replace_triggered_by here would add unnecessary churn without addressing the underlying lifecycle propagation requirement.

Add lifecycle { create_before_destroy = true } to the aws_db_instance so the database is never left in a destroyed state during updates.

Why it fails: create_before_destroy only changes the ordering of replacement operations so a new object is created before the old one is destroyed. It does nothing to stop an explicit terraform destroy or removal of the resource from configuration, so the production database could still be deleted. It also does not distinguish between prod and staging environments, making it irrelevant to this requirement.

Apply a separate terraform destroy -target=aws_db_instance.staging command and rely on operators never targeting the production instance.

Why it fails: Relying on operator discipline is not an enforced control. A plain terraform destroy with no -target removes every managed resource, including the production database, so the compliance guarantee would depend entirely on human behavior. Terraform offers no built-in protection here unless prevent_destroy is set, so this approach fails the stated policy.

Move the production database into a separate workspace and document that terraform destroy must not be run against that workspace.

Why it fails: Workspaces isolate state, not permissions or safety rails. Nothing in Terraform prevents someone from selecting the production workspace and running destroy, and the isolation actually increases the chance of an accidental deletion because operators switch contexts frequently. Documentation alone cannot enforce the compliance policy that the database must never be destroyed.

Set `force_destroy = false` on the S3 bucket resource.

Why it fails: force_destroy controls whether Terraform can delete a bucket that contains objects. Setting it to false means Terraform will fail to delete a non-empty bucket, but it does not prevent deletion of an empty bucket. It is not a comprehensive prevention mechanism and does not stop `terraform destroy` from deleting the bucket if it is empty.

Add a `depends_on` to another resource to create a dependency that blocks deletion.

Why it fails: depends_on creates an ordering dependency for creation and updates, but it does not prevent destruction. Terraform will still destroy the bucket when it is removed or when destroy is run, after handling dependencies. It is not a deletion protection feature and does not satisfy the requirement.

Enable versioning on the S3 bucket to allow recovery of deleted objects.

Why it fails: Versioning protects objects within the bucket, not the bucket itself. If the bucket is destroyed, versioned objects are also deleted (unless MFA delete is used, which is a separate feature). Versioning does not prevent the bucket from being deleted by Terraform, so it does not meet the requirement.

Set `ignore_changes = [ami]` on the instance to force a replacement.

Why it fails: ignore_changes suppresses differences for the listed attributes and never causes a replacement. Using it here would hide AMI differences rather than trigger replacement, which is the opposite of the desired outcome. It has no role in making replace_triggered_by work.

Mark the instance as tainted with `terraform taint` before each apply.

Why it fails: tainting forces a replacement on the next apply, but it is a manual, one-time action and not a configuration-driven mechanism. It does not react to data source changes and would require repeated manual intervention, so it does not satisfy the requirement for automatic replacement when the value changes.

Add `create_before_destroy = true` to the instance's lifecycle block.

Why it fails: create_before_destroy controls the order of operations during a replacement but does not trigger one. It is often paired with replace_triggered_by to reduce downtime, but on its own it will not cause the instance to be replaced when the data source value changes, so it is not one of the required actions.

lifecycle { ignore_changes = [bucket] }

Why it fails: ignore_changes would prevent Terraform from detecting changes to the bucket attribute, which would stop the policy from being updated when the bucket ARN changes. This is the opposite of what is needed, as it would ignore the very change that should trigger replacement.

lifecycle { create_before_destroy = true }

Why it fails: create_before_destroy controls the order of creation and destruction but does not trigger replacement based on attribute changes. It would not cause the policy to be replaced when the bucket ARN changes; it only affects how replacement occurs if it is already triggered.

lifecycle { replace_triggered_by = [aws_s3_bucket.example] }

Why it fails: Using the resource itself without an attribute means any change to the bucket resource will trigger replacement of the policy, not just ARN changes. This could cause unnecessary replacements when unrelated bucket attributes change. The requirement is to trigger only on ARN changes, so this is too broad.

Set `lifecycle { ignore_changes = [tags] }` on the S3 bucket to prevent accidental deletion.

Why it fails: `ignore_changes` on tags only prevents Terraform from detecting tag changes; it has no effect on deletion protection. It does not prevent the bucket from being destroyed, nor does it allow object deletion. This option is irrelevant to the requirement.

Enable versioning on the S3 bucket to prevent object deletion.

Why it fails: Versioning preserves object versions but does not prevent Terraform from deleting objects or the bucket. When Terraform deletes an object, it adds a delete marker, but the object versions remain. However, this does not satisfy the requirement to allow Terraform to delete individual objects; it actually retains them. It also does not prevent bucket destruction.

Set `force_destroy = false` on the `aws_s3_bucket` resource.

Why it fails: `force_destroy = false` is the default and prevents Terraform from deleting a bucket that contains objects. However, it does not prevent the bucket from being destroyed if it is empty; it only blocks deletion when objects are present. It also does not allow individual objects to be deleted independently. The requirement is to prevent bucket destruction entirely, not just when objects exist.