A campus automation team must choose a management protocol to push VLAN changes with transactional safety, validate configs before commit, and distinguish running versus candidate views on switches. The team asks how NETCONF differs operationally from ad-hoc REST calls. Which NETCONF characteristic should the designer cite to justify transactional configuration management?
Select an answer to reveal the explanation.
Short Explanation
You need safety rails around every change, not fire-and-forget posts. Datastores let you stage, validate, and commit like drafting in a sandbox first. That transactional flow is pure NETCONF.
Full Explanation
NETCONF runs over a secure connection-oriented SSH transport with XML-encoded remote procedure calls such as get-config, edit-config, lock, unlock, commit, and validate that operate on distinct datastores like running, candidate, and startup, which enables locking for concurrency control and transactional validation before changes affect the active configuration. Describing TLS-only stateless messaging with independent resource URIs confuses NETCONF with RESTCONF principles because RESTCONF maps YANG data to URI resources over HTTPS without persistent sessions or datastore locking semantics. Describing HTTP verbs on YANG paths with JSON payloads is RESTCONF behavior, not NETCONF RPC and datastore operations, and it lacks candidate validation and transactional commit. Describing SNMP community polling with MIB views is legacy monitoring, not transactional YANG-based configuration with RPCs. For the exam, remember NETCONF equals SSH plus RPCs plus datastores and RESTCONF equals HTTPS plus verbs plus URIs, and in practice confirm device YANG support, SSH capability exchange, and candidate versus running workflow.