DevOps portfolio projects that actually get interviews in 2026

Most DevOps portfolios look identical: a Terraform module for an EC2 instance, a Jenkins pipeline that runs npm test, a Kubernetes cluster on Minikube with a hello-world deployment. Recruiters skim past. Hiring managers close the tab in 15 seconds.

The problem isn’t effort. It’s that portfolios optimize for “I know the tools” when hiring managers screen for “I’ve solved real problems.” These six projects flip that — each demonstrates a specific engineering judgment call that shows up in interviews.

What makes a portfolio project matter

Before the list, the rule that separates useful projects from resume padding: every project must have a written failure story. Not “I built X.” That’s every candidate. Instead: “I built X, it broke because Y, I fixed it by Z, and here’s what I’d do differently.”

Failure stories signal three things at once — real hands-on experience, self-critical thinking, and communication skill. All three are what mid-level interviews test.

Every project below assumes a README with a “What went wrong” section. Without that, the project counts for very little.

Project 1 — Multi-environment Kubernetes deployment with ArgoCD

What to build: three Kubernetes namespaces (dev, staging, prod) for the same application, with ArgoCD watching a Git repo. Different config per environment (replica counts, resource limits, feature flags), promoted through PRs.

Tech to actually use:

Kind or K3d for the local cluster (both are free, real Kubernetes, not Minikube)
Kustomize for per-environment overlays
ArgoCD with App-of-Apps pattern
Sealed Secrets or SOPS for secret management
GitHub Actions to lint manifests and run policy checks

Why it impresses: the vast majority of production Kubernetes shops use exactly this pattern. Interviewers immediately recognize the setup and can drill into decisions — why Kustomize over Helm, why App-of-Apps, how you handle secret rotation.

Common failure to write about: ArgoCD reconciliation loops, drift between clusters, or a broken sync-wave that took the deployment order backwards.

Anti-pattern to avoid: deploying a hello-world app. Use something with actual complexity — a small API + database + background worker. The interesting DevOps problems only show up when there’s real state.

Project 2 — Terraform module library for AWS three-tier infrastructure

What to build: reusable Terraform modules for VPC, RDS, ECS/Fargate service, ALB, CloudFront. Then a envs/ folder using those modules to spin up dev + prod with different sizing.

Tech to actually use:

Terraform with remote state on S3 + DynamoDB locking
Terragrunt or workspace-based env separation (pick one, be able to defend it)
tflint and tfsec in CI
Renovate or Dependabot for provider version updates
Cost estimation with infracost in PR comments

Why it impresses: shows infrastructure thinking at team scale, not just “I can write HCL.” The module structure, versioning strategy, and CI-integrated cost tracking are what senior engineers look for.

Common failure to write about: state file corruption after a canceled apply, cyclical module dependencies, drift between console-edited resources and Terraform state.

Anti-pattern to avoid: one giant main.tf with 800 lines. Modules exist to be composed — a portfolio that doesn’t compose them fails the first review.

Project 3 — Incident response runbook and post-mortem

What to build: deliberately break something in project 1 or 2, then respond as if it were a real incident. Write a full timeline, blameless post-mortem, and remediation PRs.

Tech to actually use:

Prometheus + Grafana + AlertManager for detection
A Slack webhook or Discord webhook for the alert
Loki or CloudWatch Logs for retrospective queries
The post-mortem template from the Google SRE book

Why it impresses: this is the single rarest DevOps portfolio item. Almost no candidates have one. Even a mediocre post-mortem beats a polished feature project because it proves you can operate a system, not just build one.

Structure the post-mortem with:

Impact (what was affected, for how long, blast radius)
Timeline (UTC timestamps, who did what, tools used)
Root cause (five-whys style, avoiding “the developer made a mistake”)
What worked (fast detection, good runbook, etc.)
What didn’t (missing alert, misleading dashboard)
Action items (concrete, owned, deadlined)

Anti-pattern to avoid: faking the incident. Actually break your infrastructure — kill a pod, corrupt a config, exhaust a quota — and respond in real time. The realism shows.

Project 4 — GitHub Actions CI/CD with matrix builds and reusable workflows

What to build: a monorepo (frontend + backend + infra) with a CI/CD system that only tests what changed, deploys different services independently, and runs security + policy checks in parallel.

Tech to actually use:

Path filters (paths: and dorny/paths-filter) so CI runs only for changed services
Matrix builds across Node/Python/Go versions where relevant
Reusable workflows (workflow_call) shared across services
Artifacts + caching to keep builds under 5 minutes
OIDC federation to AWS/GCP (no long-lived credentials in secrets)
Environment protection rules (manual approval for prod)

Why it impresses: CI/CD is what DevOps engineers spend the most time on in real jobs. Interviewers care whether you understand pipeline design at scale, not just that you wrote a .yml.

Common failure to write about: a workflow that ran on every push and burned through minutes, a matrix that quietly hid a test failure, or a permissions escalation via a compromised third-party action.

Anti-pattern to avoid: copying a template CI file without understanding it. Interviewers will ask why you chose actions/checkout@v4 over @main, and “it was in the tutorial” is not an answer.

Project 5 — Cost optimization case study

What to build: take one of the earlier projects, run it for a week, capture actual cost data, then reduce it by 40-60% with documented tradeoffs.

Tech to actually use:

AWS Cost Explorer or GCP Billing Reports (with tags)
Karpenter or spot instances for compute
Rightsizing recommendations from your cloud provider
CloudFront or CDN caching to reduce origin cost
S3 Intelligent-Tiering for storage
Reserved instances or Savings Plans (mention even if not purchased)

Why it impresses: every DevOps team is a cost center. An engineer who understands the money angle stands out immediately. Include a before/after cost graph, a table of tradeoffs (e.g., “spot instances saved $180/mo but require pod disruption budgets”), and a written recommendation for what you’d cut next.

Common failure to write about: aggressive cost cutting that caused an outage — spot instance eviction during peak, tier-lowered S3 objects that couldn’t be retrieved in time, or over-aggressive scaling that timed out on cold starts.

Anti-pattern to avoid: vague savings claims (“saved 50%”). Show the specific numbers, methodology, and time period.

Project 6 — Observability stack for a small microservice

What to build: a two- or three-service application with full observability — logs (Loki), metrics (Prometheus), traces (Tempo or Jaeger), all queryable in Grafana with dashboards that actually surface real problems.

Tech to actually use:

OpenTelemetry SDK in each service (Python, Go, or Node)
OTel Collector for pipeline
Prometheus for metrics, exemplars linked to traces
Loki + Promtail for logs
Tempo or Jaeger for traces
Grafana dashboards + alerting rules

Why it impresses: observability is the highest-signal skill in senior DevOps interviews. Building a stack from scratch and being able to explain “here’s how I’d debug a 500 error at 3 AM using these three tools together” is a very concrete demonstration.

Bonus: run a chaos experiment (kill a pod, add latency, saturate a queue) and show a dashboard walkthrough of how you’d notice and root-cause it.

Anti-pattern to avoid: vendor lock-in to a paid tool. Interviewers want to see open-source proficiency; you can always add a Datadog demo later.

What NOT to put in a portfolio

Skip these — they either look junior or waste review time:

Minikube clusters. Kind and K3d are what production teams use for local. Minikube signals “followed a 2019 tutorial.”
Ansible playbooks for a single VM. Configuration management is table-stakes; a whole project about it looks like you don’t know cloud-native.
Docker-compose for a full production stack. Fine for local dev; positioning it as production shows you haven’t operated one.
A blog post that says “I learned Kubernetes today.” Interviewers assume learning. They want to see what you built with it.
Certifications listed without projects. The CKA is worth having but by itself signals theoretical knowledge, not delivery experience.

How to present these projects

Each project needs, at minimum:

A GitHub repo with a clean README
Architecture diagram (draw.io, excalidraw, or Mermaid in the README)
The “what went wrong” failure story section
A short video walkthrough (Loom, 3-5 min) linked from the README
A summary bullet on your resume — 2 lines maximum, quantified where possible

Recruiters spend roughly 7-8 seconds on a first-pass resume scan (per TheLadders’ 2018 update to their earlier “6-second” study — a rejection glance, not a full read). GitHub profiles get 30-90 seconds if the resume passes that first glance. Video walkthroughs get watched fully only if the first 30 seconds hook interest. Optimize for these attention curves.

The interview conversation these projects create

The projects work in interviews because they invite specific questions the candidate can answer well:

“Walk me through what happened when your ArgoCD sync went wrong.” (You have a written incident.)
“Why Kustomize over Helm for this?” (You made the choice and can defend it.)
“Where did most of the cost come from before you optimized?” (You have real numbers.)
“How would you notice if a pod was slowly leaking memory?” (Your dashboard shows it.)

Compare to the generic portfolio project — “I set up a Jenkins pipeline” — which invites zero specific questions and leaves the interviewer to fish.

Bottom line

Portfolio projects get interviews when they demonstrate judgment, not just tool familiarity. Six well-executed projects with real failure stories beat twenty tutorial follow-alongs. Build fewer, break them on purpose, document what you learned, and put the honest post-mortem front-and-center. That combination puts a DevOps portfolio in the top 10% of what most hiring managers see in 2026.