Break/Fix: Provider Upgrade Changes Plan

Scenario

You are operating a production Terraform estate. The team upgraded the AWS provider from 5.0 to 5.5. The next plan is scheduled for the maintenance window. You run terraform plan and see:

# aws_instance.web will be updated in-place
~ resource "aws_instance" "web" {
    ~ ami = "ami-0e1bed4f" -> "ami-9ad034sd"
  }

Plan: 0 to add, 1 to change, 0 to destroy.

The plan proposes to update the ami attribute. The configuration has not changed.

Your task

Investigate the cause of the plan change and decide the correct action.

Evidence to discover

# Check the provider release notes
# (the AWS providers CHANGELOG is on GitHub)

# Check the configuration
grep -A2 "ami" main.tf

# Check the previous state
terraform state show aws_instance.web

Questions to answer

1. What changed in the provider?
2. Is the change intentional?
3. Should the attribute be pinned, accepted, or reverted?
4. What is the verification step?

Recovery procedure

(Do not reveal this until the student has reasoned through the problem.)

1. Read the provider release notes. The 5.5 release included a new default AMI for the t3.medium instance type.
2. Identify the cause. The providers default for ami changed. The configuration did not pin the ami.
3. Decide the remediation. The team agrees to pin the ami to the previous value.
4. Update the configuration.

resource "aws_instance" "web" {
  ami           = "ami-0e1bed4f"   # pinned
  instance_type = "t3.medium"
}

5. Verify the plan is empty.

terraform plan

The plan should be empty.

6. Document the incident. The provider upgrade, the changed default, the pinned attribute.

Remediation

• The cause was the providers new default.
• The team agreed to pin the attribute.
• The configuration was updated.
• The plan is empty after the update.

Prevention

• Pin attributes that have provider defaults.
• Read the provider release notes before every upgrade.
• Test the upgrade in a development environment.
• Use ignore_changes for attributes that should not change.
• Document the upgrade in the runbook.

What you learned

• A provider upgrade may change the plan.
• The change is intentional from the providers perspective.
• The team must decide whether to accept, pin, or revert.
• The read-the-release-notes discipline is the safety net.
• The verification is the plan must be empty.