AWS provider Resource Lifecycle Management Practice Test 4 — 15 Questions

Question 1

If a user wants to ensure that a resource's lifecycle is managed by Terraform but wants to bypass the 'prevent_destroy' protection, what is the best approach?

Accepted Answer

Remove the prevent_destroy block from the configuration and apply.. The prevent_destroy lifecycle meta-argument is a configuration-level protection, not a state-level one. To bypass it, you must edit the configuration to remove (or comment out) the prevent_destroy argument from the lifecycle block, then run terraform apply so the plan reflects the new configuration. Only after the argument is gone from the config can terraform destroy proceed against that resource.

Answer

Add 'ignore_changes = [prevent_destroy]' to the block.

Answer

Use 'terraform state rm' to remove the constraint.

Answer

Use 'terraform destroy -force-remove-prevent-destroy'.

Question 2

Which THREE of the following are true regarding 'create_before_destroy'?

Accepted Answer

It is intended to minimize downtime during updates.. Option A is correct because create_before_destroy changes Terraform's default destroy-then-create ordering so the replacement resource is provisioned first, keeping the old resource serving until the new one is ready and thereby minimizing downtime during updates. Option B is correct because create_before_destroy is a meta-argument configured inside a resource's lifecycle block, for example lifecycle { create_before_destroy = true }. Option C is correct because running both the old and new resource simultaneously requires enough provider quota/capacity to temporarily hold two instances of that resource. Option D is not correct because create_before_destroy does not automatically resolve name collisions; unique-name constraints (such as fixed Name tags or DNS names) can still cause the create step to fail and often require name generators or other workarounds. Option E is not correct because create_before_destroy is a core Terraform lifecycle meta-argument available across providers, not an AWS-only feature.

Answer

It automatically resolves all name collision issues.

Answer

It is only available for AWS providers.

Question 3

Which TWO of the following accurately describe the behavior of 'terraform state rm'?

Accepted Answer

It stops Terraform from tracking the resource.. Option A is correct because 'terraform state rm' removes the specified resource from the Terraform state file, so Terraform no longer tracks or manages that resource in future plans and applies. Option B is correct because the command only edits state metadata; it does not call the provider's delete API, so the actual real-world resource (e.g., an EC2 instance or S3 bucket) continues running untouched. Option C is wrong because no 'force' flag is required for all resources; the command simply removes the address from state. Option D is wrong because the action is not strictly irreversible — you can re-import the resource with 'terraform import' or restore a state backup. Option E is wrong because 'terraform state rm' never destroys cloud infrastructure; only 'terraform destroy' or 'terraform apply' with removal does that.

Answer

It requires the 'force' flag for all resources.

Answer

It is a permanent action that cannot be undone.

Answer

It destroys the infrastructure in the cloud.

Question 4

Which THREE of the following are consequences of drifting from the Terraform state?

Accepted Answer

The plan may show changes even if the config hasn't changed.. Option A is correct because Terraform compares the configuration against the recorded state to build the plan; if real infrastructure has drifted from that state, the refresh will detect differences and the plan can show changes even though the .tf configuration itself was never modified. Option B is correct because if someone manually deletes a resource that still exists in the state file, the next refresh/plan will fail to find it and Terraform reports an error such as 'Resource Not Found' (or removes it from state depending on version), breaking the expected mapping between state and reality. Option D is correct because when drift is detected, Terraform's plan will propose actions to bring the real infrastructure back in line with the configuration, so the next apply may revert the out-of-band manual changes. Option C is not correct because lifecycle meta-arguments (create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by) are configuration-level features and are not disabled by state drift. Option E is not correct because Terraform never rewrites your configuration files automatically; drift only affects the state and the plan, not the .tf source code.

Answer

It disables the use of lifecycle meta-arguments.

Answer

It automatically updates the configuration file.

Question 5

Which TWO of the following are valid ways to handle a resource that has become 'tainted'?

Accepted Answer

Run 'terraform apply' to recreate it.. Option A is correct because running 'terraform apply' after a resource has been tainted causes Terraform to destroy and recreate that resource, which is the standard way to replace a tainted object. Option B is correct because 'terraform untaint <resource_name>' explicitly removes the taint marker from the resource in the state, leaving the existing object in place without forcing replacement. Option C is wrong because 'terraform refresh' only reconciles state with real infrastructure and does not clear taint status. Option D is wrong because 'terraform state rm' removes the resource from state entirely, which is not a taint-handling operation and can cause orphaned infrastructure. Option E is wrong because 'terraform plan' has no '-force-apply' flag; it only previews changes and cannot apply or clear a taint.

Answer

Run 'terraform refresh' to clear the taint.

Answer

Use 'terraform state rm' to fix the taint.

Answer

Use 'terraform plan -force-apply'.

Question 6

Which TWO actions can be taken to resolve issues where a resource must be replaced, but 'prevent_destroy' is enabled?

Accepted Answer

Run 'terraform state rm' to remove the resource from state and re-import.. Option B is correct because running 'terraform state rm <resource_address>' removes the resource from Terraform's state file, which detaches it from the 'prevent_destroy' lifecycle meta-argument (that constraint is only enforced when Terraform plans to destroy a resource it manages in state); the resource can then be re-imported with 'terraform import' or recreated without triggering the destroy protection. Option D is correct because 'prevent_destroy' is a lifecycle block setting in the resource configuration, so deleting that lifecycle block (or the specific prevent_destroy argument) from the .tf file removes the constraint and allows Terraform to plan and perform the replacement. Option A is wrong because '-auto-approve' only skips the interactive approval prompt; it does not override lifecycle constraints, and the plan will still fail with an error that the resource has prevent_destroy set. Option C is wrong because 'terraform refresh' only reconciles state with real infrastructure and has no effect on lifecycle meta-arguments. Option E is wrong because 'prevent_destroy' cannot be set or toggled via a CLI flag or argument; it is defined only in the resource's lifecycle block in configuration.

Answer

Use 'terraform apply -auto-approve'.

Answer

Use 'terraform refresh' to update the constraint.

Answer

Set the prevent_destroy argument to false in the CLI.

Question 7

Which TWO factors must be considered when using 'replace_triggered_by' with multiple resources?

Accepted Answer

The trigger cannot cause a circular dependency loop.. Option C is correct because replace_triggered_by creates a dependency edge from the referencing resource to the referenced resource, so if the referenced resource already depends on the referencing one (directly or transitively), Terraform will detect a circular dependency and fail the plan. Option D is correct because replace_triggered_by can only reference resources (or attributes) that Terraform knows about within the same configuration/state; cross-state references are not resolvable as trigger sources, so the referenced resource must live in the same state file. Option A is wrong because replace_triggered_by works against any resource or attribute reference, not just the tags attribute. Option B is wrong because replace_triggered_by has no requirement that create_before_destroy be false; the two settings are independent. Option E is wrong because replace_triggered_by is provider-agnostic and works with any Terraform resource, not only AWS resources.

Answer

The trigger only works on the 'tags' attribute.

Answer

The trigger requires 'create_before_destroy' to be false.

Answer

The trigger only works with AWS resources.

Question 8

Which THREE of the following are true about 'lifecycle' blocks?

Accepted Answer

They are defined inside the resource configuration block.. Option A is correct because lifecycle blocks are nested meta-arguments declared inside a resource block (e.g., resource "aws_instance" "example" { lifecycle { ... } }), not at the top level or in provider blocks. Option B is correct because a single lifecycle block can contain multiple arguments simultaneously, such as create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by. Option E is correct because lifecycle settings are processed during the plan phase, where Terraform determines actions like replacement (create_before_destroy) and diffs to ignore (ignore_changes) before producing the execution plan. Option C is not correct because provider versions are constrained via the required_providers block and version arguments, not lifecycle. Option D is not correct because lifecycle is a resource-level meta-argument and is not inherited from provider blocks.

Answer

They allow changing the provider version dynamically.

Answer

They are inherited from the provider block.

Question 9

Which TWO of the following are limitations of 'ignore_changes'?

Accepted Answer

It can be difficult to manage for deeply nested attributes.. Option A is correct because 'ignore_changes' in Terraform must reference attribute paths, and for deeply nested attributes you have to spell out the full path (for example, using index or key syntax like tags["Name"] or nested block paths), which becomes verbose and error-prone as nesting grows. Option B is correct because 'ignore_changes' only suppresses diffs on specified attributes within a resource; it cannot ignore a change to the resource type itself, since changing the type means replacing the resource block and Terraform will plan to destroy and recreate it. Option C is incorrect because 'ignore_changes' is a core Terraform lifecycle meta-argument and works with all providers, not just AWS. Option D is incorrect because you can list any subset of attributes to ignore, not all of them. Option E is incorrect because 'ignore_changes' works with complex types such as lists, maps, and nested blocks, not only primitive types.

Answer

It is only compatible with the AWS provider.

Answer

It requires all attributes to be ignored.

Answer

It only works with primitive types.

Question 10

You manage an AWS RDS DB instance with Terraform. During a maintenance window, an operator manually resizes the instance class in the AWS Management Console. You want Terraform to detect this drift on the next plan but NOT automatically revert it, so you can decide later. What should you do?

Accepted Answer

Run `terraform plan` normally; the plan will show the drift as an in-place update, and you can defer applying.. A standard plan performs a refresh by default, comparing the real AWS resource against the configuration. The manual instance class change appears as an in-place update, so the drift is visible without applying. Deferring apply preserves the drift until you decide whether to accept it or revert it.

Answer

Run `terraform refresh` and then `terraform apply` to bring the instance back to the declared size.

Answer

Import the DB instance again with `terraform import` to update the state with the new instance class.

Answer

Add `lifecycle { ignore_changes = [instance_class] }` to the DB instance so the drift is ignored.

Question 11

You manage an Amazon RDS instance with Terraform. During an unrelated deployment, a junior engineer runs `terraform apply` and the instance is unexpectedly destroyed and recreated, causing a brief outage. You need to ensure that future `terraform apply` runs fail before any destructive change can be planned for this database. Which configuration should you add to the `aws_db_instance` resource?

Accepted Answer

Add `lifecycle { prevent_destroy = true }` to the `aws_db_instance` resource.. The prevent_destroy lifecycle argument is the only mechanism that makes Terraform refuse to execute a plan containing the destruction of that specific resource. It acts as a guardrail during the plan phase, so the apply fails before any destructive API call is made. ignore_changes, create_before_destroy, and state rm all address different concerns and none of them block a replacement.

Answer

Add `lifecycle { create_before_destroy = true }` to the `aws_db_instance` resource.

Answer

Run `terraform state rm aws_db_instance.main` to detach the instance from state.

Answer

Add `lifecycle { ignore_changes = [engine] }` to the `aws_db_instance` resource.

Question 12

An `aws_instance` resource has `lifecycle { ignore_changes = [ami] }`. A security team updates the AMI ID in the Terraform configuration to a new hardened image. The instance is currently running an older AMI. What does Terraform plan for this resource during the next `terraform apply`?

Accepted Answer

Terraform reports no changes for the `ami` attribute and leaves the instance as-is.. The ignore_changes lifecycle argument filters out differences for the named attributes when Terraform compares configuration to state. When ami is ignored, a new AMI ID in configuration produces no planned change, so the instance is not replaced and no update is attempted. This is useful for attributes managed outside Terraform, but it also means security-driven AMI updates require removing the ignore entry first.

Answer

Terraform replaces the instance with one built from the new AMI.

Answer

Terraform updates the instance in place to the new AMI without replacement.

Answer

Terraform fails the plan with an error because the AMI differs from state.

Question 13

You are refactoring a Terraform configuration by moving an `aws_s3_bucket` resource into a child module. The bucket already exists and is tracked in state at the root. You want to avoid destroying and recreating the bucket. Which command should you use to update the state address without touching the real infrastructure?

Accepted Answer

terraform state mv aws_s3_bucket.logs module.storage.aws_s3_bucket.logs. terraform state mv is the correct tool for relocating a resource within state, whether moving between modules, renaming, or restructuring. It preserves the mapping to the real object so no infrastructure is destroyed or recreated. The import command is for adopting objects not yet in state, state rm deletes the tracking entry, and refresh only updates attributes.

Answer

terraform import aws_s3_bucket.logs module.storage.aws_s3_bucket.logs

Answer

terraform refresh

Answer

terraform state rm aws_s3_bucket.logs

Question 14

You are managing an AWS S3 bucket with Terraform. The bucket has versioning enabled and contains critical data. You want to ensure that Terraform never destroys the bucket, even if someone runs terraform destroy. Which lifecycle meta-argument should you use?

Accepted Answer

prevent_destroy = true. The prevent_destroy meta-argument is specifically designed to protect resources from accidental deletion. When set to true, Terraform will produce an error if any plan attempts to destroy the resource, including during terraform destroy. This ensures the S3 bucket remains intact. Other meta-arguments either ignore changes, alter replacement order, or trigger replacement, but none prevent destruction.

Answer

ignore_changes = all

Answer

create_before_destroy = true

Answer

replace_triggered_by = [aws_s3_bucket_versioning.example]

Question 15

You are using Terraform to manage an AWS EC2 instance. During a planned update, you expect the instance to be destroyed and recreated because of a change to the user_data attribute. However, you want to ensure that the old instance is destroyed only after the new instance is successfully created, to minimize downtime. Which lifecycle meta-argument should you add to the aws_instance resource?

Accepted Answer

create_before_destroy = true. The create_before_destroy meta-argument is the correct choice because it instructs Terraform to create the replacement resource before destroying the existing one, minimizing downtime. The other options either prevent destruction, ignore the change, or trigger replacement without controlling order.

Answer

ignore_changes = [user_data]

Answer

replace_triggered_by = [aws_instance.example]

Answer

prevent_destroy = true