350-901
Developing Applications using Cisco Core Platforms and APIs (DEVCOR)
DEVCOR Exam Guide: Developing Applications Using Cisco Core Platforms and APIs
The 350-901 DEVCOR exam validates professional-level ability to design, develop, integrate, secure, test, and deploy applications that work with Cisco platforms and APIs. It is aimed at experienced network automation engineers, software developers, system-integration programmers, architects, network designers, and test-development engineers. This guide helps you decide whether DEVCOR matches your current skills, identify the blueprint areas that need the most work, and build a practical preparation plan before checking Cisco’s current scheduling information.
What does the DEVCOR exam validate?
DEVCOR tests whether you can apply software-development and network-automation judgment to real Cisco-platform integration problems, not merely recall API terminology. Cisco’s official topics identify five broad capability areas: software development and design, API usage, Cisco platforms, application deployment and security, and infrastructure and automation.
The exam sits at the intersection of networking and software engineering. A strong candidate must be able to reason about an application’s architecture, communicate with network platforms through APIs, handle failures, protect credentials and data, and move software through testing and deployment processes.
Cisco describes the associated training as preparation for professional-level network automation engineer roles and the Cisco DevNet Professional certification. Passing 350-901 DEVCOR earns the Cisco Certified DevNet Specialist – Core certification and satisfies the core-exam requirement for Cisco Certified DevNet Professional.
That makes the exam relevant to two different decisions. A candidate building a professional certification path may need DEVCOR as the core requirement, while a working engineer may use the blueprint to measure whether their development and integration skills are sufficiently mature for larger automation responsibilities. Confirm the current certification naming and exam relationship on Cisco’s official pages before registering, particularly because Cisco has announced changes to the Automation certification track.
Who should take DEVCOR, and who should wait?
DEVCOR is best suited to candidates who already work comfortably across application code, network behavior, and system integration. Cisco lists senior network automation engineers, senior software developers, senior system-integration programmers, infrastructure architects, network designers, and test-development engineers as the intended audience.
Cisco’s course overview recommends at least one year of hands-on experience developing and maintaining applications built on Cisco platforms. It also says that three to five years of relevant design and implementation experience would provide full benefit from the course. These are course-recommended experience levels, not a stated exam prerequisite.
You should consider waiting if your current preparation consists mainly of reading REST definitions or copying small scripts without understanding authentication, retries, data models, deployment, and failure behavior. The exam topics require decisions about resilience, observability, security, architecture, and integration. Those decisions are easier to learn when you can test them in a working application.
A networking background alone is not enough for efficient preparation, and a general programming background alone may leave gaps in Cisco platform behavior and network operations. Before committing to a date, inventory both sides: can you design maintainable software, and can you interpret the operational consequences of an API-driven change? If one side is weak, make it the first study priority.
How is the exam positioned in the certification path?
Passing 350-901 DEVCOR earns the Cisco Certified DevNet Specialist – Core certification and fulfills the core-exam requirement for Cisco Certified DevNet Professional, according to Cisco’s DEVCOR course material. This makes the exam more than a narrow API test: it is the central assessment for a professional-level development and automation pathway.
Cisco’s transition material states that the 350-901 exam was renamed from DEVCOR to AUTOCOR as the certification portfolio moved toward Cisco Automation naming. It also states that, on February 3, 2026, certification levels transition to the CCNA, CCNP, and CCIE taxonomy. Because names and exam versions can change, use the current Cisco exam page and exam-topics document when making a scheduling decision.
The distinction matters for candidates who are studying from older DEVCOR material. Existing material may still explain useful development, API, platform, deployment, and security concepts, but it may not represent the current exam scope after a version transition. Treat the official blueprint as the authority for the exam version you intend to take.
Do not assume that a renamed exam is automatically identical in scope. Cisco’s transition article describes the updated professional-level focus as network-automation solution development and design, while Cisco’s current exam page identifies AUTOCOR v2.0 as “Designing, Deploying and Managing Network Automation Systems.” Check the version, title, and applicable blueprint immediately before booking.
What is the exam duration and what delivery details are confirmed?
The official 350-901 DEVCOR exam-topics document describes the test as a 120-minute exam associated with the DevNet Professional certification. The supplied official material does not establish a price, question count, language list, delivery mode, scoring method, or passing score, so those details should be checked on Cisco’s current registration page.
The current Cisco exam page identifies AUTOCOR v2.0 as a 120-minute exam covering infrastructure as code, operations, and AI in automation. That is evidence about the current AUTOCOR listing, not permission to assume that every DEVCOR preparation resource or historical appointment uses the same version or title.
For scheduling, first identify the exact exam code and version shown by Cisco. Then review the current appointment, identification, delivery, rescheduling, and testing requirements supplied during registration. This prevents a common planning error: preparing for the historical DEVCOR blueprint while booking an updated Automation exam.
Do not build a study plan around an assumed number of questions or an assumed time-per-question calculation. Instead, practise making clear decisions from short technical scenarios, reviewing your reasoning, and moving on when a problem has consumed too much of the available session. The official duration is the only timing fact established here.
Which blueprint area deserves the earliest attention?
Software development and design carries 20% of the DEVCOR blueprint, and the official domain label is “software development and design.” Start here if you have networking experience but limited exposure to architecture, maintainability, release practices, or distributed-system tradeoffs.
The official software development and design topics include distributed applications, scalability, modularity, high availability, resiliency, latency, rate limiting, maintainability, observability, application-log diagnosis, database selection, architectural patterns, Git operations, release packaging, dependency management, and sequence diagrams.
Study this domain as a connected design problem rather than as a collection of definitions. For example, a distributed application may need a choice of database, a rate-limiting policy, structured logs, retry boundaries, and a release strategy. Each choice affects latency, resilience, maintainability, and operational diagnosis.
The official topics document also covers API usage, Cisco platforms, application deployment and security, and infrastructure and automation. The supplied facts do not provide the percentages for those domains, so do not create a false ranking by assigning or comparing unsupported weights. Use the complete official blueprint to identify every objective, then use your own diagnostic results to decide where additional time is needed.
How should you study software development and design?
Build one small application architecture from requirements to operations. It should have a clear purpose, a defined data flow, failure behavior, logging approach, dependency strategy, and release path. This gives abstract topics such as modularity, resiliency, observability, and maintainability a concrete relationship.
Begin by drawing a sequence diagram for a request that crosses the client, your application, an authentication service, a Cisco platform, and any data store. Mark success, timeout, rejected authorization, rate limiting, and unrecoverable failure. Then explain which component owns each decision and what information must be logged without exposing secrets.
Next, compare architectural choices rather than memorizing labels. Ask when a modular design reduces change risk, when asynchronous processing could improve responsiveness, and when an added service creates operational overhead. Consider scalability and high availability together: adding capacity does not automatically remove a single point of failure.
Practise Git operations, release packaging, and dependency management in the same project. Record dependency versions, separate configuration from code, and make a repeatable package that another person could run. The aim is not to produce a large application; it is to demonstrate that the application can be changed, tested, diagnosed, and released deliberately.
A frequent mistake is treating observability as a final dashboard task. Design logs and useful operational signals while defining the workflow. Application-log diagnosis depends on consistent context, meaningful error details, and a way to connect an external request with the internal operation that failed.
What API skills must a DEVCOR candidate demonstrate?
DEVCOR expects practical API reasoning: authentication, request construction, response interpretation, pagination, caching, timeout handling, rate-limit handling, and control flow for errors. Cisco specifically identifies REST API integrations with network error handling, pagination, and error-flow control as course objectives.
The official API topics include REST API timeout and rate-limit error handling, unrecoverable-error control flow, HTTP cache controls, pagination, and the OAuth 2.0 three-legged authorization-code grant flow. These subjects reward candidates who can explain what the application should do next, not just name the HTTP status or OAuth step.
Create a local API exercise that retrieves a collection across multiple pages, respects the server’s pagination information, and stops safely when a response is malformed. Add a timeout and a rate-limit response to your test cases. Decide which failures are retryable, which require backoff, and which should be reported without repeating a harmful operation.
Study HTTP cache controls as an application-behavior question. Understand how cache directives influence reuse, freshness, and requests to the origin. Then connect the topic to data sensitivity: caching a public, slowly changing response is a different design decision from caching information that is authorization-sensitive or rapidly changing.
For OAuth 2.0, trace the three-legged authorization-code grant from the user’s authorization through the code exchange and token use. Identify where the client secret belongs, how redirect handling affects the flow, and what the application should do when authorization fails. Avoid storing tokens in source code or treating successful authentication as proof that every requested operation is authorized.
A common error is writing one generic exception handler for all API failures. Separate connection failures, timeouts, authentication problems, authorization failures, malformed responses, rate limits, and unrecoverable application errors. The correct response may be retry, refresh credentials, ask for a different authorization, alert an operator, or terminate the workflow safely.
How can you make Cisco-platform study practical?
Use Cisco platform documentation and a controlled lab to follow a complete application workflow: authenticate, discover the required resource, send a narrowly scoped request, validate the response, handle failure, and record an operationally useful result. The platform matters because API behavior, resource models, permissions, and asynchronous operations are not interchangeable.
Cisco lists Cisco-platform application development, custom-application integration, network programmability, system integration, and automated workflow design among the DEVCOR course benefits. Use those themes to structure lab work instead of collecting disconnected API examples.
For each platform integration, write a short contract before coding. Define the input, expected output, authentication requirement, idempotency concern, timeout behavior, pagination behavior, and rollback or recovery path. This habit forces you to think about the system boundary rather than only the successful request.
Then integrate the application with a second component, such as a notification, inventory, data store, or test service. The purpose is to practise translating data models and handling mismatched assumptions. Ask what happens if the platform accepts a change but the downstream system is unavailable, or if the downstream system succeeds while the confirmation from the platform is lost.
Keep the lab deliberately small and observable. Capture request identifiers, response status, timing, and safe error context. Never use real production credentials or make uncontrolled changes merely to gain practice. A lab that can be reset is more valuable than a broad but fragile demonstration.
Do not rely on copied code without reading the authentication, error, and data-handling sections around it. During revision, explain every request and response in your own words. If you cannot say what a function does when the network is slow, the token is invalid, or the server limits requests, the exercise is not complete.
How should deployment and security fit into preparation?
Treat deployment and security as part of application design, not as a separate final chapter. A DEVCOR-ready solution should account for configuration, dependencies, credentials, access control, logging, testing, packaging, and the operational consequences of a failed release.
Start with configuration hygiene. Separate environment-specific values from application logic, keep secrets out of source control, and define how the application receives the values it needs. Review logs for accidental credential or token disclosure. These are practical controls that also make troubleshooting and promotion between environments easier.
Map the application’s permissions to its actual task. Ask whether it needs read access, change access, or a narrowly scoped operation. Consider how an OAuth flow, API token, or platform account is protected throughout its lifecycle. Authentication establishes identity; it does not remove the need to validate authorization and input.
Create a test sequence that includes normal behavior, invalid input, denied access, expired or unusable credentials, timeouts, rate limits, partial responses, and a dependency outage. Testing should verify both the result and the safety of the failure path. A workflow that silently repeats a non-idempotent change can be more dangerous than one that stops visibly.
Package the application so its dependencies and startup expectations are explicit. Then simulate a release with a configuration difference or unavailable dependency. Record what the operator would see, how the application would be rolled back or stopped, and which evidence would help diagnose the event.
A frequent preparation mistake is studying security as a list of vulnerabilities while ignoring design context. For each control, state the threat or failure it addresses, where it is implemented, and how you would verify it. That explanation is more transferable than memorizing isolated terms.
Where do infrastructure and automation enter the exam?
Infrastructure and automation topics require you to connect application behavior with repeatable operational change. Study how an automated workflow represents desired state, validates inputs, sequences dependent actions, reports failure, and avoids creating inconsistent results when a step is repeated.
The DEVCOR exam topics identify infrastructure and automation as one of the tested areas, while Cisco’s course benefits include automated workflow design and network programmability. Build workflows that can be inspected and rerun safely rather than scripts that only work once from an interactive shell.
For a workflow exercise, define prerequisites and postconditions. Check the starting state, make the smallest required change, verify the result through an independent read, and report a useful outcome. Include a branch for a partially completed operation. Decide whether the workflow can resume, must compensate for earlier changes, or must stop for human intervention.
Practise separating orchestration from platform-specific operations. A high-level workflow should express the business or operational intent, while an integration component handles authentication, request formatting, retries, and response translation. This separation improves testing and makes platform changes easier to contain.
Infrastructure automation also requires attention to ordering and concurrency. Identify which actions can run independently, which must wait for a confirmed prerequisite, and how simultaneous requests could conflict. Document assumptions about state instead of hiding them in control flow.
Do not equate automation with maximum parallelism or maximum abstraction. An automated process that is fast but opaque, unsafe to repeat, or impossible to diagnose is a weak design. The better choice is the one that provides predictable results, clear evidence, and controlled recovery.
What should a six-week preparation roadmap look like?
Use a six-week sequence only as a planning model, not as an official Cisco requirement. The order below moves from blueprint interpretation to design, API behavior, platform integration, deployment, and timed review. Extend any stage where your lab work exposes a genuine weakness.
Week 1: establish a baseline. Download the current official exam-topics document, mark every objective as familiar, partly familiar, or unfamiliar, and record the exam version you are targeting. Build a small application repository and test your ability to explain its architecture, authentication, error handling, and deployment assumptions.
Week 2: focus on software development and design. Study the 20% software development and design domain, then apply distributed-application, scalability, modularity, resiliency, latency, rate-limiting, observability, database, Git, packaging, dependency, and sequence-diagram concepts to one design. Review your choices by asking what happens during failure and change.
Week 3: work through API behavior. Implement pagination, timeout handling, rate-limit handling, cache-control decisions, and unrecoverable-error control flow. Trace the OAuth 2.0 three-legged authorization-code grant on paper and in a safe exercise. Write tests for both successful and failed responses.
Week 4: deepen Cisco-platform integration. Choose the platform areas represented in your official blueprint and build a workflow that discovers resources, performs a controlled operation, validates the result, and records safe diagnostics. Add a second system so that you must translate data and handle a dependency failure.
Week 5: cover deployment, security, testing, and automation as one delivery problem. Package the application, externalize configuration, review permissions, test invalid and partial states, and make the workflow repeatable. Create a short design review document explaining tradeoffs and recovery decisions.
Week 6: review by evidence rather than confidence. Revisit every blueprint objective, close gaps with documentation and hands-on work, and complete scenario-based practice under the official 120-minute exam duration. Do not use an assumed question count to pace yourself. Schedule only after you can explain why an answer is correct and why the alternatives fail.
If your baseline shows a major programming gap, spend additional time on code structure, testing, version control, and dependency handling before expanding platform coverage. If software design is strong but Cisco integration is weak, reverse that emphasis. A roadmap is useful only when it responds to evidence from your own work.
How should you use courses, documentation, and practice material?
Use Cisco’s official course and exam-topics documents as the scope boundary, then use documentation and labs to turn each objective into an observable skill. A course can organize learning, but it cannot replace the ability to diagnose an integration, defend an architecture, or recover from a failed workflow.
Cisco’s DEVCOR training focuses on implementing network applications on Cisco platforms, including software design, system integration, testing, and deployment automation. It also identifies REST API integration with network error handling, pagination, and error-flow control as objectives. Match each course topic to a lab result or written design decision.
Read product and API documentation with a question in mind. Look for authentication requirements, resource relationships, pagination rules, rate-limit behavior, error responses, asynchronous-operation details, and version constraints. Record the source and the assumption you made. This produces a revision notebook that is more useful than copied snippets.
Use practice questions to expose reasoning gaps, not to memorise answer patterns. After each item, explain the requirement, the relevant design principle, the expected platform behavior, and why another option would be unsafe or incomplete. Practice material that claims to reproduce live questions should not be treated as a legitimate substitute for preparation.
Cisco states that the DEVCOR training awards 64 Cisco Continuing Education credits toward recertification. That benefit may matter when comparing training options, but it does not indicate exam readiness. Keep certification maintenance considerations separate from the skills evidence you need before scheduling.
AI tools can help generate test data, explain unfamiliar syntax, or suggest edge cases, but review every generated recommendation against official documentation and your own tests. Cisco’s transition material frames AI as a tool and assistant rather than a replacement for engineering judgment. Never submit unreviewed generated code to a network or treat an AI answer as proof of platform behavior.
Which preparation mistakes cause avoidable gaps?
The most damaging mistakes are studying only successful API calls, ignoring the version transition, and treating architecture and operations as unrelated subjects. Correct them by testing failure paths, checking the current blueprint, and tracing each design choice through deployment and diagnosis.
Mistake one: memorising endpoints without learning control flow. Fix it by writing what the application does for timeout, rate limit, invalid token, denied operation, malformed data, and partial completion. The response must be safe and explainable, not merely syntactically valid.
Mistake two: over-practising code while under-practising design. DEVCOR includes architecture, scalability, modularity, availability, resilience, latency, observability, database selection, and sequence diagrams. Schedule time to compare alternatives and justify tradeoffs in writing.
Mistake three: ignoring deployment until the end. A locally successful script may fail because of missing configuration, unavailable dependencies, insufficient permissions, unsafe secrets handling, or an unrecoverable intermediate state. Package and test the application before you consider the lab finished.
Mistake four: using a historical DEVCOR outline without checking the current exam identity. Cisco’s official transition information describes the move from DEVCOR to AUTOCOR and a professional-level redesign. Confirm the applicable code, version, title, and topics before you invest in final review.
Mistake five: confusing familiarity with readiness. You may recognise every term and still be unable to choose a retry policy, identify a single point of failure, or diagnose an application log. Use a practical readiness test: explain the workflow, implement a small version, break it deliberately, and document the recovery path.
Mistake six: depending on exam dumps or leaked-question claims. Memorisation cannot establish that you can build, secure, test, or diagnose an application, and such material is not a reliable basis for professional practice. Use official topics, legitimate training, documentation, and your own controlled exercises instead.
How can you decide when to schedule?
Schedule when your preparation evidence covers the current blueprint and your weakest areas are improving, not simply because you have completed a course. The final decision should include exam-version confirmation, a realistic review window, and enough time to resolve any major gap in software design, API behavior, Cisco integration, or deployment.
Use a readiness checklist. You should be able to explain the purpose and tradeoffs of a distributed application design; implement and test pagination, timeout, rate-limit, and unrecoverable-error behavior; trace the OAuth 2.0 three-legged authorization-code flow; integrate with a Cisco platform; and describe how the application is secured, packaged, deployed, observed, and recovered.
Review the official exam-topics document one final time and map every objective to one of three kinds of evidence: a written explanation, a working lab, or a documented troubleshooting exercise. If an objective has only been read about, mark it as a risk rather than assuming that recognition equals competence.
Check Cisco’s current exam page for the code, title, version, registration instructions, and any delivery requirements that may have changed. The supplied official facts confirm the 120-minute duration for the DEVCOR topics document and for the current AUTOCOR listing, but they do not establish all appointment details.
Choose a date that creates a firm review point without forcing you to ignore a foundational gap. If your only weakness is a narrow topic, targeted practice may be enough. If you cannot yet reason about authentication, failure handling, or safe deployment, postpone and fix the underlying skill rather than trying to compensate with last-minute memorisation.
What should you do after reading this guide?
Your next action is to verify the exam version, download the applicable Cisco blueprint, and perform a hands-on baseline. Then turn the weakest blueprint areas into a small application project with deliberate failures, documented decisions, and a review date.
Start with the official 350-901 DEVCOR exam-topics document and mark each objective against your current ability. Read Cisco’s DEVCOR course overview to understand the intended role context and training scope. If you are affected by the DevNet-to-Automation transition, use Cisco’s current Automation exam page and transition material to confirm which assessment applies to your plan.
Create a repository containing a sequence diagram, a short architecture decision record, API integration code, tests for timeout and rate-limit behavior, pagination handling, authentication flow notes, safe configuration, dependency information, and a deployment checklist. Keep the project small enough to reset and inspect.
At the end of each study session, produce evidence: a passing test, a failed test that you explained, a diagram you revised, or a design tradeoff you can defend. That record will reveal whether you are gaining usable skill or merely accumulating notes.
Finally, schedule through Cisco only after confirming the current exam identity and appointment rules. Keep this guide as a planning aid, but let Cisco’s current official pages control time-sensitive registration and certification decisions.
Conclusion
DEVCOR preparation is strongest when it combines software engineering discipline with Cisco-platform and network-automation practice. Use the official blueprint to set scope, give the 20% software development and design domain deliberate attention, and build one controlled workflow that demonstrates authentication, integration, failure handling, security, testing, deployment, and observability. Verify whether your intended assessment remains DEVCOR or has moved to the AUTOCOR naming and version before scheduling. The goal is not to memorise isolated API facts; it is to make safe, explainable engineering decisions under exam conditions and in the work that follows.
Related exams
- Automating and Programming Cisco Security Solutions (300-735 SAUTO)
- 300-835 exam — Automating Cisco Collaboration Solutions (CLAUTO)
- 300-910 exam — Implementing DevOps Solutions and Practices using Cisco Platforms (DEVOPS)
- 300-915 exam — Developing Solutions Using Cisco IoT and Edge Platforms (DEVIOT)
- 300-920 exam — Developing Applications for Cisco Webex and Webex Devices (DEVWBX)