An enterprise automation team must push complex multi-device VLAN and OSPF changes nightly with validation, rollback on error, and locking to prevent concurrent edits across a 500-switch campus. A lightweight dashboard also needs simple read-write calls. Which NETCONF versus RESTCONF selection best fits the nightly transactional use case?
Select an answer to reveal the explanation.
Short Explanation
Nightly bulk edits need a dress rehearsal plus an undo button. NETCONF gives you candidate staging and confirmed commit, like transactions at a bank. RESTCONF shines for quick web-friendly reads, not guarded rollbacks.
Full Explanation
NETCONF uses SSH-based RPC with YANG models and supports candidate and running datastores, locking, validation, and confirmed commit, enabling all-or-nothing atomic changes and automatic rollback that multi-device nightly provisioning requires. Choosing RESTCONF with candidate and confirmed commit fails by concept because although RESTCONF also uses YANG over HTTPS, it is stateless REST without native datastore locking and transactional confirmed-commit semantics, making it suited to simple resource operations rather than guarded transactions. Choosing NETCONF over plain HTTP GET for simple reads fails by concept because it inverts strengths, using a stateful transactional protocol where lightweight stateless HTTPS REST calls would be simpler and more tool-friendly. Choosing SNMP polling fails by concept because SNMP lacks YANG data modeling, candidate validation, and transactional commit or rollback for configuration workflows. For the exam, remember NETCONF equals transactional and stateful while RESTCONF equals RESTful and lightweight, and in practice verify device YANG support and test commit-confirm timeouts before production pushes.