ignore_changes tells Terraform to skip updates to listed attributes after a resource is created. It is a fair tool for values another system manages, but every ignored attribute is a place where drift stops being detected. Never use it on security settings, and list attributes one by one rather than using all.
What it does
According to HashiCorp's lifecycle documentation, ignore_changes makes Terraform ignore changes to the named attributes so an outside process can manage them. The example given is ignore_changes = [tags]. Terraform only ignores attributes defined by the resource type. Setting it to all makes Terraform create and destroy the object but never propose updates.
Legitimate uses
- A desired instance count that an autoscaler changes.
- Tags added by a cost or ownership tool.
- A container image tag updated by a separate deployment pipeline.
In each case, another system is the intended owner of that value, and reverting it would cause harm.
Where it becomes a risk
- Security settings. Ignoring an ingress rule list, a public access flag, an encryption setting or a policy document means anyone can change it in the console and Terraform will not notice.
- The all keyword. It silently exempts everything, including attributes added in later provider versions.
- Copied snippets. A line added to stop a noisy diff stays forever, long after the original reason is gone.
The pattern is common: a plan shows a change someone does not understand, ignore_changes makes it disappear, and the underlying disagreement is never resolved.
Safer habits
- Ignore the narrowest attribute possible, never
all. - Add a comment with the owner and reason.
- Keep security-relevant attributes out of the list, or enforce them with a policy check that reads cloud state instead.
- Review the ignore list on a schedule, such as quarterly.
- Flag any new
ignore_changesin a pull request for a security reviewer.
Make hidden drift visible anyway
A refresh-only run updates state to reflect changes made outside Terraform without proposing other changes. HashiCorp's plan documentation describes this mode. Running it on a schedule and reviewing the output shows you what has changed outside code. Cloud-native checks and asset inventories can also compare real resources against expectations.
Safeguard's asset discovery and policy checks help here as an independent view of what exists, separate from what your state believes.
A quick audit
Search your repositories for the string ignore_changes. For each hit, ask: who owns this attribute, is it security relevant, and is the reason written down? Remove entries where the answer is unclear.
Quick check
Is ignore_changes on tags a security problem?
Usually not, unless tags drive access control, for example attribute based access policies. In that case treat tags as security settings.
What does ignore_changes = all do?
It makes Terraform create and destroy the object but never propose updates to it, so any later change goes unnoticed.
Sources
- The lifecycle meta-argument (HashiCorp Terraform)
- terraform plan command reference (HashiCorp Terraform)
Last reviewed: 19 October 2026.
