DevOps · Cloud Engineering · SRE
The whole curriculum. All 25 weeks.
This is the entire syllabus, published before you pay anything. Nothing is held back for a sales call. Read it end to end, then send week 19 to a DevOps engineer you know and ask them whether it is the right list.
25Weeks
50Live classes
21Hands-on labs
2Portfolio projects
How to read this page
Every week opens. Nothing below is a summary.
Each week is one card. Open it and you get a plain-English sentence on what the week is for, the real topic list your instructor teaches from, and the hands-on project you build afterward. It is the same list the classes are built on.
Two classes a week, three hours each, taught live. Plan on roughly six to eight hours of project work and homework between classes. Every topic gets explained on a whiteboard first — the picture comes before the command.
Classes are taught live in English or in Bengali, with a Bengali-speaking instructor. Ask admissions which option fits you. Alongside the roughly 50 regular classes, you get a private one-to-one session with the instructor about once a month — six to ten across the 25 weeks — and a support team you can reach between classes when your setup breaks or you are stuck.
You do not need DevOps experience to start. Week 1 assumes you can use a computer and are willing to learn to type commands. Weeks 1–3 build the floor everything else stands on. If a word below means nothing to you yet, that is expected — it is on this page because you will learn it, not because you should already know it.
The topic lists inside each week are written the way the industry writes them, on purpose. They are there so you, or an engineer you trust, can check that the list is the right one. Nobody expects you to understand them on day one.
AWS-first, with Azure and GCP comparison notes
We teach one cloud properly rather than three shallowly, and AWS is the one most job postings ask for. The three big clouds do the same jobs with different names. So where something differs — how accounts are organized, how you prove who you are, how you run a server, how you drive it all by typing commands — the class shows you the Azure and GCP version next to the AWS one. The words and the trade-offs travel with you to whichever cloud your employer uses. The hands-on work happens on a real AWS account you own, on the free tier plus a small budget, and every project shuts down what it built so the bill stays small.
Phase 1
Engineering Foundation
Weeks 1–16
WEEK 1 DevOps, Cloud & SRE Foundations: Roles, Workflows, and Your First Toolchain
You get a clear map of the DevOps, Cloud, SRE and Platform Engineer jobs — who does what, and what junior looks like next to senior. Then you set up the tools on your own computer and prove they work.
What you’ll learn
- DevOps, Cloud, SRE, Platform and Production Support roles compared
- How code moves from commit to production
- Push-based CI/CD vs pull-based GitOps (Argo CD / Flux awareness)
- DORA metrics: deployment frequency, lead time, change failure rate, MTTR
- What junior vs senior looks like in each track
- AWS Console, Regions and Availability Zones orientation
- AWS vs Azure vs GCP service comparison (console, CLI, IAM, compute)
- Terminal basics: pwd, ls, mkdir, cd, touch, and version checks
- Validating Git, AWS CLI, Docker and Terraform installs
- AWS CLI authentication with IAM Identity Center (SSO) and short-lived credentials
- Classifying setup errors: install vs PATH vs credentials vs daemon
- Cloud cost safety and the observe-only production mindset
Hands-on lab: In the setup-validation lab, you finish a small script that checks whether the tools on your computer — Git, the AWS command line, Docker, Terraform and VS Code — are installed and new enough. You write the part that compares version numbers, and you reproduce a real bug where a program decides 3.9 is newer than 3.10. An automatic check tells you when your script is right.
WEEK 2 Linux Fundamentals for Cloud & DevOps: Files, Permissions & System Troubleshooting
Linux runs most of the servers you will ever touch, and you drive it by typing. You learn to find and change files, control who is allowed to read what, search the logs for the useful line, and work out why a service stopped.
What you’ll learn
- Filesystem navigation with pwd, ls and cd
- File and directory operations: mkdir, touch, cp, mv, rm
- Pipes, redirection (>, >>, 2>) and find
- Log triage with grep, cut, sort, uniq, wc, awk and sed
- Symbolic and octal permissions (755, 644, 600) plus umask
- Users, groups, ownership, and chmod/chown
- Fixing “permission denied”: chmod +x vs running an interpreter
- Processes and system health: ps, top, free, uptime, nproc
- Managing services with systemctl and confirming listeners via ss -tulnp
- Reading systemd logs with journalctl
- Keyless EC2 access with SSM Session Manager (SSH as break-glass)
- Evidence-based troubleshooting of a disk-full service failure
Hands-on lab: In the linux-shell-automation lab, you lay out an app’s folders on a real Linux machine, fix a deploy script the server refuses to run, lock a secret file down so only you can read it, and pull the one useful line out of a noisy log. Then you finish three working scripts — check the disk, tidy old logs, take a backup — and produce a health report on the machine: what is running, what is listening, how much disk and memory is left.
WEEK 3 Git Workflows & Team Collaboration for DevOps, Cloud & SRE
Git is how teams keep a record of every change to their code. You learn to save your work, propose a change for a teammate to review, and untangle it safely when two people have edited the same line.
What you’ll learn
- The Git mental model: working directory, staging area, local and remote repos
- Staging, inspecting with git diff, and writing clear commit messages
- Feature branches with git switch and undoing edits with git restore
- Authoring a .gitignore to keep secrets and Terraform state out of Git
- Remote authentication via gh auth login or an ed25519 SSH key
- Pushing branches and opening pull requests and merge requests
- Code review, branch protection, and CODEOWNERS required reviewers
- Merge vs rebase vs squash, and keeping a linear history
- Safe force-pushing with --force-with-lease and git pull --rebase
- Resolving merge conflicts in VS Code and with git mergetool
- Secret safety: rotate-first response and a pre-commit hook that blocks keys
- Troubleshooting identity, untracked files, wrong branch, and failed push
Hands-on lab: In the git-collaboration lab, you run the whole team workflow yourself: save a change, put it up for review, and get it merged. You then cause a conflict between two edits on purpose and resolve it. You finish by installing a guard that refuses to let you commit a password or an AWS key by accident — and you test it by trying.
WEEK 4 AWS Cloud Foundations: Accounts, Identity, CLI & Cost Safety
Before you build anything on AWS, you learn the habits that keep you out of trouble: check which account you are in and who you are signed in as, drive AWS by typing instead of clicking, and set a spending alert that warns you before the bill does.
What you’ll learn
- AWS accounts as billing, security and governance boundaries
- Regions, Availability Zones, and AZ IDs
- Global vs regional services (IAM vs EC2)
- The AWS shared responsibility model
- Validating identity with aws sts get-caller-identity
- IAM Identity Center (SSO) vs long-lived access keys
- AWS CLI profiles, credentials and Region configuration
- Shaping CLI output with --query (JMESPath) and jq
- AWS Budgets, budget actions, and cost anomaly detection
- Building a resource tagging standard for ownership and cost
- Diagnosing credential, profile, Region and AccessDenied errors
- Multi-account patterns and AWS Organizations awareness
Hands-on lab: In the aws-cli-fundamentals lab, you finish a set of look-but-don’t-touch scripts that answer the questions you will ask every day: who am I signed in as, which region am I working in, and what is out there. An automatic check grades them. You also study a script that has been broken on purpose — it hides a login failure and reports success anyway — and you learn to spot that pattern.
WEEK 5 Networking Foundations & AWS VPC Architecture
You follow what really happens between someone typing a web address and your app answering. Then you build the private network your app lives in on AWS, and learn to find the exact point where traffic stops.
What you’ll learn
- IP addressing, public vs private IPs, and CIDR notation
- Subnet math: usable hosts, AWS-reserved addresses, and address planning
- Ports, protocols, TCP vs UDP, HTTP/HTTPS and TLS
- DNS resolution, record types (A, AAAA, CNAME, alias), and TTL/failover
- Layered troubleshooting with dig, nslookup, ping, nc, curl and ss
- Separating DNS, port, firewall and application failures with evidence
- VPCs, route tables, local routes and Internet Gateways
- Public vs private subnets defined by routing, not naming
- Multi-AZ VPC design with public and private subnets per Availability Zone
- NAT Gateway and egress-only IGW for private outbound without inbound exposure
- Security Groups vs NACLs: stateful vs stateless filtering
- Gateway and Interface VPC Endpoints (PrivateLink) for private AWS access
- VPC Flow Logs as troubleshooting evidence, and hybrid connectivity (peering, Transit Gateway, VPN, Direct Connect)
Hands-on lab: In the terraform-aws-foundations lab, you build a real private network on AWS, shaped the way a company would build it: spread across two data centers so one failure does not take you down, with a public side that the internet can reach and a private side that it cannot, and a log of every connection so you can prove what happened. You build it on a real account, then destroy it so it costs you nothing.
WEEK 6 Cloud Security & IAM: Identity, Least Privilege, and Secrets Management on AWS
You learn to control who can get into your AWS account and what they are allowed to do once they are in — giving out the least access that still works, and keeping passwords and keys somewhere safe instead of typing them into your code.
What you’ll learn
- Authentication vs authorization and the IAM access model
- IAM users, groups, managed and inline policies
- Reading IAM JSON policy structure (Effect, Action, Resource, Condition)
- Least-privilege design and scoped S3 read-only policies
- IAM roles, trust policies, and sts:AssumeRole
- Temporary credentials via STS and EC2 instance profiles
- OIDC keyless CI/CD and federation preview
- Policy evaluation order (explicit deny, SCPs, permission boundaries)
- IAM Access Analyzer for unused and externally-shared access
- Validating permissions with the IAM Policy Simulator
- AWS KMS encryption at rest, in transit, and key ownership
- Secrets Manager vs Systems Manager Parameter Store
- Troubleshooting AccessDenied for missing permissions and trust mismatches
Hands-on lab: In the security-automation lab, you write a permission rule that grants exactly enough access and no more, then test it before it goes anywhere near production. You set up a temporary pass that expires instead of a permanent key, and store a real secret encrypted and read it back. You finish by running the checks that catch the classic mistakes: a leaked key in the code, storage accidentally left open to the internet, and a permission rule that hands out far too much.
WEEK 7 EC2 Compute, AWS Storage, and Managed Databases
You start real web servers on AWS, secure them, and fix them when they will not answer. Then you learn where an app’s data belongs: on the server’s own disk, in file storage, or in a managed database.
What you’ll learn
- Launching EC2: AMIs, instance types, key pairs and Graviton
- EC2 pricing models: On-Demand, Spot, and Savings Plans right-sizing
- Bootstrapping a web server with user data and cloud-init
- Security group design for SSH and HTTP access
- Keyless access with SSM Session Manager and IAM instance profiles
- Enforcing IMDSv2 and encrypting EBS root volumes
- EBS volume types (gp3, io2, st1/sc1) and launch templates
- S3 object storage: buckets, keys, versioning, and Block Public Access
- S3 storage classes, lifecycle policies, and SSE-KMS encryption
- EBS vs S3 vs RDS vs EFS vs DynamoDB storage decisions
- Provisioning RDS with private subnet groups and Secrets Manager passwords
- Backups and recovery: EBS/RDS snapshots, point-in-time restore, RTO/RPO
- Troubleshooting unreachable web apps, S3 AccessDenied, and RDS timeouts
Hands-on lab: In the aws-storage-databases lab, you start a Linux server on AWS that installs its own web server as it boots, and you log into it without needing a key file. You add file storage and a PostgreSQL database that only your server can reach, then prove the whole thing works together — server, storage, database — on a real AWS account.
WEEK 8 Scripting and Automation: Production Bash and Python for DevOps
You stop doing the same job by hand. In two languages, Bash and Python, you write scripts that check a server on a schedule and catch a bad settings file before it reaches production.
What you’ll learn
- Bash script structure, shebang, and execution methods
- Variables, quoting, and command substitution
- Conditionals with if/elif/case, and [[ ]] vs [ ]
- Exit codes as automation and pipeline gates
- Production-safety idioms: set -euo pipefail and trap cleanup
- Functions, loops and arrays in Bash
- Text processing with grep, sed and awk
- Linting with ShellCheck and scheduling via cron and systemd timers
- Python virtual environments, lists, dictionaries and functions
- Reading and parsing JSON configuration files
- Validating required fields and allowed values
- Error handling with try/except for missing files, bad JSON and missing keys
- Read-only AWS inventory preview with boto3 and STS
- Configuration Management With Ansible: Playbooks, Roles and ansible-lint
Hands-on lab: Three labs. In linux-shell-automation you write a health check that runs on a timer across a group of servers and cleans up after itself, and a tool checks your script for the mistakes beginners make. In python-automation you write a program that reads a settings file and says clearly what is wrong with it instead of crashing. In ansible-config-mgmt you write instructions that set up many machines the same way, and check them before you run them anywhere. Each lab gives you the gaps to fill in, a worked answer to compare against, and an automatic check.
WEEK 9 CI/CD Pipelines with GitHub Actions: From Quality Gates to Keyless AWS Deployment
You build the assembly line that carries your code from a save on your laptop to running on AWS. It tests the code, scans it for security problems, packages it, and stops for a human to approve before anything goes live.
What you’ll learn
- Continuous integration vs continuous delivery vs continuous deployment
- Pipeline anatomy: jobs, steps, stages, runners and artifacts
- Writing GitHub Actions workflow YAML and avoiding indentation errors
- Lint, test, build and security gate pipeline on a real Flask app
- Matrix builds across Python 3.11 and 3.12 in parallel
- Secret scanning with gitleaks and dependency (SCA) scanning with pip-audit
- SHA-tagged build artifacts for provenance and rollback
- Branch protection and required status checks that enforce the gate
- Variables vs secrets, and secure secret handling
- Keyless OIDC federation from GitHub Actions to an AWS IAM role
- Publishing artifacts to S3 through a gated production environment with required reviewers
- Deployment strategies: rolling, blue/green and canary with rollback
- Evidence-first troubleshooting of pipeline, OIDC trust-policy and artifact failures
Hands-on lab: In the cicd-pipelines lab, you build a real assembly line in GitHub Actions. Every time you propose a change it checks the code style, runs the tests, hunts for leaked passwords and known-vulnerable libraries, and packages the result with a label that ties it back to the exact change. Then you make those checks compulsory — nobody can merge past them — and add a deploy step that pushes to AWS without any password stored anywhere, and only after a named reviewer approves.
WEEK 10 Docker Containers: Runtime Operations to Production Image Builds
A container packages an app with everything it needs, so it runs the same on your laptop as in the cloud. You learn to run containers, fix them when they will not start, and build and security-scan your own.
What you’ll learn
- Containers vs virtual machines, and the Docker architecture
- Image, container, engine, registry and tag concepts
- Running, listing, inspecting and removing containers with the Docker CLI
- Port mapping, environment variables, logs and bind mounts
- Multi-service local stacks with Docker Compose and service DNS
- Image architecture, --platform, and multi-arch builds
- Writing a Dockerfile: FROM, WORKDIR, COPY, RUN, EXPOSE, CMD
- Multi-stage builds with a non-root user and HEALTHCHECK
- Build-time vs runtime, layer caching, and .dockerignore
- Tagging, pinning by digest, and the Amazon ECR push workflow
- Image vulnerability scanning with Trivy and gating on HIGH/CRITICAL
- SBOM generation with Syft, and image signing concepts (cosign)
- Evidence-first container troubleshooting (ps -a, logs, inspect)
Hands-on lab: In the docker-containers lab, you run other people’s containers first and look inside them — how they get traffic, how you pass settings in, how two of them talk to each other. Then you package your own Python app: you keep the image small, run it as a limited user rather than an all-powerful one, give it a way to report whether it is healthy, and scan it for known vulnerabilities before you would ever ship it.
WEEK 11 Kubernetes Fundamentals: Workloads, Services & Production-Ready Manifests
Kubernetes runs your containers across many machines and restarts them when they die. You learn to put an app on it, let the outside world reach it, lock it down, and write the setup files a senior engineer would approve.
What you’ll learn
- Kubernetes architecture: control plane, API server, scheduler, kubelet and worker nodes
- Deployment, ReplicaSet and Pod relationship with desired-state reconciliation
- Authoring Deployment manifests in YAML with namespaces, labels and selectors
- Resource requests and limits, OOMKilled, and CPU throttling
- Readiness, liveness and startup probes
- Hardening Pods with securityContext and Pod Security Standards (restricted)
- Horizontal Pod Autoscaler (HPA), and why it needs resource requests
- Self-healing: deleting Pods and watching Kubernetes recreate them
- Services: ClusterIP, NodePort and LoadBalancer
- Port vs targetPort, endpoints and EndpointSlices
- Mounting ConfigMaps and injecting Secrets into a Deployment
- Exposing apps with Ingress, and an intro to the Gateway API
- Evidence-first troubleshooting of selector, label, image and port mismatches
Hands-on lab: In the kubernetes-fundamentals lab, you deploy a locked-down web server to a cluster running on your own machine. You scale it from one copy to several, delete one on purpose and watch Kubernetes bring it back, then give it a stable address, feed it its settings and a secret, and publish it to the outside world. You finish by fixing the three mistakes everyone makes at first — a typo that stops traffic finding your app, a wrong version label, and a wrong port number.
WEEK 12 Kubernetes Production Troubleshooting: Workloads, Services & Networking
Things break in production. You learn a repeatable way to find out why: gather the evidence, name the real cause rather than the first guess, fix it, and prove the fix worked — the way an on-call engineer does at 2am.
What you’ll learn
- Evidence-first troubleshooting: symptom vs root cause vs fix vs validation
- Pod lifecycle and failure states (Pending, CrashLoopBackOff, ImagePullBackOff)
- Diagnosing workloads with kubectl get, describe, logs --previous, and events
- OOMKilled containers, and reading last state / exit code 137
- Unschedulable Pending pods from oversized resource requests
- CreateContainerConfigError from missing ConfigMaps and Secrets
- Debugging shell-less distroless images with kubectl debug ephemeral containers
- Live resource usage with kubectl top and metrics-server
- Service routing: labels, selectors, endpoints, and port vs targetPort
- Kubernetes DNS and service discovery (NXDOMAIN, namespaced names, FQDNs)
- Readiness vs liveness probes, and diagnosing liveness restart loops
- NetworkPolicy default-deny, and service mesh / mTLS awareness
- Mapping local troubleshooting to EKS, ECR, IAM, ALB and CloudWatch
Hands-on lab: Across the kubernetes-fundamentals and k8s-production-ops labs, you are handed eleven broken apps on a live cluster and you fix them all. Five will not start — wrong version, crashing on a loop, missing settings, no room to run, out of memory. Six start but nobody can reach them — wrong label, wrong port, failing health check, a restart loop, a firewall rule, a broken name lookup. For each one you write down the evidence that proves the cause, not just the symptom, and prove it is really working again afterward.
WEEK 13 Helm: Packaging, Templating & Production Release Workflows for Kubernetes
Helm packages a Kubernetes app so one set of files can run in both test and production, with only the settings differing. You learn to build that package, upgrade it safely, and put it back the way it was when an upgrade goes wrong.
What you’ll learn
- Chart anatomy: Chart.yaml, values.yaml, templates/, _helpers.tpl, NOTES.txt
- Authoring Go templates: .Values, if/else, range, with, and named templates
- Whitespace control and indentation with nindent, toYaml and chomps
- Rendering and validating locally with helm template, helm lint --strict, and dry-run
- Chart vs release: one chart, many releases and environments
- Helm vs Kustomize: when to template vs patch, and how they coexist
- Subcharts, dependencies, Chart.lock, and OCI registry distribution
- Environment-specific values files for dev and prod
- Safe upgrades with helm upgrade --install, --atomic, --wait, --cleanup-on-fail
- Release history and rolling back with helm history and helm rollback
- Helm hooks, helm test, and ordered database-migration jobs
- Secrets handling with External Secrets Operator, Sealed Secrets and SOPS
- GitOps reality: where helm rollback causes drift and git revert wins
Hands-on lab: In the helm-charts lab, you finish a half-written package: one template that adapts itself depending on where it is being deployed. You check it for errors before it touches a cluster, then run it twice from the same files — once as a test environment, once as production. You upgrade it, look back through its history, and then deliberately deploy a broken version to watch it detect the failure and put the working one back on its own.
WEEK 14 Terraform Foundations: Infrastructure as Code on AWS
Instead of clicking around the AWS website to build things, you describe what you want in a file and Terraform builds it. You learn the full cycle — plan, build, change, destroy — and how to write it so it is secure by default and a team can review it.
What you’ll learn
- Infrastructure as code, and declarative vs manual provisioning
- Configuring the AWS provider and validating identity with STS
- The core Terraform workflow: init, fmt, validate, plan, apply, destroy
- Provider, resource and data source blocks
- The dependency graph, and implicit vs explicit dependencies
- Secure-by-default S3: public access block, SSE encryption and versioning
- Reading and protecting Terraform state (plaintext secrets risk)
- Input variables with types, descriptions, defaults and validation
- Complex types: bool, list, map and object, plus merge() and locals
- Providing values with terraform.tfvars across environments
- Outputs, and marking sensitive values for CI and PR safety
- Detecting and reasoning about configuration drift
- Terraform vs OpenTofu, and enterprise plan-review discipline
Hands-on lab: In the terraform-aws-foundations lab, you describe a storage bucket in a file and let Terraform build it on a real AWS account — closed to the public, encrypted, and keeping old copies of files, because you wrote those protections in yourself. You then rework it so the same file can build a test bucket or a production one just by changing the settings, and you run the whole cycle: preview the change, build it, inspect it, destroy it. A worked answer and an automatic check tell you when it is right.
WEEK 15 Terraform Enterprise Workflows: Modules, Remote State & CI/CD
You learn to organize Terraform the way real teams do, so several people can change the same infrastructure without overwriting each other, every change gets reviewed before it happens, and you can tell when someone has edited something by hand.
What you’ll learn
- Modules vs environments: enterprise repository structure
- A reusable VPC module with typed, validated input variables
- Per-environment dev/prod folders driven by terraform.tfvars
- Module sources and version pinning (local, Git ref, registry)
- for_each vs count for instantiating many resources safely
- Environment-separation strategies and their tradeoffs (folders, var-files, Terragrunt, workspaces)
- Terraform state, remote S3 backends, and DynamoDB state locking
- Reading a terraform plan: create, update, destroy and replace
- Drift detection and a safe drift-response process
- The plan-artifact handoff: plan -out=tfplan then apply tfplan
- Safe Terraform CI/CD pipelines with fmt, validate, scan, plan and gated apply
- OIDC keyless authentication from CI to AWS (no static keys)
- Policy-as-code scanning with tfsec, Checkov and OPA/Conftest
Hands-on lab: In the terraform-aws-foundations lab, you write a network once as a reusable building block, then use it to build both a test environment and a production one from the same code. You move the record of what exists to shared storage with a lock on it, so two people running at once cannot corrupt it. Then you put it all behind an assembly line that scans every change for security problems and shows you exactly what will happen before anyone approves it. An automatic check grades the result.
WEEK 16 Observability & Reliability: Metrics, Tracing, Alerting & Production Readiness
You learn to see what your system is actually doing: collect the numbers, put them on a dashboard anyone can read, and set alerts that fire on real user impact instead of noise. Then you judge honestly whether a system is ready to go live.
What you’ll learn
- Monitoring vs observability, and the three pillars (logs, metrics, traces)
- The four metric types: counter, gauge, histogram, summary
- Percentiles (p50/p95/p99) and the average-latency anti-pattern
- Scraping a /metrics endpoint with Prometheus and writing RED-method PromQL
- Deriving p95 latency with histogram_quantile
- Building RED dashboards in Grafana
- Distributed tracing with OpenTelemetry, spans and Tempo
- Cardinality, label hygiene and metric cost control
- CloudWatch logs, metrics, dashboards, and custom metrics via the AWS CLI
- Reliability framing: SLI, SLO, SLA and error budgets
- Symptom-based alerting and the availability-vs-AND nuance
- Prometheus alerting rules, and Alertmanager routing, grouping and inhibition
- Production-readiness checklists, runbooks, backups and go-live decisions
Hands-on lab: In the observability and observability-stack labs, you run the industry-standard monitoring tools against a demo app and build the dashboard that shows how busy it is, how often it fails and how slow it is for the unluckiest users. You do the same thing again with AWS’s own tooling, so you have seen both. Then you write alerts that fire when users are actually hurting — and test them against a deliberately broken app to prove they really fire. You finish by walking a real go-live checklist and making the call yourself.
Phase 2
Enterprise Skills & Final Project
Weeks 17–25
WEEK 17 AWS Landing Zones & Multi-Account Governance at Enterprise Scale
Large companies do not run everything in one AWS account. You learn how they split it up so one mistake cannot take down everything, set rules that block dangerous actions before they happen, and connect the accounts together.
What you’ll learn
- AWS Organizations, OUs, and the management account
- The enterprise account model: log archive, security, network, shared services, dev/test/prod
- Blast radius reduction and account separation strategy
- Account vending with Control Tower Account Factory, AFT, and Landing Zone Accelerator
- IAM Identity Center permission sets and account assignments
- Service Control Policies (SCPs) vs IAM permissions, and explicit deny
- Resource Control Policies, declarative policies, and delegated administration
- Preventive vs detective guardrails (block public S3, protect CloudTrail)
- Safe SCP rollout: validate, stage in a sandbox OU, then expand
- Break-glass access design with hardware MFA and CloudTrail alarms
- Multi-account networking: Transit Gateway, centralized egress and AWS RAM
- Automated remediation with AWS Config, EventBridge and SSM
- AWS vs Azure vs GCP account and governance hierarchy comparison
Hands-on lab: In a throwaway practice setup, you group AWS accounts the way a company would, then write and switch on a rule that physically prevents anyone building in the wrong part of the world — and watch it block you when you try. You set up how people sign in and what each group can do, then tear the whole thing down. The security-automation lab backs it with rules written as code and a check that hunts for over-generous permissions; the terraform-aws-foundations lab has you build and destroy a standard account network on a real account.
WEEK 18 Cloud Cost Optimization & FinOps Operations
You learn to read a cloud bill, explain to a manager why it is what it is, and bring it down without breaking anything — then write the monthly report that finance actually reads.
What you’ll learn
- Cloud cost visibility with AWS Cost Explorer and Budgets
- Tagging standards and cost allocation tags
- The FinOps framework: inform, optimize, operate
- Unit economics and cost per business unit
- Cost anomaly detection and budget alerts with owners
- CUR 2.0 and Athena for cost analysis at scale
- Organizations tag policies for governance
- Rightsizing with Compute Optimizer and Trusted Advisor
- Idle resource cleanup: EBS, snapshots, ALBs, Elastic IPs
- Commitment strategy: Spot, Savings Plans and Reserved Instances
- Coverage, utilization and commitment laddering
- Graviton migration and gp2-to-gp3 quick wins
- Non-prod scheduling automation with EventBridge and Lambda
- Monthly cloud operations reporting and action trackers
Hands-on lab: In the python-automation lab, you write three tools of your own and test them: tag_audit.py finds resources nobody has claimed ownership of, ec2_rightsize.py reads real usage figures and says which servers are bigger than they need to be, and cost_report.py turns raw spend data into a summary. Then you use them on sample data from a company with a rising bill and produce the actual deliverable: a monthly report for finance and a list of savings ranked by what is worth doing first.
WEEK 19 DevSecOps & Secure Software Supply Chain
You wire the security checks straight into the assembly line, so a leaked password or a known-vulnerable library stops the release automatically instead of being someone’s job to notice. You also learn to prove that what you deployed is what you built.
What you’ll learn
- Shift-left security and STRIDE threat modeling for pipelines
- Secret scanning with Gitleaks and false-positive tuning
- SAST with Semgrep, and dependency/SCA scanning with Trivy and Grype
- Building blocking security gates that stop the pipeline (no allow_failure)
- The vulnerability-management lifecycle: owner, severity and remediation SLAs
- OIDC keyless pipeline identity and least-privilege IAM
- Hardened Dockerfiles: multi-stage, non-root, distroless, digest-pinned
- Container image scanning with Trivy and cross-checking with Grype
- IaC policy-as-code with Checkov and OPA/Conftest (Rego)
- SBOM generation with Syft (CycloneDX/SPDX)
- Image signing and attestation with Cosign/Sigstore and SLSA provenance
- Kyverno admission control to enforce signed-images-only deployment
- Amazon ECR scan-on-push and EventBridge as a control point
- Secret rotation, Git-history exposure, and secure delivery policy design
Hands-on lab: Across the security-automation and cicd-pipelines labs, you point five real scanning tools at a sample project and read what they find. Then you build an assembly line that genuinely stops: you plant an AWS key in the code and watch the release refuse to go through. In the second class you build a stripped-down, secure container image, scan it, and add rules that reject insecure infrastructure before it is built. You finish by signing your image and setting the cluster to run signed images only — then trying to sneak an unsigned one in.
WEEK 20 Platform Engineering & Golden Paths: Building Developer Self-Service
You learn to think like a platform team: take the work you have been doing by hand and turn it into a ready-made setup other engineers can reuse, so they get from an empty project to a running, secure service without asking you.
What you’ll learn
- Platform engineering vs DevOps vs SRE responsibilities
- Golden paths, paved roads and developer self-service
- Internal developer platforms: portal, catalog and scaffolder (Backstage / Port)
- Backstage software templates and catalog-info.yaml service registration
- Control-plane (Crossplane) vs CI-driven Terraform self-service
- Reusable CI/CD: GitHub workflow_call and GitLab include templates
- Building a real Helm chart with probes, non-root securityContext and values.schema.json
- Enforced security gates: Trivy image scan and Checkov IaC/Helm scan
- OIDC keyless AWS authentication with least-privilege pipeline roles
- A reusable Terraform module for ECR, IAM roles and required cost tags
- GitOps deploy path with Argo CD: selfHeal, prune, and rollback-by-revert
- Onboarding docs, ownership metadata and rollback runbooks
- Operationalizing platform-as-a-product with DORA and DX/SPACE metrics
Hands-on lab: Across the platform-golden-path and helm-charts labs, you build the ready-made setup itself, from nothing: the project layout, a real installable package that rejects bad settings with a clear message instead of failing at 3am, a shared assembly line with the security scans already switched on and no passwords stored anywhere, a reusable block that builds the storage and permissions each new service needs, and the piece that puts it live when someone merges code. You prove all of it works before handing it to anyone.
WEEK 21 SRE Foundations: SLIs, SLOs, Error Budgets & Incident Response
You learn to turn “the site should be reliable” into measurable reliability targets, and alerts that fire on real user impact. Then you practice what happens when it breaks anyway: who runs the incident, and how to write the review afterward without blaming anyone.
What you’ll learn
- The four golden signals: latency, traffic, errors, saturation
- Reliability vs availability vs uptime, and user-perceived reliability
- Writing SLIs as good-events / valid-events specifications
- Request-based vs window-based SLIs, and threshold latency SLIs
- SLI vs SLO vs SLA, and why the SLA stays looser than the SLO
- Critical user journey (CUJ) driven SLI selection
- Nines-to-downtime budgets (what 99.9% really costs)
- Computing SLIs from real metrics with PromQL and CloudWatch Metrics Insights
- Error budgets as spendable downtime minutes and failed events
- Burn rate and multi-window multi-burn-rate (MWMBR) alerting
- SLO-as-code with Sloth and OpenSLO
- Writing an error-budget policy (triggers, freeze scope, decision owner, override)
- Toil, the 50% cap, on-call rotations and escalation
- Incident command roles, severity levels and blameless postmortems
Hands-on lab: Across the sre-incident-response and observability-stack labs, you take a demo Order Tracking Platform and decide what “working” means for it in a number you can actually measure — then measure it. You work out how much failure the target allows before you have to stop shipping features and fix things, write the alerts that catch it early, and agree in advance who decides. Then you run the drill: break the app on purpose, watch the outage happen, put it back, prove it recovered, and write the review — what happened, why, what changes, no names blamed.
WEEK 22 Performance Engineering, Capacity Planning & Production Scaling
“It feels slow” is not evidence. You learn to put a system under real load, find the one part that is actually holding it back, and plan for growth — instead of guessing and adding more servers.
What you’ll learn
- Latency, throughput and saturation: why p99 is not the average
- Latency percentiles (p50/p95/p99) and tail latency
- The RED and USE methods for triaging services and resources
- Little’s Law for connection-pool and concurrency sizing
- Open vs closed load models, and coordinated omission
- k6 load testing with ramp, steady-state and soak stages
- Finding the saturation knee in throughput vs latency curves
- Bottleneck hunting with distributed tracing and flame graphs
- Horizontal Pod Autoscaler: CPU, custom metrics, and target-vs-request
- Vertical Pod Autoscaler, metrics-server and PodDisruptionBudgets
- Cluster Autoscaler vs Karpenter for node capacity
- Event-driven scaling and scale-to-zero with KEDA on SQS
- Caching patterns: CDN edge caching and cache-aside Redis
- Scalability patterns: read replicas, sharding, queues, backpressure, circuit breakers, and retry-with-jitter
- Headroom, forecasting and cost-aware capacity planning
Hands-on lab: In the performance-scaling lab, you set an app up to add copies of itself automatically when it gets busy, then generate real traffic against it and watch it grow from one copy to five. Then the interesting part: it scales, and it is still slow — because the bottleneck moved to the database. You find that with evidence rather than guesswork, size it properly using a formula that has been around since the 1960s, and write a capacity plan that accounts for what it costs.
WEEK 23 Final Project — Build: Secure CI/CD Supply Chain to EKS with GitOps & Observability
Everything from the course becomes one system that works end to end. Your app gets packaged, scanned and signed on the way through, stored on AWS, and put live on Kubernetes by merging code — with monitoring watching it and a measurable reliability target behind it.
What you’ll learn
- Final project repository structure for app, Helm, Terraform and docs
- Multi-stage, non-root, distroless Dockerfile builds
- Provisioning ECR as code with Terraform (KMS, immutable tags, lifecycle policy)
- Commit-SHA image tagging and ECR authentication
- OIDC keyless CI/CD with no long-lived AWS keys
- Gating Trivy vulnerability scans with a documented exception path
- SBOM generation, Cosign image signing and SLSA provenance
- Authoring Architecture Decision Records (ADRs) for key trade-offs
- Provisioning EKS, VPC, node groups and IRSA with Terraform
- Building a Helm chart with probes, resource limits and values
- Deploying with helm upgrade --install, and rollback via Helm history
- Ingress, the AWS Load Balancer Controller, and TLS via ACM
- GitOps continuous deployment with Argo CD
- Deployed observability: Prometheus, Grafana and an SLO burn alert
Hands-on lab: In the final-project lab, you take a real Node.js app and package it into a stripped-down, secure container image. You build its storage on AWS from code, and send it through an assembly line that scans it, signs it, and records exactly what went into it — with no password stored anywhere. Then you build the cluster, put the app live, and set it up so changes go live by merging code and roll back the same way. It answers on a proper web address with a certificate, and an alert is watching a reliability target of 99.5%. This is the one lab with no worked answer — the final project is yours, so there is nothing to copy from.
WEEK 24 Final Project — Finalization: Production Readiness, Defense & Interview Prep
You finish the project into something you can put in front of a hiring manager, then present it and defend the decisions you made — live, with the system running, to a senior reviewer who will push back.
What you’ll learn
- End-to-end validation from Git commit to a live Kubernetes workload
- Running a production-readiness review (PRR) against an evidence-first checklist
- Authoring MADR-style Architecture Decision Records (ADRs)
- Proving infrastructure is provisioned with terraform plan and state list, not just validate
- OIDC keyless CI authentication, and gating security scans as baseline controls
- Live observability: dashboard, alert rule, and an SLO with an error budget
- Helm release history, rollback and recovery demonstration
- Docker build, ECR and EKS artifact-to-deployment workflow checks
- IAM least-privilege design and AWS identity validation
- Evidence-first troubleshooting of ImagePullBackOff, CrashLoopBackOff, and IAM/ECR failures
- Presenting the business problem, architecture and tradeoffs professionally
- Open-ended system design on unfamiliar prompts (clarify, scale, tradeoffs, failure modes)
- Senior behavioral STAR drills: leadership, mentoring, disagreement, incident command
- Quantifying impact (deploy frequency, MTTR, cost) and building a portfolio summary
Hands-on lab: In the final-project lab, you finish and check every part of your system, and prove the infrastructure is really built and running rather than just described in a file. You get monitoring working live and test that you can undo a bad release. Then you present the project and defend your decisions — and partway through, your instructor breaks something on purpose and you diagnose it in front of them. That is what the interview will feel like.
WEEK 25 Resume, Portfolio & DevOps/Cloud/SRE Interview Mastery
You turn 24 weeks of work and your final project into a resume, a portfolio and interview practice — aimed honestly at the level you are actually at, whether that is junior, mid or senior.
What you’ll learn
- ATS-safe, single-column resume anatomy for the 2026 screening funnel
- X-Y-Z quantified impact bullets and DORA metrics
- Mapping your final project and weekly labs to metric-bearing resume bullets
- Junior vs mid vs senior positioning by scope, ownership and decisions
- LinkedIn: headline, About, Skills and Featured
- A senior-signal GitHub portfolio: READMEs, diagrams, ADRs and pinned repos
- AWS/CKA/Terraform certification strategy and a 12-month plan
- The full interview loop: screen, design, debug, behavioral, take-home
- Technical screen Q&A: Linux, networking, containers, Kubernetes, IaC, CI/CD
- A 6-step system design method with failure domains, SLOs and cost tradeoffs
- Live troubleshooting with the symptom-evidence-root-cause-fix-validate method
- STAR behavioral stories, including incident command and mentoring
- Take-home assignment scoping and submission quality signals
- Offer negotiation: leveling, total compensation and counter-offer scripts
Hands-on lab: In the career-prep lab, you build the pack you will actually send out: a resume in a format the screening software can read, a project write-up with a diagram and a clear record of why you built it that way, and a LinkedIn profile that matches. Then you run mock interviews with your classmates, talk your way out loud through three things that have been broken for you in advance, and score yourself against the same rubrics a real interviewer would use.
You’ve read the plan
Now come and see a class.
The first class is free. No payment, no card, no obligation — you sit in on a real live class and decide from there. If you would rather see the work before the classroom, the labs are written up in the same detail as this page. And if you are not sure this is for you, that is a good reason to come and find out.
Questions about prerequisites, tuition or the next intake date? Email admissions@leadsacademy.org or call (804) 465-3237. Contact admissions for the next intake date.