Network Configuration Management and Templating
This domain is about generating and managing device configuration consistently. Understand templating with Jinja2: variables, {{ }} expressions, {% %} statements (if, for), filters (e.g., default, upper, join), and whitespace control. Know how templates plus a data source (YAML/JSON/CSV inventory or vars) produce per-device config - the separation of template (structure) from data (values) is central.
Understand configuration management principles: a single source of truth for intended state, version control for templates and data, idempotent application, drift detection, and rollback. Recognize the difference between full-config replace (push the whole config, risk of clobbering) and surgical/partial config (change only the relevant hierarchy) - Junos supports load replace, load merge, load override, and load update, and knowing these semantics is a frequent exam point. merge adds/updates, replace replaces matching hierarchies, override replaces the entire config, update is like merge but respects replace: tags.
Traps: forgetting that YAML is whitespace-sensitive and indentation defines structure; assuming a template variable that is undefined will fail loudly (it often renders empty unless StrictUndefined is set); and treating a rendered config as validated (it still needs commit check). Also expect questions on hierarchical vs. flat config, naming conventions, and documentation of intent.
Rule of thumb: render → diff against running config → check/validate → commit (confirmed) → verify. Never push a rendered template straight to production without a diff.
Worked example: A loop over interfaces in Jinja2 with {% for i in interfaces %} and load merge changes only listed interfaces, leaving unrelated config intact - safer than load override.