Developing Solutions Using Cisco IoT and Edge Platforms (DEVIOT) Exam Guide
DEVIOT 300-915 validated IoT application-development knowledge across Cisco edge-compute and network architecture, including IOx, EFM, visualization, and security. Cisco associated it with the Cisco Certified DevNet Professional and Cisco Certified DevNet Specialist—IoT certifications. The important decision for a reader now is not simply how to prepare: Cisco classifies the exam as retired and states that January 20, 2024 was the last day to take it. Use this guide to assess its historical blueprint, confirm your current certification path through Cisco, and retain relevant IoT engineering skills without planning for an unavailable exam.
Is DEVIOT still available to schedule?
No. Cisco’s DevNet v1.1 release notes classify DEVIOT 300-915 as End of Life/Retired, and Cisco states that January 20, 2024 was the last day to take the exam. A candidate should therefore verify the current Cisco certification catalog before purchasing training, booking an appointment, or treating an old DEVIOT study plan as a route to a current credential.
The exam overview identifies DEVIOT as Developing Solutions Using Cisco IoT and Edge Platforms v1.0 and records February 24, 2020 as the first date to test. Those dates describe the exam’s published lifecycle; they are not a current scheduling window.
This status changes how the material should be used. A learner may still study the blueprint to understand Cisco IoT application development, edge placement, sensor workflows, and relevant APIs. However, preparation should not be represented as a way to sit DEVIOT today. For a current credential, use Cisco’s current certification information rather than assuming that a retired exam has a direct replacement.
What should a candidate do before spending money?
Check Cisco’s current certification and exam information first, then decide whether your objective is a live certification, a skills refresh, or preparation based on an archived blueprint. This simple check prevents an outdated DEVIOT course, practice product, or exam voucher from becoming the centre of your plan.
If your goal is a current certification, record the current exam identifier and blueprint from Cisco before choosing resources. If your goal is engineering capability, retain the DEVIOT topics that match your work—edge-versus-cloud placement, sensor connectivity, Python automation, IOx, EFM, visualization, and security—and judge resources by whether they support those tasks rather than by their DEVIOT label.
Do not rely on claims that dumps or recalled questions can restore access to a retired exam. They cannot change Cisco’s published exam status, and memorization is not a substitute for being able to design, deploy, and troubleshoot a solution.
Who can still benefit from the blueprint?
The archived blueprint is most useful to developers, automation engineers, and IoT practitioners who need a structured way to examine Cisco edge application concepts. It is also useful to candidates comparing older DevNet IoT coverage with a current Cisco pathway, provided they treat the document as historical reference rather than a booking instruction.
The subject matter is practical rather than limited to terminology. The blueprint includes interpreting a network topology and data flow, constructing a sensor-connection workflow, troubleshooting sensor connectivity, comparing edge and generic compute devices, selecting cloud or edge deployment, and creating a Python deployment script using FND and GMM APIs.
That emphasis suits a learner who wants to explain why an application belongs near a device, identify where data moves, and automate an edge deployment. It is less useful as a stand-alone plan for someone who only wants broad programming practice, because the published objectives connect coding decisions to IoT architecture and Cisco platforms.
What did DEVIOT measure?
DEVIOT measured IoT application-development knowledge as it relates to Cisco IoT edge-compute and network architecture. The published subject areas specifically include Cisco IOx, Cisco EFM, IoT data visualization, and security methods, so a sound study plan must connect application behaviour with infrastructure, data movement, and protection rather than treating each product as an isolated vocabulary list.
Cisco Network IoT Architecture: 20%
Cisco assigns 20% of the exam blueprint to the Cisco Network IoT Architecture domain. The domain covers gateways, access points, firewalls, routers, and switches in topology and data-flow interpretation. It also includes PLCs, embedded microcontrollers, RTOS systems, Cisco interfaces, communication protocols, and communication standards.
Study this domain as a chain of decisions. Start with the device or controller producing data, identify the interface and protocol carrying it, follow the path through the relevant network components, and determine where an application or service consumes the data. This approach is more useful than memorising device names because it forces you to account for both the physical or logical source and the application’s destination.
Create diagrams from short scenarios. Mark the sensor, controller, gateway, network boundary, processing location, and consumer. Then annotate what each component contributes. If you cannot explain why a gateway, firewall, router, or switch appears in the path, revisit the architecture before moving on. The goal is not to make a decorative topology; it is to make data flow and failure points visible.
Compute and Analysis: 10%
Cisco assigns 10% of the exam blueprint to the Compute and Analysis domain. This domain covers comparing edge devices with generic compute devices and selecting cloud or edge deployment for an application scenario. The comparison is therefore about placement and suitability, not simply about whether one machine has more processing capability.
For each scenario, write down the response-time expectation, data source, connectivity assumption, processing requirement, and destination of the result. Then state what would improve if processing moved closer to the source and what might become harder. Keep the reasoning tied to the scenario; do not treat edge as automatically superior or cloud as automatically simpler.
The supplied blueprint also includes constructing a Python script to deploy an application at the edge using FND and GMM APIs. Practise the workflow around the script: identify inputs, authenticate in the manner supported by the environment, select the target, submit the deployment action, and inspect the result. Avoid inventing API parameters from memory. Use the relevant Cisco documentation or development environment when available and confirm each request and response.
Other named technology areas
Cisco’s published exam description names IOx, EFM, IoT data visualization, and security methods among the subject areas. The supplied research does not provide separate percentage weights for those topics, so do not assign them invented shares or infer a ranking from their order in the description.
Build a connected study map instead. Place IOx and edge deployment beside the compute decision; place EFM and sensor workflows beside data collection and connectivity; place visualization beside the point at which processed data becomes useful to an operator; and place security across every boundary. This arrangement helps expose dependencies that a product-by-product glossary can hide.
The two quantified domains should remain attached to their labels: Cisco Network IoT Architecture is 20%, and Compute and Analysis is 10%. The research supplied here does not establish the percentages for the other named areas. Treat that absence as a reason to read the official topic document carefully, not as permission to fill the gap with estimates.
How should you study the architecture before writing code?
Begin with system reasoning, then move to implementation. A candidate who can place devices, networks, processing, and consumers on a diagram will have a stronger basis for selecting deployment locations and diagnosing failures than a candidate who starts by memorising API names. Use short scenarios and require yourself to justify every connection and processing step.
Build a sensor-to-application workflow
For each practice scenario, construct a workflow that begins at the sensor and ends at the application or visualization layer. Identify the sensor’s immediate interface, the controller or gateway that receives the reading, the network path, the processing location, and the service that presents or consumes the result.
Next, add operational conditions. Ask what happens when the sensor has power but no network path, when the protocol is unsupported, when the gateway can reach the network but not the destination, or when data arrives but is not displayed. These questions turn a linear diagram into a troubleshooting model.
Keep separate notes for confirmed facts, assumptions, and questions requiring documentation. For example, the fact that the blueprint requires a sensor-connection workflow is official. The particular protocol, interface, or deployment command in your practice environment must come from the environment’s documentation, not from an imagined exam requirement.
Use failure isolation instead of guesswork
Troubleshoot from the source outward: verify the sensor and its local connection, inspect the controller or gateway, confirm the network path, check the application endpoint, and finally inspect the visualization or downstream result. At each layer, define what evidence would prove that layer is working before changing configuration elsewhere.
A useful worksheet has five columns: component, expected behaviour, observed behaviour, evidence to collect, and next test. This makes a vague report such as “the sensor is not working” more precise. It also helps distinguish a sensor problem from a transport problem, an application parsing problem, and a display problem.
Do not practise only successful workflows. Deliberately remove one connection or alter one assumption at a time in a lab or simulated environment. Record the symptom and the smallest test that isolates it. The exercise is valuable because the blueprint explicitly includes troubleshooting sensor-connectivity issues, not merely drawing a connected architecture.
How should you practise edge deployment and APIs?
Treat the Python deployment task as an end-to-end automation exercise rather than a code-completion drill. The target outcome is a script that uses FND and GMM APIs to deploy an application at the edge, with enough structure to make inputs, target selection, response handling, and troubleshooting understandable.
Break the script into observable stages
Organise practice code into stages: configuration, authentication or session setup, target discovery or selection, deployment request, response validation, and follow-up status handling. The exact endpoint names, fields, and authentication process must come from the applicable Cisco documentation or environment; the supplied blueprint establishes the task and APIs, not undocumented implementation details.
Use explicit variables for the target, application information, and deployment settings. Validate that required values exist before sending a request. Handle unsuccessful responses separately from successful submissions, and preserve enough response information to identify whether the failure occurred during authentication, target selection, request validation, or deployment.
Write a short explanation beside each stage. If you cannot explain what a request changes, what object it targets, and what evidence indicates success, the script is not ready for serious troubleshooting. This method also guards against copying a sample without understanding which values are environment-specific.
Practise deployment diagnosis
When a deployment does not behave as expected, first decide whether the script failed to submit the request or the platform accepted the request but the application failed later. Inspect the returned status and relevant diagnostic information before rewriting working code.
Compare the intended target with the actual edge device, review application configuration, and check whether the application’s required connectivity is available. Then separate platform errors from application errors. A deployment API can work correctly while the deployed application cannot reach a sensor, service, or data destination.
Keep a deployment journal containing the scenario, request purpose, target, observed response, corrective action, and final result. Do not copy credentials or sensitive configuration into the journal. The objective is repeatable reasoning: locate the failed stage, form one hypothesis, test it, and record the evidence.
How do IOx, EFM, visualization, and security fit together?
Study the named technologies as parts of one operational system. IOx belongs in the edge-compute and deployment discussion; EFM belongs in the IoT application and data-collection discussion; visualization belongs at the point where data becomes interpretable; and security belongs across devices, networks, APIs, applications, and data flows.
Connect platform concepts to decisions
For IOx, focus on what an edge-hosted application needs from its platform and how deployment location affects the application. For EFM, trace how device or sensor information becomes available to an application. For visualization, identify which data has been processed, what an operator needs to see, and where a failure could occur between ingestion and display.
For each topic, use the same four prompts: what is the input, where is processing performed, what interface connects the stages, and what evidence confirms the output? These prompts prevent a study session from becoming a list of definitions with no operational context.
The official description names these areas but does not, in the supplied facts, provide a complete subtopic list or individual weights. Keep notes labelled as “official objective,” “lab observation,” or “personal inference” so that your preparation does not accidentally turn a lab-specific behaviour into a claimed exam requirement.
Make security a design constraint
Apply security questions at every boundary rather than leaving security until the end. Ask how an application is identified, how access is controlled, how communication is protected, what data should be exposed, and how a failed or untrusted component is handled. Use Cisco’s published security coverage and the documentation for the actual platform or service as your evidence base.
When reviewing a workflow, mark trust boundaries on the diagram: device to gateway, gateway to network, API client to management service, and application to data consumer. Then identify the control relevant to each boundary. The correct control depends on the system; do not insert an unsupported product feature or configuration simply to make the diagram look complete.
Security practice should include negative cases. Consider invalid credentials, an unreachable management service, an unexpected device, or data that should not be displayed. The aim is to reason about safe behaviour and diagnosis, not to memorise a collection of security terms.
What preparation mistakes should you avoid?
The most damaging mistake is preparing as though DEVIOT were an available exam. Its retirement and last test date must shape every decision. Among the technical mistakes, the common pattern is confusing recognition with capability: knowing a product name, API name, or protocol label does not demonstrate that you can trace data, choose placement, deploy an application, or isolate a failure.
Mistaking an archived blueprint for a current contract
An archived topic document can be useful, but it cannot establish current eligibility, delivery, pricing, scheduling, or a replacement exam. Do not publish or repeat unsupported details about question counts, scoring, prerequisites, delivery modes, or future availability. The supplied official facts verify a 90-minute duration and English as the available exam language for DEVIOT, but those historical exam details do not make the retired exam schedulable now.
Use the official Cisco pages to distinguish lifecycle information from topic information. If a training provider describes DEVIOT as active, compare that claim with Cisco’s release notes and last-test-date statement before acting. When the sources conflict, pause and verify rather than purchasing on the strength of a third-party listing.
Overfocusing on memorization and percentages
The official weights can help allocate attention, but they do not replace hands-on reasoning. Cisco assigns 20% to Cisco Network IoT Architecture and 10% to Compute and Analysis; those numbers should remain attached to their domain names whenever you use them. They should not become a reason to ignore IOx, EFM, visualization, or security, which Cisco also names in the subject description.
A second error is comparing the 20% and 10% as if they describe all exam content. The supplied research does not provide the remaining domain percentages. Use the blueprint’s full official presentation for any complete allocation, and avoid presenting an incomplete set of figures as the whole exam.
Copying code without testing the workflow
A copied Python sample can conceal assumptions about endpoint versions, credentials, target identifiers, application packages, and response handling. Rebuild the workflow in a controlled environment, replace environment-specific values deliberately, and test both success and failure paths.
Do not treat a successful request submission as proof that the deployed application is useful. Confirm the intended target, inspect the application state through the supported tooling, and trace whether the application can obtain and process the expected data. This is a practical recommendation based on the blueprint’s deployment and troubleshooting emphasis, not a claim about an undisclosed exam task format.
What is a practical study roadmap?
For historical DEVIOT study or transferable IoT skills, use a staged roadmap: establish the official scope and lifecycle, map the architecture, practise sensor workflows, automate an edge deployment, then perform integrated troubleshooting and review. At each stage, produce an artefact—a diagram, workflow, script, test record, or decision note—so progress is demonstrated by work rather than by time spent reading.
Stage 1: Confirm the objective and scope
Start by recording the exam identifier, title, certification associations, published lifecycle information, and the official subject areas. Mark DEVIOT as retired and decide whether your outcome is historical familiarity or a current Cisco certification. If it is current certification, stop this roadmap after scope confirmation and move to Cisco’s current official pathway.
Then create a two-column scope sheet. In the first column, place confirmed objectives such as network topology interpretation, sensor workflows, edge-versus-cloud selection, and Python deployment with FND and GMM APIs. In the second, list questions requiring documentation, such as exact API syntax or environment-specific configuration. This prevents assumptions from entering your notes.
Stage 2: Model the network and data flow
Draw several topologies using the Cisco Network IoT Architecture domain as the organising frame. Include the kinds of components named by Cisco—gateways, access points, firewalls, routers, switches, PLCs, embedded microcontrollers, and RTOS systems—only when the scenario calls for them. For every arrow, state what travels across it and why that connection exists.
Review each diagram by removing one link or component and predicting the symptom. Then identify the smallest test that would isolate the fault. This stage is complete when you can explain the path from a sensor or controller to the application and identify plausible failure boundaries without relying on a memorised picture.
Stage 3: Compare edge and cloud placement
Take application scenarios and make an explicit placement decision. Record the data source, processing need, connectivity dependency, response expectation, and destination. Choose edge or cloud, then write the trade-off that supports the choice. The point is to compare edge devices with generic compute devices and select a deployment location for a stated scenario, which is the focus of the Compute and Analysis domain.
Challenge your first decision by changing one condition, such as connectivity reliability or the location of the consumer. If the decision never changes, your criteria are probably too vague. Keep the exercise tied to evidence and scenario constraints rather than claiming that one placement model always wins.
Stage 4: Implement and test deployment automation
Build a small Python workflow around FND and GMM APIs. Begin with a documented request sequence, then add input validation, response checks, and diagnostic output that does not expose sensitive values. Test target selection separately from deployment, and preserve the response needed to investigate an unsuccessful action.
After the script works, break one assumption at a time: use an invalid target in a safe environment, remove a required value, or make the destination unavailable. Record the observed response and the corrective action. This creates practical knowledge of the workflow without claiming access to live exam questions.
Stage 5: Integrate, review, and decide
Finish with an end-to-end scenario: sensor input, network path, edge or cloud decision, application deployment, data handling, visualization, and security boundaries. Produce one diagram and one troubleshooting record. Then review the official sources again and remove any note that is not supported or clearly labelled as a practice recommendation.
The final decision should be explicit. If you need a current credential, use Cisco’s current catalog because DEVIOT is retired. If you need transferable skills, keep practising the architecture, deployment, and diagnostic workflow. If you are reviewing historical certification content, preserve the official dates and scope while avoiding claims that the exam can still be taken.
What should you use as evidence?
Use Cisco’s exam overview and topic page for the exam identity, associations, duration, language, and blueprint objectives; use Cisco’s release notes for lifecycle status and the last test date; and use Cisco’s exam-topics document and DevNet IOx page for the named technical areas and testing context. These sources support a careful study plan without requiring unsupported claims about delivery or scoring.
Official references for exam facts
The Cisco Learning Network exam overview identifies DEVIOT as exam 300-915, Developing Solutions Using Cisco IoT and Edge Platforms v1.0; associates it with the Cisco Certified DevNet Professional and Cisco Certified DevNet Specialist—IoT certifications; records a 90-minute duration; lists English as the available language; and gives the first test date as February 24, 2020.
The Cisco Learning Network topic page supplies the quantified blueprint facts used here: Cisco Network IoT Architecture is 20%, and Compute and Analysis is 10%. It also describes topology interpretation, device and protocol coverage, sensor workflows, connectivity troubleshooting, edge-versus-cloud selection, and Python deployment using FND and GMM APIs.
Cisco’s DevNet v1.1 release notes update classifies DEVIOT 300-915 as End of Life/Retired. The release notes document states that January 20, 2024 was the last day to take DEVIOT 300-915. Those lifecycle facts take precedence over old commercial listings when deciding whether scheduling is possible.
Official references for technical context
Cisco’s DEVIOT exam-topics document describes the exam as evaluating IoT application-development knowledge in Cisco IoT edge-compute and network architecture and names Cisco IOx, Cisco EFM, IoT data visualization, and security methods. Cisco DevNet’s IOx IVT page provides related context about testing IOx-hosted applications for security vulnerabilities and network friendliness, as well as the stated benefits of tested applications.
That IOx testing material is useful context for thinking about integration confidence and application behaviour, but it should not be treated as an additional DEVIOT exam requirement unless the exam blueprint says so. Keep the distinction between exam evidence and a recommended engineering practice visible in your notes.
Conclusion
DEVIOT is best approached now as retired certification content and a source of transferable IoT engineering practice, not as an exam you can schedule. Confirm Cisco’s current certification route before committing money or study time. If you are using the archived blueprint, work from architecture to sensor workflow, edge-placement reasoning, FND and GMM deployment automation, visualization, security, and fault isolation. Keep every official percentage attached to its named domain, label recommendations as recommendations, and use Cisco’s current information for any live certification decision.
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-920 exam — Developing Applications for Cisco Webex and Webex Devices (DEVWBX)
- 350-901 exam — Developing Applications using Cisco Core Platforms and APIs (DEVCOR)
