Automation & Programmability
Automation and programmability reflect the shift from configuring devices one by one to driving the network with software. This domain explains controller-based and software-defined networking, the separation of the control and data planes, how REST APIs and JSON let software configure devices, the roles of Ansible, Puppet, and Chef, and Cisco's own DNA Center. The 200-301 exam tests concepts and JSON reading rather than deep coding.
Traditional vs. Controller-Based Networking
In traditional networking every device is autonomous: each router and switch runs its own control plane, makes its own forwarding decisions, and is configured individually through the CLI. This works but scales poorly — a change across a hundred devices means a hundred logins, and manual, per-device edits are slow and error-prone, producing inconsistent configurations and configuration drift over time. Controller-based networking centralizes the intelligence. A controller maintains a complete view of the network and programs many devices from one place, so a single policy can be pushed consistently everywhere. Instead of configuring boxes, operators express intent ("these users get this access") and the controller translates it into the right device configurations. This reduces human error, speeds up changes, and makes the whole network's state visible and auditable from one dashboard. The controller talks to the applications and operators above it through a northbound interface — typically a REST API — and talks down to the network devices through a southbound interface using protocols such as NETCONF, RESTCONF, or OpenFlow. Northbound is "toward the humans/apps," southbound is "toward the devices"; this is a favorite exam distinction. The benefits are consistency, speed, scalability, and better visibility, but there are trade-offs: the controller is a critical component that must be highly available, and teams must learn new tools and APIs. Many networks adopt automation gradually rather than replacing everything at once. Cisco's SDN-style solutions illustrate the model. Cisco DNA Center is the controller for enterprise campus networks, providing intent-based configuration, assurance/analytics, and automation through its northbound REST API; Cisco ACI (with APIC) plays the controller role in the data center. For the 200-301 exam you should understand why controller-based management scales better than device-by-device CLI, the northbound-versus-southbound direction, and that this is the foundation on which SDN and network automation are built.
Software-Defined Networking and Planes
Networking devices operate on three planes, and understanding them is key to SDN. The data plane (forwarding plane) actually moves packets — it looks up the destination and forwards the frame out a port, done in hardware (ASICs) for speed. The control plane is the brain that builds the information the data plane uses: it runs routing protocols like OSPF, STP, ARP, and neighbor discovery to decide how traffic should be handled. The management plane is how humans and tools administer the device — SSH, SNMP, Syslog, NETCONF. SDN (Software-Defined Networking) separates the control plane from the data plane and moves control-plane decision-making off the individual devices into a centralized controller. The devices become simpler forwarders that do what the controller tells them, while the controller holds the network-wide intelligence and programs each device's forwarding tables. This central view enables consistent, programmable, automated behavior that per-device control planes cannot easily achieve. The controller uses a southbound interface to instruct the devices — OpenFlow is the classic example, and NETCONF/RESTCONF are widely used — and exposes a northbound API (usually REST) so applications and orchestration tools can request network services programmatically without knowing device-level details. An application might call the northbound API to say "give this app a low-latency path," and the controller computes and installs the necessary forwarding entries southbound. There are degrees of SDN: fully centralized (the controller owns the control plane, e.g. OpenFlow), and hybrid or overlay models where devices keep some control-plane function but a controller adds automation and policy on top (closer to how Cisco DNA Center and SD-Access work). For the exam, be able to define each of the three planes, state that SDN separates control from data and centralizes control, and identify OpenFlow/NETCONF as southbound and REST as northbound. The payoff is a network that behaves like programmable infrastructure rather than a collection of hand-configured boxes.
REST APIs and Data Formats
A REST API (Representational State Transfer) lets software configure and query devices and controllers over HTTP or HTTPS. It is stateless — each request carries everything needed — and uses standard HTTP methods that map to CRUD operations: GET reads data, POST creates, PUT/PATCH updates, and DELETE removes. Resources are addressed by URIs (e.g. https://dnac/dna/intent/api/v1/network-device), and the server returns HTTP status codes that indicate the result: 200 OK, 201 Created, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Server Error. Authentication is typically a token obtained by first logging in, then included in a header on subsequent calls; API keys and Basic Auth are also seen. Requests and responses carry structured data, most commonly in JSON (JavaScript Object Notation). JSON represents data as key-value pairs inside objects delimited by curly braces { }, with arrays (ordered lists) inside square brackets [ ], and values that are strings (in double quotes), numbers, booleans (true/false), null, or nested objects. A small example: {"device": {"hostname": "R1", "ip": "10.0.0.1", "interfaces": ["Gig0/0", "Gig0/1"], "enabled": true}}. Here "device" maps to an object, "interfaces" maps to an array of two strings, and "enabled" is a boolean. Being able to read this — to say how many interfaces there are, or what the hostname is — is exactly what the exam asks. Two alternative formats appear. XML uses nested tags (<hostname>R1</hostname>) and is used by NETCONF. YAML uses indentation and dashes for lists, is very human-readable, and is the format of Ansible playbooks. All three encode the same kind of structured data; JSON is the most common in REST APIs. For CCNA you do not have to write code, but you should recognize valid JSON syntax (matching braces/brackets, quoted keys, commas between elements), map HTTP methods to their actions, and interpret a JSON response returned by a controller such as DNA Center. That literacy is enough to reason about how automation tools exchange data with the network.
Configuration Management and Cisco DNA Center
Configuration management tools enforce a desired state across many devices automatically and repeatably, replacing hand edits. The three the exam names are Ansible, Puppet, and Chef. The core idea they share is idempotency: you declare the state you want, and running the tool converges devices to that state without making changes if they are already correct, so re-running is safe. They differ in architecture. Ansible is agentless — it needs no software installed on the managed device and pushes configuration over SSH (or network APIs), using human-readable YAML files called playbooks; a central control machine drives the changes (a push model). Because it is agentless and simple, Ansible is popular for network automation. Puppet and Chef traditionally use an agent installed on each managed node that pulls its configuration from a central server (a pull model). Puppet uses a declarative, Ruby-based DSL and describes desired state in "manifests"; Chef uses Ruby "recipes" grouped into "cookbooks" and leans more procedural. A quick contrast: Ansible = agentless, push, YAML; Puppet = agent, pull, manifests; Chef = agent, pull, recipes/cookbooks. These tools reduce configuration drift, cut human error, make deployments consistent and fast, and give you version-controlled, auditable infrastructure-as-code. They are how a team applies one change to hundreds of devices reliably. Cisco DNA Center (DNAC) is Cisco's own controller and automation platform for enterprise networks. It provides a single dashboard for intent-based networking: design (site hierarchy, settings), policy (group-based access with SD-Access), provision (push configuration to devices), and assurance (health analytics and AI-driven troubleshooting). Crucially, it exposes a northbound REST API so external systems can automate against it, and it can integrate with tools like Ansible. On the 200-301 exam, associate DNA Center with intent-based/controller-based networking and its REST API, and be able to contrast the push/pull and agent/agentless nature of Ansible versus Puppet and Chef, plus recognize that all of them deliver consistent, automated, auditable configuration at scale.
Keep going: the full Cisco CCNA 200-301 guide covers every section of the exam. Cisco CCNA 200-301 — Complete Study Guide (2026) — PDF + EPUB, $14.99 · 14-day refund →
Practice stays free. The full Cisco CCNA 200-301 study guide is the material itself, taught start to finish — a downloadable PDF + EPUB you keep.