The sp-automation-assurance exam domain covers how to implement SDN controllers, model-driven telemetry, and network assurance. Programmability and SDN in Service Provider matter because they replace manual, error-prone configuration with centralised, automated control—saving time, reducing mistakes, and enabling networks to scale like cloud services. For the 350-501 exam, you must understand how controllers speak to devices, how telemetry streams data instead of polling, and how assurance checks health without human intervention.
Jump to a section
A simple way to picture Programmability and SDN in Service Provider
A food delivery app is a centralised brain that controls how every restaurant, driver, and customer interacts. The app does not cook the food or drive the car; it tells each part what to do, when to do it, and how to report back. In the old way, a customer would call a restaurant directly, the restaurant would call a delivery driver they knew, and the driver would call the customer to find the address. Each person had to memorise phone numbers, wait on hold, and hope nothing changed. Every new driver or menu update meant someone had to manually update a list. It was slow, error-prone, and hard to scale.
Now, with the app, everything changes. The restaurant does not need to know the driver's phone number; the app gives the driver a pickup code. The driver does not need to know the customer's address from memory; the app shows a map. If a new restaurant joins, the app updates in seconds for everyone. If a driver's phone battery dies, the app can reassign the order instantly to another driver without anyone making a single phone call. That central coordination, automated rule enforcement, and real-time status updates are exactly how Software-Defined Networking (SDN) and programmability work in a service provider network. The routers and switches become the restaurants and drivers, and the SDN controller is the app that orchestrates everything.
Let us start with the biggest idea: a traditional network is like a group of people each doing their own thing without a manager. Each router (a box that forwards data packets) and each switch (a box that connects devices within a network) has its own configuration file, its own routing table (a set of rules that decide where to send data), and its own way of handling failures. To make a change, an engineer logs into each device individually, types commands, and hopes they did not forget to update the same route on the next box. This is called the "control plane" (the brain that decides where traffic goes) and the "data plane" (the muscles that actually move the traffic) being bundled together in every device. It works for small networks but becomes a nightmare when you have hundreds or thousands of devices spread across a country.
Software-Defined Networking (SDN) separates the brain from the muscles. In SDN, the control plane is pulled out of each router and placed into a central controller—a powerful software application running on a server. The controller has a global view of the entire network. It knows every link, every device, and every path. When a change is needed, an engineer configures the controller once, and the controller pushes those changes to all the devices automatically. The devices themselves become simple forwarding engines: they just follow orders from the controller. This separation is the fundamental shift that programmability makes possible.
Now, how does the controller talk to the devices? It uses protocols like NETCONF (Network Configuration Protocol) or RESTCONF (RESTful Configuration Protocol). Let us define those:
NETCONF: A protocol that allows the controller to send configuration commands to a device using XML (a structured text format). It is like sending a formal letter with a clear list of changes, and the device replies with a confirmation.
RESTCONF: A simpler, web-friendly version of NETCONF that uses HTTP (the same language your browser uses) and either JSON or XML. It is like sending a text message instead of a formal letter.
Both protocols use a data model called YANG (Yet Another Next Generation). YANG is a template language that defines exactly what configuration options a device supports. Think of YANG as a fill-in-the-blank form. Instead of guessing what commands are valid, the controller reads the YANG model and knows, for example, that a router's interface can have an IP address, a subnet mask, and a description. The controller fills in the blanks, then sends the completed form to the device via NETCONF or RESTCONF.
Now, let us talk about model-driven telemetry (MDT). In the old days, to check if a network link was overloaded, an engineer would poll the device every five minutes by asking "What is your CPU usage?" This is called polling. The device answers, the engineer logs it, and then waits five minutes to ask again. This wastes bandwidth, misses events that happen between polls, and leaves the engineer blind during spikes. Model-driven telemetry flips the model: instead of the engineer asking, the device pushes data automatically. The device says, "My CPU just hit 90%, here is the data, now!" or "I have a new BGP peer (a router neighbour that shares routing information), here is the update." This is called streaming telemetry. The data is sent using protocols like gRPC (a high-speed remote procedure call) or the new HDLC-like telemetry protocols. The controller or a monitoring tool receives this continuous stream and can react in real time—for example, by automatically rerouting traffic around a congested link.
Network assurance is the practice of using that streamed telemetry to verify that the network is behaving as intended. It is not enough to know a device is up; you need to know it is forwarding traffic correctly, that security policies are applied, and that routing tables match the design. Assurance tools collect telemetry, compare it to a golden configuration or intent model, and generate alerts when deviations occur. For example, if an engineer accidentally configures the wrong access control list (ACL) on a router, an assurance tool detects that the traffic flow does not match the expected pattern and raises an alarm. This replaces manual audits and reduces the chance of human error causing network outages.
Why does this matter for the 350-501 exam? Cisco expects you to know the key components: SDN controllers like Cisco's NSO (Network Services Orchestrator) or open-source OpenDaylight, the protocols NETCONF and RESTCONF, the data model language YANG, and the telemetry protocols gRPC and streaming telemetry. You also need to understand the difference between the traditional CLI-based configuration and API-driven automation. The exam tests these concepts through scenario-based questions where you must choose the correct protocol or tool for a given situation. For instance, they might ask: "A service provider wants to automate the onboarding of new customer VPNs across 50 routers. Which approach is most scalable?" The answer is SDN with NETCONF/YANG, not logging into each router via SSH.
Finally, a note on controllers versus orchestrators. A controller directly manages the state of network devices in real time. An orchestrator manages higher-level services and translates business intent into configurations for the controller. For the exam, think of the controller as the direct brain talking to routers, and the orchestrator as the boss that tells the brain what to do. Both are part of the SDN ecosystem.
Define the Intent Model
The IT team defines the desired network behaviour using YANG data models. For example, they create a model that describes a new customer VPN service: bandwidth 100 Mbps, VLAN 200, routed via a specific core router. This model becomes the golden state.
Configure the SDN Controller
The controller (e.g., Cisco NSO) is installed and connected to the network devices. The devices must have NETCONF enabled and SSH keys exchanged so the controller can authenticate and send configurations securely.
Develop Automation Scripts
Engineers write Python or Ansible scripts that use the controller's northbound API to push the YANG-modelled service configuration. The script reads the intent model, converts it into NETCONF payloads, and triggers the deployment.
Deploy Service via Controller
The script sends a NETCONF edit-config message to the controller. The controller translates that into individual NETCONF sessions to each affected device (access switch, edge router, core router) and commits the changes as a single transaction. If one device fails, the entire change rolls back automatically.
Enable Telemetry Streaming
On each device, a telemetry subscription is configured. The engineer defines which sensor paths (e.g., interface statistics, CPU usage) to stream, the interval (e.g., every 10 seconds), and the destination collector IP. The device then pushes the data without being polled.
Monitor and Assure
The collector receives the telemetry data and feeds it into an assurance dashboard. The dashboard compares live data to the intent model. If the measured bandwidth for the new VPN differs from the configured 100 Mbps, an alert is generated, and the system can automatically re-apply the correct config or escalate to the team.
Continuous Improvement
Based on telemetry analytics, the team identifies trends—for example, that a particular core link always hits 70% utilisation during peak hours. They adjust the intent model to add more capacity, which triggers the controller to reconfigure bandwidth policies across the network automatically.
Imagine a mid-sized internet service provider (ISP) called FiberFast that offers broadband to 50,000 homes in a city. FiberFast has a core network of 20 routers, 100 edge switches, and 500 customer-access devices (DSLAMs or ONTs). Currently, when a customer orders a new 100 Mbps plan, an engineer logs into each device along the path—the customer's access device, the edge switch, and the core router—to manually configure quality-of-service (QoS) shaping and routing. This takes about 30 minutes per order and sometimes mistakes are made, such as forgetting to apply the speed cap on the core router, causing the customer to get 1000 Mbps for free. The ISP decides to implement SDN and programmability to fix this.
Here is what the IT professional, let us call her Priya, does:
Priya installs a Cisco NSO controller on a server. She connects it to every device in the network using NETCONF, which requires enabling NETCONF on each device and generating SSH keys for secure authentication. She also deploys a YANG model library that describes all configurable parameters across the different device models.
Priya writes a Python script using the NETCONF library (called ncclient) that, when triggered by a customer order, generates a service configuration. The script reads a template that specifies the new bandwidth limit, the VLAN ID for the customer, and the next-hop router. The script sends this configuration via NETCONF to the access device, the edge switch, and the core router simultaneously. The entire process takes 30 seconds instead of 30 minutes.
Priya enables model-driven telemetry on the core routers. She configures them to stream CPU, memory, and link utilisation data every 10 seconds to a central monitoring platform (like Prometheus or Cisco's Crosswork). When a core link reaches 80% utilisation, the telemetry system triggers a threshold alert. The network operations centre (NOC) receives an automatic ticket, and Priya is paged only if the issue escalates.
Priya sets up a network assurance dashboard (Cisco's Network Assurance Engine) that compares the telemetry data against the intent model. It detects if a misconfiguration (e.g., an ACL blocking a customer's traffic) has been applied inadvertently. The tool creates a deviation report and automatically rolls back the change if it is a known high-risk pattern.
The result: FiberFast reduces service activation time by 95%, eliminates configuration errors, and reduces network downtime by half because telemetry catches problems before customers complain. Priya now spends her time improving scripts and analysing trends instead of typing commands.
The 350-501 exam tests 'Programmability and SDN in Service Provider' with a heavy focus on identifying the correct technologies and their purposes. Expect 6-10 questions on this domain, often mixed into larger scenario-based questions. The exam loves to list three protocols (SNMP, NETCONF, RESTCONF) and ask which one uses YANG data models and supports transactional configuration commits—the answer is NETCONF. Another common pattern is to show a traditional monitoring setup with SNMP polling and ask what its disadvantage is compared to streaming telemetry. The correct answer is that polling misses transient events and wastes bandwidth, while streaming telemetry provides real-time data.
Key concepts they love to test:
The difference between SNMP (Simple Network Management Protocol) and NETCONF. Trap: SNMP is for monitoring, not configuration. NETCONF is for both configuration and state retrieval. The exam may describe a scenario where you need to change a device's IP address; the correct tool is NETCONF or RESTCONF, not SNMP.
YANG as a data modelling language. Trap: they might ask what YANG is used for. The answer is to define the structure of configuration and state data, not to transport data. NETCONF transports YANG-modelled data.
The role of an SDN controller versus a traditional management system. Trap: they might list a tool like SolarWinds (traditional NMS) and ask if it is an SDN controller. The answer is no, because it does not separate the control plane or provide real-time device state manipulation—it only reads data.
Telemetry subscription: the exam may ask how to configure a device to push data to a collector. The answer is through a telemetry subscription that specifies the sensor path (the data you want), the interval (the push frequency), and the destination (the collector's IP and port).
The concept of northbound and southbound interfaces. The northbound interface is between the SDN controller and applications (e.g., REST API), and the southbound interface is between the controller and the network devices (e.g., NETCONF, OpenFlow). Trap: they might reverse them.
Trap patterns to watch for:
A question that says, 'Which protocol is used by SDN controllers to configure devices in a service provider network?' Options include OpenFlow, NETCONF, CLI, and SNMP. OpenFlow is a southbound protocol for forwarding table manipulation (used in data centre SDN), but for service provider networks, NETCONF is more common for configuration. The exam expects NETCONF for SP networks.
Another trap: 'What is the primary benefit of model-driven telemetry over SNMP polling?' One option says 'it reduces CPU on the device', which is false. Actually, streaming telemetry increases CPU slightly because the device must send data periodically, whereas SNMP polling only uses CPU when queried. The correct benefit is real-time event detection and lower bandwidth usage overall because the data is sent only when meaningful or at a configurable cadence.
What to memorise: the acronyms—NETCONF, RESTCONF, YANG, gRPC, MDT, NSO, and their one-sentence definitions. Also, remember that Cisco's implementation of SDN for SP is called NSO (Network Services Orchestrator), which uses service models to automate multi-device configurations. The exam expects you to know that NSO uses YANG models and NETCONF to manage devices.
SDN separates the control plane (the decision-making brain) from the data plane (the forwarding hardware), centralising network intelligence into a controller.
NETCONF and RESTCONF are the two primary protocols used to configure network devices in programmable networks, with NETCONF supporting transactional commits and rollback.
YANG is a data modelling language that defines the structure of configuration and state data; it is not a transport protocol.
Model-driven telemetry pushes data from devices to collectors in real time, eliminating the blind spots and inefficiencies of traditional SNMP polling.
Network assurance compares actual telemetry data against an intent model to detect configuration drift and misbehaviour automatically.
Cisco's Network Services Orchestrator (NSO) uses service models (YANG) and NETCONF to automate multi-device configurations across a service provider network.
In the 350-501 exam, the correct tool for configuration automation in a service provider context is almost always NETCONF with YANG, not SNMP or CLI scripting.
These come up on the exam all the time. Here's how to tell them apart.
NETCONF
Supports transactional commit and rollback
Uses multiple datastores (candidate, running, startup)
Operates over SSH or TLS
RESTCONF
Stateless, does not support transaction rollback
Uses a single running datastore only
Operates over HTTP/HTTPS only
SNMP Polling
Data is pulled by the collector at fixed intervals
Receives only the data that was requested at that moment
Uses MIBs (Management Information Bases) for data definition
Model-Driven Telemetry
Data is pushed by the device autonomously at a cadence or on change
Receives continuous stream of data, including transient events
Uses YANG models for data definition
Traditional CLI Configuration
Engineer logs into each device individually
No built-in rollback at multi-device level
Manual audit and compliance checking
SDN Controller-based Configuration
Controller pushes config to all devices simultaneously
Supports atomic transactions and rollback across devices
Automatic compliance checking via intent model comparison
Mistake
SDN and network automation are the same thing.
Correct
SDN is a specific architecture that separates the control and data planes and uses a central controller. Network automation is a broader concept that includes scripting, configuration management tools (e.g., Ansible), and APIs, which can exist without SDN.
Beginners see both involve automation and assume they are identical. In reality, you can automate a traditional network with scripts without decoupling the control plane, which is the defining feature of SDN.
Mistake
YANG is a protocol for sending configuration data.
Correct
YANG is a data modelling language used to define the structure of configuration and state data. It is not a transport protocol. The protocols that transport YANG-modelled data are NETCONF and RESTCONF.
Because YANG is often mentioned alongside NETCONF, beginners incorrectly assume it is part of the communication method rather than a separate language for defining what data looks like.
Mistake
Model-driven telemetry uses SNMP but in a different way.
Correct
Model-driven telemetry is fundamentally different from SNMP. SNMP uses a request-response (poll) model; MDT uses a push model where the device sends data autonomously. They operate on different protocols and data models (YANG for MDT, MIBs for SNMP).
SNMP has been the dominant monitoring protocol for decades, so beginners assume any telemetry must be an evolution of SNMP. Actually, MDT originated from the need to overcome SNMP's limitations and is architecturally distinct.
Mistake
An SDN controller replaces all the intelligence in routers, so routers become dumb switches.
Correct
Routers in an SDN architecture still perform data plane forwarding using hardware ASICs and may run routing protocols for fallback. The controller manages the control plane, but the device is not 'dumb'—it maintains local state, handles failures, and can be configured to operate in a hybrid mode.
The marketing term 'dumb switches' is oversimplified. Beginners think the device is totally passive, but in practice, devices retain enough intelligence to forward packets even if the controller is temporarily unreachable.
Mistake
NETCONF and RESTCONF are interchangeable; you can use either for anything.
Correct
NETCONF is more feature-rich: it supports transactional rollback, multiple configuration datastores (candidate, running, startup), and built-in operations like lock/unlock. RESTCONF is simpler and stateless, better for lightweight web-based automation. They are not drop-in replacements.
Both use YANG and HTTP/TLS, so beginners assume they are versions of the same protocol. The exam tests the specific advantages of NETCONF for atomic configuration changes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
NETCONF is a full-featured protocol that supports transaction rollback, multiple datastores (candidate, running), and operations like lock/unlock. RESTCONF is a lightweight HTTP-based protocol that is simpler but less robust. For the exam, NETCONF is preferred for complex configurations that require transactional integrity.
No, you do not need to write YANG models. You need to understand that YANG is a data modelling language used to define the structure of configuration data, and that NETCONF/RESTCONF use YANG-modelled data. The exam will test recognition and application, not creation.
SNMP is still used for basic monitoring in legacy environments, but the exam focuses on model-driven telemetry for modern programmable networks. SNMP is not considered a programmable network technology because it is poll-based and does not support configuration transactions.
The SDN controller centralises the control plane: it maintains a global view of the network, computes optimal paths, and pushes forwarding rules to devices. It also manages configuration changes via NETCONF/RESTCONF, replacing manual CLI access on each device.
When a device fails, its telemetry stream stops. The collector detects the absence of data within a configured timeout (e.g., 30 seconds) and triggers an alert. This is faster than polling, where the failure might not be detected until the next poll cycle (e.g., 5 minutes).
A sensor path is a YANG-defined XPath expression that specifies exactly which data the device should stream. For example, '/interfaces/interface/statistics' means stream all interface statistics. The collector subscribes to specific sensor paths on the device.
You've finished Programmability and SDN in Service Provider. Continue through the 350-501 study guide to build a complete picture of the exam.
Done with this chapter?