Someone changed a resource in the cloud console and plan wants to revert it — explain and resolve
A teammate resized an instance in the AWS console. Your next terraform plan on the unchanged config shows the diff below. Explain WHY Terraform wants this change, and give the safe ways to resolve it — both keeping the console change and discarding it — without editing state by hand.
# aws_instance.web will be updated in-place
~ resource "aws_instance" "web" {
id = "i-0abc123"
~ instance_type = "t3.large" -> "t3.small"
# (12 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.Diagnose the cause and give the resolution.
Terraform detected drift — the console set t3.large while the config still says t3.small, so plan reverts reality to code. To keep the console value, update the config to t3.large, or add ignore_changes for that attribute. To discard it, just apply and let Terraform revert. Never hand-edit state.
- ✗Hand-editing
terraform.tfstateto match the console value - ✗Tainting the resource, forcing a needless destroy and recreate
- ✗Assuming live infrastructure always wins over the config
- →When is
apply -refresh-onlythe right way to accept a console change? - →How does
ignore_changesdiffer from removing the attribute from config?
The diff is drift: the console set t3.large while the code still asks for t3.small, so plan proposes reconciling reality back to the code.
Keep the console change
resource "aws_instance" "web" {
ami = "ami-123"
instance_type = "t3.large" # update code to match reality
# or stop managing this attribute:
lifecycle {
ignore_changes = [instance_type]
}
}Updating the code or adding ignore_changes clears the diff while keeping the live value. To accept it into state without changing anything, use terraform apply -refresh-only.
Discard the console change
Just terraform apply — Terraform restores t3.small. Never hand-edit state.
