Idempotence & no-op changes
Recognize an unchanged plan
Lesson 4 of 20 · 12 min · Module 2: Review change and scope access
Reapplying the same intended state should not invent a new change.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Compare meaning rather than property order
- Look for unnecessary churn
The idea
Terraform accepts .tf.json as an alternative configuration representation. Here, built-in terraform_data values make state and plan concepts inspectable without provisioning a cloud resource.
# Desired and recorded JSON objects can be equivalent:
# {"a":1,"b":2} and {"b":2,"a":1}
# Arrays still preserve order.01Compare meaning rather than property order
JSON object keys can be written in different orders without changing the represented object. The planner compares structure and values.
02Look for unnecessary churn
A no-op plan is useful evidence that the declared result already matches recorded state. Repeated unexplained updates deserve investigation.
03Keep observation limits clear
This model compares the provided snapshot. A real provider can also refresh observed remote state before proposing changes.
Your turn
What the checks look for
- Preserves both intended values
- Plans no update for equivalent state
Take this with you
Idempotence avoids repeated unnecessary changes, while refresh checks observed reality.
Go a little further
Add a real value change and compare the resulting plan.