300-535
Automating and Programming Cisco Service Provider Solutions (300-535 SPAUTO)
Automating and Programming Cisco Service Provider Solutions (300-535 SPAUTO) Exam Guide
The 300-535 SPAUTO exam is designed to validate implementation of automated service-provider solutions across programming concepts, orchestration, programmable operating systems, APIs, and automation tools. It is most relevant to network engineers, service-provider automation specialists, and candidates pursuing Cisco certification paths associated with service-provider programmability. The first practical decision is scheduling: Cisco’s exam-topics archive lists February 2, 2026, as the last date to test, a date identified as past as of August 18, 2026. Confirm the exam’s current status with Cisco before investing in a booking plan; use this guide to organize the technical preparation if the exam is available to you or remains relevant to a transition path.
What does SPAUTO validate?
Cisco describes 300-535 SPAUTO as Automating and Programming Cisco Service Provider Solutions. Its stated focus is the implementation of service-provider automated solutions, including programming concepts, orchestration, programming operating systems, and automation tools. This makes the exam implementation-oriented rather than a narrow test of Python syntax or device configuration alone.
The blueprint connects software techniques to Cisco service-provider environments. You should be able to select an interface, represent network data, automate configuration or operational tasks, and reason about the behavior of IOS XE and IOS XR automation workflows.
The exam is also associated with the CCNP Service Provider and Cisco Certified DevNet Professional certifications. Cisco states that passing SPAUTO earns the Cisco Certified DevNet Specialist—Service Provider Automation and Programmability certification. Confirm how Cisco currently maps this exam into your intended certification path before scheduling.
The practical profile of a candidate
The strongest preparation profile combines networking knowledge with working familiarity with software, APIs, and automation. Cisco’s service-provider developer material describes automation as combining networking, virtualization, and software expertise, with programmable IOS XR and model-driven interfaces used for structured configuration and operational data.
You do not need to treat every listed tool as an isolated certification. Instead, learn the common decisions behind them: how data models describe a device, how a client authenticates and sends an operation, how an automation tool handles repeatability, and how telemetry returns operational information.
Is SPAUTO currently schedulable?
Check Cisco’s current exam catalog before making a study or payment decision. The supplied Cisco Learning Network archive lists February 2, 2026, as the last date to test for SPAUTO, and that date is identified as past as of August 18, 2026. The evidence does not by itself establish a replacement exam, a retirement policy, or a new booking window.
This status changes the order of operations. First search Cisco’s current certification and exam pages for SPAUTO or a successor. Then confirm whether your intended certification requirement accepts this exam, whether a transition option exists, and whether the exam page still permits registration. Do not assume that an archived blueprint means a live appointment is available.
If Cisco confirms that the exam is available for your situation, use the delivery details on the current exam page rather than relying on an older booking record. If it is not available, retain the blueprint as a technical study outline but redirect scheduling research toward Cisco’s current successor or certification requirements.
What Cisco lists for delivery
Cisco’s exam page lists SPAUTO as a 90-minute exam, with English and Japanese available languages. It lists the U.S. price as $300 and says Cisco Learning Credits are accepted. These are official page details, but availability, eligibility, and booking conditions should be checked on the live Cisco page before purchase.
The 90-minute duration makes prioritization important if you eventually sit the exam. Practice identifying the protocol, data model, tool, or automation pattern being tested instead of spending too long writing a perfect solution to one scenario.
What the date means for preparation
A past last-test date is a scheduling warning, not evidence that the technical blueprint is worthless. The current exam-topics document is identified as version 1.1 and remains useful for mapping the knowledge areas Cisco associated with the exam. Treat it as a controlled study reference while Cisco confirms the operational status.
Which blueprint domains deserve the most time?
The v1.1 blueprint gives the clearest basis for study allocation. Network Device Programmability carries 30 percent, Automation APIs and Protocols carries 30 percent, and Network Programmability Foundation carries 10 percent. The remaining blueprint areas should also be covered; do not convert the visible weights into a claim that lower-weight domains can be ignored.
The two 30-percent domains deserve the deepest hands-on work because together they cover device-facing automation and the interfaces used to operate or observe networks. The 10-percent foundation domain is smaller, but it supplies concepts needed to interpret the other areas correctly.
Build a checklist from the official v1.1 exam-topics document rather than from a third-party question list. For each objective, record whether you can explain it, recognize a correct implementation, and troubleshoot a small example.
Network Programmability Foundation — 10 percent
Network Programmability Foundation is weighted at 10 percent in the v1.1 blueprint. Use it to establish the vocabulary and workflow that the larger domains assume: Git, Python, virtual environments, REST and RPC APIs, and the role of Ansible or Terraform in IOS XE and IOS XR automation.
A useful study exercise is to create a small Python project in a virtual environment, place it under Git, and document the input, API call, response handling, and expected device effect. The objective is not to build a production system. It is to understand how source control, dependencies, code, and network intent fit together.
Common mistakes include learning commands without understanding the request and response path, installing packages globally and losing track of dependencies, and treating REST and RPC as interchangeable labels. Write down the transport, data representation, operation, and returned result for each interface you study.
Automation APIs and Protocols — 30 percent
Automation APIs and Protocols is weighted at 30 percent in the v1.1 blueprint. The listed coverage includes YANG, HTTP authentication, JSON, XML, YAML, gRPC, protobuf, RESTCONF, NETCONF, and NETCONF datastore comparison.
Study these as connected choices. YANG describes structured data models; JSON, XML, and YAML represent data in different contexts; RESTCONF and NETCONF expose management operations; gRPC and protobuf support a different service and serialization pattern. Your preparation should explain what each component contributes and what problem it does not solve.
Spend time comparing NETCONF datastore concepts rather than memorizing isolated definitions. Make a table showing the role of configuration and operational data, the operation being attempted, the data encoding, and the expected result. Then connect the table to a small client workflow.
HTTP authentication is a practical troubleshooting area. For every RESTCONF exercise, identify the endpoint, method, headers, credentials or token handling, payload format, and response code. A request that reaches the device but contains the wrong model or payload is a different failure from an authentication failure.
Network Device Programmability — 30 percent
Network Device Programmability is weighted at 30 percent in the v1.1 blueprint. The v1.1 topics include ncclient, YDK with YANG Suite, Netmiko, Ansible playbooks, gNMI, RESTCONF scripting, XPath, and model-driven telemetry with gRPC for IOS XR.
The preparation goal is tool selection and implementation judgment. Compare a direct CLI session through Netmiko with model-driven configuration through ncclient, YDK, or RESTCONF. Compare configuration automation with streaming telemetry through gNMI or gRPC. Be able to explain the data model, session type, payload or generated object, error handling, and repeatability implications.
Use the same small service scenario across several tools. For example, define the intended configuration, express it in a model-driven form, apply it through one client, and inspect the result through an operational or telemetry interface. Repeating the scenario reveals which differences belong to the tool and which belong to the underlying device model.
XPath deserves deliberate practice because it connects structured XML data with selection logic. Do not only memorize syntax. Start with a known XML response, write a selection expression, check which nodes it returns, and then test what happens when the hierarchy or namespace differs.
The remaining blueprint areas
The supplied facts identify three weighted domains but do not provide the weights or complete labels for every other v1.1 domain. Cover every objective in Cisco’s official exam-topics document, while avoiding invented percentages or assumptions about which topics Cisco considers minor.
For unweighted or less familiar objectives, use the same evidence test: define the concept, identify its place in an automation workflow, complete a small implementation, and diagnose one plausible failure. This prevents the common mistake of spending all preparation time on the tools that feel most familiar.
How should you sequence the study?
Study in dependency order, not in the order that tools appear in a search result. Start with Python, Git, virtual environments, data formats, and API mechanics; move to YANG and management protocols; then compare device automation tools and telemetry. Finish with mixed scenarios that require choosing an approach rather than recalling a definition.
This sequence reduces rework. A candidate who starts with a tool may copy a working example without understanding its model, transport, or response. A candidate who first understands the data and protocol layers can transfer that knowledge between ncclient, YDK, RESTCONF, Ansible, and gNMI exercises.
Phase one: establish a repeatable coding base
Create a clean Python workspace and use a virtual environment. Put scripts and notes in Git. Practice reading configuration from structured input, validating required fields, handling an error response, and producing a useful result for the operator.
Keep each exercise small enough to inspect. A script that connects, sends one well-understood request, records the response, and closes cleanly teaches more than a large script whose behavior you cannot explain. Add comments about assumptions, but do not use comments as a substitute for testing.
Phase two: learn models and interfaces together
Take one YANG-driven task and trace it from model to request. Identify the relevant data hierarchy, select the representation, determine the management protocol, authenticate, send the operation, and inspect the reply. Repeat the trace with a second interface where practical.
Include JSON, XML, and YAML in your exercises, but keep their roles distinct. A format is not itself an automation strategy. Ask what consumes the document, how the device interprets it, and how errors are represented.
Phase three: compare implementation tools
Build a comparison sheet for ncclient, YDK with YANG Suite, Netmiko, Ansible playbooks, and RESTCONF scripting. Record whether the method is primarily CLI-oriented or model-driven, what input it expects, how it represents errors, and how you would make repeated execution safe.
Then add gNMI and model-driven telemetry with gRPC for IOS XR. Focus on the difference between requesting or applying configuration and subscribing to operational data. A workflow that changes a device and a workflow that observes a device have different success criteria.
Phase four: integrate and explain
Use mixed case studies that require a design choice. Given a structured service intent, decide how to represent it, which interface to use, how to authenticate, how to apply it to IOS XE or IOS XR, and how to confirm the result. Explain why an alternative tool would be less suitable in that case.
Finish each case by documenting rollback or failure handling, even if the blueprint does not give a single production design. This habit tests whether you understand automation as an operational process rather than merely a successful API call.
What should a practical lab contain?
A useful lab does not need to imitate the live exam or depend on unauthorized questions. It should let you observe the full path from code to interface to device or representative response. Build exercises around Cisco’s listed technologies and record what you can prove from each run.
If you lack access to every platform named in the blueprint, do not claim mastery from reading alone. Mark the topic as conceptual, use Cisco’s official documentation and developer material for supported examples, and make the distinction visible in your study tracker.
A minimum exercise set
Create one Git-managed Python project with a virtual environment. Add a RESTCONF request using a structured payload, a NETCONF or ncclient operation, a Netmiko-based CLI task, and an Ansible playbook. For each, capture inputs, authentication handling, response or command output, and an error case.
Add a YANG-focused exercise using YDK with YANG Suite or another supported learning workflow. Identify the model elements used and compare the generated or submitted data with the device result. The point is to understand model-driven intent, not to memorize a library’s exact method names.
Add a telemetry exercise covering gNMI or model-driven telemetry with gRPC for IOS XR. Write down what is subscribed to or requested, how the returned data is encoded or structured, and how an operator would distinguish a missing signal from a value that is merely unchanged.
Use XPath against XML returned by a management operation. Test a valid selection, an overbroad selection, and a selection that fails because the hierarchy or namespace assumption is wrong.
How to record lab evidence
For every exercise, save a short record with five fields: objective, implementation choice, observed result, failure encountered, and lesson. This creates revision material tied to behavior rather than a list of product names.
Also note what you did not test. A disciplined gap list is more useful than a confident but unsupported statement that a tool is mastered. Prioritize gaps in the two 30-percent domains, then return to the foundation and remaining blueprint objectives.
How can you use Cisco’s training and developer material?
Use Cisco’s official blueprint as the boundary of scope, Cisco’s service-provider developer material for context and automation examples, and the SPAUI course description as an optional structured training route. Do not treat a course description, webinar, or sample code repository as a substitute for checking every exam objective.
Cisco’s SPAUI training description says the course prepares learners for SPAUTO and awards 24 Continuing Education credits toward recertification. That makes it potentially relevant to candidates who need structured instruction or continuing-education planning, but it does not remove the need to validate current course availability and certification applicability.
When a formal course is worth considering
A formal course is most useful when you need a planned progression through service-provider automation, lack a suitable lab, or want instructor-led clarification of IOS XE and IOS XR workflows. Before enrolling, compare the course objectives with the current Cisco blueprint and confirm that the course version matches your intended exam or successor.
If you already automate networks professionally, use the course description to identify gaps rather than repeating familiar material. Allocate extra time to model-driven interfaces, datastore behavior, telemetry, and tool comparison if those are outside your daily work.
How to use Cisco DevNet resources
Cisco’s service-provider developer material presents programmable IOS XR, model-driven interfaces, Crosswork, NSO, EPNM, WAE, and related automation use cases. Use that material to understand where API-driven configuration, orchestration, and telemetry fit in a service-provider operating model.
Keep product context separate from exam evidence. A product page can show why an automation pattern exists; the official v1.1 exam-topics document determines whether a named protocol, library, or technique belongs in your exam study boundary.
Which mistakes waste the most preparation time?
The most damaging mistake is studying tool names without tracing the workflow they implement. Other common errors are ignoring the exam-status check, treating copied code as understanding, overlooking data models, and preparing only configuration automation while neglecting telemetry and error handling.
Correct these mistakes by forcing every study note to answer four questions: what is being automated, which interface carries the operation, how is the data modeled or encoded, and how is success verified? If a note cannot answer those questions, it is probably too shallow for implementation-focused preparation.
Mistake: planning around an old appointment assumption
Because the supplied archive lists February 2, 2026, as the last date to test, do not build a calendar around an assumed future booking. Check Cisco first, record the page and version you relied on, and identify any successor or transition requirement before committing study time.
Mistake: memorizing request shapes without context
A memorized RESTCONF or NETCONF payload is fragile when the model, namespace, datastore, authentication method, or response changes. Reconstruct the request from the data model and endpoint purpose. Practice explaining why the payload is valid and what response would indicate a model or authorization problem.
Mistake: treating all automation as equivalent
Netmiko, ncclient, YDK, Ansible, RESTCONF scripting, gNMI, and telemetry workflows solve related but different problems. Compare their abstractions and outputs. A CLI command sent successfully is not the same kind of evidence as a validated model-driven transaction or a streaming operational subscription.
Mistake: neglecting failure paths
Candidates often stop when a lab returns the expected result. Add invalid credentials, malformed data, an unavailable endpoint, a wrong XPath selection, and a device-side rejection where your environment permits. Then document what the client reports and what an operator should inspect next.
How should you measure readiness?
Readiness should be demonstrated through explanation and implementation, not through a percentage on an unofficial quiz. You are closer to ready when you can choose among the listed tools, explain the relevant protocol and data model, write or adapt a small workflow, and diagnose why a result is not what you expected.
Use the official v1.1 blueprint as a coverage matrix. Mark each objective as explain, implement, troubleshoot, or not yet studied. Require at least an explanation and a practical exercise for every objective; require troubleshooting practice for the two 30-percent domains.
A useful self-review session
Take a mixed set of your own lab prompts and answer without opening notes. For each prompt, state the intended outcome, the interface, the data representation, the authentication approach, and the verification method. Then implement the smallest working version and inspect the response.
Review errors by category rather than by script. Group them into Python or dependency problems, authentication problems, protocol or transport problems, model or payload problems, device behavior, and verification problems. This reveals whether your weakness is conceptual or merely procedural.
What not to use as readiness evidence
Do not treat exam dumps, leaked questions, or memorization as a reliable path to passing. They do not establish that you can implement or troubleshoot the service-provider automation skills described by Cisco, and they create a risk of preparing for content that is inaccurate, unauthorized, or no longer current.
A better final check is to explain a complete workflow to another engineer using your own lab records. If you cannot justify the tool and protocol choice, return to the blueprint objective instead of adding more random practice questions.
A four-stage roadmap for a working candidate
A practical roadmap begins with status verification, then builds foundations, develops protocol and device-automation skill, and ends with integrated review. Adjust the calendar to your confirmed exam or transition date; the official sources supplied here do not establish a new booking deadline.
The roadmap is deliberately output-based. Each stage ends with something you can inspect: a tracked project, a protocol comparison, working or documented labs, and a gap-controlled final review.
Stage one: verify the target and inventory gaps
Confirm the current SPAUTO status, certification relationship, language, duration, price, and booking conditions on Cisco’s live exam page. Download or retain the current v1.1 blueprint, list every objective, and rate your experience with Python, Git, APIs, YANG, IOS XE, IOS XR, Ansible or Terraform, and telemetry.
Choose a lab scope that matches your access. Separate platform access from conceptual study so a lack of one device does not hide an unstudied protocol.
Stage two: build the foundation
Create the Git-managed Python project and virtual environment. Practice structured data, REST and RPC concepts, authentication, response handling, and basic automation hygiene. Add an Ansible or Terraform comparison note for IOS XE and IOS XR automation rather than learning only one command pattern.
At the end of this stage, you should be able to read a small automation workflow and identify its inputs, dependency environment, interface, payload, and expected result.
Stage three: concentrate on the two 30-percent domains
Work through Network Device Programmability, which is weighted at 30 percent, and Automation APIs and Protocols, which is weighted at 30 percent. Rotate among ncclient, YDK with YANG Suite, Netmiko, Ansible playbooks, RESTCONF scripting, gNMI, XPath, and model-driven telemetry with gRPC for IOS XR.
Do not study each tool in a vacuum. Reuse one service or configuration scenario and compare how each method models, sends, applies, or observes the intended change.
Stage four: integrate, review, and decide
Run mixed implementation and troubleshooting exercises, then revisit Network Programmability Foundation, which is weighted at 10 percent, and every remaining official objective. Close gaps with Cisco sources, not with unverified question banks.
Only after Cisco confirms that your target exam or transition path is available should you finalize booking decisions. If the exam is unavailable, preserve your lab portfolio and map each skill to the current Cisco successor requirements.
What should you do next?
Start with the scheduling check, not the study calendar: open Cisco’s current SPAUTO page and Learning Network information, confirm whether 300-535 remains a valid target, and identify the applicable certification route. If confirmed, download the v1.1 topics, create a coverage matrix, and begin with a small Git-managed Python and API lab.
Your immediate technical priority should be a balanced comparison of model-driven interfaces, RESTCONF and NETCONF behavior, device automation tools, and telemetry. Keep evidence of what you implemented and what remains conceptual. That record will help you decide whether formal SPAUI training, additional lab access, or a successor exam is the most sensible next investment.
A short action checklist
Verify current exam status and certification applicability with Cisco.
Save the official v1.1 blueprint and turn every objective into a study item.
Allocate substantial practice to Network Device Programmability and Automation APIs and Protocols, each weighted at 30 percent in the v1.1 blueprint.
Cover Network Programmability Foundation, weighted at 10 percent, before relying on advanced tool examples.
Build and document small exercises using the listed protocols, tools, data models, and telemetry methods.
Recheck Cisco’s live delivery details before paying or booking.
Conclusion
SPAUTO preparation is best treated as a service-provider automation engineering project: understand the model, choose the interface, implement the workflow, and verify the result. The blueprint’s two 30-percent domains should drive the deepest practice, while the 10-percent foundation domain supports everything that follows. Because Cisco’s supplied archive lists February 2, 2026, as the last date to test, confirm the exam’s current status before scheduling. If the target remains valid, use the official v1.1 blueprint and documented labs; if not, carry the same skills into the Cisco-approved successor path.
Related exams
- 300-510 exam — Implementing Cisco Service Provider Advanced Routing Solutions
- Implementing Cisco Service Provider VPN Services (300-515 SPVI)
- 300-540 exam — Designing and Implementing Cisco Service Provider Cloud Network Infrastructure (SPCNI)
- Implementing and Operating Cisco Service Provider Network Core Technologies (350-501 SPCOR)