The same Ansible play must configure VLAN ids and interface names for two library sites. Where should that site-specific data live for reuse?
Select an answer to reveal the explanation.
Short Explanation
Keep the recipe the same and swap the grocery list—VLAN ids and interface names belong in vars so two sites share one play.
Full Explanation
When the same Ansible play must configure VLAN ids and interface names for two library sites, that site-specific data should live in vars, group_vars, or extra-vars so the task logic stays shared across sites. That placement works because Ansible separates data from task code: one playbook can loop or reference variables while each site (or group) supplies different VLAN ids and interface names. Municipal reuse improves when operators change variables instead of forking playbooks per building.
Hard-coding values inside every task line so vars files are never needed fails because duplicated literals make multi-site reuse brittle and force playbook edits for every library. Keeping data only inside ChatOps Webex messages that operators retype each run fails conceptually: chat messages are not durable, reviewable variable sources for automation. Putting the data in a Puppet Hiera tree because Ansible cannot externalize data fails because Ansible has first-class vars/group_vars/extra-vars mechanisms; Hiera is the wrong tool claim.
Exam caveat: choose variable scope deliberately—group_vars for site groups, host_vars for one-off switches, extra-vars for controlled runtime overrides—and avoid stuffing secrets in plaintext vars. Operational check: run the same play twice with different group_vars (or extra-vars) for each library site in lab, confirm VLAN ids and interface names diverge while task text stays identical, then promote the shared play plus per-site vars to the civic repo.