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.