An autoscaling group is managed by Terraform, but a scaling policy changes its desired capacity throughout the day. Every plan now proposes setting desired capacity back to the configured value. Terraform must keep managing the group's launch template, sizes and tags. Which change is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Two cooks, one pot: if the autoscaler owns the capacity knob, Terraform has to keep its hands off that one knob. ignore_changes on that single argument does it. The trap is 'all', which also stops Terraform from rolling out your launch template changes.
Full Explanation
ignore_changes lists attributes whose differences between configuration and the real object Terraform should not try to reconcile. It is intended for exactly this case, where another process legitimately manages one attribute after creation. Listing only the desired-capacity argument means Terraform still sets it on create but stops proposing updates when the scaling policy changes it, while the launch template, sizes and tags remain fully managed. A refresh-only apply records the current capacity in state, but the configuration still holds the original number, so the next normal plan proposes the same reset again; refresh-only accepts drift into state without changing what configuration wants. ignore_changes = all would stop Terraform from proposing any update to the group, which violates the requirement to keep managing the template and tags. prevent_destroy only rejects plans that would destroy the object; it has nothing to do with in-place attribute differences. Exam caveat: ignore_changes affects what Terraform proposes, not what it records; the real value is still read into state on refresh. Operational check: after adding the rule, a plan run while the autoscaler has changed capacity should report no changes for the group.