DEV Community: DevOpsLesson

I Let an AI Agent Run My CI/CD Pipeline for a Month. Here’s What Actually Changed.

Vishvesh Patel — Wed, 29 Jul 2026 02:31:47 +0000

Agentic DevOps is the biggest shift in software delivery since we all moved to the cloud and most teams are still treating AI like a fancy autocomplete. Here’s what “agents in the pipeline” really means, how to architect it, and where it breaks.

The 2025–26 shift is from AI that helps you type to AI that perceives, decides, and executes across your delivery pipeline.
An agentic pipeline can triage a failing build, find the root cause, open a fix PR, and re-run itself with a human only approving the final change.
The winning pattern is not “one giant AI.” It’s a small orchestrator + specialized tools + memory + hard guardrails.
The risk isn’t that agents are too dumb. It’s that they’re confidently wrong at 3 a.m. with production access. Guardrails are the whole game.

1. What “Agentic DevOps” actually means

For the last two years, “AI in DevOps” mostly meant a chat box that wrote a YAML snippet or explained a stack trace. Useful, but you were still the one doing everything: reading the logs, deciding what to fix, applying the change, re-running the job.

An AI agent flips that. Give it a goal (“keep the pipeline green”), a set of tools (git, the CI API, the test runner, the deploy system), and the ability to loop observe the result of its own actions and try again. Now the AI isn’t a suggestion box. It’s a teammate that does the work and reports back.

In the traditional flow, every failure blocks on a human. In the agentic flow, the failure becomes an input to a loop, the agent diagnoses, acts, and learns, and the human is pulled in only when judgment (or permission) is actually required.

2. The mental model: the agent control loop

Every useful agent (no matter the framework) runs the same four-step loop. If you understand this, you understand agentic DevOps.

Perceive :- pull in signals: build logs, test output, metrics, the diff that triggered the run, open incidents.
Reason :- an LLM plans: What failed? Why? What are my options? Which is safest?
Act :- call a real tool: apply a patch, re-trigger a job, roll back a deploy, comment on a PR.
Learn :- record what happened and feed it back into context so the next decision is better.

3. A reference architecture you can actually build

Here’s the part most hype articles skip: how do you wire this up without handing an LLM the keys to prod?

The pattern that works in practice looks like this:

The five components:

CI/CD platform : The messenger. Emits events and runs jobs.
Examples: GitHub Actions, GitLab CI, Jenkins

Agent orchestrator : The brain. Plans and coordinates the work.
Examples: an LLM paired with a planner (LangGraph, CrewAI, or a custom loop)

Tools : The hands. Scoped, auditable actions.
Examples: Git ops, test runner, kubectl , deploy/rollback APIs

Context / memory What the agent knows.
Examples: a vector store of runbooks, past incidents, and service docs

Guardrails : The brakes. Keep the agent safe.
Examples: policy checks, approval gates, blast-radius limits

The key design rule: the LLM never touches production directly. It can only act through tools you defined, and every high-impact tool sits behind a guardrail (a policy check, a dry-run, or a human approval). The orchestrator decides what to do; your tools and policies decide what’s allowed.

💡 Model Context Protocol (MCP) is quickly becoming the standard way to expose these tools to an agent. Instead of hand-rolling integrations, you wrap each system (git, CI, observability) as an MCP server and the agent discovers them. This is a big reason agentic DevOps went from demo to production in 2025.

4. The killer use case: a self-healing pipeline

The single most compelling thing an agent does is close the loop on a broken build without waking anyone up.

Here’s a real, common scenario played out step by step:

A build fails :- a nightly job goes red at 2:14 a.m.
The agent perceives :- it pulls the failed job logs and the diff from the last merge.
It reasons :- the logs show a transitive dependency bumped a minor version and broke an import. Root cause identified.
It acts :- it pins the dependency, opens a fix PR with a clear explanation, and re-triggers the pipeline against the branch.
It verifies :- the pipeline goes green. The agent posts a summary to Slack and tags a human for the one-click merge.

The engineer wakes up to a green pipeline and a ready-to-merge PR instead of a 2 a.m. page. That’s the promise and it’s achievable today for a well-scoped class of failures (flaky tests, dependency drift, transient infra errors, config typos).

5. A minimal example (so it’s not all hand-waving)

You don’t need a giant framework to start. Here’s the shape of a tiny “triage agent” triggered on a failed workflow:

# pseudo-code: a self-healing triage agent
from my_agent import Agent, tools

agent = Agent(
    goal="Diagnose the failed CI run and propose a safe fix.",
    tools=[
        tools.get_job_logs,        # PERCEIVE
        tools.get_pr_diff,         # PERCEIVE
        tools.search_runbooks,     # REASON (memory)
        tools.open_fix_pr,         # ACT  (guardrailed: never merges)
        tools.rerun_pipeline,      # ACT  (guardrailed: branch only)
    ],
    guardrails=[
        "Never touch production.",
        "Never merge or force-push.",
        "If confidence < 0.8, escalate to a human.",
    ],
)

## Triggered by the CI platform on failure
result = agent.run(context={"run_id": failed_run_id})
notify_slack(result.summary)   # human reviews the fix PR

Notice what’s doing the heavy lifting: it’s not the model. It’s the tool scoping and guardrails. The agent is only ever as dangerous as the tools you hand it.

6. Where it breaks (the honest part)

Agentic DevOps is powerful, but here’s what nobody puts in the launch blog:

Confidently wrong. An LLM will happily “fix” a symptom and mask the real bug. Without a verification step (re-run the tests!), you’re automating tech debt.
Non-determinism vs. audit. Regulated teams need to know exactly why a change happened. Log every perception, decision, and action treat the agent’s reasoning trace as a first-class artifact.
Blast radius. The gap between “re-run a job” and “roll back prod” is enormous. Scope tools tightly and gate the dangerous ones behind humans.
Cost and latency. Every loop is one or more LLM calls. Cache aggressively, and use a cheap model for triage, an expensive one only for hard reasoning.
Cognitive overload. Ironically, a flood of “the agent did X” notifications can be worse than the original problem. Report outcomes, not activity.

The teams winning with this aren’t the ones who gave an agent the most power. They’re the ones who gave it the least power needed to be useful and expanded from there.

7. How to start on Monday

You don’t need to rebuild your platform. Start with a read-only, low-blast-radius slice and earn trust:

Week 1: Observe only. An agent that explains every red build in plain English and posts to Slack. Zero write access.
Week 2: Propose. Let it open fix PRs for a narrow class of failures (dependency drift, lint, flaky tests). Humans merge.
Week 3: Act with a leash. Allow auto re-runs and non-prod actions behind policy checks.
Week 4: Measure. Track MTTR, % of failures auto-resolved, and false-fix rate. Expand scope only where the data says it’s safe.

Agentic DevOps isn’t about replacing engineers. It’s about deleting the boring, repetitive middle the log-reading, the re-running, the “did anyone see the pipeline’s red?” so your team spends its judgment where judgment actually matters.

The takeaway

The move from copilots to agents is the real story of DevOps in 2025–26. Copilots made you faster. Agents change who does the work. Start small, guardrail everything, verify relentlessly and let the machine own the loop it’s good at.

What would you trust an AI agent to do in your pipeline and what would you never hand over? Drop it in the comments. 👇

I Let an AI Agent Fix My Broken CI/CD Pipeline and Here's What Happened

Vishvesh Patel — Tue, 21 Jul 2026 21:49:41 +0000

A hands-on guide to Agentic AI in CI/CD. Build a self-healing pipeline that triages failures, opens PRs, and remediates issues with real GitHub Actions code you can copy today.

In this post I'll show you what "agentic" AI actually means for DevOps, then walk you through building a self-healing GitHub Actions pipeline that automatically triages a failed build and opens a fix PR. All code included. 🚀

The 2 AM Problem Every DevOps Engineer Knows

You've been there. A deploy fails at 2 AM. PagerDuty screams. You stumble to your laptop, open the pipeline logs, scroll through 4,000 lines of noise, and discover... a flaky test and a bumped dependency broke the build.

Twenty minutes of your life, gone. For a fix that was, honestly, kind of obvious.

Now imagine the pipeline had already diagnosed it, opened a pull request with the fix, and pinged you with a one-line summary before the pager even went off.

That's agentic DevOps, and it's the single biggest shift in CI/CD this year.

What "Agentic" Actually Means (Without the Hype)

Let's cut through the marketing. There are three levels of AI in a pipeline:

Level	What it does	Example
Assistive	Suggests code as you type	Copilot autocomplete
Generative	Produces a whole artifact on request	"Write me a Dockerfile"
Agentic	Perceives → decides → acts in a loop	Detects a failure, writes a fix, opens a PR, re-runs the job

An agentic system has:

Perception — it reads logs, test output, and diffs.
Reasoning — an LLM decides why something failed.
Tools — it can actually do things: open PRs, comment, re-run jobs, roll back.
A feedback loop — it observes the result of its action and tries again if needed.

Let's Build One 🛠️

We'll build a minimal but real self-healing pipeline in GitHub Actions. When tests fail, an AI agent will:

Grab the failure logs
Ask an LLM to diagnose the root cause
Post a diagnosis as a PR comment (and optionally open a fix PR)

You only need a GitHub repo and an API key (OpenAI, Anthropic, or your Copilot/Azure endpoint).

flowchart LR
    PR[Pull Request] --> T{test job}
    T -->|pass| M[✅ ready to merge]
    T -->|fail| G[diagnose job<br/>if: failure]
    G --> L[collect logs]
    L --> AI[🤖 LLM diagnosis]
    AI --> C[💬 comment on PR]
    AI -.optional.-> FIX[open fix PR]

Step 1: The Baseline Pipeline

Here's a normal test workflow, nothing magic yet.

# .github/workflows/ci.yml
name: CI

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Step 2: Capture the Failure

The trick: only trigger the agent when the test job fails. We add a second job that depends on the first and runs on failure.

  diagnose:
    needs: test
    if: failure()          # 👈 only runs when `test` failed
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write  # so the agent can comment
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: Collect failure logs
        run: |
          npm ci
          # capture test output (stdout + stderr) into a file
          npm test > test-output.log 2>&1 || true

Step 3: The Agent, Diagnose With an LLM

Here's the heart of it. A small script sends the logs to an LLM and asks for a structured diagnosis.

// scripts/diagnose.js
import fs from "node:fs";
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const logs = fs.readFileSync("test-output.log", "utf8").slice(-6000); // last 6k chars

const prompt = `
You are a senior DevOps engineer. A CI pipeline just failed.
Analyze the logs below and respond in this exact markdown format:

**Root cause:** <one sentence>
**Confidence:** <low | medium | high>
**Suggested fix:** <concrete, actionable steps>
**Is this flaky?:** <yes | no>

--- LOGS ---
${logs}
`;

const res = await client.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [{ role: "user", content: prompt }],
  temperature: 0.1,
});

const diagnosis = res.choices[0].message.content;
fs.writeFileSync("diagnosis.md", diagnosis);
console.log(diagnosis);

Step 4: Let the Agent Act

Now we wire the diagnosis back into the PR as a comment. This is the "agentic" part, it takes an action in your workflow.

      - name: Diagnose with AI
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: node scripts/diagnose.js

      - name: Post diagnosis to PR
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const body = fs.readFileSync('diagnosis.md', 'utf8');
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `## 🤖 AI Pipeline Diagnosis\n\n${body}`
            });

The Result

Push a PR that breaks a test, and within ~30 seconds you get a comment like:

🤖 AI Pipeline Diagnosis

Root cause: formatDate() returns undefined because the date-fns upgrade to v3 changed the import path.
Confidence: high
Suggested fix: Change import { format } from 'date-fns' to the named subpath import, or pin date-fns@2.
Is this flaky?: no

No log-scrolling. No 2 AM archaeology. Just a diagnosis waiting for you. ✨

Leveling Up: From Diagnosis to Auto-Fix

The comment version is safe and a great starting point. When you trust it, you can go further:

Open a fix PR automatically :- have the agent generate a patch and use peter-evans/create-pull-request to open it.
Auto-rerun flaky tests :- if the agent says flaky: yes, re-trigger the job instead of paging a human.
Gate on confidence :- only auto-act on high confidence; escalate the rest.

      - name: Auto-retry flaky failures
        if: contains(fromJSON(steps.diag.outputs.result).flaky, 'yes')
        run: gh workflow run ci.yml --ref ${{ github.head_ref }}
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The Guardrails You Must Not Skip 🛡️

Agentic pipelines are powerful, which means they're also a new attack surface. Before you ship this:

✅ Least privilege :- give the agent only the token scopes it needs (pull-requests: write, not admin).
✅ Human-in-the-loop for writes :- auto-comment freely, but require review before auto-merge.
✅ Never feed secrets to the LLM :- scrub logs of tokens and env vars before sending.
✅ Cap the blast radius :- rate-limit agent actions and add a kill switch (a repo variable like AGENT_ENABLED).
✅ Log everything the agent does :- you need an audit trail when it makes a bad call.

Treat the agent like a junior engineer with commit access: helpful, fast, and occasionally confidently wrong.

Where This Is Going

By the end of 2026, "the pipeline fixes itself" won't be a novelty, it'll be table stakes. We're heading toward pipelines that:

Auto-remediate infra drift (GitOps + AI)
Triage incidents before humans wake up (AIOps)
Tune their own resource usage and cost (FinOps agents)

The DevOps engineers who thrive won't be the ones fighting AI for their jobs, they'll be the ones designing the guardrails that let these agents run safely.

Your Turn 👇

Try the diagnose-only version this week, it's low-risk and genuinely useful. Then tell me in the comments:

What's the most annoying pipeline failure you'd hand off to an agent?
Would you trust an AI to open PRs against your main branch? Why or why not?

If this helped, follow the DevOpsLesson and visit https://devopslesson.com/

Happy shipping. 🚢

How to Use Claude to Find Jobs: Scrape LinkedIn with Apify (2026 Guide)

Vishvesh Patel — Sun, 19 Jul 2026 15:32:19 +0000

Connect Claude to Apify and pull fresh job postings from LinkedIn filtered to the last 24 hours straight into an Excel sheet. Plus how to use Claude for resume tailoring, mock interviews, and tracking applications.

1. Set up Claude Desktop with the Apify connector

This is the piece that turns Claude from "chatbot that gives advice" into "assistant that actually goes and fetches live job postings for you." It takes about five minutes.

Step 1: Install Claude Desktop

Download Claude Desktop for macOS or Windows from claude.ai/download and sign in with your Claude account.

Step 2: Create an Apify account and grab your API token

Sign up for a free account at apify.com if you don't already have one.
In the Apify Console, go to Settings → API & Integrations.

Create a new API token (or copy an existing one) and keep it somewhere safe as you'll paste it into Claude in the next step.

Step 3: Install and configure the Apify connector in Claude

In Claude Desktop, click on + symbol → Connectors → Add Connectors → Browse connectors.

Search for Apify MCP server, select it, and install it.

When prompted, paste in the Apify API token you just created.
Enable the connector and update it if Claude prompts you to.

Step 4: Turn it on for your conversation

Click the + button in the chat box, hover over Connectors, and toggle Apify on. It'll now show up as an available tool in that conversation, and Claude can call it whenever a prompt needs it.

Heads up: custom/directory connectors in Claude run from Anthropic's cloud, not your laptop, so this works the same way whether you're on Claude Desktop, claude.ai, or the mobile app once it's connected.

2. Pull 40 fresh DevOps and Cloud Engineer jobs into Excel

Once the connector is enabled, attach your resume to the conversation and send this prompt:

My resume is attached. Go on LinkedIn using Apify and give me 40 jobs that have been posted in the last 24 hours for the role of DevOps Engineer and Cloud Engineer in Canada, and give me that in an Excel sheet.

Claude will use the Apify connector to run a LinkedIn scraping Actor, pull postings filtered to the last 24 hours, cross-reference the roles against your resume, and hand you back a downloadable **.xlsx **file with the listings, company, title, location, posted date, and link, ready to scan and apply from.

Run this once a morning and you're job hunting with same-day postings instead of competing with everyone who already applied three days ago.

A few tips to make this more useful over time:

Narrow by city if "Canada" returns too much, try "Toronto, Ontario" or "remote, Canada" in the prompt.
Ask Claude to flag duplicates against your tracker (more on that in Step 5) so you're not re-reviewing jobs you already passed on.
Re-run it daily rather than weekly, the entire point of filtering to the last 24 hours is catching postings before the applicant pile-up.

3. Turn your resume into a living document

Start a Claude Project (or just a dedicated conversation if you don't need persistence) and upload your current resume along with a few of your strongest past performance reviews, project write-ups, or portfolio pieces. Ask Claude to pull out the underlying achievements, not just job titles in plain language:

Read my resume and these project docs. List out every concrete achievement you can find, with metrics where possible. Don't rewrite anything yet, just extract.

This step matters more than people expect. Most resumes bury the actual impact under vague responsibility statements. Getting a clean inventory of what you've actually done makes every later step faster.

4. Tailor per job posting, not once for everything

The biggest mistake in resume writing is having one version and hoping it fits every posting. Instead, paste the job description in and ask Claude to match it against your achievement inventory:

Here's a job posting. Based on my achievement list, which of my experiences are most relevant, and how would you reorder/reword my resume bullets to speak directly to this role's requirements?

You're not asking Claude to lie or invent experience, you're asking it to do the matching and rephrasing work that a human reviewer would otherwise have to do for you. Keep everything factually accurate; just let Claude help surface the right emphasis.

5. Use it as an interview sparring partner

Before an interview, paste in the job description and ask Claude to run a mock interview:

Act as the interviewer for this role. Ask me one question at a time, wait for my answer, then follow up like a real interviewer would , push for specifics, ask about edge cases, don't move on until the answer is solid.

This works especially well for behavioral and system-design style questions, where the value isn't the "correct" answer but practicing how you structure a response under a bit of pressure. Claude can also give you direct feedback afterward on where an answer was vague or ran too long.

6. Research the company without falling down a rabbit hole

Turn on web search and ask something specific instead of "tell me about this company":

Search for recent news about [Company] , funding, leadership changes, product launches, layoffs , from the last six months. I want to know what's actually happening there right now, not their About page.

This turns 45 minutes of scattered browsing into a five-minute briefing, and it means you walk into an interview able to ask an informed question instead of a generic one.

7. Keep a tracker that updates itself

This is the part most people skip, and it's the part that saves you from quietly losing track of forty open applications. Keep a simple running log , a markdown table, a spreadsheet, whatever , and paste updates into Claude as they happen:

I just applied to [Company] for [Role] today. Add it to my tracker with status 'Applied.' Also, [Other Company] moved me to a final round next Tuesday , update that row.

Ask Claude to periodically summarize: how many applications are in each stage, which ones have gone quiet longer than two weeks and might need a follow-up nudge, which interviews are coming up this week.

Visit https://devopslesosn.com for more such content, tutorials, roadmaps, cheatsheets and more.

Top 10 DevOps Projects for Your Resume (Beginner to Advanced)

Vishvesh Patel — Sat, 18 Jul 2026 19:18:07 +0000

Ten hands-on DevOps projects that hiring managers actually want to see. Covers Docker, Kubernetes, Terraform, CI/CD, AWS, and monitoring with real code and clear learning outcomes for every level.

Originally published on www.devopslesson.com, hands-on DevOps tutorials and career guides.

Project 1: Containerize a Multi-Service Application

Level: Beginner
Skills: Docker, Docker Compose, Networking
Time: 3 to 5 hours

What you build

Take a real application with at least two components, a web server and a database, and containerize it with Docker and Docker Compose. A good choice is a simple to-do app with a Node.js or Python backend and PostgreSQL or MongoDB.

What to include

A well-written Dockerfile for the application (multi-stage build, non-root user)
A docker-compose.yml that defines the app and database services
A named volume for database persistence
A custom Docker network for service communication
Health checks on both containers
Environment variable configuration via .env files
A .dockerignore to keep images lean

What it demonstrates

You understand not just docker run but how to architect a multi-service application for containers, manage data persistence, handle secrets with env vars, and write a production-quality Dockerfile.

README tip

Include the architecture diagram (even a text-based one), the commands to run it locally, and an explanation of why you chose a multi-stage build.

Project 2: CI/CD Pipeline with GitHub Actions

Level: Beginner
Skills: GitHub Actions, Docker, CI/CD
Time: 4 to 6 hours

What you build

A GitHub Actions workflow that automatically tests, builds, and pushes a Docker image to a registry every time code is pushed to the main branch.

What to include

A workflow triggered on push to main and on pull requests
A test job that runs your unit tests
A build job (dependent on the test job passing) that builds the Docker image
A push step that sends the image to Docker Hub or GitHub Container Registry (GHCR)
Image tagging with the git commit SHA for traceability
Docker layer caching with cache-from: type=gha
Secrets for registry credentials (no credentials in YAML)
Branch protection rules requiring the CI check to pass before merging

What it demonstrates

You can build a real CI/CD pipeline that follows security best practices, uses job dependencies correctly, and produces traceable artifacts.

Project 3: Infrastructure as Code with Terraform on AWS

Level: Beginner to Intermediate
Skills: Terraform, AWS, VPC, EC2
Time: 5 to 8 hours

What you build

Use Terraform to provision a complete AWS environment from scratch: a VPC with public and private subnets, an EC2 instance in the public subnet, a security group with proper rules, and an S3 bucket for state storage.

What to include

A remote backend storing Terraform state in S3 with DynamoDB locking
A reusable VPC module with public/private subnets across 2+ availability zones
An EC2 instance with user-data to install and start your application
Security groups with least-privilege rules (no 0.0.0.0/0 on SSH)
Outputs exposing the instance public IP and VPC ID
A terraform.tfvars file for environment-specific values
A .gitignore for state files and sensitive data

What it demonstrates

You can write real Terraform beyond tutorials: remote state, modules, proper variable handling, and actual AWS resource creation. This project maps directly to what teams do every day.

Project 4: Deploy to Kubernetes with Helm

Level: Intermediate
Skills: Kubernetes, kubectl, Helm, Deployments, Services, Ingress
Time: 6 to 10 hours

What you build

Take the containerized app from Project 1 and deploy it to a local Kubernetes cluster (using kind or minikube), then to a real cloud-managed cluster (AWS EKS or GKE free tier).

What to include

Kubernetes manifests: Deployment, Service, ConfigMap, Secret, Ingress
A Helm chart wrapping all your manifests with templated values
Horizontal Pod Autoscaler based on CPU utilization
Resource requests and limits on all containers
Readiness and liveness probes
A values.yaml for dev and values-prod.yaml for production
Deployment rollout with kubectl rollout status validation

What it demonstrates

You understand the difference between writing Kubernetes YAML and packaging applications properly with Helm. HPA and probes show you understand production concerns, not just getting containers to run.

Project 5: End-to-End GitOps Pipeline

Level: Intermediate
Skills: GitOps, ArgoCD or Flux, Kubernetes, CI/CD
Time: 8 to 12 hours

What you build

Implement GitOps: a Git repository is the single source of truth for what is deployed. When you merge a change to the repo, ArgoCD automatically syncs the cluster to match. No kubectl apply in pipelines.

What to include

A separate GitOps repository that holds only Kubernetes manifests
An application repository with a CI pipeline that updates the image tag in the GitOps repo on successful build
ArgoCD installed in your cluster watching the GitOps repo
Auto-sync with self-healing (ArgoCD reverts manual kubectl changes)
An ApplicationSet for managing multiple environments
A README explaining the full flow: PR merge → CI builds image → manifest repo updated → ArgoCD detects change → cluster updated

What it demonstrates

GitOps is one of the fastest-growing practices in cloud-native. Knowing ArgoCD or Flux puts you ahead of most candidates.

Project 6: Full Observability Stack

Level: Intermediate
Skills: Prometheus, Grafana, Alertmanager, Loki, OpenTelemetry
Time: 8 to 12 hours

What you build

Deploy a complete observability stack for your application: metrics with Prometheus, dashboards with Grafana, log aggregation with Loki, and alerting with Alertmanager.

What to include

Prometheus configured to scrape your application metrics endpoint
A custom Grafana dashboard showing request rate, error rate, latency (RED metrics)
An Alertmanager rule that fires when error rate exceeds 5% for 5 minutes
Loki receiving structured JSON logs from your application
A Grafana LogQL query correlating logs with spikes in error metrics
A runbook document explaining what each alert means and how to respond

What it demonstrates

Most engineers can run a service. SREs and senior DevOps engineers can observe it. This project shows you understand the difference between a dashboard that looks impressive and one that helps you find and fix problems.

Project 7: Automated AWS Infrastructure with Terraform and CI/CD

Level: Intermediate to Advanced
Skills: Terraform, AWS, GitHub Actions, remote state, modules
Time: 10 to 15 hours

What you build

Combine Terraform and CI/CD: a pipeline that automatically runs terraform plan on pull requests (posting the plan as a PR comment) and terraform apply on merge to main.

What to include

A modular Terraform codebase: separate modules for VPC, compute, database, and IAM
GitHub Actions workflow using hashicorp/setup-terraform
terraform plan output posted as a PR comment using actions/github-script
terraform apply running only on merge to main
AWS credentials passed via OIDC (not static keys — this is the modern, safer approach)
Separate Terraform workspaces for dev and prod environments
A Checkov or tfsec security scan step in the pipeline

What it demonstrates

This project combines two high-demand skills: Terraform expertise and pipeline automation. The OIDC authentication (no static AWS access keys) shows you understand security best practices.

Project 8: Self-Healing Infrastructure with Auto Scaling

Level: Advanced
Skills: AWS, Terraform, Auto Scaling, Load Balancers, CloudWatch
Time: 10 to 15 hours

What you build

An AWS application that automatically scales up under load and scales down when traffic drops, with zero-downtime deployments and a health check that routes traffic away from unhealthy instances.

What to include

An Application Load Balancer with HTTPS (ACM certificate)
An Auto Scaling group with a launch template
Scale-out policy triggered by 70% average CPU
Scale-in policy triggered by 30% average CPU
CloudWatch dashboard for the ASG and ALB metrics
A rolling deployment strategy (new instances, health check, traffic shift, old instances terminated)
Everything provisioned with Terraform

What it demonstrates

You understand how production applications actually handle variable load. This project demonstrates cloud architecture skills that go beyond tutorials.

Project 9: Multi-Environment Kubernetes Platform

Level: Advanced
Skills: Kubernetes, Terraform, EKS, namespaces, RBAC, network policies
Time: 15 to 20 hours

What you build

A Kubernetes platform with separate namespaces for dev, staging, and production environments with proper RBAC so developers can deploy to dev/staging but not production, network policies isolating environments, and resource quotas.

What to include

AWS EKS cluster provisioned with Terraform (using the official EKS module)
Three namespaces: dev, staging, production
RBAC: developer role with deploy access to dev/staging, SRE role with full access
Network policies: pods in dev cannot communicate with pods in production
LimitRange and ResourceQuota on each namespace
Cluster Autoscaler for automatic node scaling
External Secrets Operator syncing secrets from AWS Secrets Manager
A CI/CD pipeline that promotes images from dev → staging → production with manual approval gates

What it demonstrates

Platform engineering skills. You are not just deploying applications, you are building the platform that other engineers deploy to. This is what senior DevOps and platform engineering roles actually require.

Project 10: Full-Stack DevOps Deployment

Level: Advanced
Skills: All of the above combined
Time: 20 to 30 hours

What you build

Everything, end to end. A microservices application (at least two services that communicate with each other), deployed to Kubernetes on AWS, provisioned with Terraform, deployed via GitOps, monitored with Prometheus and Grafana, with a CI/CD pipeline that goes from commit to production with all the right gates.

What to include

Two or more services (e.g. an API and a worker) in separate repositories
Terraform for all AWS infrastructure (VPC, EKS, RDS, ECR, Secrets Manager)
GitOps with ArgoCD for deployments
CI pipeline per service: test, build image, push to ECR, update GitOps repo
Prometheus and Grafana for metrics (using the Prometheus Operator Helm chart)
Loki for logs
Alertmanager rules with a Slack or email notification
HTTPS via cert-manager and Let's Encrypt
Documentation: architecture diagram, runbook, deployment guide

What it demonstrates

This is a portfolio centrepiece. It touches every skill on a DevOps job description. Done well, with thorough documentation and a clear README, this is the kind of project that gets interviews.

How to present projects on your resume

GitHub is your portfolio. Make every repository public. Write a README that covers:

What the project does (one paragraph)
Architecture diagram (tools like draw.io or Excalidraw are free)
Technologies used (bullet list)
Key decisions and why you made them
How to run it locally
What you would do differently with more time

Do not list tools. Show outcomes.

Weak: "Used Terraform, Docker, and Kubernetes"

Strong: "Provisioned a multi-environment AWS EKS platform with Terraform, reducing environment provisioning time from 3 hours of manual steps to under 10 minutes"

Keep it real. Recruiters and hiring managers have seen every cloud tutorial project. What stands out is evidence of problem-solving: something that broke, what you discovered, what you changed.

Where to start

If you are new to DevOps, start with Project 1. Build each project before moving to the next. Resist the urge to jump to Kubernetes before you are comfortable with Docker.

Use these resources to get the foundation right:

DEV Community: DevOpsLesson

Top 10 Kubernetes Interview Questions for 2026 (With Answers)

How to use this guide

1. What is Kubernetes, and what problem does it solve?

2. What is the difference between a pod and a deployment?

3. What is a Kubernetes service, and why do you need one?

4. How does Kubernetes achieve self-healing?

5. What is the difference between a liveness probe and a readiness probe?

6. How do rolling updates and rollbacks work?

7. How do you manage configuration and secrets in Kubernetes?

8. What is the difference between resource requests and limits?

9. Scenario: a pod is stuck in Pending. How do you debug it?

10. Scenario: a pod keeps restarting with CrashLoopBackOff. What now?

Bonus tips to stand out in a 2026 Kubernetes interview

Key takeaways

Keep learning

I Let an AI Agent Run My CI/CD Pipeline for a Month. Here’s What Actually Changed.

1. What “Agentic DevOps” actually means

2. The mental model: the agent control loop

3. A reference architecture you can actually build

4. The killer use case: a self-healing pipeline

5. A minimal example (so it’s not all hand-waving)

6. Where it breaks (the honest part)

7. How to start on Monday

I Let an AI Agent Fix My Broken CI/CD Pipeline and Here's What Happened

The 2 AM Problem Every DevOps Engineer Knows

What "Agentic" Actually Means (Without the Hype)

Let's Build One 🛠️

Step 1: The Baseline Pipeline

Step 2: Capture the Failure

Step 3: The Agent, Diagnose With an LLM

Step 4: Let the Agent Act

The Result

🤖 AI Pipeline Diagnosis

Leveling Up: From Diagnosis to Auto-Fix

The Guardrails You Must Not Skip 🛡️

Where This Is Going

Your Turn 👇

How to Use Claude to Find Jobs: Scrape LinkedIn with Apify (2026 Guide)

1. Set up Claude Desktop with the Apify connector

2. Pull 40 fresh DevOps and Cloud Engineer jobs into Excel

3. Turn your resume into a living document

4. Tailor per job posting, not once for everything

5. Use it as an interview sparring partner

6. Research the company without falling down a rabbit hole

7. Keep a tracker that updates itself

Top 10 DevOps Projects for Your Resume (Beginner to Advanced)

Project 1: Containerize a Multi-Service Application

Project 2: CI/CD Pipeline with GitHub Actions

Project 3: Infrastructure as Code with Terraform on AWS

Project 4: Deploy to Kubernetes with Helm

Project 5: End-to-End GitOps Pipeline

Project 6: Full Observability Stack

Project 7: Automated AWS Infrastructure with Terraform and CI/CD

Project 8: Self-Healing Infrastructure with Auto Scaling

Project 9: Multi-Environment Kubernetes Platform

Project 10: Full-Stack DevOps Deployment

How to present projects on your resume

Where to start