Labs & Projects
21 labs. Every one of them runs.
Most training calls itself hands-on because you typed along with a video. Here it means you build 21 working systems on your own cloud account, and something automatic tells you whether each one actually works. This page is the long version: what is in a project, what happens when you get one wrong, and what the two you keep look like.
The anatomy of a lab
Four parts. The same four, every time.
Open any of the 21 and you will find the same four parts. Once you have done one, you know how to do all of them — so your attention goes to the technology instead of to figuring out what the assignment wants.
1 · Real files to finish
Working code with the important parts left out. Every gap is marked, so you always know where the work is — you are never staring at an empty screen wondering where to start, and never just copying a finished answer. The file types change as the weeks go on; the shape does not.
2 · You build it for real
You set up real cloud servers on your own account, under your own login. Not a simulator. Not a practice sandbox that wipes itself overnight. Every project that can cost you money says so at the top, and comes with the steps to shut it all down again when you are done.
3 · An automatic check
You run one command and it reads your actual files and your actual running system, then tells you which parts are right and which are not. When something fails it names the specific thing that failed, so the result is a starting point for fixing it rather than just a grade.
4 · A finished example
Once you pass, open the finished version and compare it with yours. Two working answers can differ, and seeing where yours went a different way is most of the learning. 20 of the 21 include one. The final project does not — because that one is yours.
Real output
The course checks its own homework
This is what the check looks like when it runs. You do not need to read code to follow it — it is a list of things that were tested, each marked pass or fail. This one is checking the week 8 Python project, and the file it runs is named validate.sh. Look at the third line. The check is confirming that the half-finished version we hand you still fails. That is deliberate: it proves the gaps are real gaps, and that finishing the project means you have to write something. A project whose starting files quietly passed would teach you nothing, and without this line nobody would notice.
$ ./validate.sh == validating python-automation == [PASS] py_compile: all .py files (syntax) [PASS] unittest: solution passes all tests [PASS] starter is incomplete (tests fail until TODOs are done) == 3 passed, 0 failed ==
Three checks: the code is valid Python, the finished example really works, and the version handed to you does not work yet. All three have to hold before we consider the project fit to teach. This is the only place on this page we show you raw output — the rest of it we will just tell you plainly.
On AI
Why a script and not a checkmark
A language model will hand you an answer to almost any exercise in this program. That is simply the world now, and pretending otherwise would waste your time and insult your intelligence. So we built the labs for that world instead of against it.
A checkbox can be ticked by anyone, and it measures nothing. The check still tells you the truth about whether the thing works, because it runs your code and goes and looks at the system you built. An answer that looks right and doesn’t run fails exactly as loudly as an answer you never wrote.
So the project does not care how you got there. Use the model. Use the documentation. Ask a classmate. What you cannot hand to someone else is the part that matters: you have to make it actually run, on real servers, with your own login and your own mistakes. Then in week 24 you have to stand up and explain out loud why you built it that way.
That is also the job. Nobody is paid to produce a file that looks plausible. They are paid for the thing to be up.
Already broken, on purpose
14 projects hand you code that is already broken
Building something from a clean start is the easy half of the job. The half you actually get hired for is walking into something that is already broken, that you did not write, and finding out why.
So 14 of the 21 projects include a second copy of the code with real faults planted in it. Your job is to work out what is wrong and fix it. Before that copy ever reaches you, the project’s own check has confirmed it really is broken — the fault is genuine, not a typo we hope you notice.
The check is also honest about its own limits. If a tool it wanted to use isn’t installed on your machine, it says so and marks that item skipped, rather than quietly counting it as a pass. You always know what was actually checked and what wasn’t. Reporting the gap instead of hiding it is a habit worth more than a clean-looking score, and it is one of the things this program is trying to teach you.
Debugging is taught here, not used as a hazing ritual
You are not thrown at the broken copy and wished luck. Every class works through the thinking first — how to read an error message, where to look next, how to narrow it down — and then you go do it. Between classes, a support team is there for the moments you are stuck on setup, on tools, or on an error that makes no sense yet. Being stuck is expected. Being stuck alone is not.
The index
All 21 labs
Each one attaches to specific weeks of the program. Several come back later at a harder level — you meet Kubernetes, the system that runs containers across many machines, in week 11, and you keep it running under pressure in week 21. Follow any project through to the week it belongs to.
setup-validation
Week 1
You finish a checker and run it on your own computer to confirm every tool the course needs is installed, so week 2 starts with work instead of an install problem.
linux-shell-automation
Weeks 2 & 8
Backup, disk-check, and log-rotation scripts. Where the command line stops being scary and starts being how you get things done.
git-collaboration
Week 3
How teams work on the same code without overwriting each other, and how changes get reviewed. You practice the mistakes here, before they matter.
aws-cli-fundamentals
Week 4
Read-only AWS operations from the command line, run live against a real account. Nothing here can cost you money.
security-automation
Weeks 6, 17 & 19
Deciding who is allowed to do what in the cloud, then writing those rules down so they are enforced automatically instead of remembered.
aws-storage-databases
Week 7
Cloud storage and databases, described in a file rather than clicked together — then really created, and really deleted again, on your own account.
python-automation
Weeks 8 & 18
Python for the repetitive parts of the job, with real tests. This is the project shown above — the one that checks its own starting files still fail.
ansible-config-mgmt
Week 8
Setting up many machines the same way from one file, every time, instead of configuring each one by hand and hoping they match.
cicd-pipelines
Weeks 9 & 19
Build the assembly line that takes code from your laptop to live users automatically — testing it on the way, with no human copying files around.
docker-containers
Week 10
Packaging an application with everything it needs so it runs the same on your laptop and in the cloud. You build it, not read about it.
kubernetes-fundamentals
Weeks 11 & 12
The basics of Kubernetes, learned one working piece at a time and checked against a real cluster rather than a diagram.
k8s-production-ops
Weeks 12 & 21
Four drills on a live cluster: release a bad version, watch it get stuck, undo it, and keep users served the whole time.
helm-charts
Week 13
Package your app once and install it into test and live environments without keeping a separate copy of everything for each one.
terraform-aws-foundations
Weeks 5, 14, 15 & 17
Write your servers and networks down as code you can review and rebuild from scratch. Nothing is created until you say so.
observability
Weeks 16 & 21
Monitoring: charts and alerts that show you what your system is doing right now, so you know rather than hope. Built with Prometheus and Grafana.
observability-stack
Weeks 16 & 21
The full monitoring setup, with measurable reliability targets and an alert that fires on real user impact. You prove the alert works instead of assuming it.
platform-golden-path
Week 20
A ready-made setup other engineers can reuse to start new services correctly — then you really build one with it. The second portfolio project, below.
sre-incident-response
Weeks 21 & 22
Reliability targets, step-by-step guides for when things break, and a written review afterward without blame. What you do at 3am, written down before 3am.
performance-scaling
Week 22
Throw heavy traffic at a system and watch it add copies of itself, 1 to 5, to cope. How much you can handle becomes something you measure, not guess.
final project
Weeks 23 & 24
Everything from weeks 4–22, joined into one working system that you build, present, and answer questions about. The first portfolio project, below.
career-prep
Week 25
Resume, system-design practice, and structured interview answers — checked for substance, not just presence.
Portfolio
Two things you build that you can show someone
Nineteen of the projects teach a tool. Two of them produce something you own, can walk a stranger through, and can send someone a link to.
Final project — code to live users, safely
Weeks 23 & 24
You build the whole path end to end: the code, the assembly line that tests and packages it, the security checks along the way, the release onto real cloud servers, and the monitoring that proves it is healthy. Changes go live by merging code, and roll back the same way. The other projects teach the pieces; this one makes you responsible for the joins between them.
Then you defend it. That is a formal-sounding word for something simple: you present what you built and answer real questions about your choices. In practice that means:
- You walk everyone through how it is put together, and why.
- You answer hard questions — not “what does this do” but “why this way and not the other way, and what did it cost you.”
- JD Lincoln breaks something in your running system, live, and you work out what happened and fix it in front of the class.
This is the one project with no finished example. There isn’t one to give you — it is your design, your trade-offs, and your answers.
A ready-made setup other engineers can reuse
Week 20
The final project asks you to build a system. This one asks something harder: build the thing other engineers would use to build their systems.
You produce a starting kit and a generator. Someone runs one command and a new service appears with its packaging, its release setup, and its assembly line already wired together and already correct — instead of every engineer reinventing it slightly differently. The project then really builds that generated service, to prove the shortcut actually works.
It is a change in altitude. You stop being the person who solves the problem once and become the person who makes it hard for the next hundred people to get it wrong. That difference is most of what separates a platform engineer from someone who knows the same tools.
Come see one
Run a lab before you decide anything
The first class is free — no payment, no card, no obligation. Come and watch a real project pass or fail in front of you, and judge the program on that rather than on a page describing it.
All you need to start is basic computer literacy, a willingness to learn the command line, and an AWS account. No prior DevOps experience. Classes run in English or Bengali, with a Bengali-speaking instructor — ask admissions which option fits, and for the next intake date: admissions@leadsacademy.org.