Who this is for
A beginner who wants to learn DevOps but does not know where to start. You need only a computer and internet. No paid course is needed to start.
One machine is enough
Every lab runs on your own computer. No cloud account, no card, no bill for the learning itself.
One step at a time
Learn in order. Do not jump to Kubernetes before you can use Linux and Git. At every step, build one small thing. Reading alone is not enough.
Proof, not just notes
Finished projects beat finished videos. You end with three working projects on GitHub that you can open, run and explain.
The learning path — 7 steps, in order
Rough total: about 3–4 months at 1–2 hours a day. This is a rough guide, not a promise. Slow is fine.
Linux
Moving around folders, listing and reading files, file permissions, running and stopping programs, checking what is using the machine, and writing one tiny script that runs commands for you. Plus network basics: a port (a numbered door), DNS (names to addresses) and HTTP (the browser asking a server for a page).
You are done when: you can set up a folder, install a tool, and find why a program stopped, using only the terminal.
Git
Save your work, look at past versions, make a branch (a separate line of work to try changes in), merge it back, fix a merge conflict (two people changed the same lines), and push to GitHub.
You are done when: your practice work lives on GitHub with a clear history of changes.
Docker
What a container is (a small box that holds an app and the things it needs to run — it helps the app run the same way on machines that are set up the same way; the machine, its settings, and outside services can still change the result), how to build one from a Dockerfile (a short recipe file). An image is a saved, ready-to-run copy of an app, built from a Dockerfile; a container is an image running. Learn to run it, map ports, stop it, and share files with a container. A named volume keeps data after the container is removed; a bind mount shares one of your folders into the container. Files written only inside a container are lost when it is removed.
You are done when: you can put a small website in a container and open it in your browser.
Kubernetes
Pods (the smallest thing Kubernetes runs, usually one container), deployments (a way to say how many copies of your app should run — you set the number; the usual starting point is 1), services (a stable address inside the cluster for your app), and reading logs. Hands-on lab included: run your Project 1 app on a small local cluster with kind.
You are done when: you can run your container app on a small local cluster, expose it with a Service, and fix it when it crashes.
Terraform
Writing down what infrastructure you want in a file, and letting Terraform create it. This is called “infrastructure as code” — infrastructure means servers, networks and settings. Terraform keeps a state file: it maps each thing in your file to the real thing Terraform created, and stores what it needs to plan the next change. State can hold private details, so never put it in a public repository.
You are done when: one Terraform file creates your practice setup, and running terraform plan again shows nothing to change (if nothing drifted — if the plan shows changes, read it before you apply).
CI/CD
A pipeline that runs on every code change — run a simple test, then build it. This kit's pipeline tests and builds; it does not deploy. CI means continuous integration (merging code often and testing it). CD can mean continuous delivery (a change kept tested and ready to release) or continuous deployment (a passing change released automatically).
You are done when: pushing code to GitHub starts your pipeline by itself and you can read its log when it fails.
Monitoring
Prometheus (collects numbers about your app, like how much memory it uses) and Grafana (turns those numbers into charts). Learn what to watch: is the app up, is it slow, is it out of memory?
You are done when: you have a Grafana chart showing your monitoring targets are up.
Start free: the zero-cost lab
Before you spend anything, set up your machine and run your first container. No cloud account. No card. Nothing here costs money. Windows users install WSL2 with Ubuntu first; Mac users need Docker Desktop for the Docker steps. The install commands below are Linux-terminal only — never run the Ubuntu/Debian install commands on macOS.
- Check what you already have: run
git --versionanddocker --version. If both print a version, skip ahead. - Install Git and Docker — Linux terminal only (Ubuntu/Debian directly, or WSL2 Ubuntu on Windows). On a Mac, do NOT run these commands — install Git and Docker Desktop, then go to Step 3. On Linux:
sudo apt install -y git docker.io, enable Docker, and add yourself to the Docker group so you can run it without sudo every time (takes effect after a fresh terminal). Warning: being in the Docker group effectively gives control of this Linux machine at the administrator level — use it only on a machine you control. - Prove Docker works:
docker run hello-world. If it fails, read the error — most often Docker is simply not running yet (Linux terminal:sudo systemctl start docker; Docker Desktop: open the app — systemctl does not apply there). If it says “permission denied”, your terminal has not picked up the Docker group yet — runnewgrp docker, or close the terminal and open it again. - Run your first real container:
docker run -d -p 8080:80 --name my-site nginx, then openhttp://localhost:8080and see the welcome page. - Look at it and stop it:
docker ps,docker stop my-site, thendocker psagain — my-site should no longer be listed (other running containers may still appear). To start it again later:docker start my-site. To remove it fully:docker rm my-site. - Make a folder for your work:
~/devops-practice— every later lab and project lives here. - Push to GitHub (first time only): free account, new repository, then in your terminal, from inside your project folder, first check Git knows who you are:
git config user.nameandgit config user.email. If either prints nothing, set them first. Then rungit statusto see what would be staged, and make a.gitignorefile first if the folder holds anything private (passwords, keys, Terraform state files) — never stage those. Thengit init,git add .,git commit -m "first commit",git branch -M main,git remote add origin <your repository address>,git push -u origin main. Later pushes are just add, commit, push. - Write your first script: a small health-check script that lists your running containers, made runnable with
chmod +x.
When something goes wrong: read the error message fully first. docker ps -a shows stopped containers too, and docker logs shows what a container printed before it stopped. Logs are the first place to look, always.
Break-and-fix labs — learn like on-call work
Each lab breaks something on purpose. Do not read the fix first. Read the symptom, try to find the cause with the commands you know, then check the fix. In real on-call work, this order — symptom, logs, cause, fix — is the whole job.
Lab 1 — The container that will not start
Break: run an image name with a typo in it. Find: the error says the image could not be found. Fix: correct the name and run again. Lesson: check the image name first, then the logs.
Lab 2 — The container that starts, then dies
Break: run a container with a command that does not exist. Find: docker logs shows the bad command. Fix: give it a program that stays alive. Lesson: a container lives only as long as its main program runs.
Lab 3 — The pipeline that fails
Break: a pipeline step runs a test file that was never created. Find: the failed step's log says the file was not found. Fix: add a real test file or a command that exists, push again, watch it go green.
Lab 4 — The Git merge conflict
Break: two branches change the same line, then merge. Find: Git stops with conflict markers showing both versions side by side. Fix: pick the right lines, delete the markers, commit. Never commit a file with marker lines still in it.
Lab 5 — The app runs, but the browser shows nothing
Break: run a container with no port mapping. Find: docker ps shows no port under PORTS, logs show nginx started fine. Fix: re-run with -p 8080:80. Lesson: the first number is your machine's door, the second is the container's.
Lab 6 — The build fails: file not found
Break: a Dockerfile copies a file that is not in the folder. Find: the failed step names the missing file; ls shows what is actually there. Fix: copy the file that exists. Lesson: a build can only see files inside the folder you build from.
After all six labs, you can say, truthfully: “I can read container logs, fix a port clash, fix a bad image name, resolve a merge conflict, find a missing port mapping, fix a failed build, and read a failed pipeline log.” That sentence is worth more than a certificate with no practice.
Portfolio projects — proof, not just notes
Employers trust things they can open and run. Three small, finished projects beat a long list of courses. Each one ends with a GitHub README you fill in — write only true things in it. If something is not done yet, say so.
Project 1 — A website in a container
Build a small web page, write a Dockerfile recipe for it, build the image, run it, open it in your browser, and push it to GitHub.
Tools: Docker, nginx, HTML
Project 2 — A pipeline that tests and builds
Add a GitHub Actions workflow to Project 1's repository so every push first tests the site, then builds the Docker image. The test step runs BEFORE the build: it fails if index.html is missing or does not hold the site's heading, so a broken site never gets built. A pipeline that only builds is not a pipeline that tests — the test step is the point. Break it once on purpose (delete the heading so the test fails, or a typo in the Dockerfile so the build fails), read the log, fix it, push again.
Tools: GitHub Actions, Docker
Project 3 — Infrastructure as code + monitoring, zero-cost
Write a Terraform file that creates a local container with the Docker provider (no cloud account, no bill), then add monitoring with Docker Compose: Prometheus collects numbers, Grafana turns them into charts, node-exporter reports numbers from inside its own container. Ports are bound to 127.0.0.1 (this machine only) on purpose — a local learning stack, not a shared service. This demo shows container monitoring, not your whole host machine. Your first chart plots the up query — up = 1 means Prometheus successfully scraped that target. It does not prove the website itself works — only that the target answered the scrape. Push to GitHub — but not everything: a .gitignore keeps out .terraform/ and state files; never commit state files.
Tools: Terraform, Docker, Prometheus, Grafana
Warning: Terraform with a cloud provider (AWS, Azure and similar) can cost real money. Do the local Docker version first. Only try a cloud version if you understand that provider's free tier and you destroy what you create afterwards.
Kubernetes lab — your app on a small local cluster
Run your Project 1 website on a small Kubernetes cluster that lives on your own machine, using kind (Kubernetes in Docker). No cloud account, no bill. You will also break it on purpose and fix it.
- Install kubectl and kind (the command tool for talking to a cluster, and the tool that creates the cluster), and check both print a version number.
- Start the cluster:
kind create cluster --name devops-practice, thenkubectl get nodesshould show one node Ready. - Load your image into the cluster:
kind load docker-image my-site:1.0— the step most beginners forget. A kind cluster cannot see images sitting in your local Docker by itself. - Run your app with a Deployment (a file that says “keep copies of my app running”), then open it with
kubectl port-forward. Expose it with a Service — a stable address inside the cluster, even when pods come and go. Your browser reaches it only through the port-forward — that does not expose the app publicly. - Read about your pod:
kubectl describe podshows details and recent events;kubectl logsshows what your app printed. When something breaks, these two commands are where you look first. - Break it, then fix it: change the image to a tag that does not exist — the pod shows ImagePullBackOff. The fix is in the Deployment file, not the pod: change the image back and apply again. Deleting the broken pod alone would not fix it — the Deployment would simply make the same broken pod again.
- Try self-healing once: delete a healthy pod and watch the Deployment make a healthy replacement by itself. That is why Deployments exist.
Note: this lab was not run end-to-end while writing the kit, and kind version links change over time — if a download link fails, take the newest link from kind's install page. If a step fails, read the error message first.
Interview pack — 23 questions, what they really test
Read the question, answer out loud in your own words, then read the “really testing” line. Interviewers care less about perfect wording and more about whether you understand the idea and have done it. If you have not done it, say what you did instead — do not pretend.
| Question | What it really tests |
|---|---|
What does chmod 755 do? | Do you understand file permissions — who can read, write and run a file? |
| A program is using too much CPU. How do you find which one? | Can you use basic tools (top, ps) to look at a live machine? |
What is the difference between git pull and git fetch? | Fetch only downloads; pull downloads and merges. |
| Your branch has a conflict. What do you do? | Stay calm, read the conflict markers, pick the right lines, finish the merge. |
| What is a container, and how is it different from a virtual machine? | A container shares the host's system; a virtual machine runs a whole second system. |
| What is a Dockerfile? | Can you describe a build recipe in plain words? |
| Your container starts and stops at once. Where do you look first? | Do you check docker logs before guessing? |
Why map ports with -p 8080:80? | The container's port and your machine's port are two different doors. |
| What is a pod? | The smallest thing Kubernetes runs, usually holding one container. |
| What does a deployment do? | It keeps a chosen number of copies of your app running and replaces failed ones. |
| Your pod keeps crashing and restarting. How do you debug it? | Read pod logs and describe the failure, instead of just restarting it again. |
| What is a service in Kubernetes? | A stable address inside the cluster for your app, even when pods come and go. Your browser reaches it only through a port-forward. |
| What is “infrastructure as code”? | Writing down wanted infrastructure in files instead of clicking around by hand. |
| What is Terraform state, and why does it matter? | Terraform keeps a record of what it created, so it knows what to change next time. |
| What happens in a CI/CD pipeline when you push code? | Walk through test, build and deploy, in order. |
| A pipeline fails. What is your first step? | Read the failed step's log before changing anything. |
| How do you know if an app is healthy? | More than “it opened once” — uptime, speed, errors and resource use. |
| What is the difference between a metric and a log? | A metric is a number over time (like CPU use); a log is a written record of events. |
| Describe a project you built and one problem you fixed in it. | Can you explain your own work clearly — usually the question that decides the interview. |
| You do not know the answer to a question. What do you say? | Honesty and method — “I don't know, but here is how I would find out” beats a confident guess. |
| What is the difference between an image and a container? | An image is the saved recipe; a container is the image running. |
| Your YAML file fails with a strange error. What do you check first? | The spaces — YAML breaks on tabs and wrong indentation. |
| You wrote a script but running it says “permission denied”. What do you do? | The file needs chmod +x before it can run. |
Resume bullets — from your projects, in simple words
Rules before you copy anything: write only what you actually did. Never invent numbers, company names or job titles. One bullet = one fact + one result, one line each. If a bullet is not true for you yet, leave it out until it is.
From Project 1
- Built and ran a containerised website using Docker and nginx, reachable at a mapped port on a local machine.
- Wrote a Dockerfile that builds the website image from a simple web page.
From Project 2
- Set up a GitHub Actions pipeline that tests the site, then builds a Docker image on every push to the repository.
- Read a failed pipeline log, found the error, and fixed it so the pipeline passed.
- Kept the project's build history visible in the repository's Actions tab.
From Project 3
- Wrote Terraform files that create a local container setup, and checked with
terraform planthat a second run needed no changes. - Added Prometheus and Grafana to watch the practice setup, with a chart showing [what your chart shows].
- Ran the whole practice setup locally with no cloud bill.
From the break-and-fix labs
- Diagnosed a container that would not start by reading its error message and correcting the image name.
- Fixed a port clash by finding the running container and changing the port mapping.
- Debugged a container that exited at once by reading its logs and finding the bad command.
- Resolved a Git merge conflict by reading the conflict markers and keeping the correct lines.
- Wrote a small Bash health-check script and made it runnable with chmod.
- Found a missing port mapping when a running container did not answer in the browser.
A short summary you can adapt: “Beginner DevOps learner. Built a containerised website, a CI/CD pipeline, and a Terraform + monitoring demo, all on GitHub. Can read logs, fix failed builds, and explain my own projects.”
What NOT to write: do not write “expert” or “experienced DevOps engineer” unless a real job gave you that role. Do not list tools you only watched videos about — list tools you actually ran. Do not copy someone else's project description. Yours is smaller and true — that is better.
Cheat sheets — commands you will actually use
Keep these open while you practise. All commands below are standard, well-known commands for their tools.
| Tool | Commands |
|---|---|
| Linux | pwd ls -la cd mkdir cat grep chmod +x ps aux top df -h free -h sudo systemctl start <service> sudo systemctl status <service> |
| Git | git init git clone git status git add . git commit -m git log --oneline git branch git checkout -b git merge git push git pull |
| Docker | docker ps docker ps -a docker images docker run docker logs docker stop <name> docker start <name> docker rm <name> docker build -t docker exec -it docker compose up -d docker compose ps docker compose down |
| Kubernetes | kubectl get pods/nodes/deployments/services kubectl describe pod kubectl logs kubectl apply -f kubectl delete -f kubectl port-forward |
| kind | kind create cluster --name devops-practice kind load docker-image kind delete cluster |
| Terraform | terraform init terraform plan terraform apply terraform destroy — destroy deletes things; only run it on your own practice setup, never on anything shared or real. |
| Prometheus & Grafana | Concepts, not commands: Prometheus collects numbers (metrics) from your apps. Grafana turns those numbers into charts. The two things to check first: is the app up, and is it slow? YAML warning: use spaces, never Tab, in .yml files. |
Best sites — what to pick, and why
Start free, pay only when you know what you need. Prices below come from earlier research done in October 2026 and are NOT freshly verified here — check the site itself before paying anything.
The map — start here (free)
roadmap.sh/devops — see the whole path in one picture: Linux, Git, Docker, Kubernetes, Terraform, CI/CD, monitoring, in order. It answers “what do I learn next?” in one page. It teaches little by itself, so use it as a map, not a course.
Free learning, topic by topic
- freeCodeCamp — free written guides and video series on Linux, Docker and Kubernetes basics.
- TechWorld with Nana (YouTube) — concepts explained slowly with diagrams.
- Learn Git Branching (browser game) — practise branching with no setup; mistakes cost nothing.
- Free GitHub DevOps roadmap (chanupen/devops-roadmap) — 34 hands-on modules on one machine, no cloud bill.
- Docker's official getting-started guide and Kubernetes official tutorials — the toolmakers' own first steps.
- Pro Git book (free online) — the standard Git book, including branching and conflicts.
- Killercoda browser scenarios — a free terminal in the browser when your own machine is busy.
Paid, when you are ready
- KodeKloud — hands-on labs inside the browser, especially Kubernetes. Earlier research priced it around ₹1,300/month — unverified, check before paying.
- Udemy — one cheap course on one topic during a sale. Earlier research found courses around ₹449–₹3,499 — unverified, and quality varies by instructor, so check ratings and last-updated date first.
- HashiCorp's own Terraform tutorials — free, from the people who make Terraform.
What NOT to buy first: a big bootcamp (tens of thousands of rupees) before you have finished the free map, the zero-cost lab and one portfolio project. Any course that promises a job or a salary — no course can promise that, whatever its page says.
The simple rule: map first, free guides second, one paid course only for the topic you are stuck on, and your own projects all the way through. The projects are the part employers can actually see.
What is inside the kit
One download with all 9 files, in plain words. The kit is 9 Markdown files — plain text you can read anywhere, no app needed. Read them in this order.
- start-here.md — who this is for, the one rule, and the 7 steps in order.
- zero-cost-lab.md — set up your machine and run your first container. Do this first.
- break-and-fix-labs.md — 6 labs that break things on purpose, so you learn to fix them.
- portfolio-projects.md — the 3 projects that prove your skills. Build them in order.
- kubernetes-lab.md — run your Project 1 app on a small local cluster. Do this in Step 4.
- cheat-sheets.md — keep open while you practise.
- interview-pack.md — 23 questions with what each one really tests. Practise answering out loud, after the projects.
- resume-bullets.md — turn finished projects into honest resume lines.
- best-sites.md — only when you are stuck on a topic and want another explanation.
Honest note
This kit teaches skills and helps you build proof. It does not promise a job, and it gives no salary number. Hiring depends on the employer, the market, and your interview — things no kit can promise. The learning times are rough guides, not promises. Test status, read first: the kit's text was reviewed line by line on 27 October 2026 and corrected. But the labs were NOT run end-to-end on a clean machine yet. Where a lab says so, that note stays, and the Draft labels stay, until a clean test run passes. This kit works in a Linux terminal: Ubuntu/Debian directly, or WSL2 Ubuntu on Windows. On a Mac, use Docker Desktop for Docker, but run the kit's commands in a Linux terminal — do not run the Ubuntu/Debian install commands on macOS. Other setups (including ARM64 machines) are unverified. Where a step is unverified, the file says so, and the real skill is reading the error message first. Cloud versions of the Terraform steps can cost real money — do the local version first.
Get the DevOps Kit — ₹399
One-time payment. After payment, the download link for all 9 kit files is shared with you. Learn on your own machine, at your own pace, in the order above.
What you get: start-here, zero-cost lab, 6 break-and-fix labs, 3 portfolio projects, Kubernetes lab, interview pack, resume bullets, cheat sheets, best sites.
Questions? Write to support@promptstudioai.in