A water utility validates that RESTCONF is working by retrieving a modeled interface resource and inspecting the returned data encoding. Which outcome best confirms successful RESTCONF resource retrieval?
Select an answer to reveal the explanation.
Short Explanation
A healthy RESTCONF get should hand you tidy YANG-shaped JSON or XML for that interface—not a CLI novel, not a SPAN tunnel, not “oops SNMP only.”
Full Explanation
A water utility validates that RESTCONF is working by retrieving a modeled interface resource and inspecting the returned data encoding. Successful RESTCONF resource retrieval is confirmed when the client receives YANG-modeled interface data encoded as JSON or XML over RESTCONF—structured, model-shaped content via the HTTP-style API—not unstructured CLI banners or unrelated encapsulations.
Replying only with unstructured CLI pagination banners fails by concept: that indicates traditional CLI output, not RESTCONF YANG resource encoding. A collector receiving ERSPAN GRE headers instead of interface data shows a mirroring path, not RESTCONF management success. SNMP returning IF-MIB counters while RESTCONF remains disabled proves SNMP works but does not validate RESTCONF retrieval of YANG interface resources.
Exam caveat: success criteria for RESTCONF are secure HTTP(S) operations against YANG resources returning JSON/XML model data. Do not confuse “some management protocol works” (SNMP/CLI) with RESTCONF specifically.
Operational check for the water utility: authenticate to RESTCONF, GET the target interface resource, verify status codes and JSON/XML YANG-shaped payloads, and confirm the data matches CLI/operational state for that interface before automating further writes.