# Start Here — Program Overview How the internship works, the 12-week syllabus and timeline, what's expected after each module, and how you'll be assessed. Read this first. # How This Program Works Welcome. This is a **12-week, hands-on path** from "I can use a computer" to "I can deploy and operate real systems." It's built for people who are new to Linux and infrastructure — every module assumes only what the modules before it taught. ## You drive; the mentor guides This program is **self-directed**. You read the lessons, do the assignments, and build real things on the lab. Your mentor is not a lecturer — they are there to **point you in the right direction, unblock you, and answer questions** when you're genuinely stuck. The more you try on your own first, the more you'll learn (and the better the questions you'll ask). ## How to use this material - Work the books **top to bottom**, in order. Each is a module. - Inside a book, study the **chapters in sequence**, then do the **Assignments** chapter at the end. - Every lesson has a **"Check yourself"** section — if you can answer those questions, you're ready to move on. - Every lesson has **"Dig deeper"** links and **"Search terms"** — use them when you want more than the lesson gives. ## The blocker protocol Getting stuck is part of learning. But spinning for hours is not. The rule: ``` 1. Re-read the lesson section that covers it. 2. Try the "Dig deeper" links / search the error message. 3. Still stuck after ~30 minutes? → Ask your mentor. When you ask, bring: what you tried, what you expected, what happened. ``` A good "I'm stuck" message is itself a skill we're teaching. ## The weekly checkpoint Once a week you'll have a short **checkpoint** with your mentor: show your latest assignment **working**, and talk through one thing that confused you. It's not a test — it's how we catch a silent blocker early and keep you on track. Come ready to *demo*, not to present slides. ## What you'll have at the end A portfolio of working things you built yourself: scripts in Git, containers in a registry, apps running on a real Kubernetes cluster, pipelines that deploy them, and dashboards that show them running — finished off by a **capstone** that ties every module together. Let's begin. Open **The 12-Week Syllabus & Timeline** next. # The 12-Week Syllabus & Timeline The program is **11 modules over 12 weeks**, at roughly **30 hours per week**. The order is deliberate: you learn to operate one machine by hand, then package it, orchestrate it, automate it, package it for Kubernetes, and finally observe it. ## The arc ``` operate ─▶ containerize ─▶ orchestrate ─▶ automate ─▶ templatise ─▶ observe (Mod 1–5) (Mod 6) (Mod 7) (Mod 8–9) (Mod 10·Helm) (Mod 11) ``` ## Module → week map | Module | Topic | Target weeks | |--------|-------|--------------| | 1 | Networking Fundamentals | Week 1 | | 2 | Linux Fundamentals | Weeks 2–3 | | 3 | Shell Scripting | Week 3 | | 4 | Git & Version Control | Week 4 | | 5 | Common Linux Services | Weeks 4–5 | | 6 | Containerization (Docker/Podman) | Weeks 6–7 | | 7 | Kubernetes & Orchestration | Weeks 8–9 | | 8 | CI/CD | Week 10 | | 9 | Infrastructure as Code | Week 11 | | 10 | Helm Charts | Week 11 | | 11 | Observability + **Capstone** | Week 12 | *(Modules 9 and 10 are both intro-depth and share Week 11 — IaC concepts plus Helm basics. Helm builds directly on Kubernetes from Module 7.)* These are **targets, not a stopwatch**. The early modules (1–3) are the foundation everything else stands on — it's fine if they take the time they take. There is roughly 10 hours/week of built-in slack versus a full-time load; that's your buffer for the weeks that run long. ## Two things we never skip 1. **The fundamentals (Weeks 1–3).** If Linux and shell are shaky, everything later turns into copy-paste-without-understanding. Don't rush them. 2. **The capstone (Week 12).** It's where the eleven topics become one skill. It's also your headline portfolio piece. ## The lab is your playground You'll work on a real environment — a private network of Linux VMs, a live Kubernetes cluster, a container registry, databases, a Git server, and a full observability stack. The lessons point you at the exact hosts to use (for example, the **Jumpbox** at `10.100.100.254` is your main entry point). You're learning on real infrastructure, not toys. Next: **What's Expected After Each Module.** # What's Expected After Each Module Here is the bar for each module — what you should be able to **do** (not just recognise) before moving on. If you can do the things on the line, you're ready for the next module. These are also exactly what your mentor will look for at the weekly checkpoint. ### After Module 1 — Networking Fundamentals You can read a machine's IP/subnet/gateway, decide whether two addresses are on the same network, explain TCP vs UDP and ports, and troubleshoot a connection from the bottom of the stack up (refused vs timeout). ### After Module 2 — Linux Fundamentals You can move around a Linux system confidently, manage files and permissions, find things with `grep`/`find`, inspect running processes, and start/stop/inspect a service with `systemctl` and read its logs with `journalctl`. ### After Module 3 — Shell Scripting You can write a readable, robust Bash script that takes arguments, makes decisions, loops, checks exit codes, and fails safely — to automate a real task. ### After Module 4 — Git & Version Control You can initialise a repo, commit cleanly, branch and merge (and resolve a conflict), and push to / pull from the lab's Gitea server, including a basic pull-request flow. ### After Module 5 — Common Linux Services You can install and do basic config of Nginx (incl. a reverse proxy), create a per-app database + user on a relational DB, and explain when you'd reach for MongoDB, Redis, or Memcached. ### After Module 6 — Containerization You can write a clean multi-stage Dockerfile (non-root, pinned, healthchecked), build and run it, network containers together, write a Compose stack, and push an image to the lab registry. You can explain Docker vs Podman. ### After Module 7 — Kubernetes You can deploy a containerized app to the live cluster with a Deployment, expose it with a Service/Ingress, configure it with a ConfigMap/Secret, and give a stateful app persistent storage with a PVC. ### After Module 8 — CI/CD You can write a pipeline that builds and pushes an image on the lab runner, and explain GitOps — deploying an app to the cluster with Argo CD. You can say when you'd pick Jenkins, Bitbucket Pipelines, or GitHub Actions. ### After Module 9 — Infrastructure as Code You can write a cloud-init config to bootstrap a VM, read/understand a basic Terraform and Ansible example, and explain which tool fits which job (provisioning vs configuration vs bootstrap). ### After Module 10 — Helm Charts You can install a public Helm chart onto the cluster and drive its full lifecycle (install, override values with a values file, upgrade, and roll back), and you can author, lint, and package a simple chart for your own app. ### After Module 11 — Observability + Capstone You can ship logs and metrics to Grafana, build a dashboard, set a working alert, and — in the **capstone** — take an app all the way from source to a containerized, pipeline-deployed, observable service running on the cluster. > If you can't yet do the line for a module, that's useful information — flag it at your checkpoint. It's far cheaper to shore up a gap now than to discover it three modules later. # How You'll Be Assessed Let's be transparent about how this works. This internship is a **talent pipeline** — the goal is to find people we want to keep. So it's worth knowing what "doing well" actually means here. ## We measure trajectory, not trivia You are **not** expected to master ten deep fields in twelve weeks — nobody does. What we're watching for is **how you learn and operate**: - **Do you make steady progress** through the modules and assignments? - **Do the things you build actually work** — and can you show them working? - **How do you handle being stuck** — do you try, search, and read first, then ask a sharp question? - **Do you document and communicate** clearly (your assignment notes, your checkpoint demos)? - **Are you curious** — do you use the "Dig deeper" links, ask "why", go a step beyond the assignment? A person who finishes Module 7 with shaky understanding looks weaker than a person who finishes Module 6 having truly *got* every piece. **Depth of understanding beats racing ahead.** ## How it's checked - **Assignment acceptance criteria.** Every assignment ends with a checklist of self-verifiable "done" conditions. Meet them honestly — the point is the skill, not the checkmark. Don't fabricate output. - **The weekly checkpoint.** A short live demo of your latest working assignment + one thing that confused you. This is the main signal. - **The capstone (Week 12).** The big one. It re-exercises every module: an app, containerized, deployed to the cluster through a pipeline, and observable in Grafana. A strong capstone is the clearest "yes" we can get. ## What a strong finish looks like By Week 12, a strong intern can independently take a small service from source code to **running and observable on real infrastructure**, explain every layer they used, and show good judgement about *why* each tool was the right choice. That's the bar for "we'd like to keep working with you." ## Your part of the deal - Be honest about what works and what doesn't — surfacing a problem early is a strength, not a weakness. - Keep your work in the open (Git, your assignment notes) so progress is visible. - Ask for help at the 30-minute mark — but bring what you tried. That's it. Do the work, build real things, stay curious, communicate clearly. Now go open **Module 1 — Networking Fundamentals**.