YAML Data Format

YAML (YAML Ain't Markup Language) is a data serialization language designed for human readability. It is commonly used for configuration files, data exchange, and defining automation workflows. YAML structures data using indentation (spaces) to denote hierarchy, making it visually clean compared to JSON or XML. The CCNA 200-301 exam expects you to understand YAML's basic syntax, data types, and how it is used in network automation contexts like Ansible playbooks.

Before YAML, configuration files often used INI, XML, or JSON. XML is verbose; JSON, while lighter, still uses braces and quotes that can be hard to read for large configurations. YAML was created to be a superset of JSON (meaning valid JSON is valid YAML) but with a more human-friendly syntax. For network automation, YAML is the default format for Ansible—a tool Cisco heavily promotes for managing network devices at scale. The exam objective 6.4 explicitly lists YAML alongside JSON and Ansible, so you must be able to read and write basic YAML.

YAML files use three primary constructs: - Scalars: single values (strings, numbers, booleans, null). - Sequences (lists): ordered items prefixed with dashes (-). - Mappings (dictionaries): key-value pairs using a colon and space (key: value).

Indentation is critical: YAML uses spaces (not tabs) to indicate nesting. The number of spaces must be consistent within the same file (commonly 2 spaces per level). Comments start with # and are ignored by the parser.

#### Example: A Simple Playbook Fragment

---
- name: Configure interfaces
  hosts: routers
  vars:
    dns_server: 8.8.8.8
    ntp_server: 192.168.1.10
  tasks:
    - name: Set DNS server
      ios_config:
        lines:
          - ip name-server {{ dns_server }}
    - name: Set NTP server
      ios_config:
        lines:
          - ntp server {{ ntp_server }}

In this example: - --- indicates the start of a YAML document (optional). - hosts, vars, tasks are keys in a mapping. - - name: Configure interfaces starts a sequence (the list of plays). - vars is a mapping containing dns_server and ntp_server. - tasks is a sequence of dictionaries, each with a name and module (e.g., ios_config). - lines is a list of commands to apply. - {{ dns_server }} is a Jinja2 template variable (not pure YAML, but commonly used with Ansible).

YAML supports several data types: - Strings: can be quoted (single or double) or unquoted if no special characters. For example: name: "Router 1" or simply name: Router 1. - Numbers: integer or floating-point: port: 22, timeout: 30.5. - Booleans: true/false, yes/no, on/off: enabled: true. - Null: ~ or nothing: description: (empty value). - Lists: - item1 - Dictionaries: key: value

YAML provides two ways to handle multi-line strings: - Literal block scalar (|): preserves newlines. - Folded block scalar (>): folds newlines to spaces.

Example:

banner: |
  This is a banner
  that spans multiple lines.

This results in the string "This is a banner that spans multiple lines. ".

YAML allows reusing data with anchors (&) and aliases (*). This is useful for DRY (Don't Repeat Yourself) configurations.

defaults: &defaults
  timeout: 30
  retries: 3

server1:
  <<: *defaults
  host: 10.1.1.1

Here, server1 merges the defaults mapping and adds host. The << key is a merge key (not standard YAML but supported by many parsers).

In network automation, YAML files are typically used as: - Inventory files: list of hosts and groups. - Variable files: define device-specific or group-specific variables. - Playbooks: define the automation workflow (tasks to execute).

Ansible, for example, reads YAML playbooks and executes tasks on network devices via modules like ios_config, ios_command, etc. The YAML structure defines the order and parameters of these tasks. Understanding YAML is therefore prerequisite to using Ansible effectively.

You will not be asked to write YAML from scratch on the exam, but you will need to:

Example exam-like question: "Which of the following is valid YAML?" with options containing tab indentation or missing spaces.

Correct answer would be the one using consistent spaces and proper syntax.

A network engineer at a mid-size enterprise manages 50 Cisco routers across multiple sites. Manually configuring each router for a new DNS server is tedious and error-prone. They decide to use Ansible with a YAML playbook. The inventory file (hosts.yml) is written in YAML:

all:
  hosts:
    router1:
      ansible_host: 10.1.1.1
    router2:
      ansible_host: 10.2.2.2
  vars:
    dns_server: 8.8.8.8

The playbook (config.yml) uses the ios_config module to apply the DNS configuration:

- name: Configure DNS
  hosts: all
  gather_facts: no
  tasks:
    - name: Set DNS server
      ios_config:
        lines:
          - ip name-server {{ dns_server }}

Running ansible-playbook -i hosts.yml config.yml pushes the command to all routers. The engineer saves hours and eliminates typos. YAML's readability makes it easy to audit the playbook before execution. If a syntax error occurs (e.g., missing space after colon), Ansible will fail with a parse error, prompting the engineer to fix the YAML.

A service provider uses Ansible to manage hundreds of devices. They store device-specific parameters in YAML variable files. For example, group_vars/routers.yml contains:

snmp_community: public
ntp_servers:
  - 192.168.1.10
  - 192.168.1.11

And host_vars/router3.yml overrides the SNMP community:

snmp_community: private

When Ansible runs, it merges variables in a specific order (group vars, then host vars). The YAML structure allows clear separation of common and specific configurations. A mis-indentation in these files could cause variables to be ignored or misapplied, leading to configuration drift. For example, if ntp_servers is accidentally indented under snmp_community, the NTP servers would not be applied. Engineers use YAML linters (e.g., yamllint) to validate syntax before deployment.

A DevOps team integrates network configuration into a CI/CD pipeline using GitLab. Developers submit changes to a YAML-based configuration template. The pipeline runs Ansible to push changes to a staging network, then after approval, to production. YAML's simplicity enables non-network engineers to review changes via merge requests. If a developer accidentally uses a tab instead of spaces, the pipeline fails early, preventing misconfiguration. The team also uses YAML anchors to define common ACL rules that are reused across multiple devices, reducing duplication.