1.0_Foundation_Deep_Dive

Practice Questions

Test your knowledge on this topic in the ENAUTO Exam Trainer — 186 questions across 5 interactive modes.

Network Automation Foundation — Deep Dive for ENAUTO v2.0

Exam Relevance

Topic 1.0 Network Automation Foundation (10%) provides the conceptual backbone for all device-level automation in Topics 2.0 and 4.0. Mastering YANG, NETCONF, and RESTCONF here unlocks every controller API and device-level script in the rest of the exam.

Exam Topics Covered:
1.1 – Compare data models (IETF, OpenConfig, native)
1.2 – Describe NETCONF and RESTCONF
1.3 – Describe YANG Suite and pyang
1.4 – Construct JSON/XML payloads from YANG models
1.5 – Interpret a YANG module tree diagram (RFC 8340)

---

Table of Contents

• 1 – YANG Data Models Overview (Exam Topic 1.1)
• 2 – NETCONF vs RESTCONF (Exam Topic 1.2)
• 3 – YANG Suite and pyang (Exam Topics 1.3, 1.4)
• 4 – RFC 8340 YANG Tree Diagrams (Exam Topic 1.5)
• 5 – Putting It All Together — YANG to API Call Workflow
• 6 – Common Patterns and Gotchas
• 7 – Exam-Style Scenarios
• 8 – Quick Reference Cheat Sheet

---

1 – YANG Data Models Overview (Exam Topic 1.1)

What is YANG?

YANG (Yet Another Next Generation) is a data modeling language defined in RFC 7950. It does not carry data itself — it defines the structure, constraints, and semantics of configuration and operational data that protocols like NETCONF and RESTCONF transport.

Think of YANG as the schema (like a database DDL) while NETCONF/RESTCONF are the query languages (like SQL).

┌───────────────────────────────────────────┐
│              YANG Model                   │
│  (defines what data looks like)           │
│  RFC 7950                                 │
└──────────────┬────────────────────────────┘
               │ describes structure for
       ┌───────┴───────┐
       ▼               ▼
┌─────────────┐ ┌─────────────┐
│  NETCONF    │ │  RESTCONF   │
│  RFC 6241   │ │  RFC 8040   │
│  XML        │ │  JSON / XML │
│  SSH :830   │ │  HTTPS :443 │
└─────────────┘ └─────────────┘

Key YANG Concepts

Concept	Description	Example
module	Top-level unit; one model = one module	module ietf-interfaces
container	Grouping node (like a folder) — maps to JSON object / XML element	container interfaces
list	Ordered collection with a key — maps to JSON array	list interface with key "name"
leaf	Single scalar value — maps to JSON key-value	leaf name { type string; }
leaf-list	Array of scalar values	leaf-list dns-server { type inet:ipv4-address; }
choice	Mutually exclusive branches	choice address-type { case ipv4 {...} case ipv6 {...} }
augment	Extend another module’s tree	ietf-ip augments ietf-interfaces
deviation	Vendor declares “I implement this differently”	Device does not support a leaf
grouping	Reusable set of nodes (like a macro)	grouping address-family { ... }
typedef	Custom type definition	typedef percent { type uint8 { range "0..100"; } }

Exam Tip

augment adds nodes to another module’s tree. deviation modifies or removes nodes a vendor cannot support. Both are commonly tested.

Three Families of YANG Models

IETF Models (Standards-Track)

• Defined by IETF working groups, published as RFCs
• Namespace: urn:ietf:params:xml:ns:yang:*
• Vendor-neutral, widely supported across platforms
• Narrow scope — one model per feature (interfaces, routing, ACLs)
• Key models:
  • ietf-interfaces (RFC 8343) — interface configuration
  • ietf-ip (RFC 8344) — IPv4/IPv6 address configuration (augments ietf-interfaces)
  • ietf-routing (RFC 8349) — routing tables and RIBs
  • ietf-yang-library (RFC 7895) — lists YANG models a device supports

OpenConfig Models (Industry Consortium)

• Created by network operators (Google, Facebook, Microsoft, etc.)
• Namespace: http://openconfig.net/yang/...
• More opinionated than IETF — designed for operational automation at scale
• Uses augment and deviation to handle vendor differences
• Separates config and state containers within each model
• Key models:
  • openconfig-interfaces — interface config and state
  • openconfig-network-instance — VRFs, routing instances
  • openconfig-bgp — BGP configuration
  • openconfig-vlan — VLAN management

Native Models (Vendor-Specific)

• Created by the device vendor (Cisco, Juniper, Arista, etc.)
• Namespace: http://cisco.com/ns/yang/...
• Full feature coverage — every CLI knob has a YANG equivalent
• Vendor lock-in: not portable across platforms
• Key Cisco models:
  • Cisco-IOS-XE-native — maps the entire IOS-XE CLI
  • Cisco-IOS-XE-bgp — BGP-specific config
  • Cisco-IOS-XE-interfaces-oper — operational interface data
  • Cisco-IOS-XR-* — IOS-XR platform models

Comparison Table: IETF vs OpenConfig vs Native

Aspect	IETF	OpenConfig	Native (Cisco)
Scope	Narrow, per-feature	Broad, operational focus	Complete device config
Portability	High	High	Low (vendor-specific)
Feature depth	Basic	Moderate	Full
Namespace	urn:ietf:params:xml:ns:yang:*	http://openconfig.net/yang/*	http://cisco.com/ns/yang/*
Example model	ietf-interfaces	openconfig-interfaces	Cisco-IOS-XE-native
Config/state	Separate trees	Inline (config + state containers)	Mixed
Governance	IETF RFCs	Operator consortium	Vendor internal
Best for	Standards compliance	Multi-vendor ops	Full vendor features

Exam Trap

The exam may ask you to identify which model family a namespace belongs to. Remember the prefixes:

• urn:ietf:... = IETF
• http://openconfig.net/... = OpenConfig
• http://cisco.com/ns/... = Native Cisco

---

2 – NETCONF vs RESTCONF (Exam Topic 1.2)

NETCONF (RFC 6241)

NETCONF is a session-based protocol for managing network device configuration. It runs over SSH on port 830 and uses XML exclusively.

Protocol Flow

Client                                 Device (NETCONF Server)
  │                                         │
  │──── SSH connect (port 830) ────────────▶│
  │◀─── <hello> (server capabilities) ─────│
  │──── <hello> (client capabilities) ─────▶│
  │                                         │
  │──── <rpc> <get-config> ... </rpc> ─────▶│
  │◀─── <rpc-reply> <data> ... </rpc-reply> │
  │                                         │
  │──── <rpc> <edit-config> ... </rpc> ────▶│
  │◀─── <rpc-reply> <ok/> </rpc-reply> ────│
  │                                         │
  │──── <close-session/> ─────────────────▶│
  │◀─── <ok/> ─────────────────────────────│

NETCONF Operations

Operation	Purpose
<get>	Retrieve running config and operational state
<get-config>	Retrieve config from a specific datastore
<edit-config>	Modify config (merge, replace, create, delete, remove)
<copy-config>	Copy entire config between datastores
<delete-config>	Delete a datastore (not running)
<lock> / <unlock>	Lock a datastore to prevent concurrent edits
<commit>	Apply candidate config to running (if candidate supported)
<validate>	Validate config without applying
<close-session>	Gracefully end session
<kill-session>	Terminate another session

Datastores

┌──────────────┐    commit     ┌──────────────┐   copy-config  ┌──────────────┐
│   candidate  │ ────────────▶ │   running    │ ─────────────▶ │   startup    │
│  (staging)   │               │  (active)    │                │  (boot)      │
└──────────────┘               └──────────────┘                └──────────────┘

Candidate Config

The candidate datastore lets you stage changes and validate them before committing. Not all devices support it — check the <hello> capabilities exchange for :candidate.

Filtering

Subtree filter (default, RFC 6241):

<get-config>
  <source><running/></source>
  <filter type="subtree">
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>GigabitEthernet1</name>
      </interface>
    </interfaces>
  </filter>
</get-config>

XPath filter (requires :xpath capability):

<get-config>
  <source><running/></source>
  <filter type="xpath" select="/interfaces/interface[name='GigabitEthernet1']"/>
</get-config>

Python Example with ncclient

from ncclient import manager
 
with manager.connect(
    host="10.10.20.48",
    port=830,
    username="developer",
    password="C1sco12345",
    hostkey_verify=False
) as m:
    # Get all interfaces
    filter_xml = """
    <filter>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
    """
    response = m.get_config(source="running", filter=filter_xml)
    print(response)

---

RESTCONF (RFC 8040)

RESTCONF maps YANG data models to a RESTful API over HTTPS (port 443). It supports both JSON and XML encoding.

URL Structure

https://{device}/restconf/data/{module}:{container}/{list}={key}

Example paths:

GET  /restconf/data/ietf-interfaces:interfaces
GET  /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
GET  /restconf/data/Cisco-IOS-XE-native:native/interface/Loopback=100

HTTP Method Mapping

HTTP Method	RESTCONF Operation	NETCONF Equivalent
GET	Read data	<get> / <get-config>
POST	Create new resource	<edit-config> (operation=“create”)
PUT	Create or replace resource	<edit-config> (operation=“replace”)
PATCH	Merge/update resource	<edit-config> (operation=“merge”)
DELETE	Remove resource	<edit-config> (operation=“delete”)

POST vs PUT vs PATCH

• POST = create only, fails if resource exists (409 Conflict)
• PUT = create or replace entire resource
• PATCH = merge changes into existing resource (safest for updates)

The exam frequently tests this distinction.

Content-Type Headers

Format	Content-Type	Accept
JSON	application/yang-data+json	application/yang-data+json
XML	application/yang-data+xml	application/yang-data+xml

Discovery

RESTCONF root is discovered via /.well-known/host-meta:

curl -k https://10.10.20.48/.well-known/host-meta

Returns:

<XRD>
  <Link rel="restconf" href="/restconf"/>
</XRD>

Python Example with requests

import requests
import urllib3
urllib3.disable_warnings()
 
BASE_URL = "https://10.10.20.48/restconf/data"
HEADERS = {
    "Accept": "application/yang-data+json",
    "Content-Type": "application/yang-data+json"
}
AUTH = ("developer", "C1sco12345")
 
# GET all interfaces (IETF model)
response = requests.get(
    f"{BASE_URL}/ietf-interfaces:interfaces",
    headers=HEADERS,
    auth=AUTH,
    verify=False
)
print(response.json())
 
# PATCH — update interface description
payload = {
    "ietf-interfaces:interface": {
        "name": "Loopback100",
        "description": "Updated by RESTCONF"
    }
}
response = requests.patch(
    f"{BASE_URL}/ietf-interfaces:interfaces/interface=Loopback100",
    headers=HEADERS,
    auth=AUTH,
    json=payload,
    verify=False
)
print(response.status_code)  # 204 = success

---

NETCONF vs RESTCONF Comparison

Feature	NETCONF	RESTCONF
Transport	SSH :830	HTTPS :443
Encoding	XML only	JSON or XML
Operations	RPC-based (<rpc>)	HTTP methods (GET/POST/PUT/PATCH/DELETE)
Filtering	Subtree + XPath	URL query params (?fields=, ?depth=)
Candidate config	Yes (if supported)	No
Locking	Yes (<lock> / <unlock>)	No
Notifications	Yes (RFC 5277, <notification>)	Yes (SSE streams, RFC 8040 Sec. 6)
Transaction	Full (<commit> / <discard-changes>)	Per-operation
Bulk operations	Yes (single <edit-config> with multiple changes)	Limited
Session	Persistent SSH session	Stateless HTTP
Authentication	SSH keys / password	HTTP Basic / token
Best for	Complex transactions, bulk changes	Simple CRUD, CI/CD integrations

When to Use Which?

• NETCONF when you need candidate config, locking, or atomic multi-device transactions
• RESTCONF when you want JSON, quick integrations, or already have HTTP tooling
• Both use the same YANG models — the payload structure is identical, just different encoding

---

3 – YANG Suite and pyang (Exam Topics 1.3, 1.4)

YANG Suite

YANG Suite is Cisco’s GUI tool for exploring YANG models, constructing RPC payloads, and testing them against live devices.

Installation (Docker)

# Clone the official repository
git clone https://github.com/CiscoDevNet/yangsuite.git
cd yangsuite/docker
 
# Start YANG Suite
docker-compose up -d
 
# Access at https://localhost:8443

Workflow

1. Add YANG Repository     →  Upload .yang files or pull from device
2. Browse Models           →  Explore tree structure in the GUI
3. Build RPC Payload       →  Click nodes to construct XML/JSON
4. Select Protocol         →  NETCONF or RESTCONF
5. Connect to Device       →  Enter credentials and execute
6. View Response           →  See device output in the GUI

YANG Suite for Payload Construction

YANG Suite can generate both JSON and XML payloads by clicking through the model tree. This is the fastest way to build correct payloads without manually parsing YANG files.

Using YANG Suite to Construct a JSON Payload

1. Navigate to Protocols > RESTCONF in the sidebar
2. Select the YANG model (e.g., ietf-interfaces)
3. Expand the tree and check the nodes you need
4. Fill in values for leaves (e.g., name = Loopback100)
5. Click Build JSON — the tool generates the correct payload
6. Copy and use in your Python script

Using YANG Suite to Construct an XML Payload

1. Navigate to Protocols > NETCONF
2. Select the YANG model and expand the tree
3. Check desired nodes, fill in leaf values
4. Click Build RPC — generates a complete <edit-config> or <get-config> XML
5. Optionally execute directly against a connected device

---

pyang

pyang is a command-line tool for validating, transforming, and visualizing YANG models.

Installation

pip install pyang

Key Commands

# Generate human-readable tree view (most common)
pyang -f tree ietf-interfaces.yang
 
# Tree view with augmentations from ietf-ip
pyang -f tree ietf-interfaces.yang ietf-ip.yang
 
# Limit tree depth
pyang -f tree --tree-depth 3 Cisco-IOS-XE-native.yang
 
# Filter tree to a specific path
pyang -f tree --tree-path /interfaces/interface ietf-interfaces.yang
 
# Generate HTML tree (interactive)
pyang -f jstree -o interfaces.html ietf-interfaces.yang
 
# Generate XML skeleton payload
pyang -f sample-xml-skeleton ietf-interfaces.yang
 
# Validate model strictly
pyang --strict --lint ietf-interfaces.yang
 
# Show module dependencies
pyang -f depend ietf-interfaces.yang
 
# List all modules in a repository
pyang -f name *.yang

Example: pyang Tree Output

$ pyang -f tree ietf-interfaces.yang ietf-ip.yang

module: ietf-interfaces
  +--rw interfaces
  |  +--rw interface* [name]
  |     +--rw name                        string
  |     +--rw description?                string
  |     +--rw type                        identityref
  |     +--rw enabled?                    boolean
  |     +--ro admin-status                enumeration
  |     +--ro oper-status                 enumeration
  |     +--ro if-index                    int32
  |     +--rw ietf-ip:ipv4!
  |     |  +--rw ietf-ip:enabled?         boolean
  |     |  +--rw ietf-ip:forwarding?      boolean
  |     |  +--rw ietf-ip:address* [ip]
  |     |     +--rw ietf-ip:ip            inet:ipv4-address
  |     |     +--rw (ietf-ip:subnet)
  |     |        +--:(ietf-ip:prefix-length)
  |     |        |  +--rw ietf-ip:prefix-length?   uint8
  |     |        +--:(ietf-ip:netmask)
  |     |           +--rw ietf-ip:netmask?          yang:dotted-quad
  |     +--rw ietf-ip:ipv6!
  |        +--rw ietf-ip:enabled?         boolean
  |        +--rw ietf-ip:forwarding?      boolean
  |        +--rw ietf-ip:address* [ip]
  |           +--rw ietf-ip:ip            inet:ipv6-address
  |           +--rw ietf-ip:prefix-length uint8

---

Constructing a JSON Payload from a YANG Model (Step-by-Step)

This is one of the most important exam skills. The process:

Step 1: Identify the YANG module and path

You want to configure Loopback100 with IP 10.100.100.1/24. The relevant model is ietf-interfaces (augmented by ietf-ip).

Step 2: Use pyang tree to see the structure

Look at the tree output above. The path is:

interfaces → interface (list, key=name) → name, type, enabled, ietf-ip:ipv4 → address (list, key=ip) → ip, netmask

Step 3: Map YANG constructs to JSON

YANG Construct	JSON Mapping
container	JSON object { }
list	JSON array [ ] (RESTCONF: object if single instance)
leaf	JSON key-value pair
leaf-list	JSON array of scalars

Step 4: Include correct module prefix

In JSON, the top-level key uses module-name:container-name. Augmented leaves use their own module prefix (ietf-ip:ipv4).

Step 5: Complete JSON payload

{
  "ietf-interfaces:interface": {
    "name": "Loopback100",
    "type": "iana-if-type:softwareLoopback",
    "enabled": true,
    "ietf-ip:ipv4": {
      "address": [
        {
          "ip": "10.100.100.1",
          "netmask": "255.255.255.0"
        }
      ]
    }
  }
}

Module Prefixes in JSON

• Top-level: always prefix with module-name: (e.g., ietf-interfaces:interface)
• Augmented nodes: prefix with the augmenting module (e.g., ietf-ip:ipv4)
• Child nodes within the same module: no prefix needed (e.g., name, enabled)

---

Constructing an XML Payload from a YANG Model (Step-by-Step)

The same Loopback100 configuration in XML (for NETCONF <edit-config>):

Step 1: Same identification — ietf-interfaces augmented by ietf-ip

Step 2: Map to XML elements with proper namespaces

YANG Construct	XML Mapping
container	XML element
list	Repeated XML element
leaf	XML element with text content
module namespace	xmlns attribute

Step 3: Complete XML payload

<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>Loopback100</name>
      <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
        ianaift:softwareLoopback
      </type>
      <enabled>true</enabled>
      <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
        <address>
          <ip>10.100.100.1</ip>
          <netmask>255.255.255.0</netmask>
        </address>
      </ipv4>
    </interface>
  </interfaces>
</config>

XML Namespace Rules

• Each YANG module has its own namespace, declared with xmlns
• The base module namespace goes on the top container element
• Augmenting modules add their namespace where their nodes appear
• Identity references (like type) require a namespace prefix declaration

---

Side-by-Side: JSON vs XML for the Same Data

Aspect	JSON (RESTCONF)	XML (NETCONF)
Module reference	"ietf-interfaces:interface"	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
Augmentation	"ietf-ip:ipv4"	xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"
List entry	Object in array [{...}]	Repeated element <interface>...</interface>
Boolean	true / false	true / false
Identity	"iana-if-type:softwareLoopback"	Prefix declaration + ianaift:softwareLoopback

---

4 – RFC 8340 YANG Tree Diagrams (Exam Topic 1.5)

What is RFC 8340?

RFC 8340 defines a standard text-based notation for representing YANG module structures. This is the format output by pyang -f tree and is the format used in exam questions.

Tree Notation Symbols

Symbol	Meaning	Example
+--rw	Read-write config node	+--rw name string
+--ro	Read-only operational node	+--ro oper-status enumeration
? after name	Optional leaf (not mandatory)	+--rw description? string
* after name	List or leaf-list (0..n entries)	+--rw interface* [name]
! after name	Presence container	+--rw ietf-ip:ipv4!
[name]	List key(s)	+--rw interface* [name]
+--:(case)	Choice case branch	+--:(prefix-length)
{feature}?	Conditional on YANG feature	+--rw mtu? uint16 {if-mib}?
Indentation	Hierarchy depth (child nodes)	3 spaces per level
|	Vertical connector	Shows tree structure

Fully Annotated Example

module: ietf-interfaces                        ◀── Module name
  +--rw interfaces                             ◀── Config container (read-write)
  |  +--rw interface* [name]                   ◀── List, 0..n entries, keyed by "name"
  |     +--rw name                string       ◀── Leaf (mandatory, it's the key)
  |     +--rw description?       string        ◀── Optional leaf (? = not required)
  |     +--rw type                identityref  ◀── Identity reference (e.g., ethernetCsmacd)
  |     +--rw enabled?            boolean      ◀── Optional, defaults to true
  |     +--ro admin-status        enumeration  ◀── Read-only operational data
  |     +--ro oper-status         enumeration  ◀── Read-only (up/down/testing)
  |     +--ro last-change?        yang:date-and-time  ◀── Optional read-only
  |     +--ro if-index            int32        ◀── SNMP ifIndex, read-only
  |     +--rw ietf-ip:ipv4!                   ◀── Presence container from ietf-ip augment
  |     |  +--rw ietf-ip:enabled?     boolean
  |     |  +--rw ietf-ip:forwarding?  boolean
  |     |  +--rw ietf-ip:address* [ip]        ◀── List of IPv4 addresses
  |     |     +--rw ietf-ip:ip          inet:ipv4-address
  |     |     +--rw (ietf-ip:subnet)          ◀── Choice node: pick one
  |     |        +--:(ietf-ip:prefix-length)  ◀── Case 1
  |     |        |  +--rw ietf-ip:prefix-length?  uint8
  |     |        +--:(ietf-ip:netmask)        ◀── Case 2
  |     |           +--rw ietf-ip:netmask?    yang:dotted-quad
  |     +--rw ietf-ip:ipv6!
  |        +--rw ietf-ip:enabled?     boolean
  |        +--rw ietf-ip:forwarding?  boolean
  |        +--rw ietf-ip:address* [ip]
  |           +--rw ietf-ip:ip              inet:ipv6-address
  |           +--rw ietf-ip:prefix-length   uint8
  +--ro interfaces-state                       ◀── Deprecated (RFC 8343)

How to Read the Tree — Line-by-Line

1. Start at the module name — this tells you which YANG module defines the tree
2. Look at rw vs ro — determines if a node is configurable or operational only
3. Check for * — indicates a list (you need to provide the key value)
4. Check for ? — optional nodes you can omit from payloads
5. Check for ! — presence container, its existence alone carries meaning
6. Follow indentation — each level deeper is a child node in the hierarchy
7. Choice nodes (...) — you must pick exactly one case; do not include both

From Tree to JSON Path

Tree path: interfaces → interface[name] → ietf-ip:ipv4 → address[ip] → ip

JSON path: ietf-interfaces:interfaces.interface[0].ietf-ip:ipv4.address[0].ip

RESTCONF URL: /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1/ietf-ip:ipv4/address=10.0.0.1

Common Exam Question Patterns

The exam will show you a tree diagram and ask:

1. “Which JSON/XML path corresponds to this node?” — trace the hierarchy
2. “Is this field read-write or read-only?” — check rw vs ro
3. “Which fields are mandatory?” — no ? after the name
4. “What is the list key?” — shown in [brackets]
5. “Can you set oper-status via RESTCONF?” — no, it’s ro

---

5 – Putting It All Together — YANG to API Call Workflow

┌─────────────────────────────────────────────────────────────┐
│  Step 1: Identify Feature                                   │
│  "I need to configure a Loopback interface with an IP"      │
└──────────────────┬──────────────────────────────────────────┘
                   ▼
┌─────────────────────────────────────────────────────────────┐
│  Step 2: Find the YANG Model                                │
│  → ietf-interfaces + ietf-ip (augment)                     │
│  → Or: Cisco-IOS-XE-native for full vendor features        │
│  Tools: YANG Suite, pyang, GitHub YANG model repos          │
└──────────────────┬──────────────────────────────────────────┘
                   ▼
┌─────────────────────────────────────────────────────────────┐
│  Step 3: Explore the Model Tree                             │
│  → pyang -f tree ietf-interfaces.yang ietf-ip.yang         │
│  → Or browse in YANG Suite GUI                              │
│  → Identify required leaves, list keys, data types         │
└──────────────────┬──────────────────────────────────────────┘
                   ▼
┌─────────────────────────────────────────────────────────────┐
│  Step 4: Construct Payload (JSON or XML)                    │
│  → Map containers to objects, lists to arrays               │
│  → Include module prefixes                                  │
│  → Fill in required leaf values                             │
└──────────────────┬──────────────────────────────────────────┘
                   ▼
┌─────────────────────────────────────────────────────────────┐
│  Step 5: Choose Protocol and Execute                        │
│  NETCONF → ncclient + XML payload                          │
│  RESTCONF → requests + JSON payload                        │
│  See [[Catalyst_Center_Deep_Dive]] for controller examples │
└─────────────────────────────────────────────────────────────┘

Complete Example: Create Loopback via RESTCONF

import requests
import urllib3
urllib3.disable_warnings()
 
DEVICE = "10.10.20.48"
BASE_URL = f"https://{DEVICE}/restconf/data"
HEADERS = {
    "Accept": "application/yang-data+json",
    "Content-Type": "application/yang-data+json"
}
AUTH = ("developer", "C1sco12345")
 
# Payload constructed from ietf-interfaces YANG model
payload = {
    "ietf-interfaces:interface": {
        "name": "Loopback100",
        "type": "iana-if-type:softwareLoopback",
        "enabled": True,
        "ietf-ip:ipv4": {
            "address": [
                {
                    "ip": "10.100.100.1",
                    "netmask": "255.255.255.0"
                }
            ]
        }
    }
}
 
# POST = create (fails if exists), PUT = create or replace
response = requests.put(
    f"{BASE_URL}/ietf-interfaces:interfaces/interface=Loopback100",
    headers=HEADERS,
    auth=AUTH,
    json=payload,
    verify=False
)
 
print(f"Status: {response.status_code}")  # 201 = created, 204 = replaced

Complete Example: Create Loopback via NETCONF

from ncclient import manager
 
config_xml = """
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>Loopback100</name>
      <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
        ianaift:softwareLoopback
      </type>
      <enabled>true</enabled>
      <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
        <address>
          <ip>10.100.100.1</ip>
          <netmask>255.255.255.0</netmask>
        </address>
      </ipv4>
    </interface>
  </interfaces>
</config>
"""
 
with manager.connect(
    host="10.10.20.48",
    port=830,
    username="developer",
    password="C1sco12345",
    hostkey_verify=False
) as m:
    response = m.edit_config(target="running", config=config_xml)
    print(f"Success: {response.ok}")

Cross-Reference

For controller-based automation that builds on these foundations, see:

• Catalyst_Center_Deep_Dive — Catalyst Center REST API
• Meraki_Deep_Dive — Meraki Dashboard API
• SDWAN_Deep_Dive — SD-WAN vManage API
• ISE_Deep_Dive — ISE ERS and Open API

---

6 – Common Patterns and Gotchas

YANG Model Gotchas for the Exam

1. IETF vs Native — Different Paths, Same Result

The same interface can be configured via different YANG models:

Model	RESTCONF Path
IETF	/restconf/data/ietf-interfaces:interfaces/interface=Loopback100
Native	/restconf/data/Cisco-IOS-XE-native:native/interface/Loopback=100

Both work, but the payload structure is completely different.

2. NETCONF XML Requires Namespaces — RESTCONF JSON Uses Prefixes

XML:  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
JSON: "ietf-interfaces:interfaces"

Missing the namespace in XML or the prefix in JSON causes errors.

3. RESTCONF Has No Candidate Datastore

• NETCONF can use <edit-config target="candidate"> then <commit>
• RESTCONF always writes directly to the running config
• Exam may ask: “Which protocol supports candidate config?” — Answer: NETCONF only

4. NETCONF Requires SSH Key or Password — Not API Tokens

• NETCONF uses SSH authentication (port 830)
• RESTCONF uses HTTP Basic Auth (or tokens if configured)
• Neither uses the X-Auth-Token pattern that Catalyst Center does

5. edit-config Default Operation is merge

If you do not specify default-operation, NETCONF merges your changes with existing config. To replace, explicitly set:

<edit-config>
  <target><running/></target>
  <default-operation>replace</default-operation>
  <config>...</config>
</edit-config>

6. RESTCONF GET Returns ro + rw Data

A GET request returns both config and operational data (like oper-status). To get config only, use:

GET /restconf/data/ietf-interfaces:interfaces?content=config

7. The type Leaf Uses identityref

Interface type is not a simple string — it references an identity from iana-if-type:

"type": "iana-if-type:softwareLoopback"     // Correct
"type": "softwareLoopback"                  // Wrong — missing module prefix
"type": "loopback"                          // Wrong — not the identity name

---

7 – Exam-Style Scenarios

Scenario 1 — YANG Model Identification

A network engineer sees the following namespace in an XML payload:

<interfaces xmlns="http://openconfig.net/yang/interfaces">

Which family of YANG model is being used? A. IETF standard model B. Cisco native model C. OpenConfig model D. Vendor-neutral NETCONF model

Answer

C. OpenConfig model

The namespace http://openconfig.net/yang/... identifies OpenConfig models. IETF uses urn:ietf:params:xml:ns:yang:... and Cisco native uses http://cisco.com/ns/yang/....

---

Scenario 2 — RESTCONF Method Selection

An engineer wants to update the description of an existing interface without replacing any other configuration on that interface. Which HTTP method should be used? A. GET B. POST C. PUT D. PATCH

Answer

D. PATCH

PATCH performs a merge operation — it updates only the specified fields without affecting others. PUT would replace the entire resource. POST would fail with 409 Conflict because the interface already exists.

---

Scenario 3 — Tree Diagram Interpretation

Given the following YANG tree:

+--rw interfaces
|  +--rw interface* [name]
|     +--rw name          string
|     +--rw description?  string
|     +--ro oper-status   enumeration

Which statement is true? A. The description field is mandatory B. The oper-status can be set via RESTCONF PUT C. Multiple interface entries can exist in the list D. The name field is optional

Answer

C. Multiple interface entries can exist in the list

The * after interface means it is a list with 0..n entries. description? (with ?) is optional, so A is wrong. oper-status is ro (read-only), so B is wrong. name is the list key [name] and therefore mandatory, so D is wrong.

---

Scenario 4 — NETCONF vs RESTCONF Capability

A network automation team needs to stage configuration changes, validate them, and then commit them atomically to multiple devices. Which protocol best supports this workflow? A. RESTCONF with PATCH method B. NETCONF with candidate datastore C. RESTCONF with PUT method D. NETCONF with running datastore only

Answer

B. NETCONF with candidate datastore

The candidate datastore allows staging changes (edit-config target="candidate"), validating them (<validate>), and then atomically applying them (<commit>). RESTCONF does not support candidate datastores. Using running datastore only does not allow staging/validation before applying.

---

Scenario 5 — JSON Payload Construction

Given the YANG tree:

+--rw dns
|  +--rw server* [address]
|     +--rw address    inet:ipv4-address
|     +--rw port?      uint16

Which JSON payload correctly adds two DNS servers?

A.

{"dns": {"server": [{"address": "8.8.8.8"}, {"address": "8.8.4.4"}]}}

B.

{"dns": {"server": {"address": ["8.8.8.8", "8.8.4.4"]}}}

C.

{"dns": [{"server": "8.8.8.8"}, {"server": "8.8.4.4"}]}

D.

{"dns": {"server-1": "8.8.8.8", "server-2": "8.8.4.4"}}

Answer

A.

{"dns": {"server": [{"address": "8.8.8.8"}, {"address": "8.8.4.4"}]}}

A YANG list maps to a JSON array of objects. Each list entry is an object containing the key leaf (address) and any other leaves. Option B incorrectly treats address as a leaf-list. Options C and D do not match the YANG structure at all.

---

Scenario 6 — pyang Usage

An engineer needs to see the hierarchical structure of the openconfig-bgp YANG model in a terminal. Which pyang command is correct? A. pyang --format xml openconfig-bgp.yang B. pyang -f tree openconfig-bgp.yang C. pyang -f json openconfig-bgp.yang D. pyang --validate openconfig-bgp.yang

Answer

B. pyang -f tree openconfig-bgp.yang

The -f tree flag generates the human-readable RFC 8340 tree diagram. -f xml is not a valid pyang output format for viewing structure. -f json is not the correct format for tree views. --validate would check the model for errors, not display its structure.

---

8 – Quick Reference Cheat Sheet

Key YANG Terms

Term	One-Liner
module	Top-level YANG file; defines a complete data model
container	Grouping node; JSON object, XML element
list	Keyed collection; JSON array of objects
leaf	Single value; JSON key-value pair
leaf-list	Array of scalars (like a list but without keys)
augment	Adds nodes to another module’s tree
deviation	Declares vendor differences from a model
grouping	Reusable node template (like a macro)
typedef	Custom data type definition
choice/case	Mutually exclusive branches
identityref	Reference to a YANG identity (needs module prefix)
presence container	Container whose existence alone has meaning (! in tree)

NETCONF vs RESTCONF — One-Liner Comparison

	NETCONF	RESTCONF
Port	830 (SSH)	443 (HTTPS)
Encoding	XML	JSON or XML
Candidate	Yes	No
Locking	Yes	No
Session	Persistent	Stateless
Best for	Transactions	Quick CRUD

Common YANG Namespaces

Family	Namespace Pattern	Example
IETF	urn:ietf:params:xml:ns:yang:{model}	urn:ietf:params:xml:ns:yang:ietf-interfaces
OpenConfig	http://openconfig.net/yang/{model}	http://openconfig.net/yang/interfaces
Cisco Native	http://cisco.com/ns/yang/{model}	http://cisco.com/ns/yang/Cisco-IOS-XE-native
IANA	urn:ietf:params:xml:ns:yang:iana-{type}	urn:ietf:params:xml:ns:yang:iana-if-type

pyang Cheat Sheet

pyang -f tree model.yang                    # Tree view (RFC 8340 format)
pyang -f tree --tree-depth 3 model.yang     # Limit depth
pyang -f tree --tree-path /path model.yang  # Filter to subtree
pyang -f tree model.yang augment.yang       # Include augmentations
pyang -f jstree -o out.html model.yang      # Interactive HTML tree
pyang -f sample-xml-skeleton model.yang     # XML skeleton payload
pyang --strict --lint model.yang            # Validate model
pyang -f depend model.yang                  # Show dependencies

RESTCONF Content-Type Headers

Accept: application/yang-data+json
Content-Type: application/yang-data+json

RFC 8340 Tree Symbols Quick Reference

+--rw   = read-write (config)
+--ro   = read-only (operational)
?       = optional
*       = list / leaf-list (0..n)
!       = presence container
[key]   = list key
(name)  = choice node
:(name) = case within choice

---

Next Steps

This foundation enables everything in the remaining exam domains:

• Catalyst_Center_Deep_Dive — Topic 3.0: Controller APIs use YANG-modeled data
• SDWAN_Deep_Dive — Topic 3.0: SD-WAN feature templates are YANG-based
• ISE_Deep_Dive — Topic 3.0: ISE ERS API
• Meraki_Deep_Dive — Topic 3.0: Meraki REST API
• Topic 2.0: ncclient (NETCONF) and requests (RESTCONF) for device-level automation

See Also

• 5 – RESTCONF Endpoints — Quick reference for all RESTCONF paths
• QuestionBank — Practice questions for Domain 1.0
• README — Hands-on labs 1.1 (YANG Models) and 1.2 (NETCONF vs RESTCONF)