200-901
DevNet Associate (DEVASC)
DevNet Associate (DEVASC) Exam Guide: Skills, Transition, and Study Roadmap
The former Cisco DevNet Associate exam validated entry-level ability to build and secure applications that interact with networks and Cisco platforms through software, APIs, and automation. It served candidates moving between development and network engineering, as well as infrastructure professionals adding programming skills. This guide helps you make the key preparation decision: whether to study the former DEVASC blueprint as written, or confirm that your booking is for its successor, 200-901 CCNAAUTO, before you choose materials and schedule study time.
Is DEVASC still the current certification name?
The former DevNet Associate certification became CCNA Automation on February 3, 2026, when Cisco moved the DevNet track into the CCNA, CCNP, and CCIE Automation track. Cisco identifies the successor exam as 200-901 CCNAAUTO, titled Automating Networks Using Cisco Platforms. Confirm the exam name shown in your Cisco account before preparing or booking.
Cisco states that the content from the previous 200-901 DEVASC exam remains unchanged in the CCNA Automation version and that only the exam name was updated. That makes the former DEVASC blueprint useful for understanding the assessed skills, but the current Cisco exam page should control decisions about registration, certification status, and any current delivery information.
Cisco also states that active DevNet certifications were automatically migrated to the corresponding Automation certifications on February 3, 2026. Candidates who already hold an active credential should therefore check their certification record rather than assuming that a separate application is required. Candidates preparing for a new attempt should use the current CCNA Automation naming when verifying the exam.
What does the exam validate?
The exam measures whether you can use software development practices, APIs, Python, Cisco platforms, application security, infrastructure automation, and networking fundamentals to solve practical automation problems. It is not simply a programming test or a product-familiarity test; preparation must connect code, network behavior, platform interfaces, and secure application design.
Cisco described the former DEVASC exam as assessing software development and design, API usage, Cisco platforms and development, application development and security, and infrastructure and automation. The v1.1 blueprint also lists Network Fundamentals, giving the exam six named domains in total.
A useful way to interpret that scope is to ask what happens across a complete automation task. You need to understand the network or platform being controlled, identify the right interface, authenticate safely, send and interpret requests, handle data and errors, and design an automation workflow that is maintainable rather than merely functional.
The blueprint included Python scripting with Cisco SDKs and knowledge of platforms such as Meraki, Cisco DNA Center, ACI, Cisco SD-WAN, NSO, Webex, Firepower, Umbrella, and ISE. You do not need to study every platform as if it were a separate certification. Instead, learn the recurring development patterns and then map those patterns to the platform examples named in the blueprint.
Who should prepare for this exam?
DEVASC is a sensible target for candidates who work with network automation, application integration, infrastructure tooling, or Cisco platform APIs and need a structured foundation. It can suit a network professional learning Python and a developer learning how applications interact with network services, provided both groups address the parts outside their existing experience.
Network engineers often need to spend more time on Python structure, data handling, API authentication, error management, and software design. Developers may need to reverse that balance by studying IP behavior, network devices, controller roles, and the differences between configuring a resource and consuming an application interface.
The certification is less suitable as a first exposure to both programming and networking if you have no way to practise either. In that case, build basic comfort with Python and networking first, then use the blueprint to identify gaps. Do not treat a list of product names as a substitute for understanding how automation works.
A useful readiness question is whether you can read a short Python script, explain the request it sends, identify the credentials involved, predict the likely response, and describe how the script should behave when the response indicates an error. If several parts of that chain are unfamiliar, start with fundamentals rather than jumping directly into timed practice.
How should you read the blueprint?
Use the official blueprint as a coverage checklist, not as a study sequence. The six domains identify what Cisco may assess, while your study order should follow dependencies: programming and networking foundations first, then API work, platform use, application security, and broader automation integration.
Software Development and Design carries 15% of the former DEVASC blueprint, and Understanding and Using APIs carries 20%. Those percentages are useful prioritisation signals, but they do not mean the other domains can be ignored. A smaller domain can still expose a major weakness, and the domains overlap in realistic automation tasks.
The blueprint’s six domains are Software Development and Design, Understanding and Using APIs, Cisco Platforms and Development, Application Development and Security, Infrastructure and Automation, and Network Fundamentals. Keep a copy of the official topic document beside your notes and turn each task into a question you can answer or a small exercise you can perform.
The v1.1 release notes state that all exam domains remained identical compared with v1.0, while some tasks were updated for product naming changes, end-of-life products, and Terraform use. This matters when choosing older study material: retain material that teaches durable concepts, but verify product references and task wording against the current official documents.
Avoid allocating study time only by percentage. A candidate who already writes Python may need little introductory coding practice but substantial API and network revision. Another candidate may need the opposite. Begin with a diagnostic pass through every blueprint task, mark each as confident, partly understood, or unfamiliar, and build the schedule around the last two categories.
Which programming skills deserve early attention?
Start with the Python skills that make automation code understandable and controllable: variables and data types, collections, conditionals, loops, functions, modules, exceptions, file handling, and structured data such as JSON. The goal is not to memorise isolated syntax. It is to interpret and adapt a script that receives data, makes a decision, and reports a result.
Practise reading code before writing large programs. Given a short script, identify its inputs, transformation steps, external calls, returned data, and failure paths. Then make a small change, such as selecting a different field from a response or adding handling for a missing value. This approach builds the debugging and comprehension skills needed for automation work.
Include the requests library in your practice because the blueprint included Python scripts using requests. Work through the complete request lifecycle: construct the URL, choose the HTTP method, add headers or parameters, provide authentication, send the request, inspect the status code, parse the response, and handle an unsuccessful result.
Cisco’s blueprint also included Python scripting with Cisco SDKs. Compare an SDK-based workflow with a direct REST request. Identify what the SDK abstracts, what configuration or credentials it still needs, and how you would inspect the underlying result when a call fails. This prevents overreliance on a single library’s convenience methods.
A common mistake is to practise only successful scripts. Add malformed input, missing keys, authentication failure, unavailable endpoints, and unexpected response data to your exercises. You are preparing to reason about automation behavior, not simply reproduce a working demonstration.
How can you make API study practical?
Learn APIs as a sequence of decisions rather than a collection of terms. For each example, identify the resource, endpoint, HTTP method, authentication approach, request body, expected response, status code, and follow-up action. That framework covers the core API topics named in the blueprint and gives you a repeatable method for analysing unfamiliar requests.
The former DEVASC blueprint included REST API requests, webhooks, HTTP response codes, API authentication, API styles, and Python scripts using the requests library. Build a compact comparison sheet for these topics, but verify your understanding by writing or reading requests rather than relying on definitions alone.
For REST practice, take one resource and trace its lifecycle. Decide how a client would retrieve it, create it, modify it, and remove it. Note which method is used, what data belongs in the request, and how the response indicates success or failure. Then consider whether repeating the request could create an unwanted duplicate or change.
Status codes should lead to an action. A successful response may allow parsing and continuation; a client-side error may indicate a bad request, missing permission, or invalid resource; a server-side error may require diagnosis, retry policy, or escalation. Do not reduce the topic to memorising code labels without asking what the automation should do next.
Authentication deserves separate attention. Distinguish credentials from authorisation, identify where tokens or keys are sent, and avoid placing secrets directly in source files. In a practice script, use a configuration mechanism that keeps secrets outside the code and document which values the script expects.
Webhooks require a different mental model from polling. A polling client repeatedly asks whether something changed; a webhook receiver waits for an event notification. Study what information an event should contain, how the receiver validates and processes it, and what happens if delivery is duplicated or delayed. This is a good place to practise idempotent handling and clear logging.
How should you study Cisco platforms without memorising product trivia?
Organise platform study around the automation question each product represents: what is being managed, which interface exposes it, what data or intent is exchanged, and how an application authenticates and handles the result. This approach is more durable than memorising disconnected feature lists and aligns platform knowledge with the development skills in the blueprint.
The blueprint named Meraki, Cisco DNA Center, ACI, Cisco SD-WAN, NSO, Webex, Firepower, Umbrella, and ISE among the Cisco platforms and development knowledge areas. Create one page per platform or platform family with four fields: purpose, likely automation interface, representative object or workflow, and security or operational consideration.
Do not try to build a full implementation of every named platform. Instead, use the official topic list to determine which platform concepts you cannot explain, then choose a small representative exercise or walkthrough. For example, practise identifying the type of resource an API manages, the information a script must supply, and the result an automation workflow should verify.
Compare controller-oriented and device-oriented automation. A controller may expose policy, inventory, or intent through an API, while direct device automation may involve configuration state, commands, or a transport mechanism. The study decision is not to declare one approach universally better; it is to understand what the selected interface represents and what consistency or validation the workflow needs.
Keep product names current in your notes. Cisco’s v1.1 release notes specifically mention updates for product naming changes, end-of-life products, and Terraform use. If a course or video uses older terminology, check it against the current Cisco blueprint and release notes before treating it as exam-aligned.
What application security and automation habits should you practise?
Treat security as part of application design, not as a final review topic. Practise least-privilege access, protected secret handling, input validation, safe logging, secure transport, error handling that does not disclose sensitive information, and dependency awareness. These habits help you evaluate both a code sample and an automation architecture.
For every script, ask where credentials originate, how long they remain available, who can use them, and whether logs could expose them. Replace hard-coded secrets in your practice code with environment-based or external configuration patterns. Also ask whether the account has more access than the operation requires.
Input validation matters when data comes from a user, webhook, file, or external API. Define what the script expects, reject values that do not meet those expectations, and handle missing or incorrectly typed fields deliberately. A script that works with one clean response but fails unpredictably with ordinary variation is not production-ready automation.
Infrastructure and automation study should include repeatability and state. Ask whether running a workflow twice produces the same intended result, whether the script can detect the current state, and how it reports partial completion. Terraform use is mentioned in the v1.1 release notes, so candidates should understand the basic purpose of declarative infrastructure tooling and how it differs from an imperative script, while using the official blueprint to determine the required depth.
A frequent preparation mistake is equating automation with speed. A fast script that makes an unsafe change, ignores an error, or cannot be audited is a poor solution. When reviewing an exercise, add a validation step, an explicit failure path, and a useful operational message before considering it complete.
How much network fundamentals should a developer revise?
Network fundamentals are the context that makes API and automation behavior intelligible. Revise addressing, subnetting, routing, switching concepts, TCP and UDP, DNS, DHCP, HTTP and HTTPS, common network services, and basic troubleshooting logic. Focus on explaining what a failure means for the application rather than studying networking as an unrelated subject.
Use a layered troubleshooting sequence. If a script cannot reach an endpoint, check name resolution, address selection, route availability, transport connectivity, TLS or certificate behavior, authentication, request syntax, and server-side authorization. This sequence prevents you from changing code when the actual problem is connectivity or credentials.
Practise translating between network and application language. A timeout is not the same problem as an HTTP error. A successful TCP connection does not prove that the API request is authorised. A valid response body does not prove that the requested configuration was applied correctly. These distinctions make scenario questions easier to analyse.
If networking is your stronger area, do not let familiarity create false confidence. Developers often lose time on subnetting, protocol behavior, or device roles; network professionals often lose time on data structures, exceptions, and application flow. Use targeted drills to close the weaker side instead of spending every session on comfortable material.
What study sequence works for a mixed developer-network audience?
A staged plan works better than switching randomly between products. Establish a baseline, build the shared foundations, connect those foundations through API exercises, then add Cisco platform patterns, security, infrastructure automation, and timed review. Adjust the emphasis after each diagnostic rather than following a fixed calendar that ignores your starting point.
Stage one is a blueprint audit. Read every domain and task, label your confidence, and note whether the gap is conceptual, procedural, or vocabulary-related. A conceptual gap requires explanation; a procedural gap requires hands-on repetition; a vocabulary gap usually needs a concise comparison table and immediate application.
Stage two is foundation repair. Review Python control flow, functions, collections, JSON, exceptions, and file handling alongside network addressing, protocols, DNS, HTTP, and authentication concepts. Write small scripts that transform structured data and explain what happens when an input or network dependency is unavailable.
Stage three is API integration. Work through REST requests with requests, response-code handling, authentication, and webhook reasoning. For every exercise, record the request, expected response, failure condition, and security concern. This turns each lab into reusable revision material rather than a one-time demonstration.
Stage four is platform mapping. Use the Cisco platform list and official task wording to decide what each platform contributes to the blueprint. Study the recurring interface and automation patterns, then test yourself without looking at the product name: what would you need to discover, authenticate, change, and verify?
Stage five is application and infrastructure design. Review secure secret handling, validation, logging, idempotence, state, and the distinction between imperative scripts and declarative tooling. Include the Terraform-related update in your review, while avoiding assumptions that a single tool represents all infrastructure automation.
Stage six is exam-oriented consolidation. Revisit every uncertain task, explain answers aloud, and complete mixed scenarios that require more than one domain. The final objective is not to remember the order of your notes; it is to move from a requirement to a safe, testable automation approach.
What should a four-week roadmap look like?
A four-week roadmap can provide structure without pretending that every candidate needs the same pace. Use the first week to diagnose and repair foundations, the second to build API fluency, the third to connect Cisco platforms with security and automation, and the fourth to consolidate. Extend any week when your diagnostic work shows that the underlying skill is not stable.
Week one: read the blueprint, establish a gap list, and practise Python and networking fundamentals. Produce small outputs: a script that reads and transforms JSON, a written explanation of a request lifecycle, and a troubleshooting checklist for an unreachable API. End the week by explaining each result without copying from notes.
Week two: focus on API mechanics. Practise REST methods, authentication, headers, parameters, request bodies, response parsing, status-code decisions, and webhook workflows. Add deliberate failures and record the cause and corrective action. Review API styles and compare polling with event-driven notification so the distinctions are meaningful rather than memorised.
Week three: map the Cisco platforms named by Cisco to the common automation workflow. Review SDK use, controller and platform roles, application security, infrastructure automation, and the Terraform update noted in the release notes. Build a matrix showing what is common across platforms and what is product-specific.
Week four: mix domains instead of studying them in isolation. Use short scenario prompts, code-reading exercises, API interpretation, network troubleshooting, and security reviews. Recheck every blueprint task marked partly understood or unfamiliar. Reserve the final sessions for concise notes and error analysis, not for collecting additional resources.
At the end of each week, make a scheduling decision. If you can explain a topic but cannot apply it, schedule more hands-on work. If you can complete an exercise only by following instructions, repeat it from a blank file. If a topic remains unclear because a source uses obsolete product language, return to Cisco’s current official material before adding another course.
Which delivery details are actually documented?
Cisco’s exam overview described the former 200-901 DEVASC exam as available in English and lasting 120 minutes. Those details belong to the former DEVASC exam record. Because Cisco has transitioned the certification to CCNA Automation, verify the current exam page and booking system for the delivery details that apply to your intended attempt.
Do not infer current languages, duration, delivery options, pricing, score requirements, question formats, or scheduling rules from an older DEVASC page. Time-sensitive exam information can change independently of the technical blueprint, and the official successor page should be the authority for the booking you are making.
Passing 200-901 CCNAAUTO earns the CCNA Automation certification and can also count toward recertification goals, according to Cisco. Candidates using the exam for recertification should confirm how their broader certification record applies rather than assuming that the same outcome applies to every credential or situation.
Before scheduling, check four items in order: the exact exam code and title, the current certification outcome, the delivery and language information, and any policies or identification requirements shown by the official registration path. Save the official page you used, because a third-party course may still use the former DEVASC name.
What mistakes waste the most preparation time?
The most expensive mistake is studying an old label without confirming the current exam. The technical content may remain unchanged, but registration, certification naming, and administrative details must be checked against Cisco’s current information. After that, the common failures are uneven coverage, passive video consumption, successful-only labs, and memorising terms without tracing an automation workflow.
Do not spend the entire schedule on Python because the exam includes scripting. The blueprint spans APIs, Cisco platforms, security, infrastructure automation, and network fundamentals. Conversely, do not spend the entire schedule reading product documentation while avoiding code. Use each study session to connect a platform action with an interface, a request, a response, and a verification step.
Do not treat blueprint percentages as a pass guarantee or as permission to ignore a domain. The 15% assigned to Software Development and Design and the 20% assigned to Understanding and Using APIs are planning information, not a promise about a particular attempt. Cisco’s topic list should remain your coverage boundary.
Avoid copying scripts without understanding their assumptions. When a sample uses a token, endpoint, object identifier, or response field, explain where each value comes from and what happens if it changes. Rewrite the exercise with a different input or failure condition to test whether you understand it.
Finally, do not use exam dumps or leaked questions as a preparation strategy. They cannot replace the ability to reason about secure code, APIs, platform behavior, and network conditions, and relying on them creates a poor basis for the certification’s practical objectives.
How can you decide that you are ready?
Readiness is stronger when you can explain and adapt a solution, not merely recognise familiar wording. Before scheduling or attempting the exam, use the blueprint as a final audit: identify the domains you can apply, the tasks you can explain, and the remaining gaps that require targeted work rather than general revision.
Use a three-part self-check for each topic. First, define the concept in plain language. Second, interpret it in a short code, request, or network scenario. Third, choose a safe next action when the scenario fails. If you can complete only the first part, your knowledge is likely theoretical; if you can complete all three, it is more usable.
For Python, read and modify a short script without relying on a step-by-step guide. For APIs, identify method, endpoint, authentication, payload, response, and error handling. For Cisco platforms, explain the automation role of the named platform and the interface pattern involved. For security, locate exposed secrets, missing validation, and unsafe error handling. For networking, distinguish reachability, transport, protocol, and authorisation failures.
Run a final gap review using the official v1.1 blueprint and release notes. Check that your notes reflect the six domains, current product naming, and the stated update involving Terraform. Then confirm the current CCNA Automation exam information before making the scheduling decision.
Your next action should be specific: complete one API exercise, revise one weak network topic, map one Cisco platform to the workflow, or verify one administrative detail on Cisco’s official page. Small, testable actions produce better preparation decisions than adding another unstructured list of resources.
Conclusion
DEVASC preparation remains useful as a skills framework because Cisco states that the former exam content continues in 200-901 CCNAAUTO, even though the certification track and name changed to CCNA Automation. Prepare from the six-domain blueprint, prioritise Python and API reasoning without neglecting security, platforms, infrastructure, and networking, and verify current registration details before booking. The most reliable final check is whether you can interpret, secure, troubleshoot, and adapt a complete automation workflow rather than recall isolated definitions.