Blueprint task 5.2 names IOS XE for RESTCONF device configuration. A candidate proposes NX-OS or IOS XR REST as the correct target. Why is that wrong for this item?
Select an answer to reveal the explanation.
Short Explanation
The exam names the building—IOS XE. Showing up with an NX-OS or XR visitor badge invents a different campus.
Full Explanation
Blueprint task 5.2 names IOS XE for RESTCONF device configuration, so proposing NX-OS or IOS XR REST as the correct target is wrong for this item because the official parenthetical device class is IOS XE—not NX-OS, IOS XR, or ASA REST. That distinction works as an exam discipline point: DEVCOR tasks bind APIs to stated platforms; answering with a different OS’s REST surface invents a different lab even if those platforms also expose useful APIs in the real world. City candidates must solve the named IOS XE RESTCONF construction.
Claiming RESTCONF never works on any Cisco platform fails because it is false and ignores IOS XE RESTCONF support the blueprint is testing. Saying Meraki Dashboard must replace all device APIs in DEVCOR fails conceptually: Meraki is a separate API family and does not erase IOS XE RESTCONF tasks. Saying only SNMP is allowed when the blueprint says RESTCONF fails because that swaps management protocols against the written objective.
Exam caveat: other Cisco platforms do have automation APIs—knowledge of NX-OS or XR REST is valuable elsewhere—but transferring those answers into an IOS XE-parenthetical item loses the point. Operational check: when writing municipal runbooks or practice answers, label the platform in the title (IOS XE RESTCONF) and refuse to paste NX-OS/XR/ASA snippets into that runbook without an explicit platform change request.