SprintUG Internet Graduate Trainee Program

Ninety days to engineer

A hands-on traineeship that builds network and systems engineers from the metal up. No frameworks, no shortcuts, no copy-paste. Version 1.0 — {{ cohortLabel }}.

Core 90 days · 13 weeks
Extension Weeks 14–21
Format On-site, full time
Cohort 8–12 trainees
01

What this program is

We do not train people to use tools. We train people to understand the machine, so that any tool becomes learnable in an afternoon.

Most graduates arrive able to drag a framework into place but unable to explain what a file descriptor is, why their commit history is a mess, or what happens between pressing the power button and seeing a login prompt. Sprint runs a network. A network is built out of exactly those fundamentals — Linux boxes, servers, DNS, permissions, uptime and disciplined change history.

So the sequence is deliberate and it is bottom-up: version control before code, markup by hand before editors, the shell before the GUI, the kernel before the distribution, the machine before the operating system. By week 7 a trainee can hold a whole computer in their head. Only then do we put a production server in their hands.

Five house rules
Type it, don't paste it Every command in every lab is typed by hand. Muscle memory is the curriculum.
Everything lives in Git Notes, configs, scripts, screenshots. If it isn't pushed, it didn't happen.
Explain before you fix A trainee states the hypothesis out loud, then acts. Guess-and-restart is not debugging.
Break your own machine Labs run on disposable VMs. Destroying and rebuilding is the point, not the accident.
Write it for the next person Each week ends in documentation another trainee could follow unaided.
02

The map

Phase 1 · Weeks 1–2

Craft foundations

Git and GitHub as a professional identity. HTML written by hand, in Notepad, with nothing helping you.

Phase 2 · Weeks 3–6

Systems literacy

The Linux command line, the kernel underneath it, and the physical computer underneath that.

Phase 3 · Weeks 7–13

Ubuntu in production

Seven weeks on Ubuntu desktop and server — users, services, networking, storage, hardening, uptime.

Extension · Weeks 14–21

Windows Server

Eight weeks of Active Directory, DNS, DHCP, Group Policy, Hyper-V and PowerShell for enterprise clients.

†

On the 90 days. Weeks 1–13 are the ninety-day core traineeship — the block a graduate must complete to be certified as a Sprint Junior Systems Engineer. Weeks 14–21 are the Windows Server specialisation, run as a second block for trainees continuing into the enterprise and IT-support side of the business. Total program: 21 weeks, 105 training days.

03

The 21 weeks, charted

Phase schedule Each column is one training week · 5 days · 40 hours
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Craft foundations
GIT · HTML
Systems literacy
SHELL · KERNEL · ARCHITECTURE
Ubuntu operations
INSTALL · SERVICES · NETWORK · STORAGE · SECURITY · UPTIME · CAPSTONE
Windows Server
AD · GPO · SERVICES · HYPER-V · POWERSHELL
Assessment
Weekly gate
Capstone & certification
Extension block
Competency build-up Depth of coverage per competency, week by week. Darker means more of the week spent there.
Version control
Markup & web
Command line
OS internals
Hardware
Networking
Server admin
Documentation
How the hours are spent
840 hours
25% taught sessions
20% guided lab
43% independent lab
12% assessment & writing

Roughly three hours on the keys for every hour taught. Nobody passes this program by listening.

Program in numbers
21 weekly gates
100+ hands-on labs
2 capstone builds
0 pasted commands
04

Week by week

Each week runs Monday to Friday: mornings taught, afternoons lab, Friday afternoon assessed. A week is not signed off until its deliverable is pushed and its gate is passed.

01 Week one Days 1–5 · Phase 1 Git, GitHub & your professional name

Before you write a line of anything, you learn how work is recorded, shared and attributed — and you choose the name that will carry your career.

Taught
  • What version control actually solves: the folder-called-final-v3 problem, lost work, two people one file.
  • Why Git exists — Linus Torvalds, 2005, the kernel team losing access to BitKeeper; distributed by design, no central permission needed.
  • Git is not GitHub. Git is the tool on your machine; GitHub (2008) is a hosting and collaboration service built on top of it. GitLab, Bitbucket and Gitea are alternatives — the skill transfers.
  • The object model in plain terms: working tree, staging area, commit, history as a chain of snapshots.
  • Branches, merges, merge conflicts, and why a conflict is normal rather than a failure.
  • Remotes: origin, fork, clone, pull request, code review as a conversation.
  • Commit hygiene: one idea per commit, imperative subject line under 50 characters, why "fixed stuff" is a professional liability.
  • The GitHub CLI (gh): auth, repo create, issue, pr create, pr checkout, run watch.
  • SSH keys and personal access tokens — authenticating without pasting a password all day.
The username talk — day one, hour one

Your GitHub username is the URL on your CV, in every commit you ever author, in every pull request an employer reads, and on the profile a client checks before signing. It follows you across jobs and continents. It outlives every project you build.

Choose: your real name or a clean variant, lowercase, short, spellable over a phone call, no birth year, no numbers padding, no jokes, no team or employer name. Avoid: anything you would not read aloud in an interview. Renaming later breaks links, forks and references — treat it as permanent.

Labs
  1. Configure identity, init a repo, stage and commit ten times, then read your own history with git log --oneline --graph.
  2. Push to a new remote, then clone it back into a second directory and prove both copies are identical.
  3. Two trainees, one repo, one file, deliberate collision — resolve the merge conflict by hand and explain each marker.
  4. Branch, open a pull request, review a partner's PR with real comments, merge, delete the branch.
  5. Repeat the entire day-4 lab using only gh from the terminal — no browser.
  6. Recover: git revert, reset and reflog on a repo you have intentionally wrecked.
Diagram 1.1 — where your work actually lives Four places, six commands
01 Working tree The files you edit
add
02 Staging area What goes in next
commit
03 Local history Your chain of snapshots
push
04 Remote — GitHub Shared, reviewed, permanent
← clone · fetch · pull · checkout
Branch A movable pointer. Cheap to make, cheap to throw away.
Pull request A request to merge, and a conversation about the change.
Conflict Two histories touched the same line. Normal. You decide.
Deliverable A public profile repo with a written README, plus a learning-log repo that every later week commits into.
Gate Clone, branch, commit, push, open and merge a PR from a cold terminal in under ten minutes, narrating each step.
02 Week two Days 6–10 · Phase 1 HTML by hand, in Notepad

No editor. No autocomplete. No emmet, no formatter, no live preview. One text file, one browser, and a person who can close their own tags.

Taught
  • What HTML is: a markup language for structure and meaning. Tags describe what content is, not what it looks like.
  • What HTML is not: not a programming language — no logic, no loops, no state. Not styling; that is CSS. Not behaviour; that is JavaScript. Not a framework, and not something you need a tool to produce.
  • How the browser really works: request, response, parse, DOM tree, render. Why a missing closing tag changes the tree.
  • Document anatomy: doctype, html, head, meta charset, viewport, title, body.
  • Text structure: headings h1–h6 as an outline, paragraphs, lists, blockquote, strong versus b, em versus i.
  • Links and paths: absolute, relative, anchors, mailto, tel — the same path thinking used later in the shell.
  • Images and alt text as an accessibility obligation, not decoration.
  • Tables done properly: thead, tbody, th, scope, caption.
  • Forms end to end: label pairing, input types, name and value, required, method and action, and what actually reaches a server.
  • Semantic layout elements: header, nav, main, section, article, aside, footer.
  • Entities, comments, whitespace behaviour, nesting and validity rules.
  • Validation with the W3C validator, and reading an error message instead of fearing it.
Why Notepad

An editor that closes your tags teaches you nothing about tags. Trainees write in Notepad on Windows and nano once they reach Linux — plain text, saved as .html, refreshed by hand. The habit that survives is the one built without assistance: on a client site, at 2am, over SSH, there is no editor.

Labs
  1. Type a valid document from memory, no reference, in under three minutes.
  2. Mark up a printed page of Sprint package copy using only structural tags — no styling of any kind.
  3. Build a five-field customer signup form, then explain what each field sends and where.
  4. Reproduce a tariff table from a screenshot as a correct semantic table.
  5. Fix a deliberately broken 60-line file: unclosed tags, wrong nesting, missing quotes, bad paths.
  6. Friday build: a five-page hand-written site — home, packages, coverage, support, contact — cross-linked, image-bearing, W3C-valid, zero CSS, committed page by page with meaningful messages.
Diagram 2.1 — tags become a tree
html
├─headmeta · title
└─body
├─headernav → a
├─main
├─h1one per page
├─sectionp · ul · img
└─formlabel + input
└─footer

Miss one closing tag and the branch attaches to the wrong parent. That is the whole reason we do not let an editor close them for you.

HTML is
Structure — what content is Meaning — machine-readable semantics A tree the browser builds Plain text, editable anywhere
HTML is not
A programming language Styling — that is CSS Behaviour — that is JavaScript Something you need a tool to write
Deliverable The five-page site, pushed, with a README explaining the structural choices made on each page.
Gate Write a valid page containing a nav, a table and a labelled form in Notepad, unaided, in twenty minutes — and state three things HTML is not.
03–04 Weeks three & four Days 11–20 · Phase 2 The Linux command line

Two weeks in a terminal with no desktop environment available. The shell stops being intimidating and becomes the fastest way to work.

Week 3 — living in the shell
  • What a shell is: kernel, shell, terminal, TTY; why bash, and what zsh and sh are.
  • The filesystem hierarchy — /, /etc, /var, /home, /usr, /tmp, /dev, /proc — and what belongs in each.
  • Absolute and relative paths, ., .., ~, tab completion, history, globbing.
  • Files and directories: ls, cd, cp, mv, rm, mkdir, touch, find, locate, stat, du, df.
  • Reading files: cat, less, head, tail -f, wc, sort, uniq, cut, diff.
  • Users, groups, ownership, and permissions in both symbolic and octal form; sudo and the root question.
  • Editors that are always there: nano first, then survival vim — open, edit, save, quit.
  • Getting unstuck: man, --help, apropos, and how to read a synopsis line.
Week 4 — composing power
  • Streams and plumbing: stdin, stdout, stderr, pipes, redirection, tee, exit codes.
  • Text processing: grep and regular expressions, sed, awk, tr, xargs.
  • Processes and jobs: ps, top, htop, kill, signals, nohup, background jobs, systemd basics.
  • Archiving and transfer: tar, gzip, scp, rsync, ssh and key-based login.
  • Networking from the terminal: ip, ping, traceroute, dig, ss, curl — the daily toolkit of an ISP engineer.
  • Environment and dotfiles: PATH, variables, aliases, .bashrc, cron and scheduled work.
  • Bash scripting: shebang, arguments, conditionals, loops, functions, set -e, and writing a script someone else can run.
Labs
  1. Terminal-only fortnight: no file manager, no GUI text editor, for ten working days.
  2. Navigate a 5,000-file tree blindfold — find every file over 10MB, every one modified today, every one owned by the wrong user.
  3. Permissions clinic: reproduce and then fix six broken-access scenarios, explaining the octal each time.
  4. Log forensics: given a 200,000-line access log, extract the top ten client IPs, error rates per hour, and a one-line summary — with one pipeline.
  5. Write site-check.sh: pings a list of customer routers, logs results with timestamps, exits non-zero on failure, runs hourly from cron.
  6. Rebuild your own dotfiles repo and clone it onto a fresh VM to prove it works.
  7. Recover a machine with a broken .bashrc and a full /var partition.
Why two weeks

Command-line fluency is the single highest-leverage skill in this program. Everything from week 5 to week 21 is delivered through it. One week produces recognition; two weeks produce reflex.

Diagram 3.1 — the pipeline
cat access.log | grep 404 | awk '{print $1}' | sort | uniq -c | sort -rn | head
cat200,000 lines
grep 4049,140
awkone field
uniq -c412 IPs
headthe answer

Small tools, one job each, joined by streams. Trainees learn to think in stages rather than in scripts.

Diagram 3.2 — the filesystem, and what lives where
/etcConfiguration. Everything you will edit as an admin.
/varLogs, spool, databases. The partition that fills up at 3am.
/homeUsers. Their dotfiles, their mess, their data.
/usrInstalled programs and their libraries.
/devDevices as files. Disks, terminals, random.
/procThe kernel, readable as text. Week 5 lives here.
/tmpScratch space. Assume it disappears.
rwx r-x r-- = 754 — owner, group, everyone else. Drilled until instant.
Deliverable A personal shell-toolkit repo: dotfiles, five useful scripts, and a command reference written in your own words.
Gate A timed 25-task terminal exam on an unfamiliar machine, plus a script written live from a spoken specification.
05 Week five Days 21–25 · Phase 2 The Linux kernel, and why it is everywhere

The commands from weeks 3 and 4 were requests. This week you meet what was answering them — and discover the same kernel is inside the router on the customer's wall.

Taught
  • What a kernel does: process scheduling, memory management, filesystems, device drivers, networking stack, security boundaries.
  • User space versus kernel space; what a system call is; watching real syscalls with strace.
  • The history: Torvalds 1991, GNU tools plus a kernel, the GPL, and why "Linux distribution" means kernel plus everything else.
  • Monolithic versus microkernel, and where modules fit: lsmod, modprobe, dkms.
  • The boot chain: firmware, bootloader, kernel, initramfs, init/systemd, login.
  • Inspecting a live kernel: /proc, /sys, dmesg, uname, journalctl -k, sysctl tuning.
  • Interrupts, drivers and hardware — how a NIC becomes eth0.
  • Kernel versions, LTS releases, and why you patch.
Linux is in almost every machine

Every Android phone. The customer's home router, ONT and set-top box. The OLT in the exchange. Smart TVs, cars, point-of-sale terminals, ATMs, CCTV recorders, drones, the Mars helicopter, all 500 of the world's fastest supercomputers, and the overwhelming majority of servers and cloud instances the internet runs on. A trainee who understands this kernel can log into most of the infrastructure they will ever touch.

Labs
  1. Trace cat file.txt from keystroke to disk read, naming each layer crossed.
  2. strace a running process and identify ten syscalls and what each one asked for.
  3. Read a full dmesg after boot and narrate the hardware story it tells.
  4. Load and unload a module; disconnect a USB NIC and watch the kernel react.
  5. Tune two sysctl values, measure the effect, revert cleanly.
  6. SSH into a lab home router and prove it is running Linux — find the kernel version, the busybox shell, the interfaces.
  7. Compile a minimal kernel in a VM and boot it. Once. So it is never mysterious again.
Deliverable & gate A written boot-sequence walkthrough with annotated dmesg output. Gate: whiteboard the path from power-on to shell prompt, and name five Linux devices in a customer's home.
Diagram 5.1 — power button to login prompt
01FirmwarePOST, UEFI, hardware check, boot order
02BootloaderGRUB picks a kernel and passes parameters
03KernelDecompresses, claims memory, starts drivers
04initramfsTemporary root, finds the real disk
05systemdPID 1 brings up every service in order
06LoginA shell, and you are back on familiar ground
Diagram 5.2 — the boundary
User spacebash, nginx, your scripts — no direct hardware access
system callsthe only door
Kernel spaceScheduler, memory manager, filesystems, drivers, network stack
HardwareCPU, RAM, disks, NICs
Where this kernel already runs
100%of the top 500 supercomputers
~3bnAndroid devices in active use
mostweb servers and cloud instances
everyrouter, ONT and OLT on our network

Also: smart TVs, set-top boxes, ATMs, point-of-sale terminals, CCTV recorders, cars, drones. Learn one kernel, log into almost anything.

06 Week six Days 26–30 · Phase 2 The computer itself — architecture

One week with the lid off. What the hardware is, what each part actually does, and what "architecture" means when someone hands you a spec sheet or a dead machine.

Taught
  • The von Neumann model: CPU, memory, storage, input, output, and the buses between them.
  • Inside the CPU: control unit, ALU, registers, clock, cores, threads, cache L1–L3; fetch–decode–execute.
  • Instruction sets and what architecture means in practice: x86-64 versus ARM versus RISC-V — and why a package built for one will not run on the other.
  • 32-bit versus 64-bit: address space, why it caps RAM, what it means for the software you install.
  • The memory hierarchy and the cost of a cache miss; RAM versus swap versus disk.
  • Storage: HDD versus SSD versus NVMe, sectors, partitions, MBR versus GPT, RAID in outline.
  • Data representation: bits, bytes, binary, hex, two's complement, ASCII and UTF-8, and why 1TB is not 1TiB.
  • Motherboard tour: chipset, sockets, DIMM slots, PCIe lanes, SATA, NIC, PSU and power budgets.
  • Firmware and the boot chain revisited: POST, BIOS versus UEFI, secure boot, boot order.
  • Virtualisation from the hardware side: VT-x/AMD-V, hypervisors, why a VM is not an emulator, containers versus VMs.
  • Server-grade hardware: ECC memory, redundant PSUs, out-of-band management, rack units, thermal and power planning for a small ISP room.
Labs
  1. Full teardown and rebuild of a desktop tower: name every component, reseat every part, boot it again.
  2. Read the machine from software — lscpu, lsblk, lspci, lsusb, free, dmidecode — and write its spec sheet from scratch.
  3. Convert between binary, decimal and hex until it is instant; then read a subnet mask in binary.
  4. Benchmark cache-friendly versus cache-hostile access on the same data and explain the gap.
  5. Enter UEFI, change boot order, enable virtualisation, document each screen.
  6. Diagnose three faulty lab machines: no POST, bad RAM, dying disk — using indicators, beeps and logs.
  7. Spec and price a server for a 500-subscriber Sprint site, and defend every line item.
Deliverable & gate An illustrated architecture notebook plus the costed server specification. Gate: a viva — draw the data path of a single instruction, then triage an unknown faulty machine aloud.
Diagram 6.1 — the machine, drawn once and never forgotten
CPU
Control unit
ALU
Registers
L1
L2
L3 cache
fetch → decode → execute → store
Main memory RAM. Fast, volatile, addressable. Holds the running program and its data. ~100 ns
Storage NVMe, SSD, HDD. Slow, permanent, partitioned and mounted. ~100 µs – 10 ms
System bus — address · data · control PCIe · SATA · DDR channels
InputKeyboard, sensors, network in
OutputDisplay, network out
FirmwareUEFI — the first code that runs
Diagram 6.2 — why locality matters
Register<1 ns
L1 cache~1 ns
L3 cache~20 ns
RAM~100 ns
NVMe SSD~100 µs
Hard disk~10 ms
Bar length is illustrative, not linear — a disk read is roughly ten million times slower than a register read. This is why servers get RAM before they get CPUs.
Diagram 6.3 — architecture, in one line each
x86-64Desktops, servers, most of our racks. Intel and AMD.
ARM64Phones, routers, Raspberry Pi, newer cloud instances.
RISC-VOpen instruction set. Rising in embedded work.
MIPSStill inside plenty of older CPE on customer walls.
This is why .deb packages are architecture-specific, and why a binary that runs on your laptop will not run on the router. Trainees must be able to say why without hesitating.
Phase 3 · Weeks 7–13 · Days 31–65

Seven weeks of Ubuntu

From first install to a running, monitored, hardened, documented server stack. Each trainee owns one physical machine and two VMs for the whole phase, and rebuilds them from bare metal twice.

07 Week seven Installing Ubuntu properly
  • What Ubuntu is: Debian lineage, Canonical, LTS versus interim releases, release cadence and support windows, why LTS for production.
  • Desktop, Server and minimal images; ISO verification with checksums and GPG.
  • Partitioning decisions: EFI, root, swap, separate /var and /home, filesystem choice.
  • Guided versus manual install; unattended installs with cloud-init and autoinstall.
  • First-boot checklist: updates, hostname, timezone, locale, non-root admin user, SSH keys.
  • Desktop orientation for trainees who need it: GNOME, settings, the difference between the shell you know and the GUI.
Labs & output Install Ubuntu Server three ways — manual on bare metal, in a VM, and fully unattended from an autoinstall file. Then destroy and rebuild the bare-metal box from your own written runbook, timed. Deliverable: a versioned install runbook another trainee can follow without asking a question.
08 Week eight Users, packages & services
  • Account administration at scale: useradd, groups, sudoers, password policy, expiring accounts, PAM in outline.
  • APT end to end: repositories, sources, keys, apt versus dpkg, pinning, PPAs and the risk they carry, snaps.
  • Upgrades that do not break production: unattended-upgrades, kernel updates, reboot windows, do-release-upgrade.
  • systemd for operators: units, enable versus start, dependencies, timers instead of cron, journalctl.
  • Writing your own service unit and making it survive reboots and crashes.
  • Time discipline: NTP, chrony, and why clock drift ruins logs, auth and billing.
Labs & output Provision fifteen users with correct group policy from a script. Package one of your week-4 scripts as a systemd service with a timer, then prove it restarts after a hard power cut. Deliverable: an onboarding/offboarding script plus a service unit, both reviewed by pull request.
09 Week nine Networking on Ubuntu
  • TCP/IP for operators: the layers, IPv4 addressing, subnetting and CIDR by hand, gateways, MTU, an IPv6 primer.
  • Interface configuration with netplan; static addressing, bonds, VLANs, bridges.
  • DNS in depth: resolvers, record types, forward and reverse zones, systemd-resolved, running BIND9 or unbound.
  • DHCP: leases, scopes, reservations, and running isc-dhcp-server or kea.
  • Routing, NAT and firewalling: ip route, ufw, iptables/nftables concepts.
  • Diagnosis in order: cable, link, address, gateway, DNS, application — with ping, ip, ss, dig, mtr, tcpdump.
  • ISP context: how a subscriber's traffic reaches Sprint's core, and where a junior engineer is allowed to look.
Labs & output Build a two-subnet lab network with your own DNS and DHCP servers, route between them, then run a blind fault-finding round where a trainer breaks one layer and you have fifteen minutes to name it. Deliverable: a network diagram, netplan and zone files in Git, and a one-page troubleshooting decision tree.
Diagram 9.1 — the lab network each trainee builds
UpstreamSprint edgepublic /30
GatewayUbuntu routernftables · NAT
Services VLAN 10DNS · DHCP · web10.10.10.0/24
Client VLAN 20Workstations10.10.20.0/24
Diagram 9.2 — fault-finding order
1Physical — link light, cable, port
2Address — ip a, is there a lease
3Gateway — ping it, then beyond it
4Name resolution — dig, not the browser
5Application — port, service, logs
Always bottom-up, always one layer at a time. "It's the DNS" is a conclusion, not a starting point.
Diagram 9.3 — subnetting, read in binary
10.10.20.37 / 24
00001010
00001010
00010100
00100101
network network network host
Network 10.10.20.0 · Broadcast 10.10.20.255 Usable hosts 254 · Mask 255.255.255.0
10 Week ten Storage, filesystems & backup
  • Block devices, partitioning with fdisk/parted, formatting, mounting, fstab and UUIDs.
  • ext4 versus xfs versus ZFS in practice; inodes, journaling, fsck.
  • LVM: physical volumes, volume groups, logical volumes, live extension, snapshots.
  • Software RAID with mdadm; what RAID protects against and what it does not.
  • Network storage: NFS and Samba shares for an office.
  • Backup strategy: 3-2-1, full versus incremental, rsync, borg or restic, retention, offsite, encryption.
  • Restore drills, because an untested backup is not a backup.
  • Capacity monitoring and the disk-full incident.
Labs & output Grow a live LVM volume with no downtime. Fail a RAID member and rebuild the array. Then have a trainer delete a directory you care about and restore it from your own backup, timed. Deliverable: an automated encrypted backup job with a written, tested restore procedure.
11 Week eleven Serving & securing
  • Nginx and Apache: virtual hosts, reverse proxy, static versus dynamic, logs.
  • TLS properly: certificates, chains, Let's Encrypt and certbot, renewal, HSTS, expiry as an outage cause.
  • Serving the week-2 hand-written site from your own server, over HTTPS, on a real hostname.
  • Databases in outline: installing PostgreSQL or MariaDB, users, grants, a dump and a restore.
  • SSH hardening: keys only, no root login, non-default port debate, fail2ban.
  • Firewall policy, least privilege, the principle of minimum installed software.
  • Patch discipline, CVEs, unattended security updates, and Ubuntu Pro/livepatch.
  • Auditing: auth logs, sudo logs, lynis, and what a compromised box looks like.
Labs & output Harden a deliberately weak server against a trainer-run attack script, then swap machines and try to break a partner's. Score by what each of you actually stopped. Deliverable: a live HTTPS site on your own server plus a completed hardening checklist with evidence.
12 Week twelve Monitoring, automation & uptime
  • What to monitor and why: the four signals, thresholds, alert fatigue.
  • Standing up Prometheus, node_exporter and Grafana; useful dashboards rather than pretty ones.
  • Uptime checking and alerting to email and WhatsApp-style channels.
  • Centralised logs: journald, rsyslog, rotation, retention.
  • Automation: bash to Ansible — inventories, playbooks, idempotence, configuring three servers from one command.
  • Containers in outline: Docker images, containers, volumes, compose, and when a container is the wrong answer.
  • Incident practice: detect, triage, communicate, fix, write the post-mortem.
  • On-call etiquette, escalation paths and customer communication during an outage.
Labs & output Monitor the whole cohort's servers from one Grafana instance. Then a live incident hour: trainers break three machines at random and trainees run the response as a team, with a written post-mortem due the same day. Deliverable: an Ansible playbook that rebuilds your entire stack from scratch, plus one post-mortem.
13 Week thirteen Capstone — day 90

Build the complete branch-office stack for a fictional Sprint site, alone, from bare metal, in five days.

  • Ubuntu Server installed from your own runbook, hardened to your own checklist.
  • Internal DNS and DHCP, correct addressing, documented network plan.
  • A file share, an HTTPS site, and a small database, all backed up and restorable.
  • Monitoring and alerting live, with dashboards a manager could read.
  • Everything reproducible by playbook; everything committed with clean history.
  • A handover document and a fifteen-minute defence in front of the team.
Day 90 certification

On the final day, the trainer wipes one random component of the trainee's stack without warning. Recovery within the hour, using their own documentation, is the last requirement for the Sprint Junior Systems Engineer certificate.

Trainees who pass are eligible for placement in the NOC, field operations or IT support, and for the Windows Server extension.

Diagram 13.1 — the capstone stack Every layer built by the trainee, reproducible from their own repo
Observability
Prometheus
Grafana dashboards
Alerting
Services
DNS
DHCP
Nginx + TLS
Samba share
PostgreSQL
Platform
Ubuntu Server LTS
systemd units
LVM + backups
Hardening
Hardware
Bare-metal tower · managed switch · two VLANs · lab router
Reproducible by
Ansible playbook
Git history
Written runbook
05

Extension — Windows Server

Weeks 14–21. Sprint's business customers run Windows. This block turns a Linux-fluent junior into someone who can walk into an SME, inherit a domain, and be trusted with it. The Linux discipline carries over — same rigour, different vendor.

14 Foundations & install
  • Windows Server editions, licensing and CALs explained without hand-waving.
  • Desktop Experience versus Core; why Core is the professional default.
  • Installation, roles and features, Server Manager, Windows Admin Center.
  • NTFS versus share permissions, the registry, Event Viewer, services.msc.
  • Where Windows differs from Linux in mental model — and where it does not.
Lab: install Server Core, configure it entirely from the command line, join it to nothing yet, document every step.
15 Active Directory
  • Why a directory exists: identity, authentication, authorisation in one place.
  • Forests, domains, trees, trusts, sites, OUs and objects.
  • Promoting a domain controller; a second DC and why one is never enough.
  • Users, groups, computers, delegation, service accounts.
  • Kerberos and NTLM in outline; replication and the FSMO roles.
Lab: build a two-DC domain for a 40-person company, with an OU structure that reflects a real org chart.
16 DNS, DHCP & networking
  • AD-integrated DNS, zones, records, scavenging, conditional forwarders.
  • DHCP scopes, reservations, options, failover, and DHCP in a routed network.
  • Routing and remote access, VPN for staff, RADIUS/NPS for Wi-Fi authentication.
  • Windows Firewall with Advanced Security.
  • Interoperating with the Linux DNS you built in week 9.
Lab: a client-site network where Windows and Ubuntu servers serve the same users without conflict.
17 Group Policy & endpoints
  • GPO structure, scope, inheritance, precedence, loopback processing.
  • Security baselines, password and lockout policy, drive mapping, software deployment.
  • Joining and managing Windows 10/11 clients; printers; roaming and folder redirection.
  • Patch management with WSUS; endpoint protection.
  • Troubleshooting policy with gpresult and RSoP instead of guesswork.
Lab: lock down a lab of client machines with eight policies, then prove each one applies and why.
18 File, print & web services
  • File server role, shares, DFS namespaces and replication, quotas, shadow copies.
  • Permission design that survives staff turnover; auditing file access.
  • Print services and deployed printers.
  • IIS: sites, bindings, app pools, certificates, and hosting the site you wrote in week 2.
  • Certificate services in outline; internal PKI basics.
Lab: a departmental file structure with least-privilege access, quotas and self-service restore.
19 Virtualisation & storage
  • Hyper-V: hosts, virtual switches, generations, checkpoints, live migration.
  • Storage Spaces, iSCSI targets, deduplication.
  • Failover clustering concepts and a two-node cluster in the lab.
  • Windows Server Backup, bare-metal recovery, and Azure/hybrid options in outline.
  • Disaster recovery planning: RPO, RTO, and a written DR runbook.
Lab: lose a domain controller on purpose and recover the domain from backup, timed.
20 PowerShell & automation
  • Objects not text: the pipeline, cmdlet naming, Get-Help, Get-Member.
  • Filtering, formatting, exporting; CSV in, CSV out.
  • Remoting, sessions, and running a change across fifty machines safely.
  • Scripts, functions, modules, parameters, error handling, -WhatIf.
  • Bulk AD administration; scheduled tasks; monitoring and reporting scripts.
  • Comparing the same job in bash and PowerShell — one engineer, two toolkits.
Lab: onboard 100 users, groups, shares and mailboxes-equivalent from a spreadsheet, in one idempotent script.
21 Enterprise capstone
  • Design and build a complete SME environment: two DCs, DNS, DHCP, file, print, IIS, VPN, backup, monitoring.
  • Mixed estate — the Ubuntu server from week 13 must coexist and serve the same users.
  • Full documentation set: network diagram, IP plan, admin runbook, DR plan, client handover pack.
  • Trainer-run failure day: three unannounced faults across both platforms.
  • Final panel defence in front of engineering and management.
Award: Sprint Systems Engineer — Enterprise, with placement in business support or field engineering.
06

How trainees are measured

The weekly scorecard
Practical gate — can you do it, unaided 40%
Deliverable quality & documentation 25%
Explanation — can you teach it back 20%
Professional conduct — punctuality, commit hygiene, teamwork 15%
Pass mark
70%
Pass mark 70%. Below 70% earns one supported re-sit the following Monday; two failed gates trigger a formal review with the training lead.
Daily rhythm
SU
TAUGHT
GUIDED
INDEPENDENT LAB
LOG
08:30 09:00 11:15 13:00 14:00 16:30
Stand-up — yesterday, today, blockers. Ten minutes, standing. Log — commit the day's work and write one paragraph on what broke. Friday 14:00 — gate assessment and deliverable review, no exceptions.
On graduation, a trainee can
  • Work entirely from a terminal on an unfamiliar Linux machine.
  • Install, configure, secure, monitor and back up a production Ubuntu server.
  • Run DNS, DHCP, web and file services and diagnose them layer by layer.
  • Explain what happens between power-on and login, and why it matters.
  • Keep every change in Git with a history a reviewer would respect.
  • Write documentation a colleague can execute without help.
  • Hold a professional GitHub identity worth showing a client.
  • After the extension: inherit, operate and recover a Windows domain.
What each trainee needs
  • A laptop with virtualisation enabled, 8GB RAM minimum, 100GB free.
  • A GitHub account created on day one under their permanent username.
  • Shared lab kit: one tower per trainee, a managed switch, a rack, spare drives, a lab router and ONT.
  • A notebook. Paper. Used daily.
Diagram 6.4 — the handover of responsibility Trainer involvement falls as trainee autonomy rises. By week 13 the trainee leads; by week 21 they can train someone else.
Trainee autonomy
Trainer support
W1 — everything demonstrated W7 — half led by the trainee W13 — solo capstone W21 — teaches the next cohort
SprintUG Internet

We are not filling seats. We are building the engineers who will keep Uganda connected.

Program owner Training & Technical Operations
Applications sprintug.com
Document Curriculum v1.0 · 21 weeks