A city public-works network inventory in Ansible YAML has grown clever anchors and merges that junior operators struggle to edit safely. What guidance best balances encoding power with operations?
Select an answer to reveal the explanation.
Short Explanation
Clever YAML merges are like a street map drawn entirely with ditto marks—experts smile, juniors get lost and break a pump station. Spell out the inventory clearly even if it repeats a little. Opaque anchors save keystrokes until someone ships the wrong VLAN.
Full Explanation
Public-works Ansible YAML inventories that grow clever anchors and merges junior operators struggle to edit safely should prefer clear, explicit inventory structure over dense YAML anchors/merges that obscure how host vars actually resolve. Operational clarity beats encoding cleverness when on-call staff must change a pump-station var at 2 a.m. Readable inventory is a reliability control.
Maximizing alias indirection so every site is a single-character anchor reference maximizes confusion. Converting inventory to a binary pickle so operators cannot mis-edit it blocks legitimate ops work. Putting all civic devices under one ungrouped host list with no variables abandons useful structure.
Exam caveat: limited, documented reuse is fine; the failure mode is opacity, not the existence of YAML features. Operational check: rewrite a complex anchor block into explicit group vars, have a junior operator apply a safe change successfully, and lint inventory in CI. Keep a style guide for the public-works automation guild. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services. Re-validate after the next maintenance window that telemetry, API results, and device state still match the documented design intent.