Courseiva

CCNA Resource Lifecycle Management Questions

39 questions · Resource Lifecycle Management · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

What is the primary risk of relying solely on 'create_before_destroy' without considering dependency chains?

A.It can lead to resource contention or naming conflicts.
B.It causes infinite loops in Terraform.
C.It increases the cost of the plan.
D.It creates a security risk.
AnswerA

Relying on create_before_destroy duplicates dependent resources before the originals are removed, so unique names, tags, or quotas collide. This directly satisfies the stem's dependency-chain constraint: Terraform cannot sequence replacements, producing naming conflicts and resource contention during the overlap window.

Why this answer

'create_before_destroy' makes Terraform create the replacement resource before destroying the old one. When resources have unique names, fixed IPs, or other globally unique identifiers, the new resource cannot be created while the old one still exists, causing naming conflicts or resource contention. This is the primary risk when dependency chains are not carefully considered.

Exam trap

The trap is assuming 'create_before_destroy' is always safe for zero-downtime — candidates forget that unique naming constraints and dependency chains can force a conflict, making 'resource contention or naming conflicts' the correct risk.

How to eliminate wrong answers

Option B is wrong because 'create_before_destroy' does not cause infinite loops — Terraform's graph is acyclic and the lifecycle flag only reorders create/destroy operations. Option C is wrong because plan cost is not affected by lifecycle ordering; cost estimation depends on resource types and counts, not on create/destroy sequencing. Option D is wrong because 'create_before_destroy' is not inherently a security risk — it is an availability/ordering concern, not a security control.

Practice this question →
2
Multi-Selecthard

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

Select 2 answers
A.The trigger only works on the 'tags' attribute.
B.The trigger requires 'create_before_destroy' to be false.
C.The trigger cannot cause a circular dependency loop.
D.The referenced resource must be in the same state file.
E.The trigger only works with AWS resources.
AnswersC, D

Because replace_triggered_by creates a dependency edge from the triggering resource to the replaced one, referencing resources that already depend on each other forms a cycle, which Terraform rejects during graph construction. Avoiding circular dependency loops is therefore mandatory for valid configuration.

Why this answer

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.

Exam trap

The trap is assuming `replace_triggered_by` works across state files or with any attribute; actually, it requires same-state references and cannot form cycles.

Practice this question →
3
Multi-Selectmedium

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

Select 3 answers
A.It is intended to minimize downtime during updates.
B.It is defined within the resource lifecycle block.
C.It requires sufficient quota to temporarily have two resources.
D.It automatically resolves all name collision issues.
E.It is only available for AWS providers.
AnswersA, B, C

The lifecycle argument reverses Terraform's default destroy-then-create order, provisioning the replacement first so the old resource keeps serving traffic until the new one is ready. This directly satisfies the stem's downtime constraint, since the default ordering leaves a gap where no resource exists.

Why this answer

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.

Exam trap

The trap is assuming create_before_destroy magically solves all replacement problems — candidates forget it can actually CAUSE name-collision failures and that it consumes double the quota temporarily.

Practice this question →
4
Multi-Selecthard

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

Select 2 answers
A.Run 'terraform apply' to recreate it.
B.Run 'terraform untaint <resource_name>' to clear the status.
C.Run 'terraform refresh' to clear the taint.
D.Use 'terraform state rm' to fix the taint.
E.Use 'terraform plan -force-apply'.
AnswersA, B

A tainted resource is marked for destruction and recreation on the next apply, so running terraform apply replaces it, satisfying the requirement to handle the taint. Terraform reads the taint flag from state and plans a destroy-then-create cycle without further intervention.

Why this answer

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.

Exam trap

The trap here is confusing state-reconciliation commands (refresh) or state-removal commands (state rm) with taint management — only apply and untaint actually change the tainted status.

Practice this question →
5
MCQhard

You want to remove a resource from Terraform management without destroying the actual AWS resource. Which command accomplishes this?

A.terraform destroy -target
B.terraform untrack
C.terraform apply -ignore
D.terraform state rm
AnswerD

terraform state rm deletes the resource's entry from the state file only, leaving the real AWS infrastructure untouched. Subsequent plans no longer track it, which matches the stem's requirement to remove it from management without destroying it.

Why this answer

The `terraform state rm` command removes a resource from the Terraform state file without touching the actual infrastructure. This is the correct way to 'orphan' a resource so Terraform no longer manages it, while the real AWS resource continues to exist. It is commonly used when migrating resources to another state file or handing them off to manual management.

Exam trap

The trap here is confusing 'remove from management' with 'destroy the resource' — candidates often pick `terraform destroy -target` thinking it only detaches, but it actually deletes the real infrastructure.

How to eliminate wrong answers

Option A is wrong because `terraform destroy -target` actually destroys the targeted resource in AWS, which is the opposite of what is needed. Option B is wrong because `terraform untrack` is not a real Terraform command — it is a fabricated option. Option C is wrong because `terraform apply -ignore` is not a valid command; there is no `-ignore` flag for apply, and apply would not remove a resource from state anyway.

Practice this question →
6
MCQeasy

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?

A.ignore_changes = [user_data]
B.replace_triggered_by = [aws_instance.example]
C.prevent_destroy = true
D.create_before_destroy = true
AnswerD

This meta-argument ensures that the replacement resource is created before the existing one is destroyed. It is specifically designed to reduce downtime during updates that force replacement. By setting it to true, Terraform will create the new EC2 instance first, then destroy the old one, achieving the desired behavior.

Why this answer

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.

Exam trap

The trap here is assuming that replace_triggered_by controls the order of operations, but it only triggers replacement, not the sequence.

Practice this question →
7
MCQeasy

Which of the following is a valid lifecycle meta-argument in Terraform?

A.delete_on_success
B.wait_for_completion
C.create_before_destroy
D.create_after_update
AnswerC

`create_before_destroy` is a genuine Terraform lifecycle meta-argument, controlling replacement ordering so a new resource is provisioned before the old one is destroyed. It satisfies the stem's requirement for a valid lifecycle meta-argument, unlike `depends_on` (a meta-argument but not lifecycle-scoped) or `prevent_destroy` variants.

Why this answer

create_before_destroy is a valid lifecycle meta-argument in Terraform, used to ensure that a new resource is created before the old one is destroyed during replacement. This is one of the four supported lifecycle meta-arguments: create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by. The other options are not valid Terraform lifecycle meta-arguments.

Exam trap

The trap is that candidates may confuse Terraform lifecycle meta-arguments with similar-sounding options from other tools or invent new ones; only the four documented meta-arguments are valid.

How to eliminate wrong answers

Option A is wrong because delete_on_success is not a Terraform lifecycle meta-argument; it is not recognized by Terraform and would cause a configuration error. Option B is wrong because wait_for_completion is not a Terraform lifecycle meta-argument; it is a concept used in other tools but not in Terraform's lifecycle block. Option D is wrong because create_after_update is not a valid Terraform lifecycle meta-argument; the correct meta-argument for creation order is create_before_destroy.

Practice this question →
8
MCQmedium

You have defined a resource and set 'prevent_destroy = true'. If you perform a 'terraform destroy', what will happen?

A.Terraform will destroy all resources except the one with the rule.
B.Terraform will ignore the rule and destroy the resource anyway.
C.Terraform will return an error and abort the destroy operation.
D.Terraform will prompt for confirmation twice.
AnswerC

Terraform's lifecycle `prevent_destroy` meta-argument causes the plan phase to fail whenever a destroy action targets that resource, so `terraform destroy` errors out and aborts before removing anything. This satisfies the stem's protection requirement, halting the entire operation rather than skipping the resource silently.

Why this answer

When a resource has `prevent_destroy = true` in its lifecycle block, Terraform treats any plan that would destroy that resource as invalid. During `terraform destroy`, Terraform first generates a destroy plan; because that plan includes deleting the protected resource, Terraform immediately returns an error and aborts the entire operation before any resource is destroyed. This is a safety mechanism to prevent accidental deletion of critical infrastructure.

Exam trap

The trap here is assuming that Terraform will skip the protected resource and destroy everything else, or that it will prompt for extra confirmation—when in fact it aborts the entire operation with an error.

How to eliminate wrong answers

Option A is wrong because Terraform does not selectively skip the protected resource and destroy the rest; it aborts the entire destroy operation. Option B is wrong because Terraform does not ignore the `prevent_destroy` rule—it enforces it strictly and will not destroy the resource under any circumstances unless the rule is removed. Option D is wrong because Terraform does not add extra confirmation prompts; it simply errors out and stops, regardless of how many times you confirm.

Practice this question →
9
Multi-Selecthard

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

Select 2 answers
A.It can be difficult to manage for deeply nested attributes.
B.It cannot ignore changes to the resource type itself.
C.It is only compatible with the AWS provider.
D.It requires all attributes to be ignored.
E.It only works with primitive types.
AnswersA, B

ignore_changes accepts attribute paths, and for deeply nested blocks or complex structures those paths become unwieldy and error-prone to maintain. This manageability constraint is the recognised limitation, not any effect on resource type or provider behaviour.

Why this answer

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.

Exam trap

The trap is assuming 'ignore_changes' is more powerful than it is, such as thinking it can ignore resource type changes or that it requires all attributes to be ignored. Candidates might also think it's provider-specific.

Practice this question →
10
MCQmedium

You have an AWS EC2 instance managed by Terraform. The operations team occasionally updates the instance's tags directly in the AWS Console to reflect temporary maintenance status. You want Terraform to ignore these external tag changes and not revert them during the next apply. However, you still want Terraform to manage other attributes of the instance. Which lifecycle meta-argument should you use?

A.ignore_changes = [tags]
B.replace_triggered_by = [aws_ec2_tag.example]
C.ignore_changes = all
D.prevent_destroy = true
AnswerA

ignore_changes = [tags] tells Terraform to ignore any changes to the tags attribute of the EC2 instance. This means that if tags are modified outside of Terraform, the next plan will not show a diff for tags, and apply will not revert them. Other attributes remain managed, which aligns with the requirement to ignore only tags.

Why this answer

The ignore_changes meta-argument allows you to specify which attributes Terraform should ignore when detecting drift. By listing tags, Terraform will not plan updates for tag changes made outside of Terraform, while still managing other attributes. This precisely matches the scenario where tags are updated manually but other instance properties must remain under Terraform control.

Exam trap

The trap here is using ignore_changes = all, which would ignore all attributes and thus stop managing the instance entirely, rather than just tags.

Practice this question →
11
MCQmedium

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?

A.terraform import aws_s3_bucket.logs module.storage.aws_s3_bucket.logs
B.terraform state mv aws_s3_bucket.logs module.storage.aws_s3_bucket.logs
C.terraform refresh
D.terraform state rm aws_s3_bucket.logs
AnswerB

terraform state mv renames the address of a resource within state, preserving the association with the real object. Moving the bucket from the root address to the module address means Terraform will plan no changes after the move, because the object is already tracked under the new address. This avoids any destroy or recreate.

Why this answer

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.

Exam trap

The trap here is reaching for terraform import to adopt a resource that is already in state, when the actual need is to move an existing state entry with terraform state mv.

Practice this question →
12
Multi-Selecthard

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

Select 2 answers
A.It stops Terraform from tracking the resource.
B.It leaves the real-world resource running.
C.It requires the 'force' flag for all resources.
D.It is a permanent action that cannot be undone.
E.It destroys the infrastructure in the cloud.
AnswersA, B

Removing a resource from state halts tracking without destroying the real infrastructure, satisfying the requirement that the resource be forgotten rather than deleted. Terraform no longer manages or plans changes for it, though the underlying cloud object persists untouched until re-imported or removed manually.

Why this answer

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.

Exam trap

The trap is conflating state operations with infrastructure operations — candidates assume removing a resource from state also deletes it in the cloud, when in fact state rm only stops Terraform from tracking it.

Practice this question →
13
MCQmedium

When a resource is marked as 'tainted', what is the expected outcome of the next 'terraform apply'?

A.It is ignored.
B.It is destroyed and recreated.
C.It is removed from the state file.
D.It is updated in place.
AnswerB

This is the definition of tainting.

Why this answer

A tainted resource is one Terraform has marked as degraded or partially created, so the next 'terraform apply' will destroy the existing object and create a fresh replacement. This is the standard recovery mechanism when a resource is in an unhealthy or unknown state but you want to keep it managed by Terraform.

Exam trap

The trap is confusing 'tainted' with 'removed from state' — candidates think tainting deletes the resource record, but it only flags it for replacement on the next apply.

How to eliminate wrong answers

Option A is wrong because tainting explicitly forces action — Terraform will not ignore a tainted resource during the next apply. Option C is wrong because tainting does not remove the resource from state; the resource remains tracked, just flagged for replacement. Removing from state requires 'terraform state rm'.

Option D is wrong because tainting forces destroy-and-recreate, not an in-place update — in-place updates occur when only mutable attributes change.

Practice this question →
14
MCQeasy

Which file stores the mapping between your Terraform configuration and the real-world infrastructure?

A.terraform.tfstate
B.terraform.tfvars
C.provider.tf
D.backend.tf
AnswerA

Terraform records each resource's real-world identity and attribute values in terraform.tfstate, the sole artefact binding configuration addresses to actual infrastructure. Without it, Terraform cannot detect drift or determine which objects to update or destroy, so it is the mapping file the question asks for.

Why this answer

The `terraform.tfstate` file is Terraform's state file, which stores the mapping between resources declared in configuration and the real-world infrastructure objects, including their attributes and dependencies. It is the source of truth Terraform uses to plan changes and detect drift.

Exam trap

The trap is confusing the state file with the backend configuration file — `backend.tf` tells Terraform where to store state, but the actual mapping lives in `terraform.tfstate`.

How to eliminate wrong answers

Option B is wrong because `terraform.tfvars` stores variable values, not the resource-to-infrastructure mapping. Option C is wrong because `provider.tf` configures provider plugins and their authentication, not state. Option D is wrong because `backend.tf` configures where state is stored (e.g., S3, HCP Terraform), but the actual mapping is in the state file itself, not the backend configuration file.

Practice this question →
15
MCQmedium

You have an AWS Lambda function defined with the aws_lambda_function resource. The function's source code is packaged in an S3 object. You want Terraform to replace the Lambda function whenever the S3 object's ETag changes, indicating a new version of the code. Which configuration should you add to the aws_lambda_function resource?

A.lifecycle { prevent_destroy = true }
B.lifecycle { replace_triggered_by = [aws_s3_object.lambda_package.etag] }
C.lifecycle { ignore_changes = [s3_key] }
D.lifecycle { create_before_destroy = true }
AnswerB

replace_triggered_by with the S3 object's etag attribute will trigger replacement of the Lambda function whenever the ETag changes. This directly ties the function's lifecycle to the code version, ensuring updates when the code changes. It is the precise solution for the scenario.

Why this answer

Using replace_triggered_by with the S3 object's etag attribute ensures the Lambda function is replaced when the code changes, as indicated by the ETag. The other options either ignore changes, control order, or block destruction, none of which trigger replacement based on ETag.

Exam trap

The trap here is thinking that create_before_destroy triggers replacement, but it only controls the order once replacement is already triggered.

Practice this question →
16
MCQmedium

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?

A.Run `terraform refresh` and then `terraform apply` to bring the instance back to the declared size.
B.Run `terraform plan` normally; the plan will show the drift as an in-place update, and you can defer applying.
C.Import the DB instance again with `terraform import` to update the state with the new instance class.
D.Add `lifecycle { ignore_changes = [instance_class] }` to the DB instance so the drift is ignored.
AnswerB

By default, plan refreshes state against AWS and compares to configuration. The manually changed instance class will appear as an in-place update to restore the declared value. Simply not applying leaves the drift in place for later review, which matches the requirement to detect but not revert automatically.

Why this answer

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.

Exam trap

The trap here is assuming that ignoring an attribute is the way to handle drift, when ignoring actually suppresses detection rather than surfacing it.

Practice this question →
17
MCQmedium

You have an aws_instance resource in your Terraform configuration that was created six months ago. The operations team now requires that any future replacement of this instance preserves the existing Elastic Network Interface (ENI) to maintain its private IP address. You add a lifecycle block with create_before_destroy = true to the aws_instance resource. What is the effect of this change when the instance must be replaced?

A.Terraform creates a new instance but reuses the existing ENI, so the private IP address remains the same.
B.Terraform creates a new instance and a new ENI, but it also updates the old ENI to have the same private IP address as the new one.
C.Terraform creates a new instance with a new ENI, then destroys the old instance and its ENI, so the private IP address changes.
D.Terraform destroys the old instance first, then creates a new one, causing a brief outage but preserving the ENI.
AnswerC

With create_before_destroy, Terraform provisions the replacement aws_instance first, but because the ENI is managed by the instance, a new ENI is created for the new instance. The old instance and its ENI are destroyed afterward, so the private IP is not preserved. The ENI's private IP is tied to the ENI itself, and a new ENI gets a new IP. To preserve the IP, the ENI must be a separate resource with its own lifecycle.

Why this answer

The lifecycle meta-argument create_before_destroy changes the order of operations during replacement: Terraform first creates the new resource, then destroys the old one. However, for an aws_instance, the ENI is an integral part that is recreated with the instance. Therefore, the new instance gets a new ENI and a new private IP.

To keep the same private IP, the ENI must be defined as a separate aws_network_interface resource and attached to the instance, allowing it to persist across instance replacements.

Exam trap

The trap here is assuming that create_before_destroy preserves dependent resources like ENIs, when it only changes the order of creation and destruction of the resource itself.

Practice this question →
18
MCQmedium

If you use 'ignore_changes = [tags]', and you manually change the tags in the AWS Console, what will happen during the next 'terraform plan'?

A.Terraform will plan to revert the tags to the configuration state.
B.Terraform will fail with an attribute mismatch error.
C.Terraform will update the state file to match the console tags.
D.Terraform will ignore the difference and perform no action on the tags.
AnswerD

ignore_changes = [tags] instructs Terraform to disregard differences in the tags attribute between configuration and real infrastructure. Manually altered tags in the AWS Console are therefore not detected as drift, so the next plan performs no action on the tags.

Why this answer

The `ignore_changes` lifecycle meta-argument tells Terraform to disregard differences between the desired configuration and the actual remote state for the specified attributes. When `ignore_changes = [tags]` is set, Terraform will not plan any changes to the `tags` attribute even if the real-world resource has been modified outside of Terraform. Therefore, during the next `terraform plan`, Terraform will ignore the tag differences and perform no action on the tags.

Exam trap

The trap here is confusing `ignore_changes` with automatic state reconciliation; candidates often think Terraform will update the state or revert the change, but it simply ignores the difference.

How to eliminate wrong answers

Option A is wrong because `ignore_changes` prevents Terraform from reverting the tags; without it, Terraform would indeed plan to revert, but the lifecycle rule overrides that behavior. Option B is wrong because Terraform does not fail with an attribute mismatch error; it simply ignores the difference for the specified attribute. Option C is wrong because Terraform does not automatically update the state file to match the console tags; the state file remains as it was, and the difference is ignored, not reconciled.

Practice this question →
19
MCQeasy

A teammate accidentally deleted an `aws_security_group` through the AWS Console. The resource is still present in Terraform state, and no configuration changes have been made. What will `terraform plan` report for that resource, and what is the appropriate next step?

A.Plan shows no changes, because state still contains the resource.
B.Plan fails with an error and requires `terraform import` before proceeding.
C.Plan shows the resource will be created, because refresh detects it is missing.
D.Plan shows the resource will be destroyed and recreated.
AnswerC

During plan, Terraform refreshes each resource by reading its current state from AWS. Because the security group was deleted outside Terraform, the refresh marks the resource as missing and the plan proposes to create it again. Running apply then recreates the security group according to the existing configuration, restoring the desired state.

Why this answer

Terraform's refresh step reconciles state with reality before planning. A resource deleted outside Terraform is detected as missing, and the plan proposes to create it so configuration and reality match again. Applying the plan recreates the security group.

No import is needed because the object no longer exists to be adopted.

Exam trap

The trap here is believing that a resource remaining in state means Terraform will see no changes, when refresh actually detects the external deletion and plans a create.

Practice this question →
20
MCQmedium

A resource has an attribute 'tags' that is managed by an external script. You want Terraform to ignore any changes made to 'tags' after the initial creation. How should you configure the 'lifecycle' block?

A.ignore_changes = [tags]
B.lifecycle { tags = ignore }
C.prevent_destroy = [tags]
D.ignore_changes = [all]
AnswerA

ignore_changes with the tags attribute instructs Terraform to disregard drift in that attribute after creation, so external script modifications no longer appear as diffs. This satisfies the requirement to leave post-creation tag changes untouched during planning and apply.

Why this answer

The 'ignore_changes' argument within a lifecycle block tells Terraform to ignore changes to the specified attributes after resource creation. Setting 'ignore_changes = [tags]' ensures that any external modifications to the tags attribute are not detected as drift, preventing Terraform from reverting them. This is the correct way to handle attributes managed outside of Terraform.

Exam trap

The trap is confusing 'ignore_changes' with other lifecycle arguments or using invalid syntax like 'ignore_changes = [all]', which is not a valid list element; candidates may also think 'prevent_destroy' can be used for attributes.

How to eliminate wrong answers

Option B is wrong because 'lifecycle { tags = ignore }' is not valid Terraform syntax; the lifecycle block does not accept a 'tags' argument. Option C is wrong because 'prevent_destroy = [tags]' is invalid; 'prevent_destroy' is a boolean that prevents resource destruction, not an attribute-level setting. Option D is wrong because 'ignore_changes = [all]' is not a valid value; while 'ignore_changes = all' is valid, it ignores all attributes, which is broader than needed and not the best practice for this scenario.

Practice this question →
21
Multi-Selecthard

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

Select 2 answers
A.Use 'terraform apply -auto-approve'.
B.Run 'terraform state rm' to remove the resource from state and re-import.
C.Use 'terraform refresh' to update the constraint.
D.Remove the prevent_destroy block from the configuration.
E.Set the prevent_destroy argument to false in the CLI.
AnswersB, D

Removing the resource from state with `terraform state rm` detaches it from Terraform's management, so the `prevent_destroy` lifecycle guard no longer applies to it. The subsequent re-import brings it back under management, letting the replacement proceed without the guard blocking destruction.

Why this answer

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.

Exam trap

The trap is assuming that CLI flags like -auto-approve or a hypothetical -prevent-destroy=false can override lifecycle settings; in reality, prevent_destroy is configuration-only and must be removed or bypassed via state manipulation.

Practice this question →
22
MCQeasy

Where are lifecycle meta-arguments placed within a Terraform configuration?

A.At the root of the configuration file.
B.Inside the resource block, within a 'lifecycle' block.
C.Inside the module block.
D.Inside the provider block.
AnswerB

Lifecycle meta-arguments govern an individual resource's creation and destruction behaviour, so they nest inside the resource block as a lifecycle block. This satisfies the constraint that settings such as create_before_destroy apply only to that resource.

Why this answer

Lifecycle meta-arguments are used to customize the behavior of a specific resource, such as preventing its destruction or ignoring changes to certain attributes. They are defined within a nested 'lifecycle' block inside the resource block, as they directly modify that resource's lifecycle. This placement ensures the arguments apply only to that resource, not globally or to modules/providers.

Exam trap

The trap here is confusing where meta-arguments like 'lifecycle' can be placed, as some meta-arguments (e.g., 'count', 'for_each') can be used at both resource and module levels, but 'lifecycle' is exclusively a resource-level meta-argument.

How to eliminate wrong answers

Option A is wrong because placing lifecycle meta-arguments at the root of the configuration file is invalid; Terraform does not support lifecycle blocks at the root level, and such placement would cause a syntax error. Option C is wrong because while modules can have lifecycle-related settings, the 'lifecycle' meta-argument itself is not placed inside a module block; modules use other meta-arguments like 'count' or 'for_each', but lifecycle is resource-specific. Option D is wrong because provider blocks configure the provider plugin, not resource lifecycle behavior; lifecycle meta-arguments are not valid inside provider blocks.

Practice this question →
23
MCQhard

An operations engineer needs to remove an aws_iam_role and its attached aws_iam_role_policy_attachment from Terraform management without deleting the role in AWS, because the role is shared with an external team. The configuration for both resources will also be deleted from the repository. Which command sequence accomplishes this?

A.Delete the resource blocks from the configuration and run terraform apply -refresh=false so Terraform forgets the resources.
B.terraform state mv aws_iam_role.example aws_iam_role.shared, then terraform apply to drop the old address
C.terraform destroy -target=aws_iam_role_policy_attachment.example, then remove the aws_iam_role block from state with terraform import
D.terraform state rm aws_iam_role_policy_attachment.example, then terraform state rm aws_iam_role.example
AnswerD

terraform state rm detaches resources from state without calling any AWS API, so the role and its attachment remain intact in the account. Removing the attachment entry first avoids a dangling reference to a resource that no longer exists in state. After both entries are gone and the configuration is deleted, future plans ignore them entirely, which is exactly what a shared-resource handoff requires.

Why this answer

Unmanaging resources without deleting them in the cloud requires removing their entries from state. terraform state rm performs exactly that, issuing no provider API calls, and ordering the attachment before the role keeps the state consistent. Destroying, moving, or merely editing configuration all either delete the real objects or leave them tracked.

Exam trap

The trap here is confusing terraform state rm, which only forgets resources in state, with terraform destroy, which actually deletes the live AWS objects.

Practice this question →
24
MCQmedium

You need to ensure that a resource is always recreated if an associated data source value changes. Which meta-argument supports this?

A.create_before_destroy
B.replace_triggered_by
C.lifecycle_hooks
D.prevent_destroy
AnswerB

`replace_triggered_by` forces Terraform to destroy and recreate the resource whenever a referenced attribute or resource changes, satisfying the requirement that the resource is always recreated when the associated data source value changes. It accepts resource references directly, unlike `lifecycle` triggers, which only react to arbitrary values.

Why this answer

The replace_triggered_by meta-argument forces Terraform to destroy and recreate the resource whenever any of the referenced attributes or resources change, including data source values. It is designed exactly for the scenario where a resource must be replaced based on an external or computed value rather than a direct attribute reference. When the referenced value changes between plans, Terraform marks the resource for replacement.

Exam trap

The trap here is confusing create_before_destroy with a replacement trigger — candidates often pick it because it sounds like it controls recreation, but it only controls ordering, not the decision to replace.

How to eliminate wrong answers

Option A is wrong because create_before_destroy only controls the ordering of replacement (create the new instance before destroying the old) — it does not trigger replacement on its own. Option C is wrong because 'lifecycle_hooks' is not a real Terraform meta-argument; the lifecycle block contains create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by, but there is no lifecycle_hooks argument. Option D is wrong because prevent_destroy does the opposite — it blocks destruction and causes an error if a plan would destroy the resource, rather than triggering recreation.

Practice this question →
25
Multi-Selectmedium

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

Select 3 answers
A.The plan may show changes even if the config hasn't changed.
B.It can lead to 'Resource Not Found' errors if someone manually deletes an item.
C.It disables the use of lifecycle meta-arguments.
D.Terraform may attempt to revert changes during the next apply.
E.It automatically updates the configuration file.
AnswersA, B, D

Because the state file records the last-known real-world attributes, any out-of-band modification makes the stored values diverge from actual infrastructure. Terraform therefore reports a non-empty diff during plan even when the configuration itself is untouched, satisfying the drift-detection consequence.

Why this answer

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.

Exam trap

The trap is believing drift disables lifecycle rules or auto-updates config — drift only affects state versus reality, not configuration semantics or lifecycle behavior.

Practice this question →
26
Multi-Selectmedium

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

Select 3 answers
A.They are defined inside the resource configuration block.
B.Multiple lifecycle arguments can be used in one block.
C.They allow changing the provider version dynamically.
D.They are inherited from the provider block.
E.They are evaluated during the planning phase.
AnswersA, B, E

A lifecycle block is nested within the resource block it modifies, applying only to that specific resource. This positional placement is what makes it a valid statement about lifecycle blocks, distinct from provider or terraform-level configuration.

Why this answer

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.

Exam trap

The trap here is confusing lifecycle meta-arguments with provider configuration — candidates often assume lifecycle settings can control provider versions or are inherited from provider blocks, but they are strictly resource-scoped planning directives.

Practice this question →
27
MCQhard

You are managing a production database instance. You want to ensure that if a developer accidentally removes the resource block from the Terraform configuration, Terraform will refuse to destroy the database. How do you implement this?

A.Set prevent_destroy = true in the lifecycle block.
B.Set create_before_destroy = false.
C.Use the ignore_changes meta-argument for the lifecycle block.
D.Configure a provider-level block to disable deletions.
AnswerA

Setting `prevent_destroy = true` in the resource's `lifecycle` block makes Terraform reject any plan that would destroy the database, including removal of its resource block. This directly satisfies the stem's requirement that Terraform refuse destruction after an accidental configuration deletion, failing the apply with an error rather than deleting the instance.

Why this answer

The 'prevent_destroy' lifecycle meta-argument, when set to true, causes Terraform to reject any plan that would destroy the resource. This includes accidental removal of the resource block from configuration, which would otherwise trigger a destroy. It acts as a safety net for critical resources like production databases.

Exam trap

The trap is confusing 'prevent_destroy' with other lifecycle arguments like 'ignore_changes' or 'create_before_destroy'. Candidates might think 'ignore_changes' prevents destruction, but it only ignores attribute updates.

How to eliminate wrong answers

Option B is wrong because 'create_before_destroy = false' is the default behavior and does not prevent destruction; it only controls the order of creation and destruction. Option C is wrong because 'ignore_changes' is used to ignore changes to specific attributes, not to prevent resource destruction. Option D is wrong because there is no provider-level block to disable deletions; such control is at the resource level via lifecycle.

Practice this question →
28
MCQmedium

When using 'create_before_destroy', what is a common side effect that may cause the plan to fail?

A.Resource naming collisions.
B.Terraform will delete the state file.
C.Provider credentials will expire.
D.All other resources will be destroyed.
AnswerA

Creating the replacement before destroying the original means both exist simultaneously, so fixed names, unique DNS labels or static identifiers clash. The provider rejects the duplicate, causing the plan or apply to fail until the name is parameterised or the old resource is destroyed first.

Why this answer

With create_before_destroy, Terraform creates the new resource before destroying the old one. If the resource has a unique name or identifier (e.g., an AWS resource with a fixed name), the new resource may conflict with the existing one, causing the plan to fail due to naming collisions.

Exam trap

The trap is assuming create_before_destroy always works smoothly; candidates forget that resources with fixed names will collide. The exam tests whether you understand the side effect of creating a duplicate resource before destroying the original.

How to eliminate wrong answers

Option B is wrong because Terraform does not delete the state file during create_before_destroy; state is updated normally. Option C is wrong because provider credentials are not affected by lifecycle settings. Option D is wrong because create_before_destroy only affects the resource it's applied to, not all other resources.

Practice this question →
29
MCQmedium

When refactoring code, you rename a resource in your configuration. What happens if you run 'terraform plan' without updating the state?

A.Terraform will propose destroying the old resource and creating a new one.
B.Terraform will do nothing.
C.Terraform will automatically rename it in the state.
D.Terraform will throw an error and stop.
AnswerA

Terraform tracks resources by address in state. Renaming the block changes its address, so the plan shows the old address destroyed and the new one created, unless a moved block or state mv is used.

Why this answer

Renaming a resource in configuration changes its address, so Terraform sees the old address as removed and the new address as added, resulting in a plan to destroy the old resource and create a new one. State still maps the old address to the real resource, so Terraform cannot associate the new name with the existing object. This is why terraform state mv is used to rename without destruction.

Exam trap

The trap is assuming Terraform recognizes renamed resources as the same object — it does not, because state is keyed by address, not by resource identity.

How to eliminate wrong answers

Option B is wrong because Terraform does not ignore the rename; it detects the address change and plans replacement. Option C is wrong because Terraform never automatically renames resources in state — state changes only occur via apply, state mv, or import. Option D is wrong because Terraform does not error on a rename; it simply plans a destroy/create cycle, which is valid behavior.

Practice this question →
30
MCQmedium

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?

A.Add 'ignore_changes = [prevent_destroy]' to the block.
B.Use 'terraform state rm' to remove the constraint.
C.Use 'terraform destroy -force-remove-prevent-destroy'.
D.Remove the prevent_destroy block from the configuration and apply.
AnswerD

Removing the prevent_destroy argument eliminates the protection at its source, so the subsequent apply can destroy and recreate the resource. Terraform still manages the lifecycle, satisfying the stem's requirement to retain management while bypassing the guard.

Why this answer

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.

Exam trap

The trap here is assuming prevent_destroy can be overridden at runtime via a CLI flag or state manipulation, when in reality it can only be removed by editing the configuration itself.

How to eliminate wrong answers

Option A is wrong because ignore_changes only accepts resource attribute names to ignore during diff calculation — prevent_destroy is a lifecycle meta-argument, not an attribute, so it cannot be listed there. Option B is wrong because terraform state rm removes the resource from state entirely, which would cause Terraform to lose track of the real infrastructure rather than simply bypassing the protection. Option C is wrong because terraform destroy has no such flag as -force-remove-prevent-destroy; the CLI does not provide a command-line override for prevent_destroy.

Practice this question →
31
MCQmedium

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?

A.Add `lifecycle { prevent_destroy = true }` to the `aws_db_instance` resource.
B.Add `lifecycle { create_before_destroy = true }` to the `aws_db_instance` resource.
C.Run `terraform state rm aws_db_instance.main` to detach the instance from state.
D.Add `lifecycle { ignore_changes = [engine] }` to the `aws_db_instance` resource.
AnswerA

Adding a lifecycle block with prevent_destroy set to true causes Terraform to reject any plan that would destroy the RDS instance, failing the apply before the destructive action occurs. This protects the database from accidental replacement caused by configuration drift or an unintended change to a force-new attribute, which is exactly the outage scenario described.

Why this answer

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.

Exam trap

The trap here is assuming that any lifecycle meta-argument protects a resource from deletion, when only prevent_destroy actually blocks a destroy plan.

Practice this question →
32
MCQeasy

Which command is used to move a resource from one state file to another, commonly used when refactoring modules?

A.terraform migrate
B.terraform plan -refactor
C.terraform refresh
D.terraform state mv
AnswerD

terraform state mv relocates a resource entry between state files or addresses, updating the state to match refactored configuration without destroying or recreating infrastructure. This satisfies the module-refactoring scenario by preserving existing resources while their configuration addresses change.

Why this answer

terraform state mv moves a resource from one state address to another, and when used with different state files (via -state and -state-out), it can move resources between state files. This is the standard command for refactoring modules without destroying and recreating resources. It updates the state mapping so Terraform associates the existing resource with the new address.

Exam trap

The trap is inventing commands like terraform migrate or plan -refactor — only terraform state mv (and terraform state push/pull for whole files) can move resources between states.

How to eliminate wrong answers

Option A is wrong because terraform migrate is not a real Terraform command. Option B is wrong because terraform plan -refactor does not exist; plan has no refactor flag. Option C is wrong because terraform refresh only reconciles state with real infrastructure, it does not move resources between state files or addresses.

Practice this question →
33
MCQhard

During a refactor, an engineer renames the Terraform address of an aws_s3_bucket from aws_s3_bucket.logs to aws_s3_bucket.audit_logs in the configuration, keeping every argument identical. The bucket holds production logs. What is the safest way to apply this change without destroying and recreating the bucket?

A.Add lifecycle { prevent_destroy = true } to the renamed resource, then apply so Terraform refuses to delete the original bucket.
B.Run terraform state mv aws_s3_bucket.logs aws_s3_bucket.audit_logs, then run terraform plan to confirm no changes.
C.Use terraform apply -replace=aws_s3_bucket.audit_logs so Terraform rebuilds the bucket under the new name without data loss.
D.Run terraform import aws_s3_bucket.audit_logs with the bucket name, then delete the old resource block from configuration.
AnswerB

terraform state mv rewrites the resource address inside the state file without touching the real S3 bucket, so the renamed configuration block now matches an existing state entry. A subsequent plan should report no changes, proving the bucket is preserved. This is the standard technique for refactoring addresses while avoiding an unnecessary destroy and recreate of production data.

Why this answer

Renaming a resource address changes only the identifier in configuration and state, not the underlying object. terraform state mv updates the state entry to match the new address so no destroy or create is planned, and a follow-up plan verifies the migration. Import creates duplicates, prevent_destroy blocks the apply, and -replace deliberately destroys the bucket.

Exam trap

The trap here is assuming that renaming a resource block is harmless metadata, when Terraform actually plans to destroy the old address and create a new one unless state is moved first.

Practice this question →
34
MCQeasy

A team is using Terraform to manage an aws_s3_bucket. They want Terraform to ignore any changes made to the bucket's tags outside of Terraform, but they still want Terraform to manage the bucket policy and versioning configuration. Which lifecycle configuration should they add?

A.Add lifecycle { ignore_changes = all } to the aws_s3_bucket resource.
B.Add lifecycle { create_before_destroy = true } to the aws_s3_bucket resource.
C.Add lifecycle { ignore_changes = [tags] } to the aws_s3_bucket resource.
D.Add lifecycle { prevent_destroy = true } to the aws_s3_bucket resource.
AnswerC

ignore_changes = [tags] tells Terraform to exclude the tags attribute from diff comparison, so out-of-band tag changes are not reverted. Other attributes such as policy and versioning remain managed, satisfying the requirement to keep controlling those settings while tolerating external tag edits.

Why this answer

ignore_changes = [tags] excludes only the tags attribute from diff evaluation, so external tag edits are tolerated while policy and versioning remain under Terraform management. The other lifecycle meta-arguments address deletion protection, full drift suppression, or replacement ordering, none of which match the stated requirement.

Exam trap

The trap here is reaching for ignore_changes = all or prevent_destroy when only a single attribute needs to be excluded from drift detection.

Practice this question →
35
MCQhard

What happens if you set 'ignore_changes = all' in a resource lifecycle block?

A.It disables the prevent_destroy rule.
B.It ignores the resource existence entirely.
C.It causes Terraform to ignore all changes to the resource attributes.
D.It causes a syntax error.
AnswerC

ignore_changes = all tells Terraform to disregard every attribute difference between configuration and real infrastructure during planning, so no updates are proposed for that resource. This matches the stem's description of ignoring all attribute changes.

Why this answer

Setting ignore_changes = all in a lifecycle block tells Terraform to ignore all attribute changes for that resource, so drift or configuration changes to attributes will not trigger updates. Terraform still manages the resource's existence, creating or destroying it as needed, but it will not modify attributes. This is useful for resources managed partly outside Terraform.

Exam trap

The trap is thinking ignore_changes = all makes Terraform ignore the resource entirely — it only ignores attribute changes, not resource existence or lifecycle rules.

How to eliminate wrong answers

Option A is wrong because ignore_changes does not affect prevent_destroy; they are independent lifecycle settings. Option B is wrong because ignore_changes does not ignore the resource's existence — Terraform still creates and destroys the resource based on configuration presence. Option D is wrong because ignore_changes = all is valid syntax and does not cause an error.

Practice this question →
36
MCQhard

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?

A.prevent_destroy = true
B.ignore_changes = all
C.create_before_destroy = true
D.replace_triggered_by = [aws_s3_bucket_versioning.example]
AnswerA

prevent_destroy is a lifecycle meta-argument that prevents Terraform from destroying the resource. When set to true, any plan that includes destruction of the resource will fail, thus protecting the S3 bucket from accidental deletion. This directly meets the requirement to ensure the bucket is never destroyed.

Why this answer

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.

Exam trap

The trap here is thinking that ignore_changes = all will prevent destruction, when it actually only ignores attribute updates and does not block destroy operations.

Practice this question →
37
MCQhard

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`?

A.Terraform reports no changes for the `ami` attribute and leaves the instance as-is.
B.Terraform replaces the instance with one built from the new AMI.
C.Terraform updates the instance in place to the new AMI without replacement.
D.Terraform fails the plan with an error because the AMI differs from state.
AnswerA

With ami listed in ignore_changes, Terraform ignores any difference between the configured AMI and the value recorded in state. The plan therefore shows no change for that attribute, and the running instance remains on the older AMI until the ignore_changes entry is removed and an apply is run.

Why this answer

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.

Exam trap

The trap here is expecting ignore_changes to still detect a difference and prompt a replacement, when it actually suppresses the difference and leaves the resource untouched.

Practice this question →
38
MCQhard

You have two resources, A and B. You want B to be replaced whenever A is updated. How do you configure B?

A.In resource B, set lifecycle { create_before_destroy = [resource_a] }
B.In resource A, set lifecycle { triggers = [resource_b] }
C.In resource B, set lifecycle { replace_triggered_by = [resource_a] }
D.In resource B, set depends_on = [resource_a]
AnswerC

Setting `replace_triggered_by` within resource B's lifecycle block forces Terraform to destroy and recreate B whenever the referenced resource A changes, satisfying the stem's requirement that B be replaced on A's update. This differs from `create_before_destroy`, which only alters replacement ordering, not the trigger itself.

Why this answer

The replace_triggered_by meta-argument in resource B's lifecycle block specifies that B should be replaced when resource A changes. This directly ties B's replacement to A's updates, ensuring B is recreated whenever A is updated.

Exam trap

The trap is confusing replace_triggered_by with depends_on or create_before_destroy. Candidates might think depends_on causes replacement, but it only orders operations. The exam tests whether you know the specific meta-argument for triggering replacement.

How to eliminate wrong answers

Option A is wrong because create_before_destroy does not accept a resource reference; it's a boolean. Option B is wrong because triggers is not a valid lifecycle argument for resources (it's for null_resource). Option D is wrong because depends_on only establishes a dependency order, not a replacement trigger.

Practice this question →
39
MCQhard

Why might someone use 'prevent_destroy = true' on a database resource while allowing it on smaller web server instances?

A.To increase the speed of the destroy process.
B.To protect critical data from accidental deletion.
C.To ensure create_before_destroy works.
D.To satisfy the AWS provider requirements.
AnswerB

Databases hold irreplaceable state, so prevent_destroy blocks the destroy plan step before Terraform can issue the deletion API call, guarding against accidental loss. Web servers are stateless and rebuildable, so the same guard would only obstruct routine replacement, making the protection disproportionate there.

Why this answer

prevent_destroy = true is used to protect resources whose loss would be catastrophic or unrecoverable, such as databases containing critical data. Web server instances are typically stateless and easily recreated, so the protection is unnecessary there — making option B correct.

Exam trap

The trap is conflating prevent_destroy with create_before_destroy or assuming it applies universally — the exam tests whether you understand it is a targeted safety control for high-value resources.

How to eliminate wrong answers

Option A is wrong because prevent_destroy does not speed up destruction; it actually blocks it entirely for the protected resource. Option C is wrong because create_before_destroy is a separate lifecycle argument that controls replacement ordering, not destruction protection. Option D is wrong because prevent_destroy is a Terraform core feature, not an AWS provider requirement — no provider mandates its use.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Resource Lifecycle Management questions.

Start 20-question session