A parks IT developer must edit interface configuration on an IOS XE switch via RESTCONF. Which URI family is the correct datastore root for that edit?
Select an answer to reveal the explanation.
Short Explanation
The RESTCONF front door is /restconf/data—like the city’s official records vault—not a leftover /api/v1 hallway or a scraped web UI.
Full Explanation
Editing interface configuration on an IOS XE switch via RESTCONF requires addressing the YANG datastore root under /restconf/data with a module-qualified resource path—https://switch/restconf/data/<module>:<resource>/…. That URI family works because RESTCONF maps YANG modules and lists onto hierarchical HTTPS paths; the municipal developer navigates to the exact interface (or other) resource the model defines, then GET/PATCH/PUT/DELETE against that path. Staying under /restconf/data keeps edits inside the official datastore API rather than inventing a parallel HTTP surface.
Using https://switch/api/v1/interfaces copied from an unrelated internal microservice fails because that path is not the IOS XE RESTCONF datastore root; borrowing a city app’s URL pattern does not create YANG-bound device config. Guessing https://switch/rest with no YANG module prefix fails conceptually: RESTCONF needs the /restconf/data (or operations) namespace and module-qualified resources, not a shortened guess. Scraping https://switch/webui/config from the HTML management page fails because the device web UI is not a machine RESTCONF API and HTML scraping is neither YANG-valid nor exam-correct.
Exam caveat: exact module and list-key names differ between IETF and Cisco-IOS-XE-native trees; the scored idea is the /restconf/data family with a proper module:resource path, not memorizing one vendor string forever. Operational check: after enabling RESTCONF, browse or GET /restconf/data to confirm reachable modules, then resolve the interface resource path before writing, and reject any automation that targets Web UI or ad-hoc /api/v1 URLs on the switch.