Resource Lifecycle Management

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?

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?

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?

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

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?

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

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?

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?

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

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?

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?

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?

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?

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

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?

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

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?