A municipal script must change only the description leaf on an existing IOS XE interface without replacing the whole interface resource. Which RESTCONF HTTP verb matches that intent?
Select an answer to reveal the explanation.
Short Explanation
PATCH is the surgical sticky-note on the filing cabinet—merge just the leaf you care about—while PUT swaps the whole folder and GET only reads.
Full Explanation
Changing only the description leaf on an existing IOS XE interface without replacing the whole interface resource is a merge-style edit: RESTCONF PATCH. PATCH works because it applies a partial update to the addressed resource—updating the intended leaf while leaving sibling configuration (addresses, shutdown state, and other leaves) intact unless the payload says otherwise. For municipal scripts that must surgically retag interfaces, PATCH matches intent better than a full-object rewrite.
GET fails because retrieval is read-only; reading an interface never writes a new description. PUT fails the stated intent conceptually when used as a full resource replace: replacing the entire interface object risks dropping leaves the script did not resubmit, which is the opposite of “change only the description.” DELETE followed by POST fails because destroying and recreating the interface is unnecessary churn for an in-place leaf edit and can briefly remove addressing or other state the city still needs.
Exam caveat: some platforms or YANG models also allow carefully scoped PUT on a leaf path; DEVCOR still emphasizes PATCH as the merge verb when the question says “only this leaf, not the whole resource.” Operational check: before production PATCH, capture a GET of the interface, apply the description-only PATCH in a lab VRF or change window, then GET again and confirm sibling leaves (IP, admin state) are unchanged while the description matches the intended civic label.