Ignore_changes lifecycle rule in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Effect of ignore_changes on resource updates

Consider a Terraform resource with the ignore_changes lifecycle rule applied to the tags attribute. What happens when you manually update the tags of this resource outside Terraform and then run terraform apply?

Terraform

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  tags = {
    Environment = "dev"
  }

  lifecycle {
    ignore_changes = ["tags"]
  }
}

A Terraform will throw an error during apply because tags were changed outside Terraform.

B Terraform will detect the manual tag changes and overwrite them with the tags defined in the configuration.

C Terraform will ignore manual changes to tags and keep them as they are without overwriting.

D Terraform will remove the tags attribute completely from the resource.

💡 Hint

Think about what ignore_changes means for attributes changed outside Terraform.

The ignore_changes lifecycle rule tells Terraform to ignore changes to specified attributes made outside Terraform. So manual changes to tags will not be overwritten during terraform apply.

❓ Configuration

intermediate

Correct syntax for ignore_changes lifecycle rule

Which of the following Terraform resource lifecycle blocks correctly uses ignore_changes to ignore changes to the metadata and labels attributes?

A

lifecycle {
  ignore_changes = [metadata, labels]
}

B

lifecycle {
  ignore_changes = ("metadata", "labels")
}

C

lifecycle {
  ignore_changes = { metadata, labels }
}

D

lifecycle {
  ignore_changes = ["metadata", "labels"]
}

💡 Hint

Remember how lists of strings are written in Terraform HCL.

The ignore_changes attribute expects a list of strings, so the attribute names must be quoted and enclosed in square brackets.

❓ Architecture

advanced

Using ignore_changes in multi-environment Terraform setup

You manage multiple environments (dev, staging, prod) with Terraform. You want to allow manual changes to the description attribute of a resource in the dev environment only, without Terraform overwriting it on apply. How should you configure ignore_changes to achieve this?

Terraform

variable "environment" {
  type = string
}

resource "aws_s3_bucket" "example" {
  bucket = "my-bucket-${var.environment}"
  description = "Managed by Terraform"

  lifecycle {
    ignore_changes = var.environment == "dev" ? ["description"] : []
  }
}

A Use a conditional expression in <code>ignore_changes</code> to ignore <code>description</code> only when environment is dev.

B Set <code>ignore_changes</code> to always ignore <code>description</code> for all environments.

C Remove <code>ignore_changes</code> and manually revert changes after apply.

D Use separate Terraform workspaces without <code>ignore_changes</code>.

💡 Hint

Think about how to conditionally apply lifecycle rules based on variables.

Using a conditional expression in ignore_changes allows ignoring changes only in the dev environment, while other environments remain fully managed by Terraform.

❓ security

advanced

Security risks of using ignore_changes on sensitive attributes

What is a potential security risk when using ignore_changes on sensitive attributes like password or access_key in Terraform resources?

A Terraform will overwrite sensitive attributes with empty values, causing service disruption.

B Manual changes to sensitive attributes outside Terraform will persist unnoticed, possibly causing security drift.

C Terraform will expose sensitive attributes in logs when using ignore_changes.

D ignore_changes disables encryption on sensitive attributes.

💡 Hint

Consider what happens if Terraform ignores changes to secrets made outside its control.

Using ignore_changes on sensitive attributes means manual changes outside Terraform are not detected or reverted, which can lead to security drift and unmanaged secrets.

✅ Best Practice

expert

Best practice for using ignore_changes with nested attributes

You have a resource with a nested attribute settings.network. You want Terraform to ignore changes only to the network nested block but still manage other parts of settings. Which ignore_changes configuration is correct?

Terraform

resource "example_resource" "test" {
  settings = {
    network = {
      cidr_block = "10.0.0.0/16"
      dns = "8.8.8.8"
    }
    logging = true
  }

  lifecycle {
    ignore_changes = ["settings.network"]
  }
}

A ignore_changes = ["settings.network"]

B ignore_changes = ["settings"]

C ignore_changes = ["settings.network.cidr_block", "settings.network.dns"]

D ignore_changes = ["settings.network.*"]

💡 Hint

Think about how Terraform references nested blocks in ignore_changes.

Using "settings.network" tells Terraform to ignore changes to the entire nested network block but still manage other parts of settings. Ignoring settings would ignore all nested attributes.

Practice

1. What is the main purpose of the ignore_changes lifecycle rule in Terraform?

easy

A. To prevent Terraform from updating specified resource attributes during apply

B. To delete resources automatically when attributes change

C. To force Terraform to recreate resources on every apply

D. To enable Terraform to ignore syntax errors in configuration files

Solution

1. Step 1: Understand the role of ignore_changes

   This rule tells Terraform to skip updating certain attributes even if they change outside Terraform.

2. Step 2: Compare options with this behavior

   Only 'To prevent Terraform from updating specified resource attributes during apply' matches this behavior by preventing updates on specified attributes.

3. Final Answer:

   To prevent Terraform from updating specified resource attributes during apply -> Option A

4. Quick Check:

   ignore_changes skips updates = D [OK]

Hint: Remember: ignore_changes skips updates on chosen attributes [OK]

Common Mistakes:

• Thinking ignore_changes deletes resources
• Confusing ignore_changes with forcing recreation
• Believing ignore_changes fixes syntax errors

2. Which of the following is the correct syntax to ignore changes on the attribute tags in a resource lifecycle block?

easy

A. lifecycle { ignore_changes = tags }

B. lifecycle { ignore_changes = ["tags"] }

C. lifecycle { ignore_changes = { tags = true } }

D. lifecycle { ignore_changes = "tags" }

Solution

1. Step 1: Recall the correct syntax for ignore_changes

   It requires a list of attribute names as strings inside square brackets.

2. Step 2: Match options to this syntax

   Only lifecycle { ignore_changes = ["tags"] } uses a list with quotes around "tags" correctly.

3. Final Answer:

   lifecycle { ignore_changes = ["tags"] } -> Option B

4. Quick Check:

   ignore_changes needs list of strings = A [OK]

Hint: Use square brackets and quotes for ignore_changes list [OK]

Common Mistakes:

• Omitting square brackets for the list
• Using a map or boolean instead of list
• Passing a single string without brackets

3. Given this Terraform resource snippet:

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  tags = {
    Name = "example-instance"
  }

  lifecycle {
    ignore_changes = ["tags"]
  }
}

If someone manually changes the tags in AWS console, what will happen when you run terraform apply next time?

medium

A. Terraform will throw an error about tag drift

B. Terraform will overwrite the tags back to the config values

C. Terraform will keep the manual tag changes and not overwrite them

D. Terraform will recreate the instance to fix tags

Solution

1. Step 1: Understand ignore_changes effect on tags

   ignore_changes on "tags" means Terraform ignores any changes to tags outside Terraform.

2. Step 2: Predict apply behavior

   Terraform will not overwrite manual tag changes and will keep them as is.

3. Final Answer:

   Terraform will keep the manual tag changes and not overwrite them -> Option C

4. Quick Check:

   ignore_changes on tags keeps manual changes = C [OK]

Hint: ignore_changes means Terraform skips updating those attributes [OK]

Common Mistakes:

• Assuming Terraform always overwrites manual changes
• Expecting errors on drift with ignore_changes
• Thinking resource will be recreated due to tag changes

4. You wrote this lifecycle block:

lifecycle {
  ignore_changes = "tags"
}

Terraform plan shows an error. What is the problem and how to fix it?

medium

A. ignore_changes cannot include tags attribute

B. ignore_changes requires a boolean value, not string

C. ignore_changes must be outside lifecycle block

D. ignore_changes must be a list, fix by using ["tags"]

Solution

1. Step 1: Identify syntax error in ignore_changes value

   ignore_changes expects a list of attribute names, not a single string.

2. Step 2: Correct the syntax

   Wrap "tags" in square brackets to make it a list: ["tags"]

3. Final Answer:

   ignore_changes must be a list, fix by using ["tags"] -> Option D

4. Quick Check:

   ignore_changes needs list syntax = B [OK]

Hint: ignore_changes always needs a list, even for one attribute [OK]

Common Mistakes:

• Passing a single string instead of list
• Placing ignore_changes outside lifecycle block
• Using boolean instead of list for ignore_changes

5. You manage an AWS S3 bucket with Terraform. The bucket has a versioning block that is sometimes changed manually outside Terraform. You want Terraform to manage all bucket settings except ignore changes to versioning.enabled. How do you configure ignore_changes correctly?

hard

A. lifecycle { ignore_changes = ["versioning[0].enabled"] }

B. lifecycle { ignore_changes = ["versioning.enabled"] }

C. lifecycle { ignore_changes = ["versioning"] }

D. lifecycle { ignore_changes = ["versioning.enabled.enabled"] }

Solution

1. Step 1: Understand nested attribute syntax in ignore_changes

   For nested blocks like versioning, Terraform uses index notation like versioning[0].enabled to specify the attribute.

2. Step 2: Choose the correct attribute path

   lifecycle { ignore_changes = ["versioning[0].enabled"] } uses the correct syntax with index 0 for the first versioning block and the enabled attribute.

3. Final Answer:

   lifecycle { ignore_changes = ["versioning[0].enabled"] } -> Option A

4. Quick Check:

   Nested block attribute needs index notation = A [OK]

Hint: Use index like versioning[0].enabled for nested block attributes [OK]

Common Mistakes:

• Ignoring index notation for nested blocks
• Using incomplete attribute path
• Ignoring nested block structure in ignore_changes