A building permits desk wants engineers to hand-edit site inventory—hostnames, management IPs, and uplink roles—before generating device configs. Which encoding best fits that human-centric workflow?
Select an answer to reveal the explanation.
Short Explanation
YAML is the sticky-note format for humans: indented, comment-friendly, and easy to tweak in a text editor before you render configs. Minified JSON and binary ASN.1 are what machines love—not the permits clerk reviewing inventory.
Full Explanation
Building-permits engineers who hand-edit site inventory—hostnames, management IPs, and uplink roles—before generating configs need a human-centric encoding. YAML documents remain readable with indentation and comments, which fits operator editing far better than opaque binary or minified blobs. That is why Ansible-style inventories and site var files commonly use YAML in civic NetDevOps.
Dense ASN.1 BER blobs committed to git are not hand-editable by network engineers. Minified single-line JSON with no whitespace or comments frustrates safe human edits even though machines can parse it. Raw TCAM dumps from access switches are hardware state exports, not an inventory source encoding.
Exam caveat: YAML’s indentation sensitivity is a tradeoff; linting and schema validation should accompany human edits so a bad indent does not generate wrong configs. Operational check: store site inventory in commented YAML, run a template render in CI, and have a second engineer review a diff before applying to permits-desk switches. Prefer explicit keys over clever anchors when junior staff maintain the files. 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.