A teammate is choosing between NETCONF and RESTCONF for a nightly job that must save a file containing only the device's current configuration, then stage a change for operator review before it takes effect. Which NETCONF operation and datastore pairing fits both parts of that job?
Select an answer to reveal the explanation.
Short Explanation
You’ve got two different NETCONF operations working like a snapshot and a draft: get-config on running saves the current configuration, while edit-config on candidate stages the change for an operator to review and commit.
Full Explanation
NETCONF deliberately separates reading configuration from reading operational state: get-config takes an explicit source and returns only the configuration tree, so pulling from running produces a file that can be diffed against the live device, while edit-config against candidate stages changes without touching production until an operator commits them. Plain get also sweeps in state data such as interface counters and session statistics, which pollutes a configuration backup and makes every nightly comparison noisy. edit-config against running is perfectly valid NETCONF, but it applies the change immediately, so nobody gets the review step the job requires. If candidate contains uncommitted work, get-config from candidate captures that work along with the candidate configuration, rather than just the configuration the device is currently serving. Caveat: not every platform exposes candidate, so check the server's capabilities before you rely on staging. Practical check: run get-config against both datastores in a lab and compare the XML you get back.