Understanding the Connection Between YANG, NETCONF, RESTCONF, and CCNP Enterprise

The CCNP Enterprise certification has evolved significantly from its earlier versions, and one of the most substantial changes in recent years has been the inclusion of network automation and programmability as a core exam component. Cisco made a deliberate decision to incorporate these topics because the networking industry itself has shifted. Organizations are increasingly managing their infrastructure through software tools, APIs, and automated workflows rather than relying exclusively on engineers typing commands into individual devices. Candidates who ignore the automation section of the CCNP Enterprise curriculum do so at a real cost to both their exam score and their professional relevance.

YANG, NETCONF, and RESTCONF sit at the center of this automation curriculum and represent a set of technologies that work together to enable programmatic network management. Understanding each individually is necessary, but the deeper value comes from understanding how they connect and depend on one another. A network engineer who grasps these relationships can read vendor documentation more intelligently, work more effectively with automation tools, and contribute meaningfully to infrastructure-as-code initiatives that are becoming standard practice in well-run network operations teams.

What YANG Actually Is and the Problem It Was Designed to Solve

YANG stands for Yet Another Next Generation and is a data modeling language developed specifically for describing the structure of network configuration and operational data. Before YANG existed, network management suffered from a fundamental inconsistency problem. Different vendors described their device configurations in incompatible ways, and there was no standardized method for defining what data a network device could accept or return. This made it extremely difficult to build management tools that worked reliably across multiple vendors or even across different software versions from the same vendor.

YANG solves this by providing a formal language for describing data models that define exactly what configuration parameters a device supports, what operational state information it can report, and what the relationships and constraints between different data elements are. A YANG model for OSPF, for example, defines every configurable parameter related to OSPF, the data types each parameter accepts, which parameters are mandatory, and how they relate to each other. These models serve as contracts between network devices and the management systems that interact with them, making programmatic network management predictable and reliable in a way that screen-scraping CLI output never could be.

How YANG Models Are Structured and Read

YANG models are written in a hierarchical tree structure that organizes data into modules, containers, lists, leaf nodes, and leaf-list nodes. A module is the top-level organizational unit, similar to a file in a programming language. Containers group related data elements together without having a value themselves, while leaf nodes represent individual configuration parameters that hold specific values. Lists are used for repeating elements, such as multiple BGP neighbors or multiple OSPF interfaces, where each list entry has the same structure but different values.

Reading a YANG model for the first time can feel intimidating, but CCNP candidates do not need to become experts in writing YANG from scratch. The exam expects familiarity with YANG’s purpose and basic structure, the ability to interpret a YANG tree diagram, and an understanding of how YANG models relate to the data exchanged through NETCONF and RESTCONF. The pyang tool, which converts YANG modules into readable tree diagrams, is widely used in the industry and produces output that makes the hierarchical structure of a model much easier to visualize than reading the raw YANG syntax directly.

NETCONF as the Protocol That Carries Network Configuration Data

NETCONF, defined in RFC 6241, is a network management protocol that uses YANG-defined data models to exchange configuration and operational data between a management system and a network device. It operates over an SSH transport layer and uses XML as its encoding format for all data exchanges. NETCONF establishes a session between a client, typically a network management system or automation script, and a server running on the network device, and uses a set of defined operations to get, edit, and delete configuration data in a structured and transactional way.

The transactional nature of NETCONF is one of its most important characteristics and a key differentiator from traditional CLI-based management. When a NETCONF operation is sent to a device, it either succeeds completely or fails completely, preventing the partial configuration states that can occur when a CLI script encounters an error midway through execution. NETCONF also supports candidate configuration datastores, which allow a full configuration to be built and validated before being committed to the running configuration. This capability is particularly valuable in enterprise environments where configuration changes carry significant risk and rollback capability is essential.

NETCONF Operations and How They Work in Practice

NETCONF defines a specific set of operations that a client can invoke against a network device. The get-config operation retrieves configuration data from a specified datastore, while the get operation retrieves both configuration and operational state data. The edit-config operation is used to modify configuration data and supports different modes including merge, replace, and delete, giving the client precise control over how the new configuration interacts with what already exists on the device. The commit operation applies the candidate configuration to the running datastore, and the lock and unlock operations prevent other management sessions from making conflicting changes during a critical operation.

For CCNP Enterprise exam purposes, candidates should be able to recognize each of these operations by name, describe what each does, and understand when each would be used in a typical automation workflow. Exam questions in this area often present scenarios where a specific management task needs to be accomplished and ask which NETCONF operation is most appropriate. Candidates who have spent time looking at real NETCONF request and response XML payloads, even without running them against actual devices, develop a much clearer mental picture of how these operations work than those who study them only as abstract definitions.

RESTCONF as the HTTP-Based Alternative to NETCONF

RESTCONF, defined in RFC 8040, provides a way to access the same YANG-defined data that NETCONF exposes, but through an HTTP-based interface that follows REST architectural principles. Where NETCONF uses SSH and XML, RESTCONF uses HTTPS and supports both JSON and XML as encoding formats. This difference is significant in practice because most modern programming languages and automation tools have mature, easy-to-use libraries for working with HTTP and JSON, making RESTCONF considerably more accessible for developers and network engineers who are newer to automation than NETCONF’s XML-over-SSH approach.

RESTCONF maps the YANG data hierarchy to URL paths, so each resource in a YANG model becomes accessible at a specific URL endpoint on the device. Standard HTTP methods are used for all operations: GET retrieves data, POST creates new resources, PUT replaces existing resources, PATCH modifies specific attributes within a resource, and DELETE removes resources. This mapping to familiar HTTP conventions is one of the primary reasons RESTCONF has become popular for network automation tasks, particularly in environments where teams are building automation tools using general-purpose programming languages rather than specialized network management platforms.

Comparing NETCONF and RESTCONF for Different Automation Scenarios

CCNP Enterprise candidates are expected to understand the differences between NETCONF and RESTCONF and to have a sense of when each is more appropriate. NETCONF is generally preferred for large-scale configuration management tasks, particularly those involving complex configuration changes that benefit from candidate datastore support and transactional commit semantics. Its ability to lock datastores, validate configurations before committing, and roll back changes makes it well-suited for production network management where reliability and precision are paramount.

RESTCONF is typically preferred for simpler data retrieval tasks, operational monitoring, and integration with web-based tools and microservices architectures. Its HTTP foundation makes it easy to test with standard tools like curl or Postman and easy to integrate with REST-native frameworks. One important distinction candidates should remember is that RESTCONF does not support all of NETCONF’s datastore operations, including the candidate datastore and the lock operation, which means it is less suitable for complex configuration workflows that require those capabilities. Understanding these tradeoffs allows candidates to answer scenario-based exam questions about protocol selection accurately.

The Role of YANG Models in Connecting NETCONF and RESTCONF

YANG models are the element that connects NETCONF and RESTCONF into a coherent system rather than treating them as two separate technologies. Both protocols use the same underlying YANG data models to define the structure of the data they exchange, which means that a YANG model describing BGP configuration applies equally whether that configuration is being accessed via NETCONF or RESTCONF. This shared data modeling foundation is what makes it possible to build management systems that can use either protocol interchangeably depending on the context.

Cisco publishes YANG models for its IOS-XE, IOS-XR, and NX-OS platforms in a public GitHub repository, giving candidates direct access to the actual models used by real Cisco devices. Browsing these models and using tools like pyang to generate readable tree diagrams is one of the most effective ways to build familiarity with how YANG structures network data. Candidates who spend even a small amount of time examining real Cisco YANG models develop a much more concrete understanding of the technology than those who study it exclusively through textbook descriptions.

How These Technologies Appear in the CCNP ENCOR Exam

The CCNP ENCOR 350-401 exam allocates a specific percentage of its questions to the automation and programmability domain, and YANG, NETCONF, and RESTCONF appear within that domain consistently. Exam questions test candidates at several levels. Some questions test factual recall, asking candidates to identify what a specific technology is, what protocol it uses, or what encoding format it supports. Other questions are scenario-based, presenting a network management task and asking which technology or protocol combination is most appropriate. A smaller number of questions may present fragments of NETCONF XML or RESTCONF URLs and ask candidates to interpret what operation is being performed or what data is being requested.

Candidates who want to perform well on this section of the exam should study the topic across multiple dimensions. Conceptual study through reading and video instruction builds the foundational understanding needed for recall questions. Reviewing real NETCONF and RESTCONF payloads, even without executing them, builds the pattern recognition needed for interpretation questions. Working through scenario-based practice questions builds the judgment needed to select the right technology for a described situation. Using all three approaches together produces more robust preparation than relying on any single study method.

Practical Tools for Gaining Hands-On Experience With These Technologies

Getting hands-on experience with YANG, NETCONF, and RESTCONF does not require access to physical Cisco hardware. Several practical options are available to candidates who want to move beyond conceptual study into actual experimentation. Cisco DevNet provides a range of free sandbox environments, including always-on IOS-XE devices that support NETCONF and RESTCONF access. These sandboxes allow candidates to send real NETCONF requests and RESTCONF queries to actual Cisco devices and observe the responses without any setup cost or infrastructure requirement.

Python is the most practical language for experimenting with these technologies, and the ncclient library provides a straightforward interface for making NETCONF requests from a Python script. The requests library, which is standard in Python automation work, handles RESTCONF calls over HTTP. Candidates who write even simple scripts that retrieve the running configuration from a Cisco DevNet sandbox device via NETCONF and compare it to the same data retrieved via RESTCONF gain a concrete, memorable understanding of how both protocols work that no amount of reading can fully replicate. This kind of direct experimentation is highly recommended for anyone who finds the automation section of the CCNP curriculum abstract or difficult to internalize.

Connecting These Technologies to Broader Network Automation Concepts

YANG, NETCONF, and RESTCONF do not exist in isolation within the CCNP Enterprise curriculum. They connect directly to other automation topics tested on the exam, including configuration management tools like Ansible, model-driven telemetry, and the broader concept of intent-based networking. Ansible, for example, includes modules that use NETCONF as the underlying transport for configuring Cisco devices, meaning that understanding NETCONF makes Ansible’s network modules significantly easier to work with. Model-driven telemetry, which allows devices to stream operational data to a collector in real time, uses YANG models to define the structure of the streamed data, connecting that topic directly back to the data modeling concepts covered here.

Candidates who study these technologies as an interconnected ecosystem rather than as isolated facts develop a much more resilient understanding that holds up better under the varied questioning styles used on the exam. When the relationship between YANG models, NETCONF operations, and RESTCONF endpoints is clearly understood, questions that approach these technologies from unexpected angles become much more manageable. Building this connected understanding is ultimately what separates candidates who genuinely grasp the automation curriculum from those who have memorized individual facts without seeing how the pieces fit together.

Conclusion

Stepping back and viewing these technologies within the full scope of the CCNP Enterprise certification reinforces why they deserve serious attention rather than being treated as a minor section to skim through. The CCNP Enterprise certification positions its holders as professionals capable of designing, implementing, and managing complex enterprise networks at a level of sophistication that goes well beyond what the CCNA validates. In 2024 and beyond, that sophistication increasingly includes the ability to interact with network infrastructure programmatically, interpret vendor documentation written in terms of YANG models and API endpoints, and contribute to automation initiatives that are becoming standard in enterprise network operations.

Candidates who invest genuinely in this topic area come away with more than exam preparation. They gain a foundation for working with Cisco DNA Center’s northbound APIs, which use RESTCONF-style interfaces. They develop the vocabulary to collaborate with DevOps teams who are building infrastructure automation pipelines. They build the conceptual framework needed to evaluate and adopt new network management tools that are built on the same underlying standards. 

The time invested in deeply learning YANG, NETCONF, and RESTCONF is not just an investment in passing a certification exam; it is an investment in professional capability that will remain relevant and increasingly valuable as the networking industry continues its shift toward software-driven infrastructure management. For any network professional who is serious about operating effectively in the enterprise networking landscape that exists today and will continue to develop over the coming years, this knowledge is not optional; it is foundational.