A network team automates weekly VLAN audits with ad-hoc queries from scripts, plus a real-time interface monitor that must receive pushed change notifications with transactional rollback on failure. Which NETCONF or RESTCONF selection fits the audit and streaming telemetry use case?
Select an answer to reveal the explanation.
Short Explanation
You've got quick checkups and a live monitor that can't miss a beat. Let RESTCONF handle the simple asks and NETCONF handle the session work, like texts versus a phone call.
Full Explanation
RESTCONF maps YANG operations to stateless HTTP methods, which suits simple ad-hoc retrieval from scripts without session overhead, while NETCONF runs over a persistent SSH session supporting capabilities exchange, candidate configuration with commit and rollback, and subscriptions for event streaming. That split matches audits plus reliable telemetry. Reversing the roles fails by concept because RESTCONF lacks NETCONF-style persistent subscriptions and transactional operations, while using NETCONF for simple stateless fetches adds unnecessary session complexity. Using RESTCONF for both persistent streaming and commits fails because RESTCONF does not provide the same session-oriented commit, rollback, and notification subscription model. Describing NETCONF over stateless HTTP and RESTCONF for capability negotiation inverts the transports, since NETCONF is session-based and capability negotiation is a NETCONF hello behavior. For the exam, tie stateful transactions and streaming to NETCONF and lightweight HTTP CRUD to RESTCONF; in practice confirm YANG model support and notification requirements.