Network Automation

Ansible, Terraform, RESTCONF, and Python can each build the very same VLAN, OSPF process, interface, or ACL; what changes is how the tool expresses the change and what it costs you to own. One model makes all of them legible, which is to judge every tool on two axes. The intent axis asks how a tool expresses change: a declarative tool states the desired end state and applies only the delta, so re-running it is an idempotent no-op (a second run changes nothing), while an imperative tool runs the ordered steps you script and leaves you to build the "is it already done?" checks yourself. The interface axis asks how a tool talks to the device: a model-driven interface exchanges structured data described by a YANG data model (the device's formal schema) over NETCONF, RESTCONF (RFC 8040), or gNMI and survives software upgrades, while command-line-interface (CLI) screen-scraping sends and parses the text a human would type, so it breaks when that output shifts. The classic trap is reaching for the most powerful tool when a declarative framework or a controller template already meets the requirement: the exam rewards the least capability that clears the bar, because you pay to build and own everything above it.

Network Automation is 30% of the 350-901, matched only by Infrastructure as Code at 30%, so the two together are about 60% of the blueprint. Read this page as a map, then follow the six subtopics in order. Network Automation with Ansible pushes declarative resource modules (ios_vlans, ios_ospfv2, ios_acls) from a control node over SSH, NETCONF, or HTTPS, keeping raw CLI only for whatever no module models; reach for it for agentless, playbook-driven change across a mixed fleet. Network Automation with Terraform describes the same end state in HashiCorp Configuration Language (HCL) and keeps an authoritative state file that detects drift, so it fits a stable fleet you run through a full create, update, and destroy lifecycle. Network Automation with RESTCONF is HTTP CRUD straight onto a device's YANG datastore, where the URL walks the model tree and the HTTP verb is the datastore operation; reach for it to change one device with no controller in the way. Network Automation with Python is the custom-application escape hatch, preferring model-driven libraries and dropping to CLI scraping only for the unmodeled, justified when logic the frameworks cannot express is genuinely needed. Selecting the Network Automation Approach is the chooser that turns the axes above (build, intent, interface, and, on Cisco, platform scope) into one rule: buy the least capability that meets the technical and business requirement. Consuming REST APIs at Scale is the hardening layer any code-driven approach needs once a client drives a REST application programming interface (API) in a loop: pagination, persistent authentication, rate-limit handling, and safe retries.

Across every tool the same instinct earns the point. Prefer the declarative expression, because idempotency then comes for free and re-running in a pipeline or on a drift schedule stays safe, where imperative code has to earn that by hand. Prefer the model-driven interface, because a YANG contract survives the upgrades and cross-platform format changes that quietly break CLI scraping; a stem that stresses surviving upgrades, structured data, or validate-and-roll-back is signaling this axis. And prefer the smallest tool that meets the requirement over the most capable one, a controller template or an infrastructure-as-code (IaC) framework before a bespoke application, because capability you do not need is still cost you own.