300-550 NPDESI Exam Guide: Skills, Study Priorities, and Scheduling Decisions
Cisco 300-550, the Network Programmability Design and Implementation Specialist (NPDESI) exam, validates practical understanding of network programmability fundamentals, APIs and automation protocols, data models, operations, and controllers. It is intended for candidates working with programmable Cisco networks and automation workflows. This guide helps you decide whether your current skills are ready, which blueprint areas deserve the most study time, how to practise without relying on unauthorized question material, and what to verify before registration.
What 300-550 validates
300-550 tests whether you can connect programming concepts with network design and implementation decisions. The subject areas span network programmability fundamentals, APIs and automation protocols, data models, operations, and controllers rather than a single programming language or one Cisco platform.
The exam is identified by Cisco as the Network Programmability Design and Implementation Specialist exam, abbreviated NPDESI. Its scope requires you to recognize how applications communicate with network devices, how configuration and operational data is represented, and how automation tools fit into a controlled network-management process.
This is best treated as an applied technology exam. Reading definitions is not enough if you cannot explain why an engineer would choose NETCONF, RESTCONF, an SDK, a configuration-management tool, or a controller for a particular task. Your preparation should therefore alternate between concept review and small implementation or analysis exercises.
Cisco describes the published exam-topic list as a general guideline. Related topics may also appear, and Cisco says the guidelines may change without notice. Use the blueprint to organize preparation, but confirm the current official information before committing to a booking.
Who should take this exam
The exam is most relevant to network professionals who need to design, automate, or maintain programmable Cisco environments. It suits candidates who already understand core networking and now need to work across APIs, data models, automation tooling, security controls, and controller-based operations.
A strong candidate profile includes experience interpreting device configuration, reading basic Python, using Linux command-line tools, and reasoning about authentication and authorization. You do not need to make every topic a software-development specialty, but you should be able to follow code and select an appropriate automation approach.
Candidates coming from traditional network administration should give extra attention to data representation, API behavior, and software delivery concepts. Candidates coming from software or DevOps backgrounds should deliberately strengthen Cisco platform knowledge, device management protocols, and the differences between standardized and platform-specific models.
Before studying, write down two or three tasks you expect to perform at work: for example, retrieving interface data, validating a YANG model, applying a repeatable configuration, or protecting a management plane. Map each task to an exam domain. This reveals whether your gaps are conceptual, platform-specific, or procedural.
How the blueprint should shape study time
The published weights make Data Models and APIs and Automation Protocols the first priority, while Network Programmability Fundamentals provides the foundation for the remaining topics. Use the percentages to sequence effort, not to assume that lower-weight areas can be ignored.
The v1.1 blueprint allocates 23% to Data Models. This area includes YANG model validation and development, YANG with NETCONF and RESTCONF, platform-specific and standardized data models, the Management Information Tree, and VISORE.
The v1.1 blueprint allocates 24% to APIs and Automation Protocols. Prepare northbound and southbound APIs, Cisco platform APIs for NX-OS, IOS XR, IOS XE, and ASA OS, RESTful APIs, RESTCONF, NETCONF, OpenFlow, and the listed transport or security technologies: TLS, HTTPS, HTTP, gRPC, and SSH.
The v1.1 blueprint allocates 16% to Network Programmability Fundamentals. Review the purpose of programmability, the relationship between applications and network devices, and the terminology needed to distinguish an API, protocol, data model, controller, and automation tool.
Do not turn these percentages into a prediction of how many questions will appear in a particular session. They are blueprint allocations, so use them to choose revision depth and practise coverage. The official outline remains the controlling reference for the topics you study.
Build a data-model study track
Data Models deserves a dedicated study track because it combines syntax, structure, validation, device representation, and protocol use. Your target is not merely to recognize the word YANG; it is to follow how a model describes configuration or state and how a client uses that description.
Begin by learning the role of YANG in representing network data. Then practise distinguishing a model's structure from the protocol that retrieves or changes data. NETCONF and RESTCONF are not interchangeable labels for YANG; understand how the model and management protocol work together.
Add platform-specific and standardized data models to your comparison notes. For each, record what kind of portability or device specificity it provides, what problem it solves, and what trade-off it creates for an automation design. This is more useful than memorizing isolated definitions.
Include the Management Information Tree and VISORE in the same study sequence. Draw a small hierarchy of data paths and explain how you would locate the object needed for an operational or configuration task. If you cannot describe the path from an intended change to the relevant model node, revisit the structure before moving on.
A practical exercise is to take a simple interface or routing requirement and describe it in three stages: the intended network outcome, the modelled data involved, and the management method used to exchange that data. This exposes confusion between a business requirement, a data model, and an API call.
Compare APIs and protocols by use
Study APIs and automation protocols through design choices rather than a vocabulary list. For each technology, ask what it exposes, which direction the interaction takes, what data or operation is involved, and what security or transport mechanism must be considered.
Make a comparison table with northbound and southbound APIs as the first distinction. Then add RESTful APIs, RESTCONF, NETCONF, and OpenFlow. The purpose is to explain the role each plays in an architecture, not to claim that one is universally superior.
Include the Cisco platform coverage explicitly: NX-OS, IOS XR, IOS XE, and ASA OS APIs. A common preparation mistake is learning a generic REST example while overlooking how platform families expose different capabilities or operational models.
Review TLS, HTTPS, HTTP, gRPC, and SSH as related technologies in the communication path. Practise identifying whether a scenario is asking about an application interface, a management protocol, a transport, or a security mechanism. Many wrong answers arise from selecting a familiar term at the wrong architectural layer.
When practising, write a short justification for every choice: “Use this because…” and “Do not use that because…”. The explanation should refer to the required operation, platform, data representation, direction, or protection method. This makes your reasoning portable when a question changes its wording.
Use code and command practice intelligently
The blueprint includes Python code analysis, SDK use cases, and Linux commands, so preparation should include interpretation as well as memorization. You should be able to trace what a short script or command is intended to do and identify an obvious implementation or security issue.
For Python, practise reading variables, loops, conditionals, functions, dictionaries, lists, exception handling, and basic request or SDK patterns. Focus on inputs, outputs, control flow, and the network action being attempted. You do not need to turn every exercise into a large application.
For SDK use cases, ask what the SDK abstracts and what the caller still needs to supply: credentials, target device, resource or operation, payload, error handling, and output processing. A script that runs syntactically may still be unsafe or unsuitable if it applies an unintended change or exposes credentials.
Use Linux commands to reinforce operational reasoning. Practise interpreting command output, locating files, filtering text, checking processes or connectivity, and identifying permissions. The objective is to understand what a command contributes to an automation workflow, not to collect a disconnected list of shell options.
Keep a code-review notebook. For each exercise, record the intended result, the evidence in the code, one possible failure, and one security concern. Revisit entries after a few days without looking at the solution. If you can explain the behavior but cannot predict the result, your review needs more hands-on repetition.
Cover operations, automation, and controllers
Operations preparation should connect automation tools with the way teams manage change. The blueprint covers orchestration and automation, agent-based versus agentless configuration management, Puppet, Chef, Ansible, OpenStack Neutron, Agile versus Waterfall, and DevOps concepts.
Start with the agent-based and agentless distinction, then compare the operational implications. Ask where the automation component runs, how it communicates with the target, what must be installed or maintained, and how that affects scale, control, and troubleshooting.
Study Puppet, Chef, and Ansible as examples within configuration-management practice. Build a one-page comparison based on execution model, representation of desired state, dependencies, and likely workflow. Avoid reducing the comparison to brand recognition; the useful skill is selecting or explaining a tool in context.
Include OpenStack Neutron in your review of network automation and orchestration. Place it in an architecture diagram with the surrounding services or network resources you are studying. The diagram should make clear whether a component is coordinating infrastructure, managing a device, modelling data, or providing an interface to another system.
Finally, connect Agile, Waterfall, and DevOps concepts to network change delivery. Practise explaining how planning, testing, version control, repeatability, feedback, and rollback affect an automated change. This prevents a narrow study approach in which tools are memorized without understanding the delivery process they support.
Treat security as a design requirement
Security is embedded in the technical topics, not an optional final chapter. Prepare to reason about management-plane security, least privilege, and whitelist-versus-blacklist approaches alongside credentials, protocols, access scope, and automation behavior.
For least privilege, identify the smallest set of permissions required for the task. Separate read-only discovery, operational retrieval, configuration change, and administrative functions in your notes. When reviewing an example, ask whether the account, token, or process can do more than the stated job requires.
Compare whitelist and blacklist approaches by their default treatment of access. Then apply each to a concrete management scenario and consider what happens when a new endpoint, command, or service appears. The correct design depends on the required policy and risk, so avoid memorizing an absolute rule without context.
Review the management plane as an attack surface. A technically successful automation workflow can still be unacceptable if it transmits credentials improperly, exposes an unnecessary service, grants excessive rights, or fails to validate the target and requested change.
During every lab or code exercise, add one security checkpoint: How is access authenticated? What is authorized? Which transport protection is used? What would be logged? This habit improves both technical understanding and decision-making under exam conditions.
A practical study roadmap
A staged plan works better than reading the blueprint repeatedly. Start with a diagnostic, build the two largest technical tracks, add code and operations, then use mixed review to expose weak connections between domains.
Stage one is orientation and diagnosis. Read the official topic material, list every term you cannot explain, and mark each as familiar, partly understood, or new. Test yourself with short explanations rather than searching for answers immediately. Confirm that your study material matches the relevant official blueprint version and check Cisco for any later change.
Stage two establishes fundamentals and APIs. Review Network Programmability Fundamentals, then move to northbound and southbound interactions, platform APIs, RESTful APIs, RESTCONF, NETCONF, OpenFlow, and the listed transport and security technologies. Draw architecture diagrams and annotate the direction and purpose of each interaction.
Stage three concentrates on Data Models. Work through YANG validation and development, model categories, NETCONF and RESTCONF usage, the Management Information Tree, and VISORE. Pair every reading session with a small data-path exercise or diagram. Your checkpoint is the ability to explain how a requirement becomes modelled data and then an exchange with a device.
Stage four adds implementation fluency. Analyse short Python examples, identify SDK use cases, practise relevant Linux command interpretation, and review management-plane security, least privilege, and whitelist-versus-blacklist approaches. Keep the exercises small enough that you can inspect the result and explain each step.
Stage five covers operational context. Compare orchestration with automation, agent-based with agentless management, Puppet with Chef and Ansible, and Agile, Waterfall, and DevOps concepts. Include OpenStack Neutron in your architecture notes and controllers in your explanation of how a system coordinates network behavior.
Stage six is mixed practice. Rotate domains instead of studying one topic until it feels familiar. For each missed question or exercise, classify the problem as a definition gap, protocol confusion, data-model error, code-reading error, or careless reading. Fix the category, not just the individual answer.
How to practise without misleading yourself
Practice quality matters more than collecting a large number of questions. Use official topic boundaries, documentation, and your own small exercises to test reasoning; do not rely on dumps, leaked questions, or memorized answer patterns as evidence of readiness.
After each practice set, review every response, including correct guesses. Explain why the selected option fits the scenario and why the alternatives do not. If you cannot do that, mark the topic for review even when the result looks good.
Create scenario prompts from the blueprint. For example, ask which layer is being described, whether the task is configuration or retrieval, whether the data is standardized or platform-specific, what permissions are required, and which communication method matches the design. This develops transfer rather than recognition.
Avoid a common trap: treating a lab that succeeds once as proof that you understand the concept. Change one variable at a time, such as the target platform, operation, data path, permission level, or transport protection. Then explain what should change and what should remain constant.
Use timed mixed practice only after you can explain the fundamentals. Timing can expose slow reading or indecision, but it cannot repair a missing mental model. Keep a final error list limited to recurring issues so the last revision period remains focused.
What the delivery facts mean for scheduling
Cisco lists 300-550 as a 90-minute exam with 65–75 questions, in English, and identifies Pearson VUE as the registration and delivery partner. Use these details to plan pacing and to locate the current booking information, but verify all scheduling information before registering.
The listed question range means you should practise making decisions without spending an excessive amount of time on one unfamiliar scenario. Your preparation should include concise reading, elimination of answers that belong to the wrong architectural layer, and a willingness to move on when the evidence is insufficient.
Because Cisco lists English as the available exam language, candidates should study the technical vocabulary in English and practise reading distinctions such as configuration versus operational data, northbound versus southbound, and agent-based versus agentless. This is a preparation recommendation based on the listed language, not a claim about personal language ability.
Pearson VUE is the identified registration and delivery partner. Follow Cisco’s current exam and registration guidance for the available booking path and delivery choices. Do not assume that a catalogue entry or an older preparation page reflects current availability.
Cisco’s current-exams and retired-exams pages retrieved for this research do not provide a current availability entry or a retirement date specifically for 300-550. That means this guide does not assert that the exam is currently available or retired. Check the official Cisco listing and Pearson VUE information immediately before making a scheduling decision.
Final readiness checks
Book only after you can explain the main relationships in the blueprint without depending on keyword recognition. Readiness should mean that you can reason through unfamiliar wording, inspect a small code fragment, and choose a defensible design based on protocol, model, platform, operation, and security context.
Confirm that you can describe the purpose of network programmability, distinguish APIs from protocols and transports, and explain northbound and southbound interactions. Then test whether you can place NX-OS, IOS XR, IOS XE, and ASA OS API considerations in the right platform context.
Use a data-model checkpoint: validate a simple YANG-related scenario, explain how YANG relates to NETCONF or RESTCONF, distinguish standardized from platform-specific models, and navigate the conceptual relationship between the Management Information Tree and VISORE.
Use an operations checkpoint: compare agent-based and agentless approaches, describe plausible roles for Puppet, Chef, Ansible, and OpenStack Neutron, and connect Agile, Waterfall, and DevOps concepts to controlled automation delivery.
Use a security and implementation checkpoint: interpret basic Python and Linux activity, identify an SDK use case, apply least privilege, and explain whitelist-versus-blacklist reasoning. If any answer depends on memorized wording rather than a reasoned explanation, return to the relevant domain.
Finally, reread the official topic guidance and verify exam logistics. Cisco notes that related topics may appear and that guidelines may change without notice. The safest final action is therefore a current-source check, followed by a study plan that targets your remaining weaknesses rather than adding indiscriminate material.
Conclusion
300-550 preparation is strongest when it combines blueprint-led prioritization with practical reasoning. Give particular attention to Data Models and APIs and Automation Protocols, then connect those areas to Python, Linux, operations, controllers, and management-plane security. Use small, explainable exercises instead of unauthorized question collections, and verify Cisco and Pearson VUE information before scheduling because exam guidance and availability can change. Your next step is to download or review the official topic material, complete a gap assessment, and assign each weak area a specific practice task.
