Lifecycle customization in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Effect of lifecycle ignore_changes on resource updates

Given the following Terraform resource configuration, what will happen if the tags attribute is changed outside Terraform and then Terraform applies a change to instance_type?

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  tags = {
    Environment = "dev"
  }

  lifecycle {
    ignore_changes = [tags]
  }
}

A Terraform will update the instance_type but will NOT revert the external changes to tags.

B Terraform will update the instance_type and revert the tags to the declared values.

C Terraform will ignore all changes and not update instance_type or tags.

D Terraform will fail to apply changes due to conflict in tags.

💡 Hint

Consider what ignore_changes does to attributes changed outside Terraform.

The lifecycle block with ignore_changes on tags tells Terraform to ignore any changes to tags made outside Terraform. Therefore, when instance_type changes, Terraform updates it but leaves tags as they are, not reverting external changes.

❓ Architecture

intermediate

Using lifecycle prevent_destroy to protect critical resources

You have a Terraform-managed database instance that must never be destroyed accidentally. Which lifecycle configuration ensures Terraform will refuse to destroy this resource even if you run terraform destroy or remove it from the configuration?

A lifecycle { create_before_destroy = true }

B lifecycle { ignore_changes = [all] }

C lifecycle { prevent_destroy = true }

D lifecycle { replace_triggered_by = ["aws_security_group.db"] }

💡 Hint

Which lifecycle setting blocks resource destruction?

The prevent_destroy setting in lifecycle blocks Terraform from destroying the resource, causing an error if a destroy is attempted.

❓ service_behavior

advanced

Impact of create_before_destroy on resource replacement

Consider a Terraform resource with the lifecycle block:

lifecycle {
  create_before_destroy = true
}

What is the behavior when a change requires resource replacement?

A Terraform creates the new resource first, then destroys the old one after the new is ready.

B Terraform destroys the old resource first, then creates the new one.

C Terraform updates the resource in place without replacement.

D Terraform fails with an error because create_before_destroy is incompatible with replacement.

💡 Hint

Think about how create_before_destroy affects resource replacement order.

With create_before_destroy, Terraform creates the replacement resource before destroying the original, minimizing downtime.

❓ security

advanced

Risks of ignoring changes on sensitive attributes

If you configure lifecycle ignore_changes on a sensitive attribute like password in a database resource, what is a potential risk?

A Terraform will expose the password in logs, causing a security leak.

B Terraform will never update the password even if changed in configuration, causing drift and security risk.

C Terraform will delete the resource when password changes.

D Terraform will prompt for password on every apply.

💡 Hint

Consider what ignoring changes means for sensitive data updates.

Ignoring changes on sensitive attributes means Terraform won't apply updates to them, so if the password changes in config, it won't be updated in the real resource, causing drift and potential security issues.

✅ Best Practice

expert

Combining lifecycle blocks for zero-downtime deployment

You want to update an AWS autoscaling group with zero downtime. Which lifecycle configuration combination best supports this goal?

A lifecycle { ignore_changes = [all] }

B lifecycle { prevent_destroy = true; ignore_changes = [launch_configuration] }

C lifecycle { create_before_destroy = true; prevent_destroy = true }

D lifecycle { create_before_destroy = true; ignore_changes = [desired_capacity] }

💡 Hint

Think about how to replace resources safely and avoid scaling interruptions.

create_before_destroy ensures new resources are ready before old ones are removed, and ignoring desired_capacity changes prevents Terraform from resetting scaling during updates, supporting zero downtime.