Why is idempotency critical to Ansible's module design?

Automation that isn't idempotent is dangerous to re-run: if a task blindly creates a user, appends a line to a config file, or restarts a service every single time it executes regardless of current state, running the same playbook twice can create duplicate users, duplicate config lines, or unnecessary service restarts, turning routine re-runs into a source of drift or outages rather than a safe, predictable operation.

Idempotency is what makes Ansible's core workflow - "just run the playbook again" - safe as a default response to almost any situation, whether that's recovering from a partial failure, applying a playbook to a fleet that's in a mixed, unknown state, or simply re-verifying that a system still matches its intended configuration. Because idempotent tasks only report changed when something genuinely needed to happen, playbook output over time also becomes a meaningful signal: a run that reports many changes on a system that should already be configured correctly is itself useful information, suggesting drift, whereas a run reporting all ok confirms the system matches the desired state exactly. Without that guarantee, every re-run would carry real risk instead of being routine.