The learning path & teaching method

Ten phases of progression, one rule: every chapter is built so it can only be understood because you understood the last one. No leaps, no assumed knowledge.

01The progression

The course is engineered as a ramp, not a reference manual. You climb through ten escalating phases:

02First-principles, always

Most material teaches how: "run this command." That produces engineers who are helpless the moment reality differs from the tutorial. This course refuses that. For every technology you will always get six things:

• Why it exists — the pain that created it.
• What problem it solves — stated in plain business terms.
• Why enterprises adopt it — the scale or risk that justifies the complexity.
• When not to use it — the cases where it is over-engineering.
• Alternatives — what else solves the same problem and how they differ.
• Business impact — what it costs and what it earns.

03What every module gives you

04A note on resources

Everything recommended in this course is free or open-source wherever a free option exists: official documentation, open-source projects, public datasets, free cloud sandboxes and community tooling. You can complete the entire path without paying for a course platform — only optional certification exams cost money.

Cloud Engineer vs Cloud Architect

The same curriculum serves two destinations. The early modules build the Engineer; the later modules and the architectural lens throughout build the Architect. Knowing which you are aiming for changes how you study.

01How the same task looks at each level

Linux Foundations

Every container, every server, every Kubernetes node is Linux. If Linux is a mystery, everything above it is magic — and you cannot debug magic. This module makes the operating system concrete.

01Learning objectives

By the end of this module you will be able to:

• Navigate the filesystem, manage files, and read any path on sight
• Understand the user / group / other permission model and fix "permission denied"
• Inspect and control processes, signals, and resource usage
• Read and configure basic Linux networking (interfaces, ports, DNS, firewall)
• Install and manage software with apt/yum/dnf
• Write Bash scripts that automate real server tasks with variables, loops, conditionals and functions

02Core concepts

flowchart TB
  U["You — the User / Shell (bash, zsh)"]:::u
  S["Shell interprets your command
expands variables, globs, pipes"]:::s
  K["Kernel — schedules CPU, manages memory,
talks to devices, enforces permissions"]:::k
  H["Hardware — CPU · RAM · Disk · Network"]:::h
  U -->|"types: ls -l /var"| S
  S -->|"syscall: openat, read"| K
  K -->|"electrical signals"| H
  H -->|"bytes"| K --> S -->|"prints result"| U
  classDef u fill:#EAF0FF,stroke:#2B57F0,color:#1B3CC0,stroke-width:1.5px;
  classDef s fill:#EFE8FC,stroke:#7444D9,color:#3d2c63,stroke-width:1.5px;
  classDef k fill:#FBEFD7,stroke:#D9870C,color:#7a4a06,stroke-width:1.5px;
  classDef h fill:#E1F4EB,stroke:#0E9C66,color:#0a5c3c,stroke-width:1.5px;
    

03Hands-on labs

# where am I, what's here, who am I
$ pwd && ls -la && whoami
# make a project, inspect permission bits
$ mkdir -p app/logs && touch app/run.sh
$ ls -l app          # note the -rw-r--r-- string
# make the script executable for the owner only
$ chmod 744 app/run.sh && ls -l app/run.sh
# follow live kernel state — every process is a folder
$ ls /proc | head && cat /proc/cpuinfo | grep -m1 "model name"

# top processes by memory, the Unix way: compose small tools
$ ps aux --sort=-%mem | head -5
# what's listening on which port?
$ sudo ss -tlnp
# can I reach the world? resolve DNS + check route
$ dig +short github.com && ip route
# send a signal: start, find, gracefully stop a process
$ sleep 300 & ; jobs -l
$ kill -TERM %1

#!/usr/bin/env bash
# bootstrap.sh — idempotent server setup. Run: sudo ./bootstrap.sh
set -euo pipefail              # fail fast, fail loud
LOG="/var/log/bootstrap.log"
log(){ echo "[$(date -Is)] $*" | tee -a "$LOG"; }

log "Updating package index"
apt-get update -y && apt-get upgrade -y

if ! id deploy &>/dev/null; then
  log "Creating deploy user"
  useradd -m -s /bin/bash deploy
fi

for pkg in nginx ufw curl; do
  log "Installing $pkg"; apt-get install -y "$pkg"
done

log "Configuring firewall"
ufw allow OpenSSH && ufw allow 'Nginx Full' && ufw --force enable
log "Done. Nginx status: $(systemctl is-active nginx)"

04Common mistakes & best practices

05Certification mapping

06Interview preparation

07Free resources

Git & GitHub

Git is the time machine and the collaboration layer for everything you will build. In modern DevOps the Git repository is the single source of truth — pipelines, infrastructure and deployments all trigger from it. Master Git and you've mastered the trigger for the entire pipeline.

01Learning objectives

• Explain Git's three states (working dir → staging → committed) and the object model
• Branch, merge, rebase, and resolve merge conflicts without panic
• Choose between Git Flow and trunk-based development for a given team
• Run a professional Pull Request & code-review workflow
• Use tags, releases, and .gitignore correctly
• Recover from mistakes with reflog, revert, and reset

02Core concepts

gitGraph
   commit id: "init"
   commit id: "feat-a"
   branch feature-login
   checkout feature-login
   commit id: "form"
   commit id: "validation"
   checkout main
   commit id: "hotfix"
   merge feature-login id: "PR #42 merged"
   commit id: "release v1.0" tag: "v1.0"
    

03Branching strategies — a decision framework

04Hands-on labs

$ git init demo && cd demo
$ echo "v1" > app.txt && git add . && git commit -m "init"
# two branches edit the SAME line -> a conflict
$ git switch -c feature && echo "feature change" > app.txt && git commit -am "feat"
$ git switch main && echo "main change" > app.txt && git commit -am "main"
$ git merge feature        # CONFLICT — open app.txt, pick the right content
$ git add app.txt && git commit   # conflict resolved
# the safety net: see EVERY move you've made
$ git reflog

05Common mistakes & recovery

06Certification & interview

07Free resources

Docker & Containers

"It works on my machine" is the most expensive sentence in software. Containers kill it by packaging your app and its entire environment into one portable, immutable unit that runs identically on a laptop, a CI runner, and a production cluster.

01Learning objectives

• Explain why containers exist and how they differ from virtual machines
• Describe the Docker architecture: client, daemon, images, containers, registry
• Understand image layers, the build cache, volumes and networks
• Write efficient multi-stage Dockerfiles and slash image size
• Orchestrate multi-container apps with Docker Compose
• Apply container security: non-root users, image scanning, minimal base images

02Containers vs Virtual Machines — the key idea

A VM virtualizes hardware: each one carries a full guest operating system, so it's heavy (gigabytes) and slow to boot (minutes). A container virtualizes the operating system: containers share the host kernel and isolate only the application's processes and files using Linux namespaces (isolation) and cgroups (resource limits). The result is megabytes, not gigabytes, and millisecond startup.

flowchart TB
  subgraph VM["VIRTUAL MACHINES — heavy"]
    direction TB
    H1["Host OS + Hypervisor"]:::base
    G1["Guest OS"]:::vm --> A1["App A"]:::app
    G2["Guest OS"]:::vm --> A2["App B"]:::app
    H1 --> G1 & G2
  end
  subgraph CT["CONTAINERS — lightweight"]
    direction TB
    H2["Host OS + Container Runtime"]:::base
    H2 --> C1["bins/libs → App A"]:::app
    H2 --> C2["bins/libs → App B"]:::app
    H2 --> C3["bins/libs → App C"]:::app
  end
  classDef base fill:#0F1A2B,stroke:#2B57F0,color:#cdd9f0;
  classDef vm fill:#FBEFD7,stroke:#D9870C,color:#7a4a06;
  classDef app fill:#EAF0FF,stroke:#2B57F0,color:#1B3CC0;
    

03Core concepts

04Multi-stage builds — the production technique

Your build tools (compilers, dev dependencies) should never ship to production. Multi-stage builds use one stage to build and a second, tiny stage to run — carrying only the final artifact across. This routinely cuts an image from 1.2 GB to under 50 MB.

# ---- Stage 1: build ----
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci                 # cached unless deps change
COPY . .
RUN npm run build

# ---- Stage 2: runtime (tiny) ----
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
USER nginx                 # never run as root
EXPOSE 8080
HEALTHCHECK CMD wget -qO- localhost:8080 || exit 1

05Hands-on labs

$ docker build -t myapp:1.0 .
$ docker run -d -p 8080:8080 --name web myapp:1.0
# what's actually inside? layers + size
$ docker history myapp:1.0
$ docker images myapp        # compare size before/after multi-stage
# exec into a running container to debug
$ docker exec -it web sh
# view logs + resource usage live
$ docker logs -f web ; docker stats web

# docker-compose.yml
services:
  web:
    build: ./frontend
    ports: ["3000:80"]
    depends_on: [api]
  api:
    build: ./backend
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on: [db]
  db:
    image: postgres:16-alpine
    volumes: ["pgdata:/var/lib/postgresql/data"]
    environment:
      POSTGRES_PASSWORD: secret
volumes:
  pgdata:

06Mistakes, security & best practices

07Enterprise example

08Certification & interview

09Free resources

Kubernetes

One container is easy. A thousand containers across fifty machines — self-healing, auto-scaling, rolling out new versions with zero downtime — is the hard problem Kubernetes was built to solve. This is the largest and most career-defining module in the course.

01Learning objectives

• Explain the control-plane / worker-node architecture and what each component does
• Work fluently with Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets
• Expose apps with Services, Ingress, and understand cluster DNS & service discovery
• Manage configuration & secrets with ConfigMaps and Secrets
• Handle storage with Persistent Volumes, PVCs and Storage Classes
• Secure access with RBAC and isolate workloads with Namespaces
• Package apps with Helm; autoscale and run highly-available, multi-region clusters

02Architecture

flowchart TB
  subgraph CP["CONTROL PLANE — the brain"]
    API["kube-apiserver
front door, all traffic"]:::api
    ETCD[("etcd
cluster state DB")]:::etcd
    SCH["scheduler
places Pods on nodes"]:::cp
    CM["controller-manager
runs reconcile loops"]:::cp
    API <--> ETCD
    SCH --> API
    CM --> API
  end
  subgraph N1["WORKER NODE 1"]
    K1["kubelet"]:::node --> P1["Pod"]:::pod
    KP1["kube-proxy"]:::node
  end
  subgraph N2["WORKER NODE 2"]
    K2["kubelet"]:::node --> P2["Pod"]:::pod
    KP2["kube-proxy"]:::node
  end
  API -->|"desired state"| K1 & K2
  DEV(["You: kubectl apply"]):::dev --> API
  classDef api fill:#2B57F0,stroke:#1B3CC0,color:#fff;
  classDef etcd fill:#FBEFD7,stroke:#D9870C,color:#7a4a06;
  classDef cp fill:#EFE8FC,stroke:#7444D9,color:#3d2c63;
  classDef node fill:#DEF3F1,stroke:#0C9488,color:#0a5048;
  classDef pod fill:#EAF0FF,stroke:#2B57F0,color:#1B3CC0;
  classDef dev fill:#0F1A2B,stroke:#2B57F0,color:#cdd9f0;
    

03The workload objects

04A first Deployment + Service

# deployment.yaml — declarative desired state
apiVersion: apps/v1
kind: Deployment
metadata: {name: web}
spec:
  replicas: 3
  selector: {matchLabels: {app: web}}
  template:
    metadata: {labels: {app: web}}
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports: [{containerPort: 8080}]
          resources:                 # ALWAYS set these
            requests: {cpu: 100m, memory: 128Mi}
            limits:   {cpu: 500m, memory: 256Mi}
          readinessProbe:            # don't send traffic until ready
            httpGet: {path: /healthz, port: 8080}

05Hands-on labs

$ kubectl apply -f deployment.yaml
$ kubectl get pods -o wide          # 3 pods across nodes
# watch self-healing: delete a pod, it comes back
$ kubectl delete pod -l app=web --field-selector ...; kubectl get pods -w
# scale by changing desired state
$ kubectl scale deploy/web --replicas=10
# zero-downtime rollout + rollback
$ kubectl set image deploy/web web=myapp:2.0
$ kubectl rollout status deploy/web
$ kubectl rollout undo deploy/web    # instant revert

06Mistakes, security & best practices

07When NOT to use Kubernetes

08Enterprise example

09Certification & interview

10Free resources

CI/CD — Continuous Integration & Delivery

This is the conveyor belt of the whole pipeline. CI/CD turns "a human runs some commands and prays" into "every commit is automatically built, tested, scanned and shipped." It is the difference between deploying quarterly and deploying a hundred times a day.

01Learning objectives

• Distinguish Continuous Integration, Delivery and Deployment
• Design a multi-stage pipeline: build → test → scan → package → deploy
• Manage secrets, artifacts and caching in pipelines
• Implement safe deployment strategies: rolling, blue-green, canary, feature flags, shadow
• Build real pipelines in GitHub Actions (and read Jenkins/GitLab CI)
• Add automated rollbacks and notifications

02Anatomy of a pipeline

flowchart LR
  C(["git push"]):::g --> B["Build
compile + image"]:::s
  B --> T["Test
unit + integration"]:::s
  T --> Q["Scan
SAST + image CVEs"]:::s
  Q --> A["Package
push to registry"]:::s
  A --> ST["Deploy → Staging"]:::d
  ST --> G{"Gate:
approve?"}:::gate
  G -->|yes| PR["Deploy → Prod
(canary → full)"]:::p
  G -->|no| X["Rollback / fix"]:::x
  classDef g fill:#0F1A2B,stroke:#2B57F0,color:#cdd9f0;
  classDef s fill:#EAF0FF,stroke:#2B57F0,color:#1B3CC0;
  classDef d fill:#DEF3F1,stroke:#0C9488,color:#0a5048;
  classDef p fill:#E1F4EB,stroke:#0E9C66,color:#0a5c3c;
  classDef gate fill:#FBEFD7,stroke:#D9870C,color:#7a4a06;
  classDef x fill:#FBEAE8,stroke:#DB433A,color:#8c241d;
    

03Deployment strategies — the decision table

04Hands-on project

# .github/workflows/deploy.yml
on: { push: { branches: [main] } }
jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test           # CI: fail fast on red tests
      - run: docker build -t $REG/app:${{ github.sha }} .
      - run: trivy image --exit-code 1 $REG/app:${{ github.sha }}  # block on CVEs
      - run: docker push $REG/app:${{ github.sha }}
      - run: kubectl set image deploy/web web=$REG/app:${{ github.sha }}

05Tools & when to pick them

06Certification & resources

Infrastructure as Code

Clicking around a cloud console to build infrastructure is slow, unrepeatable, and undocumented. IaC defines your entire cloud — networks, servers, databases, permissions — in version-controlled code you can review, diff, and recreate identically in seconds.

01Learning objectives

• Explain declarative IaC and why it beats manual/imperative provisioning
• Write Terraform: providers, resources, variables, outputs, modules
• Manage state safely — remote backends, locking, and why state is sacred
• Structure reusable modules and multiple environments with workspaces
• Compare Terraform vs CloudFormation vs Pulumi vs OpenTofu

02The Terraform workflow & state

Terraform's loop is write → plan → apply. plan shows you exactly what will change before it happens — the killer feature. The state file is Terraform's map of what it manages in the real world; it is the most sensitive artifact in the system.

# main.tf — a tiny, real example
terraform {
  backend "s3" { bucket = "my-tfstate", key = "prod/net", dynamodb_table = "tf-lock" }
}
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = "t3.micro"
  tags          = { Name = "web-${var.env}" }
}
output "public_ip" { value = aws_instance.web.public_ip }

03Tool comparison

04Project

05Certification & resources

Cloud Platforms — AWS · Azure · GCP

The cloud is the rented factory everything runs in. You don't need to memorize all three providers — you need the mental model of cloud building blocks (compute, network, storage, identity) so you can map any service in any provider to a concept you already understand.

01Learning objectives

• Map the core building blocks (compute, networking, storage, IAM, databases) across providers
• Understand regions, availability zones, and the shared responsibility model
• Stand up compute, a VPC/VNet, object storage and managed databases
• Reason about cloud cost models and the basics of cost control
• Deploy the same infrastructure to all three clouds and compare

02The same concept, three names

03Cost & the shared responsibility model

Two ideas the architect must internalize. Shared responsibility: the provider secures the cloud (hardware, hypervisor); you secure what's in it (your data, IAM, patching). Cost: compute is billed per-second, storage per-GB-month, and — the silent killer — egress (data leaving the cloud) is expensive. Architecture decisions are cost decisions.

04Project

05Certification & resources

Observability

You cannot operate what you cannot see. When a distributed system misbehaves at 3 a.m., observability is the difference between a five-minute fix and a five-hour outage. This is the quality-control station of the pipeline.

01Learning objectives

• Distinguish the three pillars: metrics, logs, traces — and when to use each
• Understand monitoring vs observability
• Collect metrics with Prometheus and visualize with Grafana
• Aggregate logs (Loki / ELK) and trace requests (OpenTelemetry / Jaeger)
• Set meaningful alerts on symptoms, not noise

02The three pillars

03Project

04Resources

Security — DevSecOps

Security bolted on at the end is security that fails. DevSecOps shifts security left — into every stage of the pipeline you've built — so vulnerabilities are caught at commit time, not by an attacker in production.

01Learning objectives

• Apply identity foundations: IAM, RBAC, OAuth, OIDC, SSO — and least privilege
• Manage secrets properly with Vault and cloud secret managers
• Embed scanning in CI: SAST, DAST, dependency & container scanning
• Enforce policy as code (OPA/Gatekeeper, Kyverno)
• Secure the software supply chain: SBOMs, image signing (Sigstore/cosign), SLSA

02The DevSecOps toolchain by stage

03Core concepts

04Project

05Certification & resources

Cloud Architecture

This is where engineer becomes architect. You stop asking "how do I deploy this?" and start asking "what should we build, and why?" — designing systems that scale to millions, survive regional failures, and stay affordable.

01Learning objectives

• Design microservices & event-driven systems — and know when a monolith is better
• Apply service mesh (Istio/Linkerd), API gateways, CQRS and event sourcing appropriately
• Architect for high availability, disaster recovery and multi-region
• Use caching and async messaging to scale
• Make and defend trade-offs across cost, reliability, latency and complexity

02Monolith vs microservices — the central trade-off

03An event-driven reference architecture

flowchart LR
  U(["Clients"]):::u --> GW["API Gateway
auth · rate-limit · route"]:::gw
  GW --> S1["Order svc"]:::svc
  GW --> S2["User svc"]:::svc
  S1 -->|publish event| Q[("Message broker
Kafka / SQS")]:::q
  Q --> S3["Inventory svc"]:::svc
  Q --> S4["Email svc"]:::svc
  S1 --> CA[("Cache
Redis")]:::ca
  S1 --> DB[("DB")]:::db
  classDef u fill:#0F1A2B,stroke:#2B57F0,color:#cdd9f0;
  classDef gw fill:#FBEFD7,stroke:#D9870C,color:#7a4a06;
  classDef svc fill:#EAF0FF,stroke:#2B57F0,color:#1B3CC0;
  classDef q fill:#EFE8FC,stroke:#7444D9,color:#3d2c63;
  classDef ca fill:#FBEAE8,stroke:#DB433A,color:#8c241d;
  classDef db fill:#DEF3F1,stroke:#0C9488,color:#0a5048;
    

04HA & disaster recovery — the language of risk

Architects speak in RTO (how fast you recover) and RPO (how much data you can lose). These dictate — and are dictated by — spend.

05Capstone-style project

06Resources

Enterprise Operations & SRE

Building a system is one thing; running it reliably and affordably for years is another. This module covers the disciplines that keep enterprise platforms alive: SRE, FinOps, governance, compliance and incident response.

01Learning objectives

• Apply SRE: SLIs, SLOs, SLAs and error budgets
• Run effective incident response & blameless postmortems
• Control cloud spend with FinOps practices
• Establish governance & compliance guardrails (SOC 2, ISO 27001, GDPR basics)
• Design backup & DR operations that are actually tested

02The vocabulary of reliability

03FinOps — engineering meets the bill

Cloud spend is a shared, engineering-driven responsibility. FinOps brings visibility (tag & attribute every dollar), optimization (right-size, autoscale, use spot/savings plans, kill idle resources), and accountability (teams see and own their costs).

04Project

05Resources

Capstone Projects

Everything converges here. These end-to-end builds are designed to become the centerpiece of your portfolio and your interview stories — each one exercises the entire pipeline from source to operated production.

01The capstone tracks

Every capstone must include: containerization, a CI/CD pipeline, IaC-provisioned cloud infra, Kubernetes deployment, observability, security scanning, and a written architecture doc.

02Definition of "done"

• One command (or one git push) takes it from code to running in the cloud
• Infrastructure is 100% codified — destroy and rebuild works
• The pipeline blocks insecure or failing changes automatically
• Dashboards show the golden signals; at least one meaningful alert fires correctly
• A clear README + architecture diagram explains every decision and trade-off
• You can whiteboard the whole system and defend it in an interview

Certification Roadmap

Certifications are a forcing function for breadth and a filter many employers screen on. Sequence them with the modules — don't chase a cert before you've done the hands-on work behind it. Exam codes, pricing and availability change; always confirm on the official provider site.

01Suggested sequence

02By domain

Weekly Study Plan

200 hours feels infinite until you schedule it. At a sustainable ~13 hours/week (≈2 hrs/weekday + a weekend block), the full path takes about 16 weeks. Adjust to your pace — the order matters more than the speed.

01The 16-week schedule

02A sustainable weekly rhythm

Resource Library

Every resource here is free or open-source. This is the consolidated list — bookmark it. You can complete the entire path on these alone.

01Free sandboxes & labs

02Documentation (always the primary source)

03Free books & deep references

04Open-source tooling to know

05One reference repo to start from

Built as a complete, navigable learning path — Modules 1, 3 and 4 carry the deepest treatment; the remaining modules give you the full roadmap, core concepts, a hands-on project, and curated resources, ready to expand to that same depth whenever you want to go further on a specific topic.