A tooling team needs both one-time retrieval of switch inventory over HTTPS and long-lived configuration change subscriptions with transactional rollback on failure. Which protocol selection matches programmatic management requirements for these distinct use cases?
Select an answer to reveal the explanation.
Short Explanation
You're picking the right wrench for each job, quick reads versus guarded changes. RESTCONF shines for lightweight web reads while NETCONF handles strict transactions with rollback when things go sideways.
Full Explanation
The correct approach works because RESTCONF maps YANG models to stateless HTTPS operations that suit simple reads and ad hoc automation, while NETCONF uses SSH-based RPCs with datastores, locking, confirmed commit, and rollback plus subscriptions that suit transactional, long-lived management sessions. Using NETCONF over HTTPS with stateless GET fails by concept because NETCONF is session-oriented over SSH with structured RPCs, so describing it as stateless HTTPS reads confuses its transport and strengths with RESTCONF. Using RESTCONF with candidate locking and confirmed commit fails by concept because those transactional datastore capabilities are NETCONF features, not RESTCONF behaviors, so it attributes the wrong mechanism to the protocol. Using SNMP polling with MIB replication fails by concept because SNMP lacks YANG modeling, datastores, and transactional commit or rollback, making it unsuitable for either modern programmatic requirement. For the exam, remember NETCONF equals stateful transactions and subscriptions and RESTCONF equals lightweight HTTPS CRUD; in practice confirm YANG model support and test rollback behavior in a lab before production automation.