Resource Lifecycle Management

You need to ensure that an AWS Auto Scaling Group maintains capacity during a configuration change that requires a new launch template. Which lifecycle meta-argument should you use?

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

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?

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

You have an AWS Lambda function that should be replaced whenever the source code S3 object changes. How do you trigger this replacement specifically based on the S3 object key change?

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?

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

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

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

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

What is the purpose of the 'terraform state refresh' command?

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

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

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

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

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

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

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

You need to ignore changes to a specific index in a list of security group rules. How is this formatted in 'ignore_changes'?

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

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

Which meta-argument is used to prevent a resource from being replaced when its configuration changes?

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?

When using 'replace_triggered_by', what happens if the referenced resource is deleted?

Which THREE of the following are valid lifecycle meta-arguments?

Which THREE of these are reasons to use the 'ignore_changes' lifecycle meta-argument?

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

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

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

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

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

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

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

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