A city automation script PATCHes an IOS XE interface over RESTCONF. Which Accept/Content-Type media type matches the official YANG-data exchange?
Select an answer to reveal the explanation.
Short Explanation
RESTCONF speaks YANG-data dialects—like ordering coffee in the shop’s official menu language—not generic JSON slang, raw CLI paste, or Webex upload wrappers.
Full Explanation
When a city automation script PATCHes an IOS XE interface over RESTCONF, the Accept and Content-Type headers must use the YANG-data media types—application/yang-data+json or the XML twin application/yang-data+xml. Those types work because RESTCONF’s contract is YANG-encoded resources, not free-form HTTP bodies: the device parses module-qualified leaves according to the YANG model, validates types and keys, and applies datastore edits only when the payload speaks that dialect. Using the official media type keeps municipal scripts interoperable with IOS XE’s RESTCONF stack and with tooling that expects standard YANG-data encoding.
Sending application/json with any homemade object the script invents fails because generic JSON without the YANG-data media type (and without model-shaped structure) is not a guaranteed RESTCONF YANG exchange; inventing field names breaks validation. Posting text/plain that contains a block of CLI configuration lines fails conceptually: RESTCONF is not a CLI paste endpoint, and text/plain does not encode YANG leaves. Using multipart/form-data as used for Webex file uploads fails because that content type belongs to file-upload and collaboration APIs, not IOS XE YANG datastore edits.
Exam caveat: both JSON and XML YANG-data twins can be correct; the exam cares that you pick a YANG-data type, not that you memorize only one encoding. Operational check: log the request Content-Type and response errors on the first failed PATCH—IOS XE typically rejects mismatched or CLI-shaped bodies—then confirm a successful edit returns the expected YANG-data Content-Type on subsequent GETs of the same interface resource.