A stormwater bureau stores per-site variables in YAML and needs consistent IOS XE configs for dozens of pump-station routers. Which concept best describes generating those configs from the data?
Select an answer to reveal the explanation.
Short Explanation
Templating is the cookie cutter: YAML is the dough (site data), Jinja-like templates are the cutter shape, and each pump station gets a consistently shaped config. Hand-pasting fifty routers is how typos flood the storm drains.
Full Explanation
Stormwater per-site variables stored in YAML become consistent IOS XE configs through templating: Jinja-style templates with loops and variables render site-specific CLI from structured data. That concept—data plus template equals generated config—is the core of scalable civic config generation for dozens of pump-station routers. It replaces copy-paste snowflakes with reviewable renders.
Pasting identical full configs by hand and editing hostnames only in Notepad does not scale and invites drift. Disabling routing so templates are unnecessary dodges the requirement. Capturing packets with EPC and converting pcaps into running-config is not a templating workflow.
Exam caveat: templates must be idempotent and environment-aware (lab vs prod) so rendering cannot silently point pump stations at the wrong AAA or NTP. Operational check: render two site YAML files through the same template, diff outputs for expected uniqueness, and apply to a lab router before batch pushes. Store templates and data in version control with peer review for the stormwater automation guild. 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.