A fleet garage automation team must pick encodings for three jobs: REST controller calls, NETCONF device edits, and hand-maintained inventory files. Which mapping best matches common practice?
Select an answer to reveal the explanation.
Short Explanation
Match the tool to the job: JSON rides REST taxis, XML rides the NETCONF bus, and YAML sits on the clipboard while humans edit inventory. Mixing those roles is how garage automation gets lost on the wrong street.
Full Explanation
Fleet-garage automation that spans REST controller calls, NETCONF device edits, and hand-maintained inventory should map encodings to each job: JSON for REST APIs, XML for NETCONF/YANG exchanges, and YAML for human-edited inventory. That mapping matches common practice across controllers, model-driven device protocols, and operator files. Teaching the trio prevents mixing wire formats incorrectly.
Using XML for every REST call, JSON for NETCONF, and ASN.1 for inventory reverses typical conventions. YAML on the wire for NETCONF, XML for human inventory, and syslog for REST misassigns each channel. CSV for controller APIs, protobuf for inventory, and YAML for NETCONF likewise mismatches mainstream EI tooling.
Exam caveat: exceptions exist (RESTCONF JSON/XML, gNMI protobuf), but the default trio in EI programmability questions remains JSON/XML/YAML for REST/NETCONF/inventory. Operational check: document the encoding per integration in the garage automation README, validate one sample of each path, and fail CI if a NETCONF client suddenly emits JSON bodies. Keep civic inventory YAML as the human source of truth feeding templates. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services.