Infrastructure as Code

In infrastructure as code (IaC), the network's intended state lives as versioned text: variables in a source of truth, configuration templates, a pipeline file. An automated pipeline then renders, tests, and deploys that text onto devices, so a device's running configuration is an output of the process, not the thing you edit. Picture a one-way flow: intent enters as code, a pipeline carries it through validation and a test lab, and only the final stage writes to a device; you never fold a device's live change back into the code by hand. The trap this whole domain sets, in a dozen costumes, is treating the device or its running-config as the source of change: hand-editing a router that the next render will silently overwrite, or trusting a scraped running-config as the source of truth when it is only actual state. Sort what is intent from what is derived output, and most of the questions answer themselves.

Read this page as a map of the toolchain that carries a change from a commit to a live, verified device, then follow the seven subtopics in order. That toolchain has a handful of parts: version control, the pipeline, a test bed, the runtime it all runs in, a source of truth, and the config data it produces. At thirty percent of the 350-901 blueprint, tied with Network Automation for the largest share, it earns the attention. Git Version Control Operations is the substrate for version control: every change is a commit, and the one split that decides most questions is which operations add to history (safe on a branch others share) versus rewrite it (fine locally, dangerous once pushed). The pipeline owns the next two subtopics. Diagnosing GitLab CI/CD Failures is reading the pipeline when a job goes red: find the first error and sort it into a missing dependency, a version incompatibility, or a failed test. Building a GitLab CI/CD Pipeline is the delivery path itself, four stages (build, prevalidation, deploy, post-validation) where deploy is the only stage that writes to a device. Network Simulation with Cisco CML is the test bed: a disposable replica running real network operating system (NOS) images, so you prove the automation before it touches production. Interpreting Docker Compose Files is the runtime those tools and jobs execute in, read through its services, networks, volumes, and links. Source of Truth Integration is the authoritative store of intended state, an IP address management (IPAM) system, a data center infrastructure management (DCIM) inventory, or version-controlled variables, that configuration is rendered from. YAML/JSON from YANG Models is the config data at the far end: how a YANG data model becomes the JSON a RESTCONF request carries. Each subtopic holds the mechanisms and the traps; this overview only shows how they connect.

Across every subtopic the exam rewards the same instinct: preserve reproducibility and never bypass the pipeline. Change the source of truth and re-render rather than touch a device; add to shared Git history with a revert or a merge rather than rewrite it with reset or rebase; gate a change in prevalidation and prove it in a CML replica before deploy writes anything; keep one authoritative system per kind of data instead of scattering the same fact across a wiki and a spreadsheet. When two options both technically work, the exam-correct one is almost always the choice that keeps the change auditable, reversible, and reproducible from code.