An engineer is rolling out one change to 40 IOS XE access switches: add an NTP server plus a login banner, then confirm the running config contains both lines. The script must send the change as configuration and read the result back at the normal prompt. Which Netmiko call sequence performs the change and the verification?
Select an answer to reveal the explanation.
Short Explanation
Netmiko splits the job by prompt: send_config_set walks into configuration mode for you, then send_command runs the show at the normal prompt. It's one key to open the door and another to check the room, because the config mode prompt is a different place. That two-step rhythm is what makes the verification trustworthy.
Full Explanation
send_config_set is designed for changes: it enters configuration mode, feeds each line in, leaves the mode and hands the session back, which is exactly what you want when forty switches need the same NTP and banner lines. send_command is designed for reads, because it waits for the normal prompt and returns the show output as a string you can assert on before the script moves to the next device. Passing configuration lines to send_command sends them at the exec prompt, where IOS XE rejects them as invalid input, so nothing is ever applied and the verification only proves the errors came back. Placing the show command inside the same send_config_set list runs it while the session is still inside configuration mode, where that command is unavailable without the do prefix, so you get no usable read-back. Treating the echoed configuration as proof mistakes what the session accepted for what the running config now contains; command echo alone does not confirm that the configuration was applied. Caveat: output formatting varies between IOS XE releases, so assert on the key lines rather than an exact string match. Practical check: run the pair against one lab switch and diff the read-back against the expected NTP and banner entries before scaling out.