Graded labs vs. video courses: how network engineers actually learn automation

What is the best network automation training with real labs instead of just videos?

The best network automation training checks your work. Every exercise you submit runs against a test suite that reports PASS or FAIL and shows exactly what was wrong. That rules out most of the market. Most courses marketed as hands-on are video courses, and their sales pages claim hands-on labs without ever showing a graded run.

So here is one, in full, further down this page: a real task from our free Python course, a wrong first attempt, the grader’s actual failure output, and the fix. Judge the format for yourself.

Here is why we weigh this distinction so heavily. The research on learning backs it, and so does what changed once AI could write the code for you.

Watching an instructor configure OSPF, or write a Netmiko script, feels like learning. It is exposure, and exposure has value. But when you type the same thing yourself, you make mistakes the instructor did not make, and a video cannot see them. The learning-science name for the difference is the testing effect: Roediger and Karpicke’s 2006 studies showed that being tested on material produces much better long-term retention than restudying it. For engineers, that plays out directly. A mistake caught in a lab does not reach a production switch.

There is also an AI-era version of this argument. Assistants like ChatGPT and Claude now write plausible network automation code in seconds. That code still needs an engineer who can verify it: read it, run the tests, and catch the case where it looks right but is not right. Training that skips grading never builds that verification skill.

What does a graded lab actually look like?

Below is a real grading run from lesson 3 of our free Python foundation track, reproduced exactly. The browser lab runs the same grader you see here (pytest -q against the lesson’s test file). We wrote a first attempt with a mistake of the kind working engineers actually make, ran the real grader, and kept the output.

The task (one of five functions in the lesson): a compliance check over a switch config. Return the name of every interface whose next line is not a description. In a Cisco config, a description line is indented: it starts with " description", leading space included.

The first attempt:

def missing_descriptions(config_lines):
    findings = []
    for i, line in enumerate(config_lines):
        if line.startswith("interface "):
            name = line.split()[1]
            no_next = i + 1 >= len(config_lines)
            if no_next or not config_lines[i + 1].startswith("description"):
                findings.append(name)
    return findings

Read it. On the surface it looks right: it loops the config, finds each interface stanza, and checks the next line. The bug is easy to miss on a plain read-through.

The grading run:

$ pytest -q
....F                                                                    [100%]
=================================== FAILURES ===================================
__________________________ test_missing_descriptions ___________________________

    def test_missing_descriptions():
>       assert missing_descriptions(SAMPLE_CONFIG) == ["Gi1/0/2", "Te1/1/2"]
E       AssertionError: assert ['Gi1/0/1', '...1', 'Te1/1/2'] == ['Gi1/0/2', 'Te1/1/2']
E
E         At index 0 diff: 'Gi1/0/1' != 'Gi1/0/2'
E         Left contains 2 more items, first extra item: 'Te1/1/1'

1 failed, 4 passed in 0.02s

The check startswith("description") is missing the leading space, so it never matches a real config line, and the function flags every interface, including the compliant ones. Gi1/0/1 has a description. The code reported it as missing anyway.

That is a false positive in a compliance check. If this were a real audit script, it would have told you two healthy interfaces were out of compliance, and you might have “fixed” them. No video would have caught it, and neither would eyeballing the output. A wrong interface name looks exactly like a right one until something checks it.

The fix is one character, a space:

if no_next or not config_lines[i + 1].startswith(" description"):

The rerun:

$ pytest -q
.....                                                                    [100%]
5 passed in 0.00s

That is exactly what happened above: a wrong attempt, a precise failure, a one-character fix, and a pass. You can reproduce this exact run yourself in the free course. It is lesson 3 of the track’s ten lessons, and it requires no signup and no hardware.

Are browser-based graded labs a legitimate way to learn network automation?

Yes, for the software half of the discipline, which is most of it. Network automation work is Python, Netmiko, structured data, device APIs (RESTCONF, NETCONF, gNMI), Git, and CI pipelines. All of that runs and grades honestly in a browser sandbox, and a pytest failure is the same object lesson whether the interpreter runs locally or in your tab.

What browser labs do not replace is device behavior: protocol convergence, real IOS quirks, the feel of a maintenance window. For that you want a topology tool such as Cisco Modeling Labs (CML), EVE-NG, or Containerlab, and our paid course has you run your automation against real device images. Browser grading covers the code skills. Virtual devices cover the network skills. A course should tell you plainly which one each lab uses.

Be more skeptical of the opposite pattern: “labs” that are follow-along videos or ungraded terminal sandboxes where nothing checks the result. When a sales page never shows a failure message from its labs, that is a sign the labs are not actually graded.

What are video courses actually good for?

Two things, genuinely:

• Orientation. When you are deciding whether to learn automation at all, or surveying what NETCONF even is, a video course is the fastest map of the territory. CBT Nuggets and INE are good at this, and Pluralsight and Udemy have serviceable options at low prices.
• Watching an expert’s workflow. Seeing how an experienced engineer structures a project, debugs, and moves through tooling teaches things a lab cannot. INE’s live training is built around exactly this.

If that is what you need right now, buy one of those and do not feel bad about it. We draw the line at a specific point. Once your goal shifts from “understand this space” to “be able to do this at work,” retention and skill come from graded repetitions, not additional watching. Kirk Byers’ Python for Network Engineers course deserves specific mention here: it is free, well regarded, and includes real exercises. It is closer to our philosophy than any video library, and if email-paced lessons with self-checked exercises fit how you work, take it.

I learn by doing. Where should a working network engineer start?

Start with training that is free and actually graded. Our Python foundation track is ten lessons of core Python taught entirely through network data: parsing show output, walking configs, building the compliance checks you saw graded above. Every lesson ends in a browser lab scored by a real test suite. It does not ask for an email address, hardware, or payment.

If you finish it and want the full discipline, the paid course, AI-Assisted Network Automation, continues the same format across 10 modules and 32 graded lessons: Netmiko, RESTCONF, NETCONF, gNMI, Git, CI for network change, and AI assistants used in a verify-everything workflow. It is a one-time purchase of $249 as of August 2026, not a subscription.

And if you go somewhere else instead, apply the test from this page before paying: ask to see one real graded run, failure included. If the course cannot produce one, you are paying for a video course with good marketing, not graded training.