An engineer is scripting against an IOS XE router over NETCONF using ncclient. The script must read the current interface configuration, change an interface description, and leave that change applied after the session ends and after a reload. The router has the optional candidate datastore enabled, and in this lab a successful commit is also saved to startup. Which ncclient calls accomplish the read and the durable write?

The correct sequence uses manager.connect with the IOS XE device handler, reads configuration with get_config, stages the interface-description change in the candidate datastore with edit_config, and commits it. The commit applies the candidate configuration to the device, so the change is active when the session ends and, as stated in this question, saved to startup and retained across a reload. Editing running directly is a valid way to apply a NETCONF change, but without saving the resulting configuration to startup it does not meet the reload-persistence requirement. Reading startup is a valid way to inspect the saved configuration, but startup can differ from the current running configuration; it therefore does not satisfy the requirement to read the current interface configuration, even though the subsequent candidate edit and commit can apply a change. Editing candidate without committing is also a valid staging workflow, but the change remains uncommitted and is not applied as required. Exam caveat: On IOS XE the candidate datastore must be enabled explicitly and a commit does not normally write startup by itself, so the question states both conditions; NETCONF datastore behavior and persistence details can vary by IOS XE release and platform, so do not assume that a successful commit always writes startup configuration unless the device documentation confirms it. Practical check: after the commit, verify the interface description in running configuration, confirm the platform’s startup-save behavior, and, if needed, inspect startup configuration or perform a controlled reload test.