Infrastructure as Code and Configuration Management
Infrastructure as Code and Configuration Management
This domain tests declarative desired-state management, idempotency, drift, and Junos configuration semantics. You must know how tools such as Ansible and templates enforce a documented state rather than ad hoc CLI edits.
Core rules
- Declarative IaC describes the end state; imperative scripting describes steps. Declarative tools converge repeatedly and should be idempotent: a second run with no drift makes no changes.
- Source of truth: the repository, not the device, is authoritative. Rendered configs come from templates plus data (YAML/JSON), not untracked manual changes.
- Junos load modes:
mergeadds or updates specified hierarchy;replacereplaces the stated hierarchy;overridereplaces the entire candidate config. Choose the narrowest mode that meets intent. - Safe change controls:
commit confirmed <minutes>auto-rolls back unless confirmed;rollback nrestores prior configs; a rescue config provides a known-good baseline. - Ansible for Junos uses modules such as
junos_config,junos_command, andjunos_facts;junos_configsupportslines,src,comment, andcommitoptions.
Worked example
An Ansible task enforces an NTP server on all edge routers:
- name: enforce NTP
junos_config:
lines:
- set system ntp server 192.0.2.10
comment: 'IaC: NTP baseline'
commit: yes
Reasoning: the task is declarative at the playbook level, but junos_config with lines uses merge semantics. Running it twice yields the same state, so it is idempotent for that line. For a full baseline, prefer a templated src and choose the load action deliberately; use override only when you truly own the whole config, otherwise you risk deleting unmanaged statements.
Traps
- Calling a script 'IaC' when it is an imperative sequence with no drift detection.
- Using override on a device that has out-of-band management config.
- Forgetting that
commit confirmedrequires a follow-up commit or it rolls back. - Storing credentials in plaintext YAML.