You've completed all 33 lessons. Now it's time to build from scratch without step-by-step guidance. These projects simulate real scenarios you'll face as a DevOps engineer/architect. Each one is scoped, has clear milestones, and covers high-demand production patterns.

How to Use These Projects

Rules of engagement:
  • Build everything from scratch — no copy-pasting from lessons
  • Use the lessons and reference materials as lookup (not step-by-step guides)
  • Every project should result in a working GitHub repo you can show in interviews
  • Complete milestones in order — each builds on the last
  • If stuck for >30 minutes, review the relevant lesson, then try again
Intermediate ~4-6 hours

Project 1: Full-Stack App with Multi-Environment CD

Scenario: You're the sole DevOps engineer for a startup. They have a Node.js REST API and a React frontend. You need to set up CI/CD that deploys to staging automatically and to production with approval.

GitHub Actions Node.js React Docker Azure App Service OIDC Environments

What You'll Build

  • A mono-repo with api/ and web/ directories
  • Path-filtered CI — only build what changed
  • Container builds for both services
  • Staging auto-deploys on merge to main
  • Production requires manual approval
  • Slack/email notification on deploy success/failure

Milestones

M1: Create the mono-repo with a working API (Express + tests) and a React app. Both run locally.
M2: CI pipeline: lint + test for each service, path-filtered (changing api/ doesn't trigger web/ CI).
M3: Dockerize both services with multi-stage builds. Push to ACR with SHA tags.
M4: Deploy API to Azure App Service (staging) automatically. Add smoke test.
M5: Add production environment with approval gate. Deploy both services.
M6: Add a reusable workflow so both services share the same CI template.

Stretch Goals

  • Add a workflow_dispatch that lets you deploy any previous image tag to any environment
  • Add PR preview URLs (deploy each PR to a unique staging URL)
  • Add dependency caching and measure the speed improvement

What This Proves

You can set up a complete CI/CD system for a real product team from scratch — the most common ask in DevOps roles.

Advanced ~6-10 hours

Project 2: GitOps-Driven Microservices on AKS

Scenario: You're joining a platform team. They have 3 microservices that need GitOps deployment to AKS with ArgoCD. They want zero-touch staging deploys and PR-based production promotion.

GitHub Actions ArgoCD AKS Kustomize ACR OIDC ApplicationSet External Secrets

What You'll Build

  • 3 simple microservices (e.g., users-api, orders-api, gateway)
  • Separate app repos and a single GitOps repo
  • ArgoCD managing all services via ApplicationSet
  • CI builds images → commits tag to GitOps repo → ArgoCD syncs
  • PR-based production promotion
  • Self-healing enabled (demonstrate with manual drift)

Milestones

M1: Create 3 simple services (each: Express API with /health, Dockerfile, basic tests). Push to separate repos.
M2: Set up AKS cluster + ACR. CI pipeline: test → build → push to ACR for each service.
M3: Create GitOps repo with Kustomize structure: base/ + environments/staging + environments/production per service.
M4: Install ArgoCD. Create ApplicationSet that auto-discovers all services.
M5: Wire CI to update GitOps repo (staging auto-deploy). Verify the full loop works end-to-end.
M6: Implement PR-based production promotion. CI creates PR → review → merge → ArgoCD syncs production.
M7: Add External Secrets Operator pulling from Azure Key Vault. Each service reads its DB password from Key Vault.
M8: Demonstrate self-heal: manually scale a deployment → watch ArgoCD revert it.

Stretch Goals

  • Add Argo Rollouts canary strategy to one service
  • Add preview environments per PR (namespace per PR, cleanup on close)
  • Add ArgoCD notifications to Slack on sync success/failure
  • Add Gatekeeper policy: block any deployment without resource limits

What This Proves

You can architect and operate a GitOps platform for a multi-service system — the core skill of a platform/DevOps engineer at a mid-to-large company.

Advanced ~5-8 hours

Project 3: Secure Pipeline with Supply Chain Verification

Scenario: A fintech company is preparing for SOC 2 compliance. They need their CI/CD pipeline to be hardened, images signed, and only verified images allowed in production.

GitHub Actions Cosign Trivy SBOM (Syft) Kyverno OIDC CODEOWNERS Branch Protection

What You'll Build

  • A hardened CI/CD pipeline following all security best practices
  • Image scanning (Trivy) that blocks HIGH/CRITICAL vulnerabilities
  • Keyless image signing with cosign
  • SBOM generation attached to each image
  • Admission controller that rejects unsigned images in production
  • Complete audit trail from commit to production

Milestones

M1: Harden the workflow: pin all actions to SHA, set minimal permissions, add timeouts, create CODEOWNERS.
M2: Add Trivy vulnerability scanning. Pipeline fails on HIGH/CRITICAL. Upload SARIF to GitHub Security tab.
M3: Add cosign keyless signing. Sign every image that passes the scan.
M4: Add SBOM generation (Syft). Attach to the image as an attestation.
M5: Install Kyverno on AKS. Create policy that rejects unsigned images in production namespace.
M6: Test: try to deploy an unsigned image → blocked. Deploy signed image → succeeds. Document the flow.
M7: Add secret scanning (Gitleaks) and a scheduled weekly vulnerability re-scan of deployed images.

Stretch Goals

  • Add SLSA provenance attestation (level 2)
  • Create a compliance dashboard showing: all images signed, all scans passing, no policy violations
  • Implement Dependabot + auto-merge for patch updates that pass all checks

What This Proves

You understand supply chain security end-to-end — a top-demand skill as companies face regulatory pressure (SOC 2, ISO 27001, US Executive Order 14028).

Expert ~8-12 hours

Project 4: Platform Engineering — Reusable Pipeline Library

Scenario: You're the platform engineer for an organization with 15 services across 5 teams. Each team shouldn't have to write their own CI/CD. You build a shared pipeline library that teams consume with minimal configuration.

Reusable Workflows Composite Actions workflow_call ArgoCD ApplicationSet Helm Semantic Release GitHub Packages

What You'll Build

  • A "platform" repo with reusable workflows: CI, container build, deploy, release
  • Composite actions for common steps (setup, auth, deploy)
  • A Helm chart template that works for any service
  • An ApplicationSet that auto-onboards new services
  • Documentation: "Onboarding a new service in 5 minutes"

Milestones

M1: Create a platform-pipelines repo with reusable workflows: ci.yml, docker-build.yml, deploy-aks.yml, release.yml.
M2: Create composite actions: setup-node, azure-auth, helm-deploy. Each encapsulates 3-5 steps.
M3: Create a generic Helm chart (configurable via values.yaml) that any Node.js service can use.
M4: Create a "template service" repo showing how a team consumes the platform: 5-line CI workflow, values file, done.
M5: Create 3 service repos that all use the platform library. Each has <5 lines of CI config.
M6: Set up ApplicationSet: adding a new directory to the GitOps repo auto-creates the ArgoCD Application.
M7: Write onboarding documentation: "How to get your service deployed in 5 minutes" (README in the platform repo).
M8: Add semantic-release to automatically version and tag releases based on commit messages.

Stretch Goals

  • Version your reusable workflows (teams pin to @v1, @v2)
  • Add a "pipeline dashboard" that shows all services' CI status in one view
  • Create a CLI tool or GitHub template repo for instant service bootstrapping
  • Add cost tracking: report minutes used per team per month

What This Proves

You can think at the platform level — building tools that other engineers consume. This is the highest-value DevOps/platform engineering skill and the path to architect-level roles.

Expert ~10-15 hours

Project 5: Progressive Delivery with Observability

Scenario: A high-traffic e-commerce API serves 10,000 requests/minute. A bad deploy could cost $50,000/hour in lost revenue. You need canary deployments with automated rollback based on real metrics.

Argo Rollouts Prometheus Grafana AnalysisTemplate ArgoCD Load Testing (k6) AKS

What You'll Build

  • An API service instrumented with Prometheus metrics (request count, latency, errors)
  • Prometheus + Grafana deployed to cluster (monitoring stack)
  • Argo Rollouts canary strategy: 5% → 25% → 50% → 100%
  • AnalysisTemplate querying Prometheus for error rate
  • Automated rollback when error rate exceeds threshold
  • Load testing to simulate traffic during canary
  • Grafana dashboard showing canary vs stable metrics side-by-side

Milestones

M1: Create an API that exposes Prometheus metrics (/metrics endpoint). Track: request count, latency histogram, error count.
M2: Deploy Prometheus + Grafana to AKS (use kube-prometheus-stack Helm chart).
M3: Create a Grafana dashboard showing request rate, error rate, and P95 latency.
M4: Replace Deployment with Argo Rollout. Define canary steps: 5% → pause 2m → 25% → pause 5m → 100%.
M5: Create AnalysisTemplate that queries Prometheus: success rate must be ≥ 95%.
M6: Deploy a "good" version → watch it promote to 100%. Verify in Grafana.
M7: Deploy a "bad" version (inject 10% errors) → watch analysis fail → automatic rollback. Verify in Grafana.
M8: Add k6 load test that runs during canary to generate realistic traffic for analysis.

Stretch Goals

  • Add blue-green strategy as an alternative (switchable via values)
  • Add latency-based analysis (abort if P99 > 500ms)
  • Integrate with PagerDuty/Slack for rollback notifications
  • Create a runbook: "What to do when canary auto-rolls back"

What This Proves

You can implement the most sophisticated deployment pattern used by top tech companies — automated canary with metric-based rollback. This is senior/staff-level work.

Project Selection Guide

What's your goal? "Get hired as DevOps" → Project 1, then 2 Covers 80% of interview Qs "Senior DevOps" → Project 2, 3, then 4 GitOps + Security + Platform "Architect / Staff" → All 5, especially 4 + 5 Platform thinking + advanced patterns Recommended order: 1 → 2 → 3 → 4 → 5 Each project adds a layer. Skip 1 only if you've already built basic CI/CD professionally.

Tips for Success

  • Timebox: If a milestone takes >2 hours, step back and review the relevant lesson
  • Document as you go: Write a README for each project — future you (and interviewers) will thank you
  • Break things on purpose: The best learning comes from debugging failures
  • Use real Azure resources: Free tier covers most of this. Delete when done to avoid charges
  • Make it public: These repos ARE your portfolio. Link them on your LinkedIn/resume
  • One project at a time: Finish completely before starting the next. Depth > breadth

After the Projects

Once you've completed 2-3 projects, you're ready to:

  • ✅ Apply for DevOps/Platform Engineer roles with confidence
  • ✅ Design CI/CD for your team from scratch
  • ✅ Make architectural decisions and defend them in design reviews
  • ✅ Mentor others on pipeline best practices
  • ✅ Contribute to open-source CI/CD tooling

Remember: the lessons taught you the concepts. The projects make them permanent. There's no substitute for building it yourself, breaking it, fixing it, and shipping it.