01
What DevOps Is — and What It Isn't
A culture loop, not a job title. CALMS, the three ways, and why Netflix can deploy 1000× a day.
▾
How to explain to students
Open with the original sin: "In 2008, devs threw code over a wall to ops, ops blamed devs when it broke at 3am, devs blamed ops for slow deploys. DevOps was the answer — break the wall, share ownership." Today, the term has expanded — but the core idea is the same: shorten the loop between writing code and the user feeling it.
CALMS is the canonical framing: Culture, Automation, Lean, Measurement, Sharing. It's not a tool, it's a way of working. The tools (Docker, Terraform, GitHub Actions) are the output, not the input. "Doing DevOps" without changing how teams collaborate is just buying expensive software.
┌──── plan ─────┐
│ │
operate ─ ─ code
│ │
monitor build
│ │
deploy ─ ─ test
│ │
└──── release ──┘
# CALMS — the cultural framing
C ulture — devs + ops + security + product, one team, shared on-call
A utomation — anything done twice gets a script, anything in prod gets a pipeline
L ean — small batches, fast feedback, blameless postmortems
M easurement — DORA metrics, SLOs, cost dashboards
S haring — runbooks, internal blogs, pair programming, paid OSS contributions
# The 4 DORA metrics — research-backed signal of team health
- Deploy frequency (low: monthly | elite: multi-daily)
- Lead time for changes (low: months | elite: < 1 hour)
- Change-failure rate (low: 30–45% | elite: 0–15%)
- Mean time to recover (low: weeks | elite: < 1 hour)
# Common myths to debunk
❌ "DevOps = ops engineers who learned Docker"
❌ "Hire a DevOps engineer to do DevOps for us"
❌ "DevOps is a tool we install"
✅ DevOps is a working pattern that produces a job title
It's a loop
Plan → code → build → test → deploy → operate → measure → plan again.
Measured by DORA
Deploy frequency, lead time, failure rate, MTTR. Hire-relevant numbers.
Culture first
Tools without shared ownership = expensive theatre.
Blameless postmortems
"What broke" not "who broke it" — or no one shares info next time.
🎯 Practice Questions
Q1.
In one sentence each, define the 5 letters of CALMS. Which of these would survive if every DevOps tool you knew was deleted tomorrow?
Show Answer
C — Culture: shared ownership of code + production; on-call rotations include developers.
A — Automation: repeatable tasks become pipelines; one-shots become scripts.
L — Lean: small batches, fast feedback, blameless postmortems, continuous improvement.
M — Measurement: DORA metrics, SLOs, cost dashboards — decisions backed by data.
S — Sharing: runbooks, internal blogs, retrospectives, OSS contributions.
Culture, Lean, and Sharing all survive without tools. Automation and Measurement need tools but the practice outlasts any specific tool. The lesson: tools change every 5 years; the working pattern doesn't.
A — Automation: repeatable tasks become pipelines; one-shots become scripts.
L — Lean: small batches, fast feedback, blameless postmortems, continuous improvement.
M — Measurement: DORA metrics, SLOs, cost dashboards — decisions backed by data.
S — Sharing: runbooks, internal blogs, retrospectives, OSS contributions.
Culture, Lean, and Sharing all survive without tools. Automation and Measurement need tools but the practice outlasts any specific tool. The lesson: tools change every 5 years; the working pattern doesn't.
Q2.
A startup's CTO says "let's hire a DevOps engineer to do DevOps." What's the polite version of why this won't work?
Q3.
A team has a 30% change-failure rate and a 2-week lead time. Which DORA quartile are they in? Which lever do you pull first to improve?
💡 Lead time → smaller batches.
Q4.
A blameless postmortem — what concretely is + isn't said in one? Give one example sentence of each.
02
DevOps Roles — DevOps Engineer, SRE, Platform Engineer, Cloud Engineer
Four job titles, overlapping skills, very different day-to-days. How to pick which one to chase.
▾
How to explain to students
Job titles in this space are messy — what one company calls "DevOps Engineer" another calls "Platform Engineer" or "SRE". The skills overlap heavily. The day-to-day differs.
Rough mental model: DevOps Engineer works alongside one product team to build their CI/CD + infra. SRE is reliability-focused — owns the SLOs, error budgets, on-call. Platform Engineer builds the internal tooling other teams use (the "golden path"). Cloud Engineer is more infra-focused, often AWS/Azure-cert-heavy.
DevOps Eng SRE Platform Eng Cloud Eng
──────────────── ───────────── ─────────────── ────────────── ──────────────
Reports to product team reliability/eng platform/infra cloud/infra
Customer devs in a team the service all dev teams all dev teams
Owns SLOs? sometimes always sometimes rarely
On-call? often definitely usually sometimes
Code daily? yes (CI/IaC) yes (tooling) yes (platform) some (IaC)
AWS depth medium medium-high medium high
Software-eng medium high high medium
# Salary bands (Pakistan, 2026, PKR / month — rough ranges)
Junior (0–1 yr) local: 60k–120k · remote (USD): $1k–2k
Mid (2–4 yrs) local: 150k–300k · remote (USD): $2k–5k
Senior (5+ yrs) local: 350k–700k · remote (USD): $5k–10k+
Staff (US-FAANG) not common locally · remote: $150k–250k+
# Title evolves with experience
Junior DevOps → DevOps Eng → Senior DevOps / SRE / Platform Eng → Staff / Principal
DevOps Engineer
Embedded with a product team. CI/CD + IaC + on-call rotation. Common entry point.
SRE
Reliability-first. SLOs, error budgets, deep production. More software-eng heavy.
Platform Engineer
Builds internal tooling other teams consume. "Golden paths". Hot title in 2026.
Cloud Engineer
Heavier on networking + AWS-specific architecture. Often migration-focused.
🎯 Practice Questions
Q1.
A startup of 3 engineers wants their first "DevOps" hire. Which role title should they post for, and why?
Show Answer
DevOps Engineer. At 3 engineers, the team needs someone who pairs with developers, sets up CI/CD, picks the cloud architecture, handles on-call — generalist work. SRE / Platform Engineer titles imply specialisation that hasn't formed yet.
The role title also affects the talent pool: "SRE" attracts people expecting strong software-engineering practice and explicit SLOs; "DevOps Engineer" attracts a wider, more pragmatic pool fitting an early-stage team. Once the company is 30+ engineers, splitting into SRE + Platform Engineer pays off.
The role title also affects the talent pool: "SRE" attracts people expecting strong software-engineering practice and explicit SLOs; "DevOps Engineer" attracts a wider, more pragmatic pool fitting an early-stage team. Once the company is 30+ engineers, splitting into SRE + Platform Engineer pays off.
Q2.
An SRE friend says "platform engineers don't really do anything different from us." Counter-argument in 2 sentences with a concrete example of platform-eng work.
💡 "Golden path" tooling — internal developer portals, Backstage, opinionated templates.
Q3.
For a Pakistan-based learner targeting remote work in 12 months, which 3 skill investments compound fastest? Justify briefly.
Q4.
A junior is choosing between a local Lahore role at PKR 180k vs a US remote role at $3k/month. Beyond pay, list two non-financial factors that should swing the decision.
03
The DevOps Tools Ecosystem in Concrete Terms
CI/CD, IaC, containers, monitoring — what each is, what it solves, the dominant tool you should know first
▾
How to explain to students
There are thousands of DevOps tools. Job descriptions list 30+ logos and it scares people. The truth: 10–12 tools cover 95% of jobs. Pick one tool per category, learn it deeply, then add adjacent ones. The categories — and the tool I'd start with in 2026 — below.
Category Pick first Adjacent ones to know
───────────────────── ──────────────── ─────────────────────────────────
OS / shell Linux + bash Powershell (Windows shops only)
Version control Git + GitHub GitLab, Bitbucket
CI/CD GitHub Actions GitLab CI, CircleCI, Jenkins
Containers Docker Podman, Buildah
Container orchestration K8s (later) ECS Fargate (start here)
IaC Terraform AWS CDK, Pulumi, CloudFormation
Cloud AWS GCP, Azure
Monitoring (metrics) Prometheus CloudWatch, DataDog
Monitoring (logs) Loki / CloudWatch ELK stack, Splunk
Visualization Grafana Kibana, DataDog
Secrets AWS Secrets Mgr Vault, SSM Parameter Store
Security scanning Trivy + Semgrep Snyk, Aqua, Checkmarx
# Order to learn — fastest path to job-ready
1. Linux + bash (week 1–2)
2. Git + GitHub (week 3)
3. AWS basics + IAM (week 4–5)
4. Docker + Compose (week 6–7)
5. CI/CD (GitHub Actions) (week 8)
6. Terraform (week 9–10)
7. Monitoring (Prom+Graf) (week 11)
8. DevSecOps basics (week 12)
→ now you can interview for junior DevOps anywhere
# Skip these as a beginner — overhyped or specialised
- Service meshes (Istio, Linkerd) — don't need until you have 20+ services
- ArgoCD / Flux — needs K8s mastery first
- ChatOps bots — tooling on top, not foundation
🎯 Practice Questions
Q1.
A learner is overwhelmed by a 30-tool job description for a junior role. Cut it down to the 6 they should learn first, in priority order.
Q2.
Why does this guide recommend "ECS Fargate before Kubernetes" for first deployments?
Show Answer
Kubernetes has a steep learning curve — pods, services, deployments, ingress, RBAC, network policies, persistent volumes, operators, helm. Roughly 2–3 weeks to be productive, 6+ months to be confident.
ECS Fargate gives you 90% of the value — containers running in the cloud with auto-scaling, load balancing, IAM — for 10% of the conceptual overhead. A junior can ship to Fargate in a week. By the time you graduate to K8s, you've already mastered containers, networking, secrets, and load balancers — and K8s feels like the natural next step.
The exception: a job description specifically says "Kubernetes operator experience required." Then you go straight to K8s. Otherwise, build velocity first.
ECS Fargate gives you 90% of the value — containers running in the cloud with auto-scaling, load balancing, IAM — for 10% of the conceptual overhead. A junior can ship to Fargate in a week. By the time you graduate to K8s, you've already mastered containers, networking, secrets, and load balancers — and K8s feels like the natural next step.
The exception: a job description specifically says "Kubernetes operator experience required." Then you go straight to K8s. Otherwise, build velocity first.
Q3.
Your team uses GitLab CI but a job posting wants GitHub Actions. How transferable is the knowledge? Pick the right framing for your CV.
Q4.
A friend wants to skip Linux + bash and go straight to Terraform + Kubernetes "because that's what jobs ask for." What breaks first?
💡 Debugging a failing K8s pod requires
kubectl exec and Linux skills.04
Using AI / Copilot in DevOps Practice
In 2026, AI is a co-pilot, not a replacement. The engineer who uses it well ships 3× faster.
▾
How to explain to students
Every DevOps page in this course has an "AI module" because AI is now part of the workflow, not a separate skill. The pattern: (1) describe the task in detail, (2) ask AI to draft, (3) read + understand every line, (4) verify with the tool's own output. Skip step 3, ship a Dockerfile that runs as root.
DevOps tasks are especially well-suited for AI: they're text-heavy (YAML, HCL, bash), pattern-rich, with massive training data. The cost: it's also easy for AI to invent — wrong CVE numbers, fake AWS actions, deprecated arguments. Verify everything.
# Where AI is great
✓ Scaffolding YAML / HCL / Dockerfiles from a description
✓ Translating cryptic error messages into "what's broken"
✓ Writing one-shot bash + awk + jq pipelines
✓ IAM policy review for over-permission
✓ Brainstorming attack vectors on your design
✓ Explaining a CVE in plain language
# Where AI is dangerous
✗ Confidently inventing IAM action names that don't exist
✗ Quoting CVE IDs that don't match the description
✗ Generating policies with "Action: *" because it works for the demo
✗ Skipping edge cases (no input validation, no error handler)
✗ Suggesting deprecated provider arguments
# The verification habit
After every AI generation:
1. Read every line. Understand each.
2. Run the tool's own validator (terraform validate, docker build, semgrep)
3. Search for any unfamiliar action / resource / argument
4. Treat it like a PR from a smart-but-junior engineer
# Tools to know in 2026
- ChatGPT / Claude — general assist, prompt-and-iterate
- GitHub Copilot — IDE inline suggestions
- Cursor / Claude Code — agentic, edit-many-files-at-once IDE
- Amazon Q Developer — AWS-aware, knows IAM + CloudFormation
- Aider / Continue — open-source CLI assistants
🎯 Practice Questions
Q1.
A junior pastes their entire AWS Secrets Manager output to ChatGPT to "ask why my Lambda can't read it." What's wrong?
Show Answer
Three layers of wrong:
1. Real production secrets are now in the AI vendor's logs. Even if not used for training, they're stored, possibly accessible to vendor staff, and a target for abuse.
2. Account IDs and role ARNs leak organisational context useful for an attacker (which AWS account, which roles exist).
3. The AI doesn't need the actual secret to help — it needs the IAM policy attached to the Lambda's role and the error message. Replace secret values with
Workflow: rotate the secret immediately (assume compromised), then ask the question again with redacted versions.
1. Real production secrets are now in the AI vendor's logs. Even if not used for training, they're stored, possibly accessible to vendor staff, and a target for abuse.
2. Account IDs and role ARNs leak organisational context useful for an attacker (which AWS account, which roles exist).
3. The AI doesn't need the actual secret to help — it needs the IAM policy attached to the Lambda's role and the error message. Replace secret values with
<PLACEHOLDER>.Workflow: rotate the secret immediately (assume compromised), then ask the question again with redacted versions.
Q2.
List 3 DevOps tasks AI is great at and 3 it's bad at, with 1-line reasoning each.
Q3.
A friend says "I don't use AI because real engineers don't need it." Why is this position about to be a career problem?
05
Project: Build a Personal DevOps Roadmap + GitHub README
A public document that says "I am a junior DevOps engineer" — the artefact recruiters Google before they call
▾
How to explain to students
Every student leaves this module with two artefacts: (1) a personal DevOps roadmap — a 6-month plan listing what to learn and in what order, with target outcomes; (2) a polished GitHub profile README showcasing projects, tools, and a TL;DR for recruiters. Both are public. Both are recruiter-magnets.
## Hi, I'm Muzammil 👋
### Aspiring DevOps Engineer · Karachi, Pakistan · Open to Remote
I'm working through the [BanoQabil DevOps Foundations](https://...) curriculum.
Currently building infrastructure with Terraform + AWS + GitHub Actions.
### 🛠️ What I work with
   
  
### 🚀 Featured projects
- [**portfolio-iac**](link) — S3 + CloudFront + Route 53 deployed entirely via Terraform
- [**ci-pipeline-demo**](link) — Node API with full GitHub Actions: test → build → ECR → ECS
- [**system-monitor**](link) — Bash script + cron, alerts to Slack on disk > 85%
- [**serverless-todo-api**](link) — Lambda + API Gateway + DynamoDB, deployed via Serverless Framework
### 📈 Currently learning
- Kubernetes essentials (week 13–14)
- Cosign image signing for supply-chain
### 📊 GitHub stats
 
### 📫 Reach me
- 💼 [LinkedIn](link) · 📨 muzammil@example.com · 🌐 [muzammilbilwani.com](link)
# Roadmap.md (6 months)
| Month | Goal | Outcome / artefact |
|-------|-------------------|------------------------------------------|
| 1 | Linux + Git | Daily-tip script in cron, repo + README |
| 2 | AWS + IAM | EC2 + Beanstalk Node deploy, https |
| 3 | Docker + Compose | Multi-service stack on ECS Fargate |
| 4 | GitHub Actions CI | OIDC AWS deploy on every main push |
| 5 | Terraform | Replicate AWS stack via terraform apply |
| 6 | Monitoring + Sec | Prom+Graf+Loki + Trivy + Cosign |
→ Apply for first remote junior DevOps role
Public roadmap
Commits the plan. Forces honesty. Shows momentum to recruiters.
4 pinned projects
Each demonstrates a different tool. Not 17 abandoned demos.
Real domain in profile
https://<your-name>.com signals seriousness — covered in the AWS module.
Date-stamped progress
"Currently learning" updated monthly. Stale READMEs hurt.
06
Quiz: DevOps Concepts
5 MCQs + 2 fill-in-the-command questions
▾
Sample quiz questions (interactive)
Q1. The 5 letters in CALMS stand for:
A
Culture, Automation, Lean, Measurement, SharingB
Code, Automation, Linting, Monitoring, SecurityC
Containers, AWS, Linux, Microservices, SecurityD
Cloud, Agile, Lean, Microservices, SREQ2. Which is NOT one of the 4 DORA metrics?
A
Deploy frequencyB
Mean time to recoverC
Lines of code per developerD
Change failure rateQ3. The role most likely to own SLOs and error budgets:
A
Cloud EngineerB
SREC
Platform EngineerD
All of the above equallyQ4. Which is a "yellow flag" when AI generates infrastructure code?
A
Pinned versionsB
"Action": "*" or "Resource": "*"C
Tagged resourcesD
HealthchecksQ5. The fastest-compounding skill investment for a Pakistan-based junior aiming at remote work is:
A
Memorising 50 AWS servicesB
Linux + Git + AWS basics + 1 deployable project on a custom domainC
Becoming a Kubernetes expert before everything elseD
Getting 5 AWS certificationsFill-in-the-command
Fill 1: The acronym for the 4 metrics by the team that authored "Accelerate".
Fill 2: The role title that builds internal "golden path" tooling for other dev teams.
07
Assignment: Research 5 DevOps Job Postings — Skills + Salary Map
Stop guessing what to learn. Read what employers actually ask for and build a data-driven plan.
▾
How to explain to students
Frame as career calibration: "You can't optimise for a job market you haven't read. Pick 5 real postings — 3 local, 2 remote — and extract the truth." By the end, students have a personal skills-gap report, salary range, and a defensible "why I'm learning X next" answer for any interview.
📋 Assignment Requirements
- Find 5 active DevOps job postings: 3 Pakistan-based (Rozee, LinkedIn Pakistan, Mustakbil), 2 international remote (LinkedIn, Wellfound, Otta, RemoteOK)
- Mix at least 2 different titles (DevOps Engineer, SRE, Platform Engineer, Cloud Engineer)
- For each: title, company, link, posted date, level (junior/mid/senior), salary range if listed
- Extract the required skills (must-haves) and nice-to-haves for each
- Build a frequency table: which skills appear in 4–5 postings? 2–3? only 1?
- Identify your top 3 skill gaps — pick from the 4–5 frequency bucket
- For salary, list the median / range; if not listed, estimate using levels.fyi, Glassdoor, or LinkedIn salary insights
- Compare local vs remote: pay differential, expected English level, time-zone overlap, hiring bar
- Produce a 1-page write-up in markdown: top 3 gaps + a 12-week plan to close them, with concrete artefacts
- Bonus: Reach out to one person on LinkedIn currently in one of those roles. Ask one specific question. Document the response (or non-response) in the write-up.
- Bonus: Cross-reference 2 remote postings against your current portfolio — what would you put on your CV today vs in 3 months?
# Skills frequency across 5 postings
─────────────────────────────────────
AWS 5/5 ← must-have
Linux 5/5 ← must-have
Docker 5/5 ← must-have
CI/CD (GHA) 4/5
Terraform 4/5 ← my biggest gap
Kubernetes 3/5
Python 3/5
Monitoring 3/5
Helm 1/5 ← skip for now
# 12-week plan
Weeks 1–4: Terraform deep-dive — recreate AWS portfolio in HCL
Weeks 5–8: Kubernetes essentials on minikube + EKS
Weeks 9–12: Apply, mock interviews, polish portfolio
Grading rubric
5 real postings: 25. Frequency table: 25. Salary research: 15. Plan with dates + artefacts: 25. Reflective tone: 10.
Common mistakes
Cherry-picking only senior postings, copying skills lists verbatim, no frequency analysis, plan with vague verbs ("learn AWS").
Stretch
Repeat the exercise in 6 months. Compare drift — some "nice-to-haves" become must-haves, vice versa.