YAML vs JSON in Network Automation: A Complete Guide for CCNA DevNet Professionals

If you are studying for your CCNA DevNet certification or stepping into the world of network automation, you already know that JSON (JavaScript Object Notation) is everywhere. APIs use it, Python scripts parse it, and controllers like Cisco DNA Center rely on it.

But as you dive deeper into tools like Ansible or write complex configuration files, you will encounter another major player: YAML.

In this guide, we will break down what YAML is, how its structure works, and exactly how it compares to JSON so you can master both for your NetDevOps career.

---

What is YAML?

YAML stands for “YAML Ain’t Markup Language” (a recursive acronym).

From the very beginning, YAML was designed with one primary goal: to be highly human-readable. It was specifically created to work well for configuration files and log files. When data is easy for a human eye to scan and understand, configuring network devices and writing automation playbooks becomes a much simpler task.

The Main Design Goals of YAML

According to its creators, YAML was built to:

• Be easily readable by humans.

• Be portable between different programming languages.

• Match the native data structures of modern programming languages (like Python dictionaries and lists).

• Have a consistent model to support generic tools.

• Be expressive and extensible.

• Be easy to implement and use.

---

The Big Showdown: YAML vs JSON

Both JSON and YAML share a common goal: they format data so it can be read by both humans and machines. However, they have completely different priorities.

JSON’s Priority: Universality and Speed

JSON’s foremost design goal is universality. It is trivial for a computer to generate and parse JSON, but it does this at the cost of some human readability. JSON uses a lot of syntax (curly braces {}, square brackets [], and quotes "") to ensure that any programming environment can process it flawlessly and quickly.

YAML’s Priority: Human Readability

YAML’s foremost design goal is you—the human. YAML strips away the heavy punctuation of JSON, allowing for extremely clean, readable files. Because of its human-friendliness, YAML has become the undisputed king of configuration files in Network Automation and SDN (Software-Defined Networking) products (most notably, Ansible). The trade-off? YAML is slightly more complex for a machine to parse and generate compared to JSON.

Quick Comparison Table

Feature	JSON	YAML
Primary Goal	Machine parsing speed & universality	Human readability
Syntax	Uses brackets {}, [] and quotes ""	Uses indentation and whitespaces
Comments	Not supported natively	Fully supported (using #)
Best Used For	API Payloads (REST APIs)	Configuration files (Ansible, Kubernetes)

XML based prompt Engineering

XML DOM explained

XML Basics

Understanding YAML Structure and Syntax

If you take away one rule about YAML, let it be this: Indentation matters.

Unlike JSON, which relies on brackets to group data, YAML uses spaces.

• Whitespaces are syntax: Unless stated otherwise, the end of a line indicates the end of a field.

• Indentation defines structure: Indentation is defined as zero or more space characters at the start of a line.

• NO TABS ALLOWED: You must use spaces (usually 2 spaces per level). Tabs should never be used because different text editors and parsers treat tabs differently, which will break your script.

• Parent/Child Nodes: Each child node must be indented further than its parent node. All sibling nodes (items at the same level) must use the exact same indentation level.

YAML’s indentation nesting is a very simple but incredibly powerful way to build sophisticated data objects.

---

Real-World Examples: JSON vs YAML for Network Engineers

Let's look at how the exact same network data is represented in both JSON and YAML to see how YAML's indentation works in practice.

Example 1: A Simple Router Configuration

Here is a standard data object representing a router.

The JSON Way:

JSON

{
  "router1": {
    "address": "10.1.1.1",
    "operational": true,
    "uptime": 46701,
    "interfaces": [
      "GigabitEthernet0/1",
      "GigabitEthernet0/2",
      "GigabitEthernet0/3"
    ]
  }
}

The YAML Way:

YAML

--
router1:
  address: 10.1.1.1
  operational: true
  uptime: 46701
  interfaces:
    - GigabitEthernet0/1
    - GigabitEthernet0/2
    - GigabitEthernet0/3

• Explanation: Notice how YAML drops all the quotes around the keys and values. The --- at the top simply denotes the start of a YAML document. The JSON array (list of interfaces) is replaced in YAML by a simple bulleted list using dashes -.

Example 2: Configuring Multiple VLANs (List of Dictionaries)

In DevNet, you often deal with lists of complex objects.

The JSON Way:

JSON

{
  "vlans": [
    {
      "vlan_id": 10,
      "name": "Management",
      "active": true
    },
    {
      "vlan_id": 20,
      "name": "Engineering",
      "active": true
    }
  ]
}

The YAML Way:

YAML

---
vlans:
  - vlan_id: 10
    name: Management
    active: true
  - vlan_id: 20
    name: Engineering
    active: true

• Explanation: In YAML, the dash - indicates a new item in a list. Because vlan_id, name, and active are indented evenly under the dash, the YAML parser knows they all belong to that specific list item. It is significantly faster to read and write than the JSON equivalent!

---

Both JSON and YAML are indispensable skills for a CCNA DevNet professional. You will use JSON to talk to APIs, and you will use YAML to write your infrastructure-as-code configurations.