JNCIS-DevOps: Infrastructure as Code and Network Programmability

What this domain covers

This domain covers describing infrastructure as code and the programmatic interfaces on Junos: YANG and OpenConfig data models, NETCONF, REST, gNMI and templating.

Core rules and concepts

• Declarative vs imperative. Declarative tools (Terraform, Ansible resources) state the desired end state; imperative scripts state the steps. Declarative tools depend on idempotency - applying twice yields no change.
• Single source of truth. Inventory, intent and policy live in Git or a source-of-truth system; device config is rendered from it and never hand-edited.
• Data models. Junos ships native YANG models; OpenConfig provides vendor-neutral models with different naming. NETCONF carries XML configuration; gNMI carries both configuration and streaming state; the Junos REST API exposes configuration and RPCs over HTTP.
• Templating. Jinja2 templates plus YAML/JSON data produce per-device config. Keep logic out of templates; put decisions in the data.
• Terraform tracks resources in state and refreshes to detect drift. State is not a configuration backup and does not by itself reconcile device-side changes.

Worked example

A Terraform Junos provider resource describes an interface's description and MTU. terraform plan after a pull request shows exactly one attribute change. Apply is idempotent: a second plan reports no changes. If someone edits the description directly on the device, the next plan with refresh shows drift and proposes to revert it - the source of truth wins.

Traps

• Treating terraform plan as drift detection without a state refresh.
• Assuming OpenConfig and native Junos model paths are interchangeable.
• Using gNMI only for configuration when it is also the modern telemetry transport.
• Embedding per-device if logic in Jinja2 instead of in the data model.