# YANG

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/yang

## Quick definition

YANG is a language that network engineers use to describe how network devices like routers and switches should be configured and managed. It works like a blueprint for the device's settings and capabilities. This helps different software tools talk to network hardware in a consistent way, even if the devices are from different vendors.

## Simple meaning

Imagine you are building a giant Lego castle. Without instructions, everyone would build different towers, gates, and walls, and nothing would fit together. YANG is like the official Lego instruction booklet for network devices. It defines exactly what pieces (configuration options) are available, what shapes they come in (data types like numbers or text), and how they must be connected (relationships and constraints). 

 In a network, you have devices made by different companies like Cisco, Juniper, and Arista. Each speaks its own language for configuration. YANG provides a common blueprint language so that a single automation tool can understand and configure any device that follows that blueprint. It turns messy, vendor-specific command lines into organized, predictable data structures that software can read and write. 

 For example, instead of typing a proprietary command to set an IP address, a YANG model tells the tool: there is a container called “interfaces,” inside it there is a list called “interface,” and inside that list each item has a leaf called “ip-address” that must be a valid IPv4 address. This makes network automation reliable, scalable, and much less error-prone. IT professionals use YANG to build scripts that configure hundreds of devices at once, audit their settings, and ensure every device follows the same standards.

## Technical definition

YANG (Yet Another Next Generation) is a data modeling language defined in RFC 6020 and revised in RFC 7950. It was originally developed by the IETF (Internet Engineering Task Force) to model the configuration and state data of network devices. It is used with the NETCONF and RESTCONF protocols to provide programmatic, standardized access to device configurations. 

 YANG models define data in a tree structure. The primary building blocks are modules, submodules, containers, lists, leaf-list, leaf nodes, and choices. A YANG module is a file that contains the definitions. Containers group related nodes together, similar to a folder on a computer. Lists are ordered or unordered groupings of list entries, each entry identified by a key leaf. Leaf nodes hold simple values like strings, integers, booleans, or IP addresses. Leaf-lists are sequences of simple values. Choice nodes allow the model to define that exactly one of several options must be selected. 

 YANG also supports constraints like mandatory nodes, default values, unique key constraints, and when conditions. Types can be built-in (e.g. string, uint32, ipv4-address) or derived using type definitions and typedefs. XPath expressions can be used in constraints to reference other parts of the data tree. The language also supports augmentation, which allows one module to extend another module's definitions without modifying the original module, a critical feature for vendor-specific extensions. 

 For data transport, YANG models are used with NETCONF (RFC 6241) and RESTCONF (RFC 8040). NETCONF uses XML encoding and an RPC-based protocol, while RESTCONF uses HTTP methods and supports both XML and JSON encoding. The YANG model defines the schema, and the protocol carries the actual configuration and operational data that conforms to that schema. In real IT implementations, engineers use YANG models to validate configurations before applying them, to automate network changes via CI/CD pipelines, and to monitor device state in a structured way. Compliance checking, configuration templating, and multi-vendor orchestration all rely heavily on YANG.

## Real-life example

Think about ordering a pizza over the phone. If you call a new pizzeria, you might say, “I want a pepperoni pizza,” and the person might ask, “Small, medium, or large?” “Thin crust or thick?” “Extra cheese?” Each pizzeria has its own way of asking and its own set of options. If you are a hungry office manager ordering lunch for 50 people, calling each pizzeria one by one with different questions is slow and error-prone. 

 Now imagine a universal pizza order form that every pizzeria agrees to use. The form has boxes with labels like “Size (small, medium, large),” “Crust (thin, thick, stuffed),” “Toppings (select all that apply),” and “Special instructions (text).” You fill out the form once, and every pizzeria can process it because they all understand the same form. That universal form is like a YANG model. 

 In IT, network devices are the different pizzerias. The universal order form is a YANG module that defines exactly what configuration options exist and what values they accept. The automation tool is the office manager who fills out the form. Once the YANG model is created, the tool can configure any device that supports that model without needing to know the device’s proprietary language. This saves time, reduces mistakes, and makes it possible to manage a large, diverse network with a single set of instructions.

## Why it matters

YANG is crucial because modern networks are too large and dynamic to configure manually. A single misconfigured router can take down an entire data center. Automation is the only way to keep networks reliable, secure, and agile. YANG enables this automation by providing a standard, machine-readable way to describe how devices should be set up. 

 Without YANG, automation tools would need custom drivers or scripts for every device model and software version. When a new feature is added, every automation tool would need to be updated. This is expensive and slow. With YANG, the device vendor provides a YANG model, and any tool that understands YANG can immediately work with that device. This dramatically reduces integration effort and speeds up deployment. 

 YANG also improves operational accuracy. Because values are typed and constraints are enforced, a configuration that tries to set a subnet mask to “hello” will be rejected before it ever reaches the device. This prevents many common human errors. YANG models can represent both configuration and operational state, allowing teams to write compliance checks that ensure actual device settings match the intended policy. In a world of DevOps and NetOps, YANG is the language that makes infrastructure-as-code possible for networking.

## Why it matters in exams

For IT certification exams, understanding YANG is increasingly important as the industry moves toward software-defined networking and automation. Exams such as Cisco DevNet Associate (200-901) and Cisco CCNP Enterprise (350-401 ENCOR) include objectives related to YANG, NETCONF, and RESTCONF. The DevNet exam explicitly asks candidates to interpret YANG models, identify data nodes, and understand how they relate to NETCONF operations. The ENCOR exam includes automation topics where YANG is a foundational concept. 

 For the CompTIA Network+ (N10-009) exam, YANG appears as part of the network operations domain under automation and orchestration. While the depth is lighter, candidates need to know what YANG is used for and how it fits with NETCONF/RESTCONF. The Cisco CCNA (200-301) exam also touches on YANG within the automation and programmability section. Exam questions may ask which protocol YANG models are used with, or what a YANG module defines. 

 In exam scenarios, you might be given a snippet of a YANG model and asked to identify a configuration error based on the model’s constraints. Or you might be asked to choose the correct YANG path for a given network parameter. Knowing the difference between leaf, leaf-list, container, and list is essential. Also, understanding that YANG is a modeling language, not a transport protocol, is a common point. Specific exam topics include: the relationship between YANG and NETCONF, the structure of a YANG module, using YANG to validate configurations, and interpreting YANG error responses. Some exams also test the concept of datastores (candidate, running, startup) and how YANG models define them.

## How it appears in exam questions

In certification exams, YANG questions typically appear in multiple-choice, drag-and-drop, and simulation formats. A common pattern is scenario-based: “A network engineer wants to automate the configuration of VLANs across 100 switches from different vendors. Which technology provides a standard data model to represent VLAN configuration?” The correct answer is YANG (often with NETCONF or RESTCONF). Another common question type is definition-based: “Which YANG node type is used to hold a single value like an IP address?” Answer: leaf. 

 Some questions show a YANG model snippet and ask the candidate to identify errors or constraints. For example, a model might define a leaf with type “uint8” but the configuration uses the value “300”, which is out of range. The question would ask why the NETCONF operation fails. Another variant is a troubleshooting scenario: “An automation script fails with an error ‘Invalid value for leaf interface-speed’. What is the most likely cause?” The answer would be that the value does not conform to the YANG model’s type definition. 

 Drag-and-drop questions may ask to match YANG node types (container, list, leaf, leaf-list) with their characteristics. Simulation questions may ask to write or modify a simple YANG module based on given requirements, though this is more common in DevNet lab exams. For CompTIA and CCNA, the questions are more conceptual, such as “Which protocol uses YANG data models?” or “What is the purpose of a YANG module?” Some exams also include questions about YANG import and include statements, or about augmenting a YANG module. The key is to remember that YANG is about data structure, not data transport, and to be familiar with basic syntax and node types.

## Example scenario

A company called CloudNet Services manages a network of 500 routers and switches spread across three data centers. The team is tired of logging into each device separately to make changes. They want to automate the deployment of a new Quality of Service (QoS) policy across all devices. The devices come from two vendors: Cisco and Juniper. 

 The network automation engineer, Maria, decides to use YANG models. She finds that both vendors support the standard IETF YANG model for QoS policy. Maria writes a Python script that reads a YANG model describing the QoS policy structure. The model defines: a container called “qos-policy,” a list called “class-map” (keyed by class-name), and inside each class-map, leaves for bandwidth percentage, queue-limit, and drop-profile. 

 Maria’s script uses NETCONF to send configuration data in XML format that conforms to this YANG model. The same XML data works on both Cisco and Juniper devices because they both understand the same YANG model. The script applies the QoS policy to 500 devices in under 30 minutes. Later, when an auditor asks for proof that all devices have the correct QoS policy, Maria runs a script that uses NETCONF and YANG to retrieve the operational state from each device and compares it against the desired configuration. This would have been impossible without a standard, machine-readable model like YANG.

## Common mistakes

- **Mistake:** Thinking YANG is a protocol like NETCONF or RESTCONF.
  - Why it is wrong: YANG is a modeling language, not a protocol. It defines data structures but does not transport data.
  - Fix: Remember: YANG models data; NETCONF/RESTCONF transport data. They work together but are different layers.
- **Mistake:** Confusing leaf and leaf-list. Believing both can hold multiple values.
  - Why it is wrong: A leaf holds exactly one value. A leaf-list holds an ordered sequence of values. They are distinct node types.
  - Fix: Think of a leaf as a single field (e.g., a single IP address), and a leaf-list as an array of fields (e.g., a list of DNS servers).
- **Mistake:** Assuming YANG is only for configuration data, not operational state.
  - Why it is wrong: YANG models can define both configuration data and operational state data. State data is read-only and reflects device status.
  - Fix: Remember: YANG has config true and config false nodes. Config false nodes represent operational state like counters or status.
- **Mistake:** Thinking that YANG replaces vendor-specific CLI completely.
  - Why it is wrong: YANG provides a structured alternative, but many devices still support CLI. YANG is used alongside, not instead of, CLI in many environments.
  - Fix: Understand that YANG is an additional interface for automation, not a total replacement for traditional management methods.

## Exam trap

{"trap":"A question shows a YANG snippet with a leaf of type 'string' and asks what kind of data it can hold. Some candidates think string means any text, but they forget about constraints like 'pattern' or 'length' that can restrict allowed values.","why_learners_choose_it":"Learners often overlook that YANG types can have additional restrictions. They see 'string' and assume it is free text.","how_to_avoid_it":"Always read the full YANG definition, including any 'pattern', 'length', or 'range' substatements. A string leaf may only accept a specific format, like an IPv4 address or a MAC address with a regex pattern."}

## Commonly confused with

- **YANG vs NETCONF:** NETCONF is a protocol that uses YANG models to exchange configuration data. YANG defines the structure; NETCONF defines the communication method. They are not the same thing, but they are often used together. (Example: YANG is like the form layout; NETCONF is the postal service that delivers the filled-out form to the device.)
- **YANG vs RESTCONF:** RESTCONF is another protocol that uses YANG models, but it uses HTTP/REST principles instead of XML-based RPCs. YANG models are used with both NETCONF and RESTCONF, but they are different interfaces. (Example: YANG is the same form; NETCONF is one delivery method (certified mail), and RESTCONF is another (email with JSON).)
- **YANG vs SNMP MIBs:** SNMP MIBs (Management Information Base) also define data structures for network management, but they are older, less structured, and harder to extend than YANG. YANG supports richer types, constraints, and integration with modern APIs. (Example: MIBs are like a flat list of items in a warehouse; YANG is like a detailed catalog with sections, subsections, and rules about what fits where.)

## Step-by-step breakdown

1. **Identify the need for automation** — You have multiple network devices from different vendors. Managing them with CLI scripts is slow and error-prone. You need a standard way to describe configurations so that automation tools can work consistently.
2. **Create or obtain the YANG module** — You find a standard YANG module (e.g., from the IETF) that defines the configuration structure for the feature you want to manage, such as VLANs, interfaces, or routing protocols. Or you create a custom module for vendor-specific features.
3. **Understand the YANG tree structure** — The module defines a tree with containers, lists, leaves, and leaf-lists. You learn how to navigate the tree to find the specific data nodes you need to configure. This is like reading a schema before entering data.
4. **Validate your intended configuration against the YANG model** — Before sending the configuration to a device, you use a tool that checks whether your data values match the types and constraints defined in the YANG model. This catches errors like invalid IP addresses or out-of-range numbers.
5. **Send the configuration via NETCONF or RESTCONF** — The validated configuration data is encoded in XML or JSON and sent to the device using the NETCONF or RESTCONF protocol. The device, which understands the same YANG model, applies the configuration or returns an error.
6. **Verify the configuration using the same YANG model** — You retrieve the operational state or configuration from the device using a YANG-based query. The returned data follows the same model, allowing you to compare it automatically against your desired state.

## Practical mini-lesson

YANG in practice is the backbone of network programmability. When you work with devices that support NETCONF or RESTCONF, you first need to understand their YANG models. Vendors publish these models on their websites or in the device's file system. Tools like pyang or yanglint allow you to parse and validate YANG modules. 

 As a network professional, you will frequently use YANG models to create configuration templates. For example, to configure an Ethernet interface on a Cisco IOS XE device, you might use the IETF-interfaces YANG module. You need to know the exact path: /interfaces/interface[name='GigabitEthernet1']/ipv4/address/ip. The automation tool sends this path and the desired value to the device. If you get the path wrong, the device returns a “data-missing” or “invalid-value” error. 

 A common practical challenge is handling YANG model versioning. When a device upgrades its software, the YANG models may change. Leaves may be added, deprecated, or have new constraints. Automation scripts must be updated accordingly. Professional engineers use YANG model change logs and test in a sandbox before deploying to production. 

 Another key skill is writing YANG modules for custom applications. For instance, if your company has a proprietary feature, you can define a YANG module to represent it. This module can then be augmented into a standard module or used independently. Tools like Eclipse Oomph or simple text editors with YANG plugin support are used for this. YANG modules must follow strict syntax and include proper namespaces, imports, and revision statements. Errors in the module itself can break automation workflows. 

 What can go wrong: wrong data types, missing mandatory elements, duplicate keys in lists, or schema mismatch between the device and the automation tool. Troubleshooting involves checking the YANG model with a validation tool, inspecting NETCONF error messages, and verifying that both sides use the same revision of the module. In short, YANG is not a set-it-and-forget-it technology; it requires careful planning, testing, and ongoing maintenance.

## Memory tip

YANG is the blueprint; NETCONF is the builder. The blueprint describes what goes where; the builder follows the blueprint to construct the network.

## FAQ

**Is YANG difficult to learn?**

YANG has a learning curve, but if you understand basic data structures like containers and lists, it becomes easier. Start with simple models and use tools like pyang to visualize them.

**Do all network devices support YANG?**

Not all. Newer devices from major vendors like Cisco, Juniper, Arista, and Nokia support YANG via NETCONF or RESTCONF. Older devices may require an agent or upgrade.

**Can I use YANG without NETCONF?**

YANG models can be used with any protocol that can transport structured data, but they are most commonly paired with NETCONF or RESTCONF. Some tools also generate gRPC interfaces from YANG.

**What is the difference between YANG version 1 and version 1.1?**

YANG 1.1 (RFC 7950) added support for unions, pattern expressions, and improved error handling. It is backward compatible with YANG 1. Most modern devices use YANG 1.1.

**How do I find the YANG model for a specific device feature?**

Vendors publish YANG models on their support websites or within the device firmware. You can also use tools to retrieve the list of supported models via NETCONF get-schema RPC.

**Can I create my own YANG modules?**

Yes. You can write custom YANG modules using any text editor. They must follow the YANG syntax and can reference standard modules. Custom modules are common for vendor-specific features or internal applications.

## Summary

YANG is a foundational technology for modern network automation. It provides a standardized, machine-readable language to define the structure, types, and constraints of network device configurations and state data. By using YANG, network engineers can write automation scripts that work across different vendors, reduce human error through validation, and manage large networks with greater speed and consistency. 

 For IT certification exams, YANG is tested in the context of network programmability, NETCONF, and RESTCONF. Candidates need to understand the basic node types (container, list, leaf, leaf-list), how models are used to validate data, and the difference between YANG and the protocols that carry its data. Common exam traps include confusing leaf and leaf-list, and forgetting that YANG is a modeling language, not a protocol. 

 In the real world, YANG enables infrastructure-as-code for networking, making it possible to version control device configurations, run automated compliance checks, and deploy changes rapidly. As networks grow more complex and dynamic, YANG is becoming an essential skill for any IT professional involved in network operations or automation. Mastering YANG will not only help you pass exams but also prepare you for the future of network management.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/yang