NETWORK AUTOMATION

LEARNING PATH
From CLI to Code: A Practical Guide for Network Engineers

Elliot Conner
Senior Network Engineer • CCNP

The Tech-E
Table of Contents

Section Page

How to Use This Guide 3

Introduction 4

Reference Architecture 5

Which Path Should You Start With? 6

Minimum Viable Tooling 7

Phase 1: Foundation 8

Phase 2: Network Programmability 9

Phase 3: APIs and Data Models 10

Phase 4A: Configuration Management 11

Phase 4B: Infrastructure as Code 12

Phase 5: Testing and Validation 13

Phase 6: Advanced Topics 14

Your 90-Day Quick Start Plan 15

Capstone Projects 15

Resources 16

The Tech-E • Network Automation Learning Path • Page 2

How to Use This Guide
Who This Is For
This guide is for network engineers at any skill level who want to add automation to their toolkit.
Whether you've never written code, you've dabbled but nothing stuck, or you're comfortable with
Python and want to apply it to networking—there's a path here for you.

How to Pick Your Path

Everyone starts with Phase 1 (Foundation). After that, use the decision table on page 5 to choose
your next phase based on your daily work. All paths eventually converge—the table just helps you get
wins faster by matching automation to what you already do.

What 'Definition of Done' Means

Each phase has a deliverable with a checklist. These aren't suggestions—they're your finish line.
When every box is checked, you've completed the phase. This keeps you from endlessly studying
without building, and gives you portfolio pieces to show for your work.

The Weekly Practice Loop

Pick a task from your current phase → Automate it → Validate it works → Document what you
learned → Commit to GitHub. Repeat weekly. Consistency beats intensity.

Time Commitment
This guide assumes 5-7 hours per week. Each phase header shows typical completion time. If you
have less time (2-3 hours/week), double the estimates. If you already know Python, Phase 1 drops to
2-3 weeks instead of 4-6.

Demo Artifacts
Every deliverable produces something tangible: a JSON file, an HTML report, a working script. These
go in your /outputs folder and become proof of your skills. Consider recording a 2-minute screen
capture of each one—video demos are powerful for portfolios and LinkedIn posts.

The Tech-E • Network Automation Learning Path • Page 3

Introduction
Who This Guide Is For
Whether you're a network engineer who's never written a line of code, someone with basic Python
skills looking to apply them to networking, or anywhere in between—this guide is for you. The goal
isn't to turn you into a software developer. It's to give you the skills to automate the repetitive parts of
your job so you can focus on the work that actually matters.

My Story
I spent over 10 years in traditional network engineering—CLI commands, console cables, late-night
maintenance windows. I earned my CCNP, worked at Cisco, and built my career doing things the
conventional way. About three years ago, I started learning automation. Not because I had to, but
because I saw where the industry was heading.

I took a few Python courses early on and left them confused, with only a minimal understanding of the
language. I could copy code but didn't really get it. A few months ago, on the recommendation of
other network engineers, I picked up Python Crash Course by Eric Matthes. I worked through every
chapter, completed every challenge and project. That's when things finally clicked.

It wasn't a straight path. I made mistakes, hit dead ends, and spent hours debugging code that should
have taken minutes. But I kept at it. Now I build systems where AI manages network devices, where a
single command can validate an entire infrastructure, and where changes are tested before they ever
touch production. This guide is the roadmap I wish I had when I started.

How to Use This Guide

Each phase includes learning topics, a concrete deliverable, and a Definition of Done checklist so you
know when you've truly completed it. Follow the weekly practice loop: pick a task, automate it,
validate it works, document what you learned, and commit it to GitHub.

Time estimate: This guide assumes roughly 5-7 hours per week. If you have 2-3 hours per week,
double the timelines. Consistency matters more than speed.

The Tech-E • Network Automation Learning Path • Page 4

Reference Architecture
This is the ecosystem you're building toward. Each phase adds a layer. By the end, you'll have a
complete automation pipeline.

SOURCE OF TRUTH
NetBox / Nautobot / YAML Inventory
Devices, IPs, connections, intended state

AUTOMATION LAYER
Python / Ansible / Nornir
Scripts, playbooks, templates (Jinja2)

DEVICE ACCESS
SSH (Netmiko/Scrapli) | NETCONF/RESTCONF | Controller APIs
Retrieve state, push configs, execute commands

VALIDATION
pyATS / Custom Tests
Pre/post checks, compliance, drift detection

CI/CD
GitHub Actions / GitLab CI / Jenkins
Automated testing on commit, staged rollouts

OUTPUTS
Reports (HTML/JSON) | Alerts (Slack/Discord) | Logs
Audit trail, dashboards, notifications

You don't need all of this on day one. Start at the bottom (device access), work your way up. Each
phase in this guide adds capability until you have the full stack.

The Tech-E • Network Automation Learning Path • Page 5

Which Path Should You Start With?
Everyone completes Phase 1 (Foundation). After that, your daily work should guide which path you
prioritize. All paths eventually converge—this just helps you get wins faster.

If your work involves... Start with... Why

Lots of repeated CLI checks Phase 2: Quick wins automating

(health checks, audits, reports) Python + Netmiko what you do daily

Frequent config pushes Phase 4A: Immediate ROI on

(deployments, changes, templates) Ansible + Jinja2 configuration management

Controller environments Phase 3: Match your tooling to

(DNA Center, Meraki, SD-WAN) APIs first your infrastructure

Compliance/audit requirements Phase 5: Build validation into

(change validation, reporting) pyATS early your workflow from day one

Not sure? Default to the standard path: Phase 1 → 2 → 3 → 4 → 5 → 6. It's the most common
progression and builds skills in a logical order.

The Tech-E • Network Automation Learning Path • Page 6

Minimum Viable Tooling
Many beginners stall on setup. Here's the baseline environment that will carry you through all six
phases.

Python Environment
• Python 3.10 or 3.11 recommended (some network libraries lag newer releases)
• Always use virtual environments: python -m venv .venv
• Activate before installing packages, keep a [Link] in every project

Editor Setup
• VS Code (free) or PyCharm Community (free)
• Install Python extension + linter (Pylint or Ruff), enable format-on-save

Project Structure

Folder Purpose

scripts/ Your Python automation scripts

inventory/ Device lists, YAML files, testbeds

templates/ Jinja2 config templates

outputs/ Generated configs, reports, logs

tests/ Validation scripts, pyATS tests

docs/ README, notes, documentation

Lab Environment
• ContainerLab (lightweight, fast iteration—my current favorite)
• EVE-NG or GNS3 (free network emulation)
• Cisco DevNet Sandboxes (free, always-on labs for API practice)

The Tech-E • Network Automation Learning Path • Page 7

 PHASE 1: FOUNDATION
Typical time: 4-6 weeks

Goal: Get comfortable with the fundamentals that everything else builds on.

Linux Fundamentals
Most automation tools run on Linux. Focus on: basic navigation (cd, ls, pwd), file operations (cp, mv,
rm, cat), text editing (nano or vim basics), permissions (chmod, chown), and package management
(apt or yum).

Git and Version Control

Git tracks every change, lets you collaborate, and gives you a safety net. Learn: git init, add, commit,
push, pull, and branching basics. GitHub becomes your portfolio.

Python Basics
Focus on: variables, conditionals, loops, functions, file I/O, lists and dictionaries, and error handling
with try/except.

■ Phase Deliverable: Set up a GitHub repo with proper structure. Write a script that
reads a YAML inventory file, loops through devices, and writes structured output
(JSON) to the outputs/ folder.

Definition of Done:
■ Repo has standard folder structure (scripts/, inventory/, outputs/)
■ Virtual environment created and [Link] present
■ Script reads from YAML, writes to JSON
■ Script handles missing files gracefully (try/except)
■ Code pushed to GitHub with meaningful commit message
■ Demo artifact: /outputs/[Link]

■ Try This: python -m venv .venv && source .venv/bin/activate &&

pip install pyyaml && pip freeze > [Link]

■ The Tech-E Content: I cover lab setup and environment configuration in the
MCP Lab series intro. If you want to see a working multi-platform lab, that's
where to start.

The Tech-E • Network Automation Learning Path • Page 8

 PHASE 2: NETWORK PROGRAMMABILITY
Typical time: 3-4 weeks

Goal: Connect your code to actual network devices and extract structured data.

SSH Libraries
Netmiko – Most popular, simple API, works with dozens of vendors. Scrapli – Modern,
async-capable, supports parallel connections. Paramiko – Lower-level, useful when you need more
control.

Parsing Output
CLI output is text. Use TextFSM (templates), Genie parsers (pre-built for Cisco), or regex (sparingly)
to convert to structured data.

■ Phase Deliverable: Write a script that connects to 3+ devices in parallel, runs

show commands, parses output to JSON, and generates a health report. Build it
sequential first, then add threading/async once output is correct.

Definition of Done:
■ Output is structured JSON (not raw CLI text)
■ Script handles timeouts and auth failures gracefully
■ Results include timestamp and device metadata
■ One command generates a report artifact in /outputs
■ Code pushed to GitHub
■ Demo artifact: /outputs/health_report.json

■ Try This: pip install netmiko then connect to one device:

net_connect.send_command('show version')

■ Common Pitfalls: Phase 2

• Parsing breaks when CLI output format changes (use official parsers when
available)
• Concurrency issues with threading (start with sequential, add parallelism after
it works)
• Inconsistent output between device versions (test against multiple OS
versions)
• Hardcoded credentials in scripts (use environment variables or vault)

The Tech-E • Network Automation Learning Path • Page 9

■ The Tech-E Content: In my MCP Lab, I use Scrapli with asyncio to run
health checks across 12 devices simultaneously. The async migration took
checks from 25+ seconds to about 3 seconds—8x faster.

The Tech-E • Network Automation Learning Path • Page 10

 PHASE 3: APIs AND DATA MODELS
Typical time: 3-4 weeks

Goal: Move beyond screen scraping to proper programmatic interfaces.

The Mental Model Shift

This is the most important concept in this phase:

• CLI = human-readable output (meant for eyes, not code)

• API = structured state (meant for machines)
• YANG = the contract that defines what that structured state looks like
The real leap isn't learning NETCONF syntax—it's thinking in data models.

NETCONF/YANG
Industry standard. NETCONF is the protocol (how you talk), YANG is the data model (what the data
looks like). Benefits: transactions, structured responses, vendor-neutral models.

RESTCONF & Controller APIs

RESTCONF: REST-based alternative using HTTP methods. Controller APIs (DNA Center, Meraki,
SD-WAN): manage networks through a central point instead of device-by-device.

■ Phase Deliverable: Write a script that pulls interface status and BGP neighbors
via NETCONF or RESTCONF. Compare live state to expected state (YAML file).
Output a pass/fail compliance report.

Definition of Done:
■ Data retrieved via API (not CLI parsing)
■ Expected state defined in YAML file
■ Comparison logic identifies mismatches
■ Report clearly shows pass/fail per check
■ Code pushed to GitHub
■ Demo artifact: /outputs/compliance_report.html

■ Try This: Use DevNet sandbox: curl -X GET

[Link]
-u admin:C1sco12345

The Tech-E • Network Automation Learning Path • Page 11

■ The Tech-E Content: My MCP Lab uses NETCONF for structured data
retrieval—getting interface status and BGP neighbors without parsing CLI
output. Covered in the Architecture Overview episode.

The Tech-E • Network Automation Learning Path • Page 12

 PHASE 4A: CONFIGURATION MANAGEMENT
Typical time: 2-3 weeks

Goal: Automate configuration deployment with consistency and repeatability.

Ansible
Agentless, uses YAML playbooks, has modules for every major vendor. Key concepts: inventory files,
playbooks, roles, handlers, and idempotency.

Jinja2 Templating
Create templates with variables. Define data once, render consistent configs for every device. This is
how you scale configuration management.

Idempotency
Your automation should be safe to run multiple times. If desired state exists, nothing changes. This
prevents accidental disruptions.

■ Phase Deliverable: Create Jinja2 templates for base device config (hostname,
NTP, logging, SNMP). Build an Ansible playbook that renders and pushes configs.
Verify idempotency.

Definition of Done:
■ Templates separated from data (Jinja2 + YAML vars)
■ Playbook runs without errors on all target devices
■ Running playbook twice produces no changes (idempotent)
■ Configs validated post-deployment
■ Code pushed to GitHub
■ Demo artifact: /outputs/rendered_configs/ folder with per-device configs

■ Try This: ansible-playbook -i [Link] [Link]

--check --diff (dry run with diff)

The Tech-E • Network Automation Learning Path • Page 13

 PHASE 4B: INFRASTRUCTURE AS CODE
Typical time: 3-4 weeks

Goal: Establish a Source of Truth and build data-driven automation workflows.

Source of Truth (SoT)

Where does your network data live? A Source of Truth like NetBox centralizes everything: devices,
IPs, circuits, connections. Your automation reads from the SoT—one place to update.

Drift Detection
Compare intended state (SoT) to actual state (devices). Two approaches:

• Beginner-friendly: Drift on structured state (interfaces, BGP neighbors, NTP) via

parsers/NETCONF
• Advanced: Drift on rendered config vs running config with normalization rules
Start with structured state—config drift detection has edge cases (ordering, defaults, whitespace) that
can frustrate beginners.

■ Phase Deliverable: Set up NetBox. Populate with lab devices. Write a script that
pulls inventory from NetBox API, retrieves structured state from devices (interfaces,
BGP neighbors, NTP servers), compares to intended state in NetBox, and reports
drift.

Definition of Done:
■ NetBox populated with accurate device data (IPs, interfaces, connections)
■ Script pulls inventory dynamically from NetBox API
■ Live device state retrieved via NETCONF or parsers (not raw config)
■ Drift detection compares structured state (e.g., interface status, neighbor counts)
■ Report clearly identifies what drifted and where
■ Code pushed to GitHub
■ Demo artifact: /outputs/drift_report.json
■ Stretch goal: Add rendered-config vs running-config drift with normalization

■ Try This: pip install pynetbox then: [Link]() to list all

devices from NetBox

The Tech-E • Network Automation Learning Path • Page 14

■ The Tech-E Content: I've integrated NetBox with my lab environments to
pull device inventory dynamically. I'll publish a walkthrough on this workflow on
The Tech-E.

The Tech-E • Network Automation Learning Path • Page 15

 PHASE 5: TESTING AND VALIDATION
Typical time: 3-4 weeks

Goal: Know your changes work before deploying them to production.

Why Testing Matters

Automation without testing is just faster mistakes. The real value isn't speed—it's confidence.

pyATS and Genie

Cisco's testing framework (works with other vendors too). Learn device state, compare before/after
changes, run test suites, generate compliance reports.

Pre/Post Validation Pattern

Capture baseline → make change → capture post-state → compare → alert on differences.

■ Phase Deliverable: Write a pyATS test suite that captures pre-change

snapshots, runs after a config change, compares state, and generates an HTML
pass/fail report.

Definition of Done:
■ Testbed YAML properly configured for all devices
■ Pre-change snapshot captures interfaces, routing, BGP
■ Post-change snapshot captured automatically
■ Diff clearly shows what changed
■ HTML report generated in /outputs
■ Code pushed to GitHub
■ Demo artifact: /outputs/pyats_report.html

■ Try This: pyats validate testbed [Link] (validates your testbed

before running tests)

■ Common Pitfalls: Phase 5

• Testbed YAML syntax errors (validate with pyats validate testbed)
• Package version conflicts (use a dedicated venv for pyATS)
• Genie parsers not available for your platform/command (fall back to custom
parsing)
• Tests pass locally but fail in CI (environment differences—pin versions)

The Tech-E • Network Automation Learning Path • Page 16

■ The Tech-E Content: In my MCP Lab, pyATS powers health checks,
baseline snapshots, and compliance validation. I can ask Claude to 'check
compliance on R1' and get immediate feedback.

The Tech-E • Network Automation Learning Path • Page 17

 PHASE 6: ADVANCED TOPICS
Typical time: Ongoing

Goal: Explore the cutting edge of network automation.

Event-Driven Automation
Let events trigger automation. Interface down? Open a ticket and gather diagnostics. BGP drops?
Alert Slack and capture logs. Tools: StackStorm, custom webhooks.

Streaming Telemetry
Devices push data in real-time via gNMI/gRPC instead of polling. CPU, memory, interface stats every
few seconds without asking.

AI-Assisted Operations
Model Context Protocol (MCP) lets AI models interact with your network through defined tools.
Natural language queries, intelligent troubleshooting, proposed remediation.

■■ AI Operations Guardrails (Non-Negotiable)

AI-assisted operations require mature safeguards before enabling any

automation:

• Read-only tokens by default – AI should observe before it acts

• Allow-list commands only – Explicitly define what's permitted
• Human-in-the-loop for changes – AI proposes, human approves
• Comprehensive audit logging – Every action logged (who/what/when)
• Break-glass credentials stored securely – Emergency access separate
from AI
• Start with troubleshooting and reports – Build trust before enabling
remediation

■ The Tech-E Content: The entire MCP Lab series is about this: building a
system where Claude queries devices, runs health checks, discovers topology,
and proposes remediation—with proper guardrails.

The Tech-E • Network Automation Learning Path • Page 18

Your 90-Day Quick Start Plan
Assumes 5-7 hours per week. If you have 2-3 hours, double the timelines.

Weeks Focus Milestone

1-2 Linux, Git, Python basics Push first script to GitHub

3-4 Netmiko, build a lab Automate show commands (3+ devices)

5-6 Parsing, structured data Parse CLI → JSON, generate report

7-8 NETCONF or Ansible Configure devices without CLI

9-10 pyATS basics Health check + baseline snapshot

11-12 Capstone project Portfolio piece (see below)

Weekly Practice Loop: Pick → Automate → Validate → Document → Commit

Capstone Projects
Option 1: NetOps Automation Pack (NOC teams, operations engineers)
Parallel health checks + parsed JSON output + HTML report + Slack/Discord alerts. One command
validates your entire network.

Option 2: Config Pipeline (Architects, design engineers)

NetBox as SoT → Jinja2 templates → Ansible deployment → pyATS validation. Update NetBox, run
pipeline, configs deploy with validation.

Option 3: Controller Workflow (SD-WAN, cloud network engineers)

Pull state from controller API → compare to intended state → compliance report → propose changes.
Continuous compliance for controller-managed infrastructure.

The Tech-E • Network Automation Learning Path • Page 19

Resources
Recommended Reading
• Python Crash Course by Eric Matthes – The book I used to learn Python. Work through the
chapters, complete the challenges, build the projects. It's hands-on and practical. First
assignment: Finish Part 1 (Basics) and commit your challenge solutions to GitHub.

Free Learning
• Cisco DevNet – First assignment: Run a GET request against the Always-On IOS-XE sandbox
to retrieve interface data.
• Network to Code – First assignment: Follow their NetBox quickstart tutorial end-to-end.
• Kirk Byers (Python for Network Engineers) – First assignment: Complete weeks 1-4, commit
each exercise to GitHub.

The Tech-E Content

• YouTube: The Tech-E – MCP Lab series, architecture deep dives, hands-on tutorials
• LinkedIn – Tips, lessons learned, project updates as I build in public

Final Thoughts
You don't need to master everything. Pick one thing from Phase 1, learn it well enough to be useful,
then move to the next. Momentum matters more than perfection.

Three years ago, I didn't know Python. Now I build systems where AI manages my network lab. This
guide is the roadmap I followed. Now it's yours.

Connect on LinkedIn or subscribe to The Tech-E on YouTube.

"The only thing stopping you is you."

— Elliot

The Tech-E • Network Automation Learning Path • Page 20