Struggling to build a DevOps portfolio? A Senior Engineer breaks down real-world automation projects, from simple cleanup scripts to full IaC deployments, that will actually get you hired.

Stop Overthinking It: Real-World Automation Scenarios for Your DevOps Portfolio

I remember interviewing a junior engineer a few years back. Their resume was a laundry list of buzzwords: Kubernetes, Service Mesh, GitOps, the works. Their portfolio on GitHub was a single, massive repository—a forked “build your own Kubernetes on bare metal” project. When I asked them to write a simple bash script to find all files in /var/log larger than 10MB and older than 14 days, they froze. They couldn’t do it. They’d spent months trying to build the skyscraper but had forgotten how to pour the concrete foundation. That’s a huge red flag for me, and it’s a trap I see aspiring engineers fall into all the time.

The Real Problem: Chasing Complexity, Not Solving Problems

I was browsing Reddit the other day and saw a thread, “Looking for Sample Automation Scenarios – Building My Portfolio.” The replies were full of good intentions, but many jumped straight to complex CI/CD pipelines for microservices. That’s the symptom of the problem. The root cause is what I call “Portfolio Panic.” You see what senior engineers are managing, and you feel this immense pressure to replicate it. You think you need to show you can manage a fleet of 100 microservices before you’ve even proven you can automate a simple, repetitive task reliably.

Let me be clear: as a hiring manager, I’m looking for your thought process first and your tool knowledge second. A small, well-documented project that solves a real, albeit simple, problem is infinitely more valuable than a half-finished, misunderstood clone of Netflix’s infrastructure. We want to see that you can identify a pain point, choose an appropriate tool, and build a solution.

Three Scenarios to Build, From “The Janitor” to “The Architect”

Forget trying to boil the ocean. Start small and build momentum. Here are three project tiers that demonstrate practical skills and build upon each other. For each one, put it in its own GitHub repo with a killer README that explains the ‘what’, the ‘why’, and the ‘how’.

Scenario 1: The Foundational Script (The “Quick Fix”)

This is your bread and butter. It’s the “janitorial” work that every single one of us does. It shows you can solve an immediate, tangible problem with a simple script. It’s not glamorous, but it proves you can think on your feet.

The Task: Write a shell script that runs on a server (e.g., web-prod-01). It should check the disk usage of the /var/log directory. If usage is over 80%, it should find all .log files older than 7 days, compress them, and then delete the originals. Finally, it should send a simple report of its actions to a Slack webhook.

What it shows: Basic shell scripting (if/else, find, gzip, curl), problem-solving, and an understanding of basic Linux system administration.

#!/bin/bash

LOG_DIR="/var/log"
THRESHOLD=80
SLACK_WEBHOOK_URL="your_webhook_url_here"

CURRENT_USAGE=$(df $LOG_DIR | grep / | awk '{ print $5 }' | sed 's/%//g')

if [ "$CURRENT_USAGE" -gt "$THRESHOLD" ]; then
  # Find and compress old logs
  find $LOG_DIR -type f -name "*.log" -mtime +7 -exec gzip {} \;
  
  MESSAGE="Log cleanup on $(hostname): Disk usage was at ${CURRENT_USAGE}%. Compressed logs older than 7 days."
  curl -X POST -H 'Content-type: application/json' --data "{\"text\":\"$MESSAGE\"}" $SLACK_WEBHOOK_URL
else
  # Optional: send a "all clear" message or just exit silently
  exit 0
fi

Darian’s Pro Tip: This script is hacky, and that’s okay! In your README, add a “Future Improvements” section. Mention things like “Make threshold a variable,” “Add better error handling,” or “Rewrite in Python for better testability.” This shows you’re thinking ahead.

Scenario 2: The Connected Pipeline (The “Permanent Fix”)

Now let’s connect some services. This demonstrates that you understand that DevOps isn’t just about one tool, but about creating a workflow. You don’t need a complex application; a simple static website or even just some configuration files will do.

The Task: Create a simple CI pipeline using GitHub Actions. The repository will contain Terraform configuration for an S3 bucket configured for static website hosting. The pipeline should trigger on a push to the main branch and perform the following stages:

1. Lint & Format: Run terraform fmt -check and tflint.
2. Plan: Run terraform plan and save the plan file.
3. Apply: Run terraform apply with the plan file. (You’ll need to handle AWS credentials as GitHub Secrets).

What it shows: Understanding of CI/CD concepts (stages, triggers), Infrastructure as Code (Terraform), and security (managing secrets).

# .github/workflows/deploy-s3-bucket.yml
name: 'Deploy Static Site Infrastructure'

on:
  push:
    branches:
      - main

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v3

    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v2
      with:
        terraform_version: 1.2.0

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1

    - name: Terraform Init
      run: terraform init

    - name: Terraform Format
      run: terraform fmt -check

    - name: Terraform Plan
      run: terraform plan -out=tfplan

    - name: Terraform Apply
      run: terraform apply -auto-approve tfplan

Scenario 3: The End-to-End Environment (The “Nuclear Option”)

Okay, this is the capstone. We’re not just deploying infrastructure; we’re configuring a running server. This project ties together IaC, Configuration Management, and potentially CI/CD. It’s a microcosm of a real production environment.

The Task: Combine the previous concepts. Use Terraform to provision a single EC2 instance (a cheap t2.micro is fine) and a security group that allows SSH and HTTP traffic. Then, use Ansible (triggered via `local-exec` in Terraform or as a separate step) to configure the newly created instance. The Ansible playbook should:

1. Wait for the server to be available.
2. Install Nginx.
3. Create a simple `index.html` file from a template.
4. Ensure the Nginx service is started and enabled.

What it shows: You can orchestrate a full, albeit simple, application deployment from code. You understand the difference between provisioning (Terraform) and configuration (Ansible).

Here’s a breakdown of the moving parts:

My Final Two Cents

Your portfolio is not about proving you know every tool under the sun. It’s about telling a story. The story is: “I can identify a problem, select the right tools for the job, and build a clean, documented, and effective solution.” Start with the janitor script, move to the assembly line, and then build the full blueprint. If you can do that and explain your choices, you’re already ahead of the person who just forked a Kubernetes repo.

Now stop reading and go build something. We’re waiting to see it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions