How Automation Changes Network Management
Traditional network management means an engineer logging into each device over SSH and typing commands, which is slow, inconsistent between devices and almost impossible to audit at scale. Automation replaces that with defined intent expressed in machine-readable files or API calls, applied identically to every device. The benefits are consistency, because the same source of truth produces the same configuration everywhere; speed, because deploying to five hundred devices takes as long as deploying to one; and reduced human error, because a reviewed and version-controlled change is repeatable. It also enables real testing before deployment, since configurations can be validated in a virtual lab first. The costs are equally real: engineers need scripting and data format skills, an automation error propagates to the whole estate in seconds rather than to one device, and the tooling itself has to be maintained and secured. Automation does not eliminate network engineering; it moves the work from typing commands to designing and reviewing the intent behind them.
Exam tip. The exam wants the trade-off, not just the benefits. Automation gives consistency and speed but concentrates risk, since one bad change reaches every device immediately.
Traditional versus Controller-Based Networking
In a traditional network every device runs its own control plane: it builds its own routing and MAC tables, makes its own decisions, and is configured individually. That distributed model is resilient but means the network has no single place that understands the whole topology or the whole policy. Controller-based networking centralises the control plane in a controller that holds a complete view of the network and pushes forwarding and policy decisions down to devices, which retain their data plane and keep forwarding packets at hardware speed. The result is that policy is expressed once, centrally, and applied everywhere consistently, and that the controller can expose the whole network through a single API instead of hundreds of CLI sessions. The trade-off is a dependency on the controller and the need to design for its availability. On the CCNA you should be able to place each function in the right plane: control plane builds the tables, data plane forwards using them, and management plane is how humans and systems interact with the device.
Exam tip. Be able to sort a given function into control, data or management plane. Routing protocol calculation is control plane, forwarding a packet is data plane, and SSH or SNMP access is management plane.
Software-Defined Architecture: Northbound and Southbound APIs
A software-defined architecture is built around a controller sitting between the applications that express what the network should do and the devices that carry it out. Interfaces above the controller are northbound: these are the APIs that applications, orchestration systems and scripts use to ask for outcomes, and they are normally REST APIs exchanging JSON over HTTPS. Interfaces below the controller are southbound: these are the protocols the controller uses to program devices, including NETCONF over SSH, RESTCONF, OpenFlow, SNMP and even plain CLI in some implementations. The direction naming is easy once you picture the controller in the middle of a stack with applications drawn above and infrastructure below. Cisco's implementation for the campus is Catalyst Center, previously named Cisco DNA Center, which discovers devices, holds intent-based policy expressed in terms of users and applications rather than VLANs and ACLs, provisions it, and continuously monitors whether the network is delivering it, a loop called assurance.
Exam tip. Northbound and southbound are defined relative to the controller, not to any device. NETCONF and RESTCONF are southbound; a REST call from a script into the controller is northbound.
Underlay, Overlay and Network Fabrics
Modern controller-based designs separate the physical network from the logical one. The underlay is the physical topology and the routing that makes every device reachable from every other, typically a simple routed design whose only job is to move encapsulated packets reliably with no policy attached. The overlay is a set of virtual networks built on top by tunnelling traffic between edge devices, most often with VXLAN, so that logical segments can span the whole site without stretching VLANs across it. The fabric is the combination of the two together with the controller that manages them. In Cisco's software-defined access model the edge nodes attach users, border nodes connect the fabric to the outside world, and a control plane node holds the mapping of endpoint identity to location so traffic can be tunnelled directly. This split is what allows segmentation policy to follow a user regardless of which switch port they plug into, which is very hard to achieve with VLANs and ACLs alone.
Exam tip. Keep the split clear: the underlay only provides reachability between fabric nodes, while the overlay carries the user traffic and the policy. VXLAN is the overlay encapsulation to recognise.
REST API Characteristics, Verbs and Response Codes
A REST API exposes resources at URIs and manipulates them with standard HTTP methods, which maps neatly onto the four CRUD operations: POST creates, GET reads, PUT and PATCH update, and DELETE removes. REST is stateless, meaning each request carries everything the server needs and the server keeps no session context between calls, which is what allows requests to be load balanced across many servers. Requests and responses normally carry JSON, indicated by a Content-Type header, and authentication is handled by a header too, commonly an API key, a bearer token or basic credentials, with the whole exchange protected by HTTPS. The response code tells you what happened by class: 2xx succeeded, 3xx redirected, 4xx means your request was wrong, and 5xx means the server failed. Reading the code before the body is the fastest way to debug an API call, since 401 points at credentials, 403 at permissions and 404 at a wrong URI.
Exam tip. Know the verb to CRUD mapping and the code classes cold. 401 means authentication failed, 403 means you authenticated but are not allowed, and 404 means the URI is wrong.
Reading JSON, XML and YAML Data
Automation depends on structured data, and the CCNA expects you to recognise the three common encodings and read their contents accurately. JSON is the most important: data is written as objects in curly braces containing key and value pairs, and as arrays in square brackets containing an ordered list of values. Keys are always double-quoted strings, values may be strings, numbers, booleans, null, another object or an array, pairs are separated by commas, and there is no trailing comma after the last one. Nesting is what trips people up, so read from the outside in and count brackets: a value that begins with a square bracket is a list, and a value beginning with a curly brace is another object. XML wraps every value in matching opening and closing tags and is what NETCONF uses, and YAML uses indentation instead of brackets, with a hyphen introducing each list item, which is why it is the format Ansible playbooks are written in. All three represent the same kinds of structure; only the punctuation differs.
Exam tip. Expect to be shown a JSON snippet and asked for a specific value or whether the syntax is valid. Check that every key is quoted, that there is no trailing comma, and that brackets and braces are balanced.
Configuration Management with Ansible, Puppet and Chef
Configuration management tools define the desired state of systems in files and then make reality match those files, which is a fundamentally different approach from running scripts of commands. Ansible is agentless, connecting over SSH or an API, and its playbooks are written in YAML with an inventory listing the target devices; because there is nothing to install on the managed device it is by far the most common choice in networking. Puppet uses manifests written in its own declarative domain-specific language and normally relies on an agent installed on each managed node that pulls its catalogue from a Puppet primary server, though Puppet does offer an agentless option for network devices. Chef uses recipes grouped into cookbooks, written in a Ruby-based language, and also uses an agent that pulls from a Chef server. The recurring exam distinctions are agent versus agentless, push versus pull, and which file names and languages belong to which tool.
Exam tip. The single fact most often tested is that Ansible is agentless and push-based using YAML, while Puppet and Chef normally use agents that pull. Match the file name to the tool and you will get these right.
AI and Machine Learning in Network Operations
Networks now generate far more telemetry than any team can read, so machine learning is used to find patterns in it. In network operations, sometimes called AIOps, models establish a baseline of what normal looks like for each site, interface and application, and then flag deviations as anomalies instead of relying on fixed thresholds that are wrong half the time. That supports predictive maintenance, where a slowly degrading optic or a rising error rate is raised before it causes an outage, and it supports correlation, where hundreds of alarms produced by one root cause are collapsed into a single actionable finding. It is worth separating the terms: predictive AI classifies and forecasts from historical data, which is what assurance platforms mostly use, while generative AI produces new content such as configuration snippets or plain-language explanations of an incident. Machine learning is a subset of artificial intelligence in which models learn from data rather than being explicitly programmed, and deep learning is a subset of machine learning using layered neural networks. None of this removes the need for engineering judgement, because models produce confidence levels rather than certainties and can be wrong in ways that are hard to see.
Exam tip. Keep the hierarchy straight: deep learning sits inside machine learning, which sits inside artificial intelligence. Predictive AI forecasts from past data while generative AI creates new content, and assurance platforms are mostly doing the former.