Overview
Network automation replaces repetitive per-device CLI with programmatic, repeatable changes — scripts, APIs, and templates stored in version control. Controllers centralize policy while devices still forward traffic locally. At CCNA depth you need vocabulary: southbound vs northbound APIs, REST verbs, and how to recognize structured data in JSON, YAML, and XML.
Try hands-on examples in the Automation Sandbox.
Traditional vs controller-based networking
| Traditional | Automated / controller-led |
|---|---|
| Engineer SSH to each device | API or orchestration tool pushes config |
| Config drift over time | Git-tracked intended state |
| Slow at scale | Bulk changes in minutes |
| Copy-paste errors | Validated pipelines |

Traditional device-by-device CLI vs controller-based automation.
Supplementary figure from Panagiss CCNAmd
Automation use cases: initial provisioning, software version control, compliance checks, statistics collection, reporting, and troubleshooting at scale.
A bad script scales mistakes fast. Always test in a lab and validate with show commands after deployment.
Planes of networking
| Plane | Role | Examples |
|---|---|---|
| Data (forwarding) | Forward frames/packets quickly | MAC table lookup, IP routing, ACL apply |
| Control | Build tables the data plane uses | OSPF, EIGRP, STP, ARP |
| Management | Configure and monitor | SSH CLI, HTTPS GUI, SNMP, APIs |
In SDN, control plane intelligence can move to a centralized controller. Devices focus on forwarding; the controller programs behavior via southbound APIs.
Northbound vs southbound APIs
| Direction | Flow | Purpose | Examples |
|---|---|---|---|
| Southbound | Controller → devices | Push config, read state | NETCONF, RESTCONF, SNMP, SSH, OpenFlow |
| Northbound | Applications → controller | Automation apps consume network services | REST APIs on DNA Center, Meraki dashboard API |
Southbound = controller talks down to network devices. Northbound = applications talk up to the controller. Direction questions are very common.
Memory trick: South points down the topology diagram toward switches and routers. North points up toward automation apps and business logic.
Data serialization formats
Automation exchanges structured data between systems. Common plain-text encodings:
| Format | Notes |
|---|---|
| JSON | Lightweight; native to REST; keys in double quotes |
| YAML | Human-friendly; common in Ansible playbooks |
| XML | Verbose; used by NETCONF and many legacy APIs |
YANG is a data modeling language (IETF) describing device configuration and operational state — the schema behind NETCONF/RESTCONF payloads.
REST APIs and HTTP verbs
REST (Representational State Transfer) is an architectural style for web services. RESTful APIs typically run over HTTP and map cleanly to CRUD operations:
| CRUD | HTTP verb | Typical action |
|---|---|---|
| Create | POST | Add new resource (VLAN, policy, user) |
| Read | GET | Retrieve current state |
| Update | PUT / PATCH | Modify existing resource |
| Delete | DELETE | Remove resource |
REST characteristics (know for exam):
- Client/server — front end and back end independent
- Stateless — server stores no client session between requests
- Cacheable — responses may be cached for performance
Each HTTP request includes a URI (resource path) and verb. Example DNA Center workflow: POST a new security policy, GET to verify, PUT to update a setting, DELETE to remove it.
GET https://dna-center/api/v1/network-device POST https://dna-center/api/v1/template PUT https://dna-center/api/v1/template/{id} DELETE https://dna-center/api/v1/template/{id}
! Headers often include: ! Authorization: Bearer <token> ! Content-Type: application/json
REST APIs use tokens or API keys in headers — not passwords in the URL. CCNA tests the concept, not building a full OAuth flow.
JSON structure
JSON (JavaScript Object Notation) is the dominant format for REST payloads. Rules that trip up beginners:
- Keys and string values use double quotes (not single)
- Key/value pairs separated by colons
- Pairs separated by commas — no trailing comma after the last item
- Booleans are lowercase:
true/false nullrepresents empty/absent value
Data types:
| Type | Syntax | Example |
|---|---|---|
| Object | Curly braces {} | {"hostname": "SW1", "vlan": 10} |
| Array | Square brackets [] | ["10.0.0.1", "10.0.0.2"] |
| String | Double quotes | "Corp-WiFi" |
| Number | Unquoted | 24 |
| Boolean | lowercase | true |
| Nested | Objects inside objects | Device with interface list |
JSON device inventory example:
{
"devices": [
{
"hostname": "SW-FLOOR1",
"mgmt_ip": "10.0.0.11",
"vlans": [10, 20, 30],
"enabled": true
},
{
"hostname": "R-BRANCH",
"mgmt_ip": "10.0.0.1",
"ospf_enabled": true
}
]
}
Arrays preserve order; objects are unordered collections of key/value pairs. Automation tools parse JSON to loop over devices and apply templates.
YAML basics
YAML (YAML Ain't Markup Language) is a human-readable format for configuration files. Ansible playbooks and inventory files are written in YAML — you do not need to author complex playbooks for CCNA, but you must recognize valid structure when you see it on the exam.
Core rules:
- Indentation defines structure — use spaces (typically 2); tabs are invalid in strict YAML
- Key: value pairs on one line (
hostname: SW1) - Lists use a leading dash and space (
- 10.0.0.1) - Strings usually need no quotes unless they contain special characters
true/falseand numbers work like JSON booleans and integers
| YAML concept | Syntax | Meaning |
|---|---|---|
| Mapping (object) | Indented keys under a parent | Nested dictionary |
| Sequence (list) | Lines starting with - | Ordered list of items |
| Scalar | Plain text after : | String, number, or boolean |
Ansible inventory example (recognize the shape):
all:
children:
switches:
hosts:
SW-FLOOR1:
ansible_host: 10.0.0.11
SW-FLOOR2:
ansible_host: 10.0.0.12
routers:
hosts:
R-BRANCH:
ansible_host: 10.0.0.1
Minimal playbook fragment:
---
- name: Configure NTP on routers
hosts: routers
tasks:
- name: Set NTP server
ios_config:
lines:
- ntp server 10.1.1.1
Wrong indentation in YAML changes meaning — a task pushed under the wrong parent key may never run. Compare indentation columns when reading a snippet.
Same data, three formats (recognition drill):
| Format | Example for VLAN 10 named SALES |
|---|---|
| JSON | {"vlan-id": 10, "name": "SALES"} |
| YAML | vlan-id: 10 then indented name: SALES on the next line |
| XML | <vlan><id>10</id><name>SALES</name></vlan> |
XML basics
XML (eXtensible Markup Language) is a tag-based, hierarchical format. It is more verbose than JSON or YAML but maps cleanly to schemas — important for NETCONF, where requests and replies are XML RPCs described by DTDs or schemas.
Core rules (recognize, don't memorize every attribute):
- Every element has opening and closing tags:
<hostname>SW1</hostname> - Elements nest to show hierarchy (like indented YAML)
- Attributes sit inside the opening tag:
<interface name="GigabitEthernet0/1"> - One root element wraps the whole document
- Case-sensitive tag names
| XML piece | Example | Role |
|---|---|---|
| Element | <vlan>...</vlan> | Named container |
| Child element | <id>10</id> | Value inside parent |
| Attribute | <rpc message-id="101"> | Metadata on a tag |
NETCONF-style RPC (simplified — recognize the envelope):
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
jdepew88 REST APIs notes: NETCONF clients send an RPC in XML over a secure session; the server replies in XML. Both sides agree on syntax limits via XML schemas — that is why XML persists in network device APIs even when northbound REST prefers JSON.
JSON — REST APIs (DNA Center, Meraki). YAML — Ansible playbooks and inventory. XML — NETCONF southbound RPCs. RESTCONF — JSON or XML (JSON is more common on modern controllers).
NETCONF and RESTCONF (awareness)
| Protocol | Transport | Data format | CCNA depth |
|---|---|---|---|
| NETCONF | SSH (mandatory) | XML RPCs | Device configuration API; RFC 6241 |
| RESTCONF | HTTP | JSON or XML | RESTful access to YANG datastores; RFC 8040 |
NETCONF layers: secure transport → messages → operations → content (YANG models).
SNMP remains relevant for monitoring and traps, but NETCONF/RESTCONF improve structured configuration compared to SNMP SET operations.
Configuration management tools
| Tool | Model | CCNA note |
|---|---|---|
| Ansible | Agentless; SSH/API; YAML playbooks | Week 10 overview |
| Puppet / Chef | Agent or agentless patterns | Know names and purpose |
| Python scripts | Custom automation | Often calls REST or NETCONF |
Infrastructure as Code (IaC): Store playbooks, templates, and inventory in Git — review, rollback, and audit like application code.
Automation workflow (step-by-step)
Goal: ensure NTP is configured on 20 routers.
- Inventory — YAML/JSON list of device IPs and credentials (vault-encrypted)
- Template — Jinja template:
ntp server {{ ntp_ip }} - Tool — Ansible playbook loops inventory and pushes config
- Validate —
show ntp statuson sample devices - Version control — commit playbook to Git
You won't build a full CI/CD pipeline on the CCNA exam — but you will recognize the pattern and vocabulary.
Practice on this site
The Automation Sandbox covers:
- Northbound vs southbound direction
- REST verb to CRUD mapping
- JSON, YAML, and XML syntax recognition
- Ansible and Terraform awareness quizzes
Automation complements — does not replace — CLI troubleshooting. CCNA expects you to read show output and verify changes.
Exam checklist
- Define southbound vs northbound and give one example each
- Map HTTP GET/POST/PUT/DELETE to CRUD
- Identify valid vs invalid JSON (quotes, trailing commas, booleans)
- Recognize YAML — indentation,
key: value, list items with- - Recognize XML — nested tags, opening/closing pairs, NETCONF RPC envelope
- Match format to tool: JSON (REST), YAML (Ansible), XML (NETCONF)
- Explain why controllers help at scale without removing distributed forwarding