Your quarterly networking bootcamp has just lost its opening morning to broken environments, while the support reply arrives after the class has ended. The demonstration looked polished, and the vendor comparison showed plenty of features, but neither told you who would restore a failed lab during delivery. That gap matters more when the same course runs again and every unresolved task returns with the next cohort.
Feature lists rarely publish the reset process, the instructor workload, the live-class escalation path, or the contract structure behind a managed lab as a service, so the vendor calls have to surface what the comparison pages skip. Every question below is one you can ask on the phone, with the answer that should come back and the answer that should worry you.
A team still defining its delivery model may need the broader guide to cloud-based training labs before it evaluates managed service. A university comparing remote access, curriculum integration, and campus infrastructure can start with the guide to how universities build network labs. Bring whichever requirements list you end up with into the provider calls.
A course can finish successfully on Friday and still fail at the next opening session because saved configurations, expired accounts, and changed images remain in the environment. You need to know who presses the reset, what the reset restores, when it happens, and how the provider proves the next cohort received the approved starting state.
If the provider names an owner and walks you through the handoff, you are hearing a good answer: whether it restores a clean template or gold master, rebuilds from scratch, or expects your team to do either; what triggers the reset; the turnaround commitment; the checks performed afterward; and how instructor changes that should carry into the next run are preserved.
If you hear "easy reset" or "automated provisioning" with nobody attached to it, keep asking. Those phrases do not tell you whether an instructor must close sessions, remove learners, validate images, or open a service request before the next class can start. Ask the provider to walk through the days between two of your real cohorts, then record every task and its owner in your delivery plan.
An instructor teaching a routing exercise cannot also spend the session creating accounts, extending access windows, checking machine health, and guiding learners through console failures. "Managed" has no useful meaning until the provider separates its duties from the instructor's, task by task, for the hours the class is actually running.
Three call tests settle it faster than any dashboard tour. Can the instructor add a late arrival on the spot, or does that need a ticket? Can they reset one student's environment without resetting the room? Can they extend the access window when the class runs over? Then ask who monitors the underlying environment during the session, who decides when a failed resource is restarted or replaced, and what the actual instructor and student controls are on the tier you are buying, not on a demo tier.
If the answer to any of the three tests is "raise a request," you have found work that lands on the instructor mid-class. Map every recurring administrative action to the provider, the instructor, or the learner before you accept the word "managed."
A learner who loses access during a live exercise creates an immediate teaching decision: pause the room, change the exercise, or continue while that learner waits. General support availability does not answer who can report the incident, how it is prioritized, what the escalation path is, or whether the support team can act on the lab rather than log a ticket.
If coverage is tied to your timetable and the support boundary is named, the answer is good: whether learners contact support directly, whether the instructor has a priority route, who owns communication during an incident, and how unresolved cases pass between shifts. CloudMyLab, for example, publishes 24/7/365 priority support for Lab as a Service with a dedicated account manager and technical staff, and lists 24/7 student and faculty priority support on its education offering. Where a provider publishes an SLA, as CloudMyLab does at 99.9% for that service, ask what the SLA covers and what it does not: an SLA percentage says nothing about triage, who may call, or whether support can act on your lab.
If you hear "support is available" and the conversation returns to the product demonstration, that is the worrying answer. Rehearse the contact path before the first class and write down the instructor fallback if the environment goes dark mid-session.
A course validated against an approved image or software release can break when the next cohort receives a different version, default configuration, or resource profile. Workbooks, assessments, and instructor demonstrations all assume a known starting state.
Ask for the artifact by name: a gold master, a lab profile, a topology file with an image hash. Then ask the rules around it: who may change it, whether the provider can upgrade underneath you and how much notice you get, whether you can refuse an upgrade until the next intake, and what "validated" means when they say the restored environment was validated (a login, a full lab path, or a ping). A course update you approve and infrastructure maintenance they perform are two different changes and need two different approval paths.
If the provider says environments are "standardized" but cannot show a version record or a change notice, treat consistency as unproven. Request a sample change notice, the restoration procedure, and a validation record before you sign.
Twenty seconds into a vendor call you can usually classify them. If they lead with a course catalog, they sell content. If they ask for your OVA files and topology, they sell infrastructure. If they talk about lab profiles, class launch links, and scoring, they sell lab orchestration. Comparison pages put all three in one grid, which is why buyers discover too late that a course library was included in one offer and only an environment in another.
| What they sell | Examples | What the provider owns | What you still own or must confirm |
| Courseware and skills libraries | Pluralsight, CBT Nuggets | Courses, video content, and self-guided labs attached to that content | Whether your own curriculum can run there at all; live delivery support; lab customization |
| Learning management systems | TalentLMS, LearnUpon | Enrollment, learning records, assignments, course administration | The lab infrastructure itself, the reset process, live technical support |
| Lab orchestration and delivery platforms | Skillable, CloudShare, Instruqt | Lab profiles or templates, class launch, per-learner environments; some bundle official courseware for specific vendor tracks | Your own content where you bring it; images and licenses; the exact managed-service boundary |
| Hosted emulators and physical topologies | CloudMyLab (network labs) | Hosted EVE-NG, GNS3, and CML 2.0 environments; physical Learning Labs; the platform operations | Courseware and workbooks; images and their licenses; instructor workflow |
CloudMyLab is an infrastructure provider: you upload your own device images to its hosted emulators, its team can purchase licenses on your behalf for platforms where that applies, and CML 2.0 licenses come directly from Cisco. Its Learning Labs are customizable physical topologies, and it does not sell workbooks or provide training. Classify the vendor before you compare features, then get every content and licensing responsibility in writing.
A platform can support many users in an open pool and still struggle when an entire scheduled cohort signs in together. A recurring course is a concentrated start event: simultaneous authentication, provisioning, console access, and topology activity, not a smooth pattern of independent use.
Ask how the platform provisions your class at the scheduled time (from a gold master or lab profile at launch, or from environments held ready), what validation runs before access opens, and what happens when demand differs from the roster because of late additions, an overlapping cohort, a rescheduled session, or a failed resource. A useful provider will rehearse the launch pattern that resembles your class rather than pointing at aggregate platform scale.
Total user counts, customer logos, and infrastructure size tell you nothing about your forty people logging in at 9:00. Ask for a rehearsal with your topology, image mix, access method, and cohort schedule, then make a clean launch an acceptance condition.
Take one quarterly bootcamp of thirty seats and walk it through each structure a provider might offer. Priced per named seat, a learner who drops in week one still costs a seat; ask whether seats can be reassigned mid-run. Priced per course run, a run with eighteen enrolled costs the same as one with thirty; ask what counts as a run and when it starts and ends. Priced per concurrent seat, an overlapping second cohort doubles the peak; ask how overlap is metered. Priced as reserved capacity, a paused quarter still reserves; ask what pausing costs and whether environments are retained through it.
Then ask the questions that survive any of the four: how roster changes are treated, whether unused access rolls over, what is retained between runs, which managed services are included, and what work between runs is billed. "Custom pricing" is not an answer to any of that. Model your normal quarter, a small run, an overlapping run, and a paused quarter against the proposed terms, then choose the structure whose behavior you can predict.
Network courses often need emulator environments or physical topologies rather than a generic desktop or software sandbox, and most lab-delivery platforms are built for the latter. Managed lab as a service for network courses is a narrower field, and CloudMyLab is one infrastructure option in it: it hosts EVE-NG, GNS3, and CML 2.0, provides physical Learning Labs, and offers Lab as a Service, and it does not sell courseware, so your team keeps the curriculum role while the contracted service defines the infrastructure and operational role.
A network-lab fit still depends on your images, licensing position, topology, timetable, support needs, and responsibility split. Test that fit through the free trial or bring a recurring-course scenario to the CloudMyLab team, and put the same seven questions to any other infrastructure provider on your shortlist.
Most comparison pages will hand you a mixed list, and the mix is the problem: skills libraries such as Pluralsight sell self-guided labs attached to their own courses, and learning management systems such as TalentLMS or LearnUpon do not host the lab environment themselves. For managed environments behind your own recurring course, the candidates are lab orchestration and delivery platforms such as Skillable, CloudShare, and Instruqt, and, for network labs specifically, hosted emulator and physical topology providers such as CloudMyLab. Put the seven questions above to each: who resets, what the instructor can do live, support during class, consistency across runs, the content boundary, launch capacity, and contract structure.
A managed lab as a service provider should state exactly which operational tasks it owns: provisioning, reset, infrastructure monitoring, incident response, and changes between course runs. The scope varies by contract, so the word "managed" alone is not evidence that instructors or learners are free from administrative work. Put the responsibility split into the service description and the acceptance criteria.
Match support to the course timetable and define who can contact support, how incidents are prioritized, who can act on the environment, and how escalation works. Published availability or an SLA is useful only when its scope matches the service your class uses. Test the contact path during a rehearsal and document the instructor fallback if service is interrupted.
Recurring course labs stay consistent through a named artifact (gold master, lab profile, or topology file), controlled versions, recorded changes, repeatable resets, and validation before learner access. The provider should distinguish course-approved changes from maintenance and explain how unsupported dependencies are handled. Require an agreed starting-state check for every cohort.
The right structure depends on whether your schedule is best represented by named seats, a course run, concurrent seats, or reserved capacity. Compare how each treats roster changes, overlaps, pauses, environment retention, support, and reset work. Select the unit that follows your real delivery behavior and keeps responsibility clear across repeated runs.