During a maintenance window, your team must load a new ACL on 40 branch routers, let the change lead inspect exactly what will be written beforehand, and drop the entire change if it is rejected, so every router ends either fully updated or completely untouched. Which NETCONF staging workflow fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
You stage the ACL in the candidate datastore, where the lead can read it back and you finish with a single commit or discard. Nothing reaches the active configuration until you commit, so a rejection leaves every router untouched. It's like proofing a page before it ever goes to press.
Full Explanation
NETCONF separates a device's configuration into datastores, and the candidate datastore exists precisely for this staging pattern: edit-config loads your ACL into candidate, where the change lead can read the exact XML back, and a single commit promotes it to running while discard-config throws the staged copy away, so nothing is half-applied if the change is rejected. The RESTCONF approach fails because that HTTP style applies each PUT or PATCH straight to running with no commit step, leaving you to undo a rejected change by writing the old values back rather than simply dropping it. Reviewing with get-config falls short because that read operation returns the configuration that is live today, not the pending ACL the lead must approve before anything changes. Pushing with edit-config plus rollback-on-error fails the all-or-nothing discard requirement, since the device writes to running immediately and only reverts when it detects its own error, not when a human says no. Caveat: candidate datastore support depends on the device advertising the :candidate capability. Practical check: run get-config on candidate after edit-config and confirm your ACL appears before you commit.