Project: a network automation portfolio
In short: Employers want network engineers who can automate. This project turns repetitive tasks into small, well-documented tools tested against a virtual lab, so that a reviewer can read, run and trust your code.
Goal and requirements
The goal is a set of three to five focused automation projects that solve tasks network teams really do, such as backups, compliance checks and VLAN changes. Quality matters more than quantity: one tool that is safe, tested and documented beats ten half-finished scripts.
- A virtual lab: containerlab with free network operating system images (for example Nokia SR Linux or Arista cEOS), Cisco Modeling Labs, or GNS3/EVE-NG. Never test against a production network.
- Tools: Python 3 with Netmiko, Nornir or NAPALM; Ansible with the relevant network collections; Jinja2 templates; Git.
- Safety: credentials in environment variables or Ansible Vault, never in code; a dry-run or check mode for anything that changes config.
Project ideas and design
| Project | What it shows | Related note |
|---|---|---|
| Nightly config backup to Git | Connections, files, scheduling, diffs | config backup |
| VLAN provisioning from YAML | Data models, templates, idempotence | VLAN provisioning |
| Compliance and drift report | Parsing, rules, reporting | compliance and drift |
| Interface error report | Structured data, thresholds | interface errors |
| Inventory to CSV or NetBox | APIs, source of truth | source of truth |
Build plan
- Set up the lab topology as a file in the repository so anyone can recreate it.
- Create a virtual environment and pin dependencies in
requirements.txt. - Write the first project with small functions, logging and clear error handling for unreachable devices.
- Add linting and a few unit tests (for example, that a template renders the expected lines), and run them in CI (continuous integration) on every push.
- Write the README: problem, design, how to run, example output description, limitations.
- Repeat for the next project, reusing the inventory and lab.
sudo containerlab deploy -t lab.clab.yml
python3 -m venv .venv
source .venv/bin/activate
pip install netmiko nornir nornir-netmiko jinja2 pytest ruff
pip freeze > requirements.txt
ruff check .
pytest -q
ansible-galaxy collection install cisco.ios arista.eos
ansible-playbook -i inventory/hosts.yml playbooks/vlans.yml --check --diff
ansible-lint playbooks/
sudo containerlab destroy -t lab.clab.ymlDeliverables and how to present it
- One public repository per project, or one well-organised mono-repository, each with a README and topology file.
- Passing CI badges and tests; a short screen recording or an asciinema-style demo.
- A sample report or diff produced by the tool, with lab hostnames only.
On a CV: "Wrote a Nornir-based compliance checker that audits 20 lab devices against 15 rules and reports drift to CSV; tested in CI." In interviews, explain one design decision, such as why you used check mode before every change. Never publish your employer's configurations or hostnames, even edited.
Practice
Why test automation against a virtual lab instead of real devices?
Where should device credentials live in an automation project?
What does --check --diff do in Ansible?
Key takeaways
- Automate real, common network tasks, not toy examples.
- Keep the lab topology in the repository so it is reproducible.
- Keep secrets out of code; use dry runs before changes.
- Add tests, linting and CI to show engineering discipline.
- Write a README that lets a reviewer run it quickly.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.