Operators rerun an Ansible play that should ensure one static route exists on each IOS XE edge. A task always appends the route CLI blindly. What problem does that create?
Select an answer to reveal the explanation.
Short Explanation
Idempotency means a second coat of paint looks the same—not a thicker drip every time you brush. Always-append duplicates break that promise.
Full Explanation
If operators rerun an Ansible play that should ensure one static route exists on each IOS XE edge, but a task always appends the route CLI blindly, reruns pile on duplicate config instead of leaving the device at the same intended state. That is the idempotency failure: convergent automation must detect “already present” and no-op, whereas unconditional append creates multiple identical or conflicting route lines over time. Municipal edge reliability depends on plays that converge, not accumulate.
Claiming append-forever is the definition of idempotent convergence fails because idempotency means repeated application yields the same state, not thicker config each run. Saying the behavior forces Terraform to become the only valid 5.3.a tool fails conceptually: the fix is proper Ansible module/state usage, not abandoning Ansible. Claiming it converts the playbook into a Puppet agent requirement fails because agent presence is unrelated to fixing a non-idempotent task.
Exam caveat: even module-based tasks can be written non-idempotently if they always force “present” via raw CLI; prefer declarative modules with state parameters over blind ios_command appends for config assurance. Operational check: apply the play twice in lab with no intervening manual changes; the second run must report unchanged for the route task, and show running-config must show a single intended static route for that civic prefix.