What Makes a Real-world Network Automation Project?

Eighteen capstones already exist. Why does this module still need to?

This isn't a new tool -- it's a new kind of composition

Every module since "Your First Network Automation" ended with a capstone that applied one module's new tool to the same continuity fleet. That already produced eighteen small, real, working projects. This module introduces zero new automation frameworks and zero new dependencies -- its entire value is combining tools from different modules in ways no single capstone needed to.

Quick checkConcept check

This module introduces no new Python packages and no new automation framework. What, then, is actually new about it?

Nothing -- it repeats material from earlier modulesThe combinations: each project deliberately reuses tools from two or three previously separate modules together, in ways this curriculum's own capstones explicitly declined to doA browser-based execution environment replacing local scriptsA new vendor-specific automation library

Guided exercise vs. capstone vs. real-world project

A single-module capstone (what you've already done 18 times)

One tool, one module's own new mechanic
Applied to the same known fleet (SW1-SW5)
Proves: this specific tool works, end to end

A real-world project (this module)

Two or three tools from separate modules, combined
A named business problem drives the combination
Proves: you can connect what you already know, unprompted

Quick checkScenario

A learner already completed every module through Production Automation. What is the one thing they haven't been asked to do yet?

Learn NAPALM or Nornir -- neither has been introduced yetDeliberately combine tools from two or three separate, already-completed modules into one original script solving one business problemConnect to a real network device for the first timeWrite their first Python script

The eight-step frame

Each of the next three project lessons walks through the same shape. It's not a new methodology to memorize -- it's just made explicit here so the projects themselves can stay focused on the integration, not on re-explaining "how to think about a project" three times.

Business problemwhat's actually broken or missing, in plain terms
Requirementswhat "done" concretely means
Inputs / inventorywhere the fleet and its data come from
Automation workflowthe real script, built from tools you already know
Validationhow the script proves its own result, not just asserts it
Failure handlingwhat happens when something doesn't go as planned
Result / reportthe concrete output a stakeholder could read
Portfolio presentationhow to describe this work outside this course

Quick checkOrdering

In this module's eight-step frame, where does 'failure handling' sit relative to 'validation'?

Failure handling comes first -- you plan for failure before you build anythingRight after validation -- once a workflow can prove whether it succeeded, the next question is what happens when that proof comes back negativeThey're the same stepFailure handling only applies to the closing lesson, not the projects

Quick checkScenario

A learner wants to build a real-world project but is only comfortable using the one tool from the module they just finished. Is that consistent with this module's own approach?

Yes -- using only the newest tool is exactly the pointNot quite -- every project ahead deliberately reaches back across multiple earlier modules, not just the most recent one. A real-world project's value comes from the combination, not from favoring whichever tool was learned lastIt doesn't matter which tools are used, as long as the code runsThis module requires using every tool from every module at once

What's reused, what's not

Referenced, not re-taught

Every project ahead assumes you can already do the following without a refresher: pull device state or push configuration with NAPALM, orchestrate a fleet with Nornir, read/write with GitPython, and reason about NetBox as a dynamic inventory source. None of those fundamentals are re-explained here -- each project lesson names exactly which earlier lesson covered the mechanic it's reusing, and moves straight to the new combination.

Narrower than the Capstone, on purpose

None of the next three projects touches the full curriculum. Each combines two or three modules, never all of them. The Capstone -- the module directly after this one -- is reserved for the first genuinely cumulative project. Keeping these three focused is what leaves that room.

Key takeaways

This module adds zero new automation frameworks -- its value is combining already-verified tools from separate modules in ways no prior capstone did.
A real-world project differs from a capstone by scope, not difficulty: it's driven by a named business problem that pulls in two or three tools at once, not one tool applied once.
All three projects ahead follow the same eight-step frame: problem, requirements, inputs, workflow, validation, failure handling, report, portfolio.
Nothing here re-teaches NAPALM, Nornir, Git, or NetBox fundamentals -- each project names its prerequisites and moves straight to the new integration.
These projects are deliberately narrower than the Capstone, which comes next and is reserved for the first genuinely cumulative project.

What you'll learn

Eighteen capstones already exist. Why does this module still need to?

Guided exercise vs. capstone vs. real-world project

The eight-step frame

What's reused, what's not