An engineer runs an Ansible playbook against two IOS XE routers: task one adds three NTP servers with cisco.ios.ios_config, task two sets an interface description with parents, and both tasks notify a handler that saves the config. After a clean first run, what change status and handler activity should an immediate second run report?
Select an answer to reveal the explanation.
Short Explanation
The ios_config module works like a checklist: it compares each line with what's already on the router and sends only what's missing. Since nothing differs, both tasks come back changed false, and a handler only fires when a task notifies it. So your second pass finishes without ever telling the save to run.
Full Explanation
The cisco.ios.ios_config module is idempotent by design: before sending anything it compares the requested lines with the router's current configuration, including the block built from the parents argument, and pushes only the differences, returning changed false when the device already matches. Handlers are event-driven, so a handler named by notify runs only within the same play when a task reports a change; a no-op pass does not queue the save handler. The full-apply view fails because it assumes Ansible re-sends the entire task list on every execution, which would make repeatable automation impossible. The always-run handler view fails because handlers are queued rather than executed unconditionally at play end, and nothing notified them. The parents-bypass view fails because parent and child lines are compared together as one block, so nested configuration is idempotent as well. Exam caveat: custom or third-party collections may skip the comparison step, so read the module documentation before assuming idempotence. Practical check: run the playbook twice with -v and confirm the second pass shows ok and no handler output.