An enterprise automation engineer must back up running configs nightly from 60 IOS XE switches and push a standard NTP change using Python over NETCONF on port 830 with trusted host keys. The script must separate read and write operations cleanly. Which ncclient usage meets the NETCONF requirements?
Select an answer to reveal the explanation.
Short Explanation
You keep reads and writes tidy with get_config on the running datastore and edit_config on the running target. This datastore-aware pattern gives you a safe backup-then-change rhythm while honoring trusted host-key verification.
Full Explanation
The usage with trusted host-key verification pairs get_config to read the running datastore with edit_config targeting running for the NTP change. A filter can limit the backup to relevant configuration, and explicitly naming the read source and write target keeps the operations distinct. Reading source running captures the live configuration needed for the nightly backup; writing target running applies the NTP change to the active configuration. The usage that backs up source startup before editing target running reads the saved configuration, so unsaved changes can be omitted from the backup. The usage that backs up source running but edits target startup changes the saved configuration without applying the NTP change to the active running configuration. The usage that connects on port 22 fails the required NETCONF endpoint requirement; SSH commonly uses port 22, but this task requires port 830. Exam caveat: candidate-datastore workflows with validation and commit are common where devices support them, but they are not interchangeable with the requested running-target workflow. Practical check: verify the session’s port and host-key policy, inspect a filtered running-config response, and confirm the NTP setting in running after the edit.