YANG emerged in 2010 as a specialised data modelling language, originally defined to describe data sent over the NETCONF network management protocol. It provides a standardised framework for defining how network devices are configured and managed, enabling the detailed specification of network devices’ configuration, operational data, and policies in a structured, modular, and extensible manner. Think of YANG as a schema or blueprint that tells the network exactly what shape the configuration data should take before any protocol touches the device.
In the context of CCNP Enterprise, YANG is not just a theoretical concept. It is the backbone of how modern Cisco devices accept and respond to programmatic configuration requests. Cisco IOS-XE, IOS-XR, and NX-OS all ship with native YANG models that describe every configurable feature on those platforms. When a network engineer wants to automate the deployment of OSPF, BGP, or interface configurations across hundreds of devices simultaneously, YANG is the language that defines what that configuration data looks like in a structured, machine-readable format. Without YANG, there is no consistent data structure for automation tools to work with.
What NETCONF Protocol Does
NETCONF, which stands for Network Configuration Protocol, is an IETF-standardised protocol defined in RFC 6241. It operates over SSH on port 830 and uses XML-based Remote Procedure Calls to communicate between a management client and a network device acting as the server. NETCONF was specifically designed to install, manipulate, and delete the configuration of network devices, providing configuration rollback and locking mechanisms to ensure safe management transactions. These capabilities make it far more reliable than traditional CLI-based configuration, which offers no native rollback protection if something goes wrong mid-change.
The operations available through NETCONF include get-config for retrieving configuration data, edit-config for making changes, copy-config for duplicating configurations between datastores, delete-config for removing stored configurations, lock and unlock for preventing conflicting changes, and close-session for ending a connection cleanly. NETCONF also supports the concept of datastores, including the running configuration, the candidate configuration, and the startup configuration. The candidate datastore is particularly valuable because it allows engineers to stage and validate changes before committing them to the running configuration, which significantly reduces the risk of network disruption during maintenance windows.
What RESTCONF Protocol Does
RESTCONF is defined in RFC 8040 and was introduced as a simplified, HTTP-based alternative to NETCONF for accessing and managing network device datastores. Where NETCONF uses XML over SSH, RESTCONF uses standard HTTP or HTTPS methods that are already familiar to software developers and DevOps teams. The HTTP verbs used in RESTCONF map directly to configuration actions: GET retrieves data, POST creates new resources, PUT replaces existing resources, PATCH makes partial updates, and DELETE removes resources. This alignment with standard web development conventions makes RESTCONF significantly easier to integrate into existing automation pipelines and application frameworks.
RESTCONF supports both JSON and XML as data encoding formats, which gives it a flexibility advantage over NETCONF, which is exclusively XML-based. In practice, most modern automation scripts and tools prefer JSON because it is lighter, easier to read, and integrates naturally with Python libraries and REST API clients. RESTCONF does not support all of the transactional features that NETCONF provides, such as the candidate datastore with confirmed commit, but for many straightforward configuration and retrieval tasks it is the more accessible and developer-friendly choice. Understanding when to use RESTCONF versus NETCONF is itself a skill tested in the CCNP Enterprise examination.
How the Three Connect
The relationship between YANG, NETCONF, and RESTCONF is best understood as a three-layer system. YANG sits at the foundation as the data modelling language that defines what configuration data looks like and what constraints apply to it. NETCONF and RESTCONF sit above it as transport protocols that carry that structured data between management applications and network devices. Neither protocol operates independently of YANG in a meaningful way. Without a YANG model, there is no agreed-upon structure for the data being exchanged, and without NETCONF or RESTCONF, there is no standard way to deliver that data to the device.
Cisco IOS-XE, IOS-XR, and NX-OS all support YANG-powered NETCONF, with IOS-XE and NX-OS also supporting RESTCONF. This means that when a network engineer sends a NETCONF RPC to a Cisco router, the XML payload of that RPC must conform to the YANG model that the device supports for that feature. If the data does not match the YANG schema, the device rejects the request and returns an error. The same principle applies to RESTCONF, where the JSON or XML body of an HTTP request must conform to the appropriate YANG model. This tight coupling between data model and protocol is what makes model-driven automation reliable and repeatable at scale.
Where CCNP Exam Tests These
The CCNP Enterprise certification is built around two required components: the core exam known as 350-401 ENCOR, and one concentration exam chosen by the candidate. YANG, NETCONF, and RESTCONF appear in the ENCOR blueprint under the Automation domain, which accounts for 15 percent of the total exam content. This domain covers Python scripting, REST APIs, Ansible, Cisco DNA Center APIs, vManage APIs, and model-driven programmability including YANG, NETCONF, and RESTCONF. The fact that automation represents 15 percent of a core enterprise exam signals clearly that Cisco no longer treats programmability as an optional specialty skill but as a foundational competency for any enterprise network engineer.
Beyond the ENCOR core exam, candidates who choose the automation concentration will sit the 300-435 ENAUTO exam, which goes considerably deeper into these technologies. ENAUTO explicitly requires candidates to describe OpenConfig, IETF, and native YANG models in detail, and to demonstrate working knowledge of NETCONF and RESTCONF as distinct but related protocols. The concentration exam also tests practical skills such as writing Python scripts that use the ncclient library to establish NETCONF sessions, send RPCs, and parse XML responses. Candidates preparing for ENAUTO need hands-on lab experience with these protocols, not just conceptual familiarity, because the exam includes scenario-based questions that reflect real automation workflows.
YANG Models Types Explained
There are three main categories of YANG models that appear in CCNP Enterprise study material, and distinguishing between them is important for both exam preparation and real-world application. The first category is native models, which are vendor-specific models written by Cisco for their own platforms. These models expose features and configuration options that are unique to Cisco devices and may not be available through any standardised model. Native models are often the only option for configuring advanced platform-specific features, but they sacrifice portability because they only work with Cisco devices.
The second category is IETF models, which are standardised models published by the Internet Engineering Task Force. These models cover common networking features such as interfaces, IP addressing, and routing protocols using a vendor-neutral schema that should work consistently across devices from different manufacturers. The third category is OpenConfig models, which are developed by an operator-driven working group with the goal of creating consistent, use-case-driven models that work across multi-vendor environments. OpenConfig models are widely used in service provider and large enterprise environments where network infrastructure includes devices from multiple vendors. Understanding the purpose and scope of each model type is a specific exam objective in both ENCOR and ENAUTO.
NETCONF Operations In Practice
In a practical CCNP Enterprise context, NETCONF operations are invoked through a client library such as ncclient in Python. A typical workflow begins by establishing an SSH connection to the device on port 830 and performing a capabilities exchange, during which both the client and the server advertise which YANG models and NETCONF features they support. This capabilities exchange is a critical step because it determines which operations and datastores are available for the session. After the capabilities exchange, the client can begin sending RPC requests to retrieve or modify configuration data.
A get-config RPC retrieves configuration from a specified datastore and returns it as structured XML conforming to the relevant YANG model. An edit-config RPC sends an XML payload describing the desired configuration changes and applies them to the target datastore. If the device supports the candidate datastore, the engineer can commit the staged changes after validation, or roll back if the validated result is not what was expected. These transactional capabilities are one of NETCONF’s greatest advantages over CLI-based automation, where a failed script mid-execution can leave a device in an inconsistent configuration state with no automatic recovery mechanism.
RESTCONF Practical Use Cases
RESTCONF is particularly well-suited to use cases where the automation tooling is built around web technologies or where the team responsible for network automation comes from a software development background rather than a traditional networking background. Because RESTCONF uses standard HTTPS and returns data in JSON by default, it integrates naturally with tools like Postman for testing, curl for quick command-line queries, and Python’s requests library for scripted automation. This accessibility lowers the barrier to entry for teams that want to automate network configuration without learning the XML-heavy syntax of NETCONF from scratch.
A practical RESTCONF workflow on a Cisco IOS-XE device involves constructing a URL that identifies the specific resource being accessed, formatted according to the YANG model hierarchy. For example, retrieving the configuration of a specific interface would involve an HTTP GET request to a URL that encodes the device address, the RESTCONF root path, and the YANG module and container path that corresponds to interfaces. The response arrives as JSON or XML and can be parsed, processed, and acted upon programmatically. RESTCONF is also useful for building dashboards and monitoring tools that periodically poll device state and configuration data, because the HTTP request model is simple to implement in virtually any programming language.
Automation Domain Study Tips
Preparing for the Automation domain of the CCNP ENCOR exam requires a combination of conceptual study and hands-on practice. On the conceptual side, candidates need to understand what YANG, NETCONF, and RESTCONF are, how they relate to each other, how they differ from older management protocols like SNMP and CLI-based scripting, and what specific use cases each protocol is best suited for. Reading the relevant RFCs at a summary level, working through Cisco DevNet learning labs, and studying official Cisco documentation for IOS-XE model-driven programmability are all high-value activities that build the foundational knowledge the exam tests.
On the practical side, setting up a lab environment using Cisco DevNet sandboxes or local virtual routers such as Cisco CSR1000v or IOS-XE on EVE-NG provides the hands-on experience that turns theoretical knowledge into retained understanding. Writing Python scripts that connect to a device via NETCONF using ncclient, send a get-config request, parse the XML response, modify a value, and send it back via edit-config is the kind of task that consolidates multiple exam objectives simultaneously. Similarly, using Postman or Python’s requests library to send RESTCONF HTTP requests and inspect JSON responses builds the practical familiarity that scenario-based exam questions are designed to assess.
Conclusion
The significance of YANG, NETCONF, and RESTCONF extends well beyond passing a certification exam. Enterprises today are increasingly adopting software-driven network architectures, cloud integration platforms, and AI-enhanced monitoring tools, all of which rely on robust data models and standardised programmatic interfaces. A network engineer who can only configure devices through a CLI becomes a bottleneck in environments where hundreds or thousands of devices need consistent, auditable, and repeatable configuration management. Model-driven automation removes that bottleneck by enabling programmatic configuration workflows that scale without proportional increases in manual effort.
From a career perspective, proficiency in model-driven programmability significantly expands the roles and opportunities available to a certified CCNP Enterprise professional. Network automation engineers, infrastructure-as-code practitioners, and site reliability engineers working in network-adjacent roles all require the kind of skills that YANG, NETCONF, and RESTCONF represent. As organisations continue their migration toward intent-based networking, zero-touch provisioning, and continuous compliance verification, the demand for engineers who genuinely understand these technologies at both the conceptual and practical level will continue to grow. The CCNP Enterprise certification, with its explicit automation content, positions candidates directly at the intersection of traditional networking expertise and the programmatic skills that modern infrastructure demands.
