A network automation team must apply a block of CLI configuration lines to fifty IOS XE switches from an Ansible controller. SSH is the only enabled management protocol on the estate, and a second run must leave an already configured switch untouched. Which Ansible connection type and module combination should the playbook use?
Select an answer to reveal the explanation.
Short Explanation
The network_cli connection opens an SSH session, and ios_config compares your lines with the switch's current configuration, like ticking off a packing list instead of rewriting it. If the configuration already matches, a second run makes no configuration changes. The other routes either don't provide the needed configuration comparison or require a protocol the estate doesn't have enabled.
Full Explanation
The cisco.ios.ios_config module over ansible.netcommon.network_cli is the appropriate combination: network_cli manages network devices through their CLI over SSH, and ios_config compares intended lines with the running configuration so an unchanged switch is not needlessly reconfigured on a later run. This fits the IOS XE devices, the available management protocol, and the requirement to apply a CLI block across the estate. Using httpapi with ios_config can be a valid approach for supported devices when that API is enabled, but this estate has SSH as its only enabled management protocol, so that connection cannot meet the stated access constraint. Setting match: none is a supported way to have ios_config treat the configuration as unmatched and send it again; it therefore gives up the required unchanged-second-run behavior even though the module and connection otherwise fit. Setting run_once: true is a legitimate Ansible control for tasks intended to execute on just one host, but here it limits the task to one switch instead of applying the block to all fifty. Exam caveat: network_cli selects the CLI transport; it does not by itself make arbitrary commands idempotent—the module’s comparison behavior matters. Practical check: run the play twice against a test switch and confirm the second run reports no configuration changes, then verify the intended block is present on every target.