5.1Model-driven programmability and IaC

The starting point of network automation is not "configure faster" but expressing configuration as human-readable code so it can be reproduced, reviewed, and tracked. Manual CLI may be fast for one device, but applying the same change safely to 100 devices—with an audit trail of "what state we are in now"—is hard. This section organizes the problems IaC solves, its core principles of declarative, idempotent, and version-controlled, and the design choice of whether to drive automation device-by-device or through a controller's intent, so you choose from the problem to solve rather than from tool names.

5.1.1The value of IaC

• Infrastructure as Code (IaC) means writing infrastructure configuration (VLANs, routing, ACLs, etc.) as code and applying that code to build the environment. Unlike manual work following a runbook, the same code always reproduces the same configuration (reproducibility), curbing configuration drift—the phenomenon where devices diverge due to human variation.
• The biggest benefit of coding is that it rides on version control (Git): who changed what, when, and why is recorded in history; changes can be applied only after third-party review (Pull Request); and if something breaks you can roll back to a prior commit. Network change shifts from "tribal knowledge" to an "auditable process."
• Treat IaC as a tool for consistency, safety, and scale rather than raw speed. A one-off change to a single device may be faster by CLI, but the moment you need repeated application across many devices, an audit trail of changes, and team collaboration, the value of IaC kicks in.

5.1.2IaC principles

• Declarative means describing the desired end state (what) rather than "how to do it (the steps)." For example, you declare "VLAN 10 exists and Gi0/1 is an access port on it," and the tool fills the gap against the current state. This is more resilient to state drift than writing each step imperatively.
• Idempotency is the property that applying the same code any number of times yields the same result, making no change if the desired state already holds. Idempotent automation removes the worry of "running it again creates duplicates or errors," and re-running after a mid-way failure (retry) is safe. An IaC tool reporting "changed=0" is this property in action.
• Version control / single source of truth (SSOT) means keeping configuration code in Git and treating it as the sole authority. The device's running config is positioned as "a derivative generated from code," and directly hand-editing it (out-of-band change) is avoided. Allowing hand edits makes code and device diverge, causing overwrite accidents on re-apply.

5.1.3Device-level and controller-level

• Device-level automation distributes configuration directly to each device (via NETCONF/RESTCONF/SSH-CLI, etc.). It gives fine per-device control and can start without a controller product, but you must manage the state of every device yourself, and scripts tend to grow complex at multi-vendor, large scale.
• Controller-level automation tells a controller's API (intent)—such as Catalyst Center or NSO—the "desired state," and the controller translates and distributes it to the many devices below. It excels at multi-vendor abstraction, global consistency, and large-scale operations, but presupposes dependence on and understanding of the controller product.

Suppose you run an enterprise network of 200 sites and ~1,500 devices (mostly Cisco but with some other vendors), and you are asked to "standardize each site's guest VLAN and ACL, and be able to show auditors who made which change and when." Today, because engineers hand-typed CLI per site, configuration drift has crept in and the supposedly identical guest VLAN differs subtly across sites. Re-pushing CLI by hand or with a naive script "because it is fast" is a poor call: it leaves no audit trail, is not reproducible, and cannot absorb multi-vendor differences. The right move is to write the standard once as declarative code, keep it in Git under version control with a Pull Request review, and apply it idempotently (sites already compliant are left untouched with changed=0)—so "who, when, why" lives in history and the audit requirement is met. Next, at which layer to automate: for a few dozen single-vendor devices, device-level (directly via NETCONF/RESTCONF) is manageable, but for 200 sites, multi-vendor, needing global consistency, carrying every device's state yourself tends to break down. Choosing controller-level (e.g., defining the guest VLAN as a service in NSO and letting it translate/distribute to the multi-vendor devices below) lets you manage the abstracted "desired state" in one place, and the controller continuously remediates drift recurrence. The key is not to misread IaC's value as "configuration gets faster." The essence here is consistency, auditability, and scale, and a returned changed=0 (already matching the desired state, doing nothing) is precisely the proof of idempotent, safe operations.

5.1.4Section summary

• IaC puts configuration as code under Git/review/rollback; its value is consistency, reproducibility, auditability, and scale, not speed
• The principles are declarative (describe the desired state), idempotent (same result on any apply, no change if unneeded = changed=0), and version control/SSOT (code is the sole authority; avoid hand edits)
• Choose the automation layer by problem: device-level for few, single-vendor, per-device control; controller-level (intent) for many sites, multi-vendor, continuous consistency