🚀 14 Hands-On DevOps Projects Every Engineer Should Build: A Complete Roadmap from Beginner to Enterprise AWS EKS

24 min read3 days ago

From writing your first shell script to designing a production-ready Kubernetes platform on AWS. Learn DevOps by building real-world projects, one step at a time.

Have you ever wondered why some DevOps engineers can confidently troubleshoot production infrastructure while others struggle when asked to deploy a simple application?

The difference isn’t necessarily the number of certifications they hold or how many tools they have mentioned on their resumes.

It comes down to practical experience.

You might have completed a Docker course, watched Kubernetes tutorials, learned Terraform syntax, and practiced Jenkins pipelines. But can you explain how these tools work together to deliver an application?

For example, imagine a developer pushes new code to GitHub.

What happens next?

How does the system identify the code change?
How is the application built?
How are automated tests executed?
How is the application packaged into a Docker image?
Where is that image stored?
How does Kubernetes deploy it?
How do users access the application?
How do engineers monitor application health?
What happens if the deployment fails?

These are the questions that real DevOps engineers deal with.

And the best way to understand them is to build projects yourself.

This article covers 14 practical DevOps projects, progressing from beginner-friendly exercises to an enterprise-style AWS EKS platform.

You don’t need to know every tool before starting. We’ll gradually introduce each technology, explain why it is needed, and understand how it fits into the bigger picture.

📘 SECTION 1: BEGINNER DEVOPS PROJECTS

Your objective: Understand the fundamentals, learn essential tools, and develop the confidence to build working systems.

Before working with complex cloud infrastructure, you need to understand how applications are developed, packaged, deployed, and monitored.

Think of these first eight projects as the foundation of your DevOps journey.

1. Build Your First CI/CD Pipeline

Tools: Git, GitHub, GitHub Actions or Jenkins

First, understand the problem.

Imagine a software developer writes code for an application.

After completing the changes, the developer sends the code to another engineer who manually:

Downloads the latest source code.
Installs application dependencies.
Builds the application.
Runs tests.
Copies files to a server.
Restarts the application.

Now imagine doing this 20 times every day.

It becomes time-consuming, repetitive, and error-prone.

This is the problem CI/CD solves.

What is CI/CD?

CI stands for Continuous Integration.

It means developers frequently integrate their code changes into a shared repository. Automated processes can then build the application and run tests to identify problems early.

CD commonly refers to Continuous Delivery or Continuous Deployment.

Continuous Delivery ensures that validated changes are ready for release.
Continuous Deployment automatically releases qualifying changes to production.

How does the project work?

First, create a simple application and upload its source code to GitHub.

Next, configure a GitHub Actions workflow.

Whenever a developer pushes code, GitHub Actions automatically starts the pipeline.

The workflow might look like this:

Developer writes code
        |
        v
Push code to GitHub
        |
        v
GitHub Actions detects changes
        |
        v
Install dependencies
        |
        v
Build application
        |
        v
Run automated tests
        |
        v
Build Docker image
        |
        v
Deploy application

Example GitHub Actions workflow

Create this file inside your repository:

.github/workflows/ci.yml

name: Simple CI Pipeline

on:
  push:
    branches:
      - mainjobs:
  build:
    runs-on: ubuntu-latest    steps:
      - name: Checkout code
        uses: actions/checkout@v4      - name: Print message
        run: echo "Building application"      - name: Verify environment
        run: |
          python --version
          git --version      - name: Complete build
        run: echo "Build completed successfully"

This is a basic demonstration, not a complete production pipeline. A real application would also install dependencies, execute tests, and build its deployable artifact.

What should you learn?

What is a Git repository?
What happens when you push code?
What is a pipeline?
What is a pipeline stage?
What is a build artifact?
What happens when a pipeline fails?
How are credentials stored securely?

Final outcome: You’ll understand how code changes can automatically trigger software validation and delivery.

2. Dockerize an Application

Tools: Docker, Dockerfile, Docker Compose

Why do we need Docker?

Consider a developer working on a Python application.

The application works perfectly on their laptop because they have Python 3.12 and all the required libraries installed.

However, the production server has Python 3.9.

The application fails.

This is a common software deployment problem: differences between development and production environments.

Docker helps solve this problem by packaging an application and its dependencies into a container image.

Understand these three concepts first

Dockerfile: A text file containing instructions for building an image.

Docker image: A packaged, read-only template containing the application and its required runtime components.

Docker container: A running instance of an image.

Think of a Docker image as a recipe and a container as the prepared meal. The recipe describes what should be created, while the container is the running result.

How to build the project

First, install Docker Desktop or Docker Engine.

Create a simple Python application.

app.py

from flask import Flask

app = Flask(__name__)@app.route("/")
def home():
    return "Hello from Docker!"if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Create a dependency file.

requirements.txt

flask

Now create a Dockerfile.

FROM python:3.12-slim

WORKDIR /appCOPY requirements.txt .RUN pip install --no-cache-dir -r requirements.txtCOPY app.py .EXPOSE 5000CMD ["python", "app.py"]

Build the Docker image:

docker build -t my-first-app:v1 .

Run the container:

docker run -d -p 5000:5000 my-first-app:v1

Open:

http://localhost:5000

You should see:

Hello from Docker!

Understand what happened

FROM specifies the base image.
WORKDIR defines the working directory.
COPY copies files into the image.
RUN executes commands during image building.
EXPOSE documents the application port.
CMD defines the default startup command.

The -p 5000:5000 option maps port 5000 on your machine to port 5000 inside the container.

Useful troubleshooting commands

docker ps

docker ps -adocker imagesdocker logs <container-id>docker inspect <container-id>docker stop <container-id>

Final outcome: You’ll understand how to package an application so that it can run consistently across different environments.

3. Configure an NGINX Reverse Proxy

Tools: NGINX, Linux, HTTP, Networking

What problem does NGINX solve?

Imagine a company has three applications:

Customer application.
Admin application.
Payment application.

Each application runs on a different backend port.

Without a reverse proxy, users might need to access different ports directly.

NGINX provides a common entry point and forwards incoming requests to the correct backend.

What is a reverse proxy?

A reverse proxy is a server that receives requests from clients and forwards them to backend servers.

For example:

Internet
                 |
                 v
             NGINX
                 |
       +---------+---------+
       |         |         |
       v         v         v
   Backend 1  Backend 2  Backend 3
   Port 5001  Port 5002  Port 5003

The user communicates with NGINX instead of directly communicating with each backend.

Build the project

Install NGINX on an Ubuntu server:

sudo apt update

sudo apt install nginx -ysudo systemctl enable nginxsudo systemctl start nginx

Check its status:

sudo systemctl status nginx

Now configure a reverse proxy.

Create or edit an NGINX server configuration:

server {
    listen 80;

    server_name example.com;    location / {
        proxy_pass http://127.0.0.1:5000;        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For
            $proxy_add_x_forwarded_for;
    }
}

Validate the configuration:

sudo nginx -t

Reload NGINX:

sudo systemctl reload nginx

What else should you explore?

HTTP and HTTPS.
Reverse proxy versus forward proxy.
Load balancing.
SSL/TLS termination.
NGINX access logs.
NGINX error logs.
Upstream health and failure handling.

Production example: If one backend server becomes unavailable, a properly configured load-balancing setup can direct requests to healthy backend servers.

Final outcome: You’ll understand how requests travel from users to backend applications.

4. Build a Linux Log Analyzer

Tools: Linux, Bash, Python, Grep, AWK

Why is log analysis important?

Imagine your production application suddenly starts returning HTTP 500 errors.

Your server generates thousands of log entries every hour.

Manually reading every line is inefficient.

A log analyzer helps extract useful information from large log files.

What are logs?

Logs are records of events generated by applications, operating systems, and infrastructure components.

For example:

2026-11-08 10:00:01 INFO Application started

2026-11-08 10:01:12 ERROR Database connection failed2026-11-08 10:02:15 WARN High memory utilization2026-11-08 10:03:21 ERROR Payment service unavailable

These messages help engineers understand what happened and when it happened.

Build a simple log analyzer

Create a file called application.log.

Add sample entries:

INFO Application started
ERROR Database connection failed
INFO User login successful
ERROR Payment service unavailable
WARN High memory utilization
ERROR Database connection failed

Create a Bash script:

log-analyzer.sh

#!/bin/bash

LOG_FILE="application.log"echo "Total log entries:"
wc -l < "$LOG_FILE"echo "Error count:"
grep -c "ERROR" "$LOG_FILE"echo "Warning count:"
grep -c "WARN" "$LOG_FILE"echo "Error details:"
grep "ERROR" "$LOG_FILE"

Give execution permission:

chmod +x log-analyzer.sh

Execute:

./log-analyzer.sh

What should you understand?

Linux file permissions.
Shell scripting.
Standard input and output.
Pipes and redirection.
Grep and AWK.
Log rotation.
Cron scheduling.

Production example: A monitoring script can periodically analyze application logs and notify the operations team when critical error patterns appear.

Final outcome: You’ll develop practical Linux troubleshooting and automation skills.

5. Implement Prometheus and Grafana Monitoring

Tools: Prometheus, Grafana, Node Exporter

Why do applications need monitoring?

Imagine your application is running successfully.

Users can access it, and no one has reported an issue.

However, the server is consuming 95% of its available memory.

Without monitoring, you might discover the problem only after the application becomes unavailable.

Monitoring helps engineers identify issues before they become major incidents.

Understand the tools

Prometheus: A monitoring and time-series database that collects and stores metrics.

Node Exporter: Exposes Linux system metrics such as CPU, memory, disk, and network statistics for Prometheus.

Grafana: Provides dashboards for visualizing metrics collected from monitoring systems.

Architecture

Linux Server
     |
     v
Node Exporter
     |
     v
Prometheus
     |
     v
Grafana Dashboard
     |
     v
Engineer

Build the project

Start by installing Node Exporter on a Linux machine.

Run Prometheus and configure it to scrape the Node Exporter endpoint.

A basic Prometheus configuration looks like this:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "linux-server"
    static_configs:
      - targets:
          - "localhost:9100"

This tells Prometheus to collect metrics from the Node Exporter endpoint every 15 seconds.

Next, configure Grafana and add Prometheus as a data source.

Create dashboards displaying:

CPU utilization.
Available memory.
Disk utilization.
Network traffic.
Server availability.

What should you learn?

What is a metric?
What is a time series?
What is a scrape interval?
What is a Prometheus target?
What is a Grafana dashboard?
What is an alert rule?
How do you investigate high CPU utilization?

Production scenario: If CPU utilization suddenly increases, Prometheus collects the relevant metrics and Grafana helps engineers investigate the pattern.

Final outcome: You’ll understand the fundamentals of infrastructure monitoring and observability.

6. Host a Static Website on AWS

Tools: AWS S3, CloudFront, Route 53, IAM

What is the requirement?

Imagine a company wants to host its website.

The website contains:

HTML files.
CSS files.
JavaScript files.
Images.

It doesn’t need a traditional application server to generate pages dynamically.

AWS provides services that can host and distribute these files.

Understand the AWS services

Amazon S3: Object storage used to store website files.

Amazon CloudFront: Content Delivery Network (CDN) that distributes content through geographically distributed edge locations.

Amazon Route 53: DNS service that translates domain names into network destinations.

AWS IAM: Identity and Access Management service used to control permissions.

Architecture

Website Visitor
              |
              v
        Route 53 DNS
              |
              v
        CloudFront CDN
              |
              v
          Amazon S3
              |
              v
       Website Files

Build the project

Create an S3 bucket.
Upload your HTML, CSS, and JavaScript files.
Configure a CloudFront distribution.
Configure CloudFront Origin Access Control.
Allow CloudFront to access the private S3 origin.
Configure HTTPS.
Connect a domain using Route 53.

Avoid making the S3 bucket public unnecessarily. CloudFront Origin Access Control allows the website to remain private while CloudFront retrieves its content.

What should you understand?

What is object storage?
What is a CDN?
What is DNS?
What is an IAM policy?
How does HTTPS work?
How does CloudFront caching work?

Final outcome: You’ll understand how cloud-native website hosting works without managing traditional web servers.

7. Automate Linux Administration Using Shell Scripts

Tools: Bash, Cron, Linux

Why do we need automation?

Imagine managing 50 Linux servers.

Every day, you need to:

Check disk utilization.
Verify application services.
Monitor memory consumption.
Clean old temporary files.
Create backups.

Doing these tasks manually every day is not practical.

Shell scripting allows engineers to automate repetitive administrative operations.

Build a server health-check script

Create server-health.sh.

#!/bin/bash

echo "===== SERVER HEALTH REPORT ====="echo "Hostname:"
hostnameecho "Current Date:"
dateecho "Disk Usage:"
df -hecho "Memory Usage:"
free -hecho "CPU Information:"
uptimeecho "Running Processes:"
ps aux --sort=-%cpu | head -n 10echo "===== REPORT COMPLETED ====="

Make the script executable:

chmod +x server-health.sh

Run it:

./server-health.sh

Automate execution using Cron

Cron is a Linux job scheduler.

It allows scripts to execute automatically at specified times.

Open the crontab:

crontab -e

Add:

0 9 * * * /home/ubuntu/server-health.sh

This schedules the script to execute every day at 9 AM, using the server’s local time.

What should you learn?

Bash variables.
Conditions and loops.
Functions.
File permissions.
Cron jobs.
Exit codes.
Error handling.
Logging script output.

Final outcome: You’ll understand how to automate routine system administration tasks.

8. Deploy Your First Kubernetes Application

Tools: Kubernetes, Minikube or Kind, kubectl

Why do we need Kubernetes?

Docker helps package applications into containers.

But imagine running 100 containers across multiple servers.

You need a way to:

Schedule containers.
Restart failed workloads.
Distribute application traffic.
Scale applications.
Manage configuration.
Maintain the desired number of running replicas.

Kubernetes provides container orchestration.

Understand the basic Kubernetes components

Pod: The smallest deployable Kubernetes unit. It contains one or more containers.

Deployment: Manages application replicas and supports controlled updates.

Service: Provides a stable network endpoint for accessing Pods.

ConfigMap: Stores non-sensitive application configuration.

Secret: Stores sensitive configuration data, although additional encryption and access controls should be configured.

Namespace: Provides logical separation of Kubernetes resources.

Build the project

First, install Minikube, kubectl, and a container runtime.

Start a local cluster:

minikube start

Create a deployment:

kubectl create deployment nginx-app \
  --image=nginx

Expose it through a NodePort service:

kubectl expose deployment nginx-app \
  --type=NodePort \
  --port=80

Check the resources:

kubectl get pods

kubectl get deploymentskubectl get services

Scale the deployment:

kubectl scale deployment nginx-app \
  --replicas=3

Now Kubernetes attempts to maintain three application replicas.

Practice troubleshooting

kubectl describe pod <pod-name>

kubectl logs <pod-name>kubectl get events \
  --sort-by=.metadata.creationTimestamp

Learn how to investigate:

CrashLoopBackOff.
ImagePullBackOff.
Pending Pods.
Failed health checks.
Service connectivity problems.

Final outcome: You’ll understand how Kubernetes manages containerized workloads.

🏗️ SECTION 2: INTERMEDIATE AND ADVANCED DEVOPS PROJECTS

Your objective: Connect multiple technologies, automate complete workflows, and understand production engineering decisions.

Now that you’ve learned the fundamentals, it’s time to build systems that resemble real organizational environments.

These projects are particularly valuable when preparing for mid-level and senior DevOps interviews.

9. Build an End-to-End CI/CD Pipeline

Tools: Jenkins, Docker, SonarQube, Trivy, AWS ECR

What makes this project different?

In Project 1, you created a basic CI pipeline.

Now you’ll build a more realistic software delivery workflow with code quality checks, security scanning, container image creation, and deployment.

Understand the architecture

Developer
    |
    v
GitHub Repository
    |
    v
Jenkins Pipeline
    |
    v
SonarQube Analysis
    |
    v
Trivy Security Scan
    |
    v
Docker Image Build
    |
    v
Amazon ECR
    |
    v
Application Deployment

Understand the tools

Jenkins: Automation server used to execute CI/CD pipelines.

SonarQube: Analyzes source code for code quality issues and potential vulnerabilities.

Trivy: Scans container images, dependencies, and other supported artifacts for security issues.

Amazon ECR: Managed container image registry where Docker images are stored.

Build the workflow

First, configure Jenkins and connect it to your GitHub repository.

Create a Jenkinsfile containing pipeline stages.

Your pipeline should:

Check out the source code.
Build the application.
Run automated tests.
Perform SonarQube analysis.
Scan dependencies and container images.
Build a Docker image.
Authenticate with Amazon ECR.
Push the image.
Deploy the application.
Validate deployment health.

Example Docker build and push commands

docker build -t myapp:v1 .

docker tag myapp:v1 \
  ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/myapp:v1

Authenticate with ECR using the AWS CLI:

aws ecr get-login-password \
  --region REGION | docker login \
  --username AWS \
  --password-stdin ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com

Push the image:

docker push \
  ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/myapp:v1

In production, use short-lived credentials or IAM roles where possible rather than storing permanent AWS access keys in Jenkins.

What should you learn?

Jenkins agents and controllers.
Jenkinsfile syntax.
Pipeline stages.
Credential management.
Docker image tagging.
ECR authentication.
Quality gates.
Vulnerability severity.
Deployment validation.
Rollback procedures.

Production scenario: A developer accidentally introduces a vulnerable dependency. Your pipeline detects the issue before the image reaches production.

Final outcome: You’ll understand how to automate software delivery with quality and security controls.

10. Build AWS Infrastructure Using Terraform

Tools: Terraform, AWS, Git

First, understand Infrastructure as Code.

Traditionally, engineers created infrastructure manually through cloud consoles.

For example, creating a VPC requires multiple operations:

Creating the VPC.
Creating subnets.
Attaching an Internet Gateway.
Creating route tables.
Configuring security groups.

Now imagine repeating these steps across multiple environments.

Terraform automates infrastructure provisioning through configuration files.

Instead of manually clicking through the AWS Console, you describe the desired infrastructure using code.

Understand the Terraform workflow

Write Terraform Code
        |
        v
terraform init
        |
        v
terraform validate
        |
        v
terraform plan
        |
        v
terraform apply
        |
        v
AWS Infrastructure Created

terraform init: Initializes the working directory and downloads required providers and modules.

terraform validate: Checks whether the configuration is syntactically and structurally valid.

terraform plan: Shows the changes Terraform intends to make.

terraform apply: Executes the approved infrastructure changes.

Build your first AWS resource

Create main.tf.

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "demo" {
  bucket = "replace-with-a-globally-unique-name"
}

Initialize Terraform:

terraform init

Validate:

terraform validate

Review changes:

terraform plan

Create the resource:

terraform apply

Terraform will ask for confirmation unless automatic approval is configured.

Move towards a production architecture

After creating your first resource, build:

VPC.
Public and private subnets.
Internet Gateway.
NAT Gateway.
Route tables.
Security Groups.
IAM roles.
EC2 instances.
S3 buckets.

Next, learn Terraform modules.

Get Arvind Verma’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

A module is a reusable collection of Terraform configuration files.

For example, you can create a VPC module once and reuse it for development, staging, and production.

Understand Terraform state

Terraform maintains a state file that records its understanding of managed infrastructure.

This file is important because Terraform uses it to determine what exists and what changes are necessary.

For team environments, configure remote state storage and locking.

For AWS, a common setup uses:

Amazon S3 for remote state.
S3 lock files for state locking with supported modern Terraform versions.

Protect state files because they can contain sensitive information.

Production scenario: Your organization needs to create identical infrastructure across three AWS accounts. Terraform modules help standardize the implementation.

Final outcome: You’ll understand how to provision, update, and manage cloud infrastructure using code.

11. Deploy a Multi-Tier Application on Kubernetes

Tools: Kubernetes, Helm, NGINX Ingress

What is a multi-tier application?

Most real-world applications contain multiple components.

For example:

Frontend: What users interact with.
Backend: Processes business logic.
Database: Stores application information.

These components communicate with one another.

Your task is to deploy them on Kubernetes.

Understand the architecture

User
              |
              v
         Ingress
              |
              v
         Frontend
              |
              v
          Backend
              |
              v
           Database

Understand the Kubernetes resources

Deployment: Ensures that the required number of application replicas are running.

Service: Allows different application components to communicate through stable endpoints.

Ingress: Defines HTTP and HTTPS routing rules into the cluster. An Ingress controller must implement those rules.

Persistent Volume: Represents storage available to Kubernetes workloads.

Persistent Volume Claim: Represents an application’s request for storage.

Helm: A package manager for Kubernetes that helps deploy and manage application resources.

What should you implement?

Deploy the frontend.
Deploy the backend API.
Configure Services for internal communication.
Configure database connectivity.
Create ConfigMaps and Secrets.
Configure health probes.
Configure resource requests and limits.
Install an Ingress controller.
Package deployments using Helm.

Production scenario

A backend application crashes repeatedly because it cannot connect to the database.

Instead of randomly restarting Pods, investigate:

kubectl get pods -A

kubectl describe pod <pod-name>kubectl logs <pod-name>kubectl get svckubectl get endpoints

Check application logs, service discovery, credentials, network policies, and database availability.

Final outcome: You’ll understand how multiple application components work together inside Kubernetes.

12. Implement GitOps Using Argo CD

Tools: Argo CD, Git, Kubernetes, Helm

What problem does GitOps solve?

Imagine an engineer changes a Kubernetes Deployment manually:

kubectl set image deployment/myapp \
  myapp=myapp:v2

The live cluster now contains a configuration that may not exist in Git.

This creates configuration drift.

Other engineers cannot easily determine which configuration is correct.

GitOps addresses this by treating Git as the source of truth for the desired application configuration.

Understand how Argo CD works

Argo CD continuously compares:

Desired configuration stored in Git.
Actual configuration running in Kubernetes.

If they differ, Argo CD identifies the difference and can reconcile the cluster with the desired state, depending on its configuration.

Architecture

Developer
    |
    v
Git Repository
    |
    v
Argo CD
    |
    v
Kubernetes Cluster
    |
    v
Application Running

Build the project

Create a Git repository.
Store Kubernetes YAML manifests or Helm charts.
Install Argo CD in Kubernetes.
Connect Argo CD to your Git repository.
Create an Argo CD Application.
Configure synchronization.
Enable automated deployment where appropriate.
Test configuration drift detection.

Important concepts

Sync: Applies the desired configuration from Git.

OutOfSync: Indicates that the live application differs from the desired Git configuration.

Self-Heal: Reconciles supported live changes back to the declared desired state when enabled.

Pruning: Removes resources that are no longer part of the desired configuration when enabled.

Production scenario

An engineer accidentally changes the number of replicas directly in Kubernetes.

Argo CD detects the difference and restores the declared configuration if automated self-healing is enabled.

Final outcome: You’ll understand how modern engineering teams manage Kubernetes deployments through GitOps.

13. Build an Enterprise AWS EKS Cluster

Tools: AWS EKS, Terraform, IAM, OIDC, IRSA, Helm

This is one of the most important projects in the entire roadmap.

It combines cloud infrastructure, networking, security, Kubernetes, and automation.

First, what is Amazon EKS?

Amazon Elastic Kubernetes Service is AWS’s managed Kubernetes service.

Kubernetes requires a control plane to manage cluster operations.

EKS manages the Kubernetes control plane for you, while you configure and manage the worker infrastructure and cluster workloads according to your architecture.

Understand the major components

VPC: Provides an isolated virtual network in AWS.

Subnets: Divide the VPC into smaller network segments.

EKS Control Plane: Runs the Kubernetes control-plane components.

Managed Node Groups: Provide worker nodes that run application Pods.

IAM: Controls access to AWS services and resources.

OIDC: Provides an identity mechanism used in supported workload authentication integrations.

IRSA: IAM Roles for Service Accounts allows Kubernetes workloads to assume specific AWS IAM roles through service-account identity.

AWS Load Balancer Controller: Creates and manages AWS load-balancing resources based on supported Kubernetes resources.

Understand the architecture

Internet
                  |
                  v
          AWS Load Balancer
                  |
                  v
             AWS EKS
                  |
        +---------+---------+
        |                   |
        v                   v
     Node 1               Node 2
        |                   |
        v                   v
    Frontend Pod         Backend Pod
        |                   |
        +---------+---------+
                  |
                  v
             Database

A production architecture would also include private networking, appropriate database isolation, IAM controls, monitoring, and secure traffic routing.

Step 1: Create AWS networking

Use Terraform to provision:

VPC.
Public subnets.
Private subnets.
Internet Gateway.
NAT Gateway.
Route tables.
Security Groups.

Understand why worker nodes are commonly placed in private subnets.

Step 2: Provision EKS

Use Terraform to create:

EKS cluster.
Managed Node Groups.
Cluster IAM role.
Node IAM role.
Required networking configuration.

Configure access to the cluster using supported EKS authentication mechanisms.

Step 3: Configure OIDC and IRSA

Suppose your application needs to upload files to an S3 bucket.

Giving the entire worker node broad S3 permissions is not a good security design.

Instead, configure workload identity so that the application can assume an IAM role with only the required S3 permissions.

This is the principle of least privilege.

Step 4: Install AWS Load Balancer Controller

The controller integrates Kubernetes resources with AWS load-balancing services.

For example, when you create a supported Kubernetes Ingress resource, the controller can provision an Application Load Balancer according to its configuration.

Step 5: Deploy applications

Use Helm to deploy your microservices.

Configure:

Deployments.
Services.
Ingress.
ConfigMaps.
Secrets.
Resource limits.
Health probes.
Autoscaling.

Step 6: Implement monitoring

Install Prometheus and Grafana.

Monitor:

Pod health.
Node utilization.
CPU and memory.
Application latency.
Request errors.
Cluster resource consumption.

Production troubleshooting

Practice investigating:

Pods stuck in Pending: Check available node capacity, scheduling constraints, taints, and storage requirements.

ImagePullBackOff: Check the image name, tag, registry access, and image pull credentials.

CrashLoopBackOff: Check container logs, startup commands, environment variables, and health probes.

Service connectivity problems: Check Service selectors, endpoints, DNS, and network policies.

AWS permission errors: Check IAM role trust policies, service-account annotations, and workload identity configuration.

Final outcome: You’ll understand how to design and operate a managed Kubernetes platform on AWS.

14. Implement Centralized Logging Using ELK

Tools: Elasticsearch, Logstash, Kibana, Fluent Bit

Why do we need centralized logging?

Imagine an EKS cluster running 30 Pods across multiple worker nodes.

An application suddenly starts failing.

Where would you look?

You could connect to individual Pods and execute:

kubectl logs <pod-name>

But what if the failing Pod has already restarted?

What if you need to correlate events across multiple services?

This is where centralized logging becomes useful.

Understand the components

Elasticsearch: Stores and indexes log data so it can be searched efficiently.

Logstash: Processes, transforms, and forwards log data.

Kibana: Provides a user interface for searching and visualizing Elasticsearch data.

Fluent Bit: Lightweight log processor and forwarder commonly used to collect container logs.

Architecture

Application Pods
       |
       v
   Fluent Bit
       |
       v
 Elasticsearch
       |
       v
     Kibana
       |
       v
   Engineer

Build the project

Deploy Elasticsearch.
Configure storage and resource requirements.
Deploy Fluent Bit as a DaemonSet.
Configure log collection from container workloads.
Forward logs to Elasticsearch.
Configure Kibana.
Create dashboards and searches.
Define retention and storage policies.

Production scenario

Your payment service generates an error at 10:05 AM.

You need to investigate:

Which application generated the error?
Which Pod was involved?
What happened immediately before the failure?
Did the database report errors?
Were other services affected?

Centralized logging makes it easier to correlate this information.

Final outcome: You’ll understand how to collect, search, and analyze logs across distributed infrastructure.

🏢 SECTION 3: THE ULTIMATE PROJECT: BUILD AN ENTERPRISE-GRADE AWS EKS PLATFORM

Your objective: Combine everything you’ve learned into a realistic cloud-native platform.

Now comes the most important part.

Instead of building 14 disconnected projects, combine the relevant technologies into one integrated enterprise-style implementation.

This is the type of project that can demonstrate your understanding of DevOps, cloud infrastructure, Kubernetes, automation, security, and platform engineering.

What Are We Building?

We’re building a production-oriented AWS EKS platform capable of hosting multiple containerized applications.

The platform should support:

Automated infrastructure provisioning.
Secure networking.
Identity and access management.
Container orchestration.
CI/CD automation.
GitOps deployments.
Centralized monitoring.
Centralized logging.
Application security.
Operational troubleshooting.

Let’s understand each architectural layer.

1. Network Layer: Build the Foundation

Tools: AWS VPC, Subnets, Route Tables, Security Groups, Terraform

Everything starts with networking.

Before deploying applications, you need to establish where your infrastructure will run and how its components will communicate.

What is a VPC?

A Virtual Private Cloud is an isolated network environment inside AWS.

For example, you can create a VPC using the CIDR range:

10.0.0.0/16

Inside this VPC, create multiple subnets.

Public subnets: Used for resources that need direct routes to an Internet Gateway, such as internet-facing load balancers.

Private subnets: Used for internal workloads that should not be directly accessible from the public internet.

Your EKS worker nodes will commonly run in private subnets.

Understand the traffic flow

Internet User
      |
      v
Internet-facing ALB
      |
      v
Private EKS Workloads
      |
      v
Internal Services

Use Terraform to create the network resources.

Engineering objective: Understand how traffic enters the network, how it reaches applications, and how security rules control communication.

2. Security Layer: Protect Infrastructure and Workloads

Tools: IAM, OIDC, IRSA, AWS Secrets Manager, Security Groups

Security should not be added as an afterthought.

It must be part of the platform architecture.

What is IAM?

AWS Identity and Access Management controls who or what can access AWS resources.

For example, an application that needs to read objects from a particular S3 bucket should not automatically receive permissions to access every AWS service.

What is OIDC?

OpenID Connect is an identity layer built on OAuth 2.0.

In EKS, an associated OIDC identity provider can be used for workload identity integrations such as IRSA.

What is IRSA?

IAM Roles for Service Accounts allows Kubernetes workloads to receive specific AWS permissions through their Kubernetes service accounts.

For example:

A reporting application needs permission to read reports from S3.

Instead of attaching broad permissions to every worker node, create a dedicated IAM role and associate it with the application’s Kubernetes service account.

This provides more granular access control.

What is AWS Secrets Manager?

It stores sensitive information such as:

Database credentials.
API keys.
Application secrets.

Your application should retrieve secrets through an appropriately configured identity and access mechanism rather than embedding passwords directly into source code.

Engineering objective: Design workloads that follow least-privilege security principles.

3. Kubernetes Platform Layer: Build the Compute Environment

Tools: AWS EKS, Kubernetes, Managed Node Groups, Helm

Now provision the Kubernetes platform.

EKS provides the managed control plane.

Worker nodes provide compute capacity for running application Pods.

Understand the relationship

AWS EKS
                |
         Control Plane
                |
        +-------+-------+
        |               |
        v               v
     Worker 1        Worker 2
        |               |
        v               v
      Pods            Pods

The Kubernetes scheduler places Pods on suitable worker nodes based on available resources and scheduling requirements.

What should you configure?

EKS cluster.
Managed Node Groups.
CoreDNS.
kube-proxy.
AWS VPC CNI.
IAM permissions.
Cluster networking.
Autoscaling.

Also understand the role of:

AWS Load Balancer Controller.
Cluster Autoscaler or Karpenter.
Helm.
Kubernetes resource requests and limits.

Engineering objective: Build a cluster that can host applications reliably and scale according to workload requirements.

4. Application Layer: Deploy Microservices

Tools: Docker, Kubernetes, Helm

Now deploy a realistic application.

For example, build a simple e-commerce application with:

Frontend service.
Product API.
Payment API.
User service.
Database.

Each component can run independently in Kubernetes.

How do these components communicate?

Kubernetes Services provide stable network endpoints.

For example, your frontend can communicate with the product API through its Kubernetes Service name.

The backend can communicate with the database through an internal service endpoint.

Use Helm charts to package and manage the application resources.

Configure:

Deployments.
Services.
Ingress.
ConfigMaps.
Secrets.
Health probes.
Resource requests and limits.
Horizontal Pod Autoscaling.

Engineering objective: Understand how multiple services operate together inside a distributed application platform.

5. CI/CD and GitOps Layer: Automate Software Delivery

Tools: GitHub, Jenkins, SonarQube, Trivy, ECR, Argo CD

This is where the platform becomes an automated software delivery environment.

Understand the complete workflow

Developer
    |
    v
GitHub
    |
    v
Jenkins
    |
    v
SonarQube
    |
    v
Trivy
    |
    v
Docker Build
    |
    v
Amazon ECR
    |
    v
GitOps Repository
    |
    v
Argo CD
    |
    v
AWS EKS
    |
    v
Application Running

What happens at each stage?

GitHub: Stores application source code.

Jenkins: Executes the CI/CD pipeline.

SonarQube: Checks code quality and identifies issues.

Trivy: Scans supported artifacts for vulnerabilities.

Docker: Packages the application into a container image.

Amazon ECR: Stores the image.

Argo CD: Synchronizes Kubernetes deployment configuration from Git.

AWS EKS: Runs the application.

A useful design is to separate the application source repository from the GitOps configuration repository.

When Jenkins builds a new image, it can update the image tag in the deployment repository.

Argo CD then detects the Git change and deploys the desired version.

Engineering objective: Build a repeatable deployment process with security checks, traceability, and rollback capabilities.

6. Observability Layer: Monitor the Entire Platform

Tools: Prometheus, Grafana, Alertmanager

A deployed application is not necessarily a healthy application.

You need to monitor what happens after deployment.

Collect metrics from:

Kubernetes nodes.
Application Pods.
API endpoints.
Infrastructure components.
Application services.

Use Prometheus to collect metrics and Grafana to visualize them.

Configure Alertmanager to route relevant alerts to the responsible engineering teams.

Example production incident

Your application suddenly experiences increased response times.

You investigate:

Are CPU and memory resources sufficient?
Are Pods restarting?
Are database requests taking longer?
Has network latency increased?
Are application errors increasing?

Instead of guessing, use metrics to narrow down the problem.

Engineering objective: Understand application health, identify bottlenecks, and respond to incidents using measurable evidence.

7. Centralized Logging Layer: Investigate Production Issues

Tools: Fluent Bit, Elasticsearch, Kibana

Metrics tell you that something is wrong.

Logs often help explain what happened.

Collect logs from application containers and infrastructure components.

Use Fluent Bit to forward log data to Elasticsearch and Kibana to search and visualize it.

For example, if a payment API starts failing, search logs using:

Application name.
Pod name.
Timestamp.
Error message.
Request identifier.
Trace identifier, when available.

This helps engineers correlate failures across multiple services.

Engineering objective: Develop the ability to investigate distributed application failures.

8. Production Hardening: Prepare for Real-World Failures

A platform is not production-ready simply because every component has been deployed.

You must test how it behaves when things go wrong.

Create failure scenarios:

Delete an application Pod.
Simulate a failed deployment.
Introduce an incorrect container image.
Exhaust available node resources in a test environment.
Break a service configuration.
Remove a required IAM permission.
Introduce an application-level failure.
Simulate increased traffic.

For each scenario:

Identify the problem.
Collect relevant metrics and logs.
Investigate the root cause.
Implement the fix.
Validate the recovery.
Document the incident.

This is how you develop production troubleshooting skills.

Recommended Implementation Roadmap

Don’t attempt to build the complete platform in one day.

Follow a progressive approach.

Phase 1: Infrastructure

Build VPC, networking, subnets, routing, and security groups using Terraform.

Phase 2: EKS Provisioning

Create the EKS cluster and managed worker nodes.

Phase 3: Identity and Security

Configure IAM, OIDC, IRSA, and workload permissions.

Phase 4: Load Balancing

Install the AWS Load Balancer Controller.

Phase 5: Application Deployment

Deploy microservices using Kubernetes and Helm.

Phase 6: CI/CD

Build Jenkins pipelines with SonarQube and Trivy integration.

Phase 7: GitOps

Configure Argo CD and automate deployment synchronization.

Phase 8: Monitoring

Install Prometheus, Grafana, and Alertmanager.

Phase 9: Logging

Deploy Fluent Bit, Elasticsearch, and Kibana.

Phase 10: Production Hardening

Implement security controls, troubleshooting procedures, backup strategies, and failure recovery.

The important thing is to understand every component rather than blindly copying commands from documentation.

Also, remember that this is a production-oriented learning architecture. A real production platform requires additional decisions around availability, disaster recovery, cost optimization, compliance, network isolation, secret management, and operational ownership.

🎯 FINAL TAKEAWAYS: HOW TO BECOME A PRACTICAL DEVOPS ENGINEER

Let’s revisit the most important lesson.

Learning DevOps is not about knowing 30 tools.

It’s about understanding how technology components work together to solve real problems.

A beginner might know how to execute:

docker build

An experienced engineer understands:

Why the image is being built.
Which base image is appropriate.
How image layers affect caching.
How dependencies are managed.
How vulnerabilities are scanned.
Where the image is stored.
How the application is deployed.
How the deployment is monitored.
How to roll back when something fails.

That difference comes from practical engineering experience.

How to Get Maximum Value from These 14 Projects

Follow these recommendations:

1. Don’t skip the fundamentals.

Understand Linux, networking, Git, and scripting before moving into advanced Kubernetes architecture.

2. Build every project yourself.

Watching someone else execute commands doesn’t mean you understand the implementation.

3. Understand every configuration file.

Don’t copy Dockerfiles, Jenkinsfiles, Terraform modules, or Kubernetes YAML without understanding what each section does.

4. Break things intentionally.

Delete test Pods, introduce incorrect configurations, simulate failures, and practice troubleshooting in controlled environments.

5. Document your work.

Maintain a GitHub repository with architecture diagrams, README files, configuration examples, and troubleshooting notes.

6. Think about security from the beginning.

Use least-privilege IAM permissions, secure secrets, image scanning, and appropriate network restrictions.

7. Prepare to explain your decisions.

An interviewer is interested not only in what you implemented but also why you selected a particular architecture.

Your DevOps Learning Journey

Start with Linux and Git.

Move to Shell Scripting and Docker.

Learn CI/CD and AWS.

Practice Terraform and Kubernetes.

Then explore Helm, GitOps, DevSecOps, Observability, SRE, and Platform Engineering.

Finally, combine everything into an enterprise-grade platform.

You don’t need to master all 14 projects immediately.

Build one project at a time. Understand the architecture. Troubleshoot the failures. Improve the implementation.

The goal isn’t to become someone who can execute commands. The goal is to become an engineer who understands systems and can solve production problems.

That is what makes the difference.

Learn. Practice. Build. Automate. Deploy. Scale. Grow. 🚀

🔖Hashtags

#DevOps #DevOpsEngineer #DevOpsProjects #AWS #Kubernetes #Docker #Terraform #Jenkins #GitHubActions #ArgoCD #GitOps #AmazonEKS #CloudComputing #InfrastructureAsCode #DevSecOps #PlatformEngineering #SRE #Linux #Prometheus #Grafana #SonarQube #Trivy #Automation #CICD #CloudNative #CareerGrowth #InterviewPreparation

👨💻 Follow Me

I regularly share practical DevOps tutorials, production troubleshooting scenarios, cloud architecture, Kubernetes, Terraform, CI/CD, DevSecOps, interview preparation, and career resources.

Connect with me across these platforms:

LinkedIn: https://www.linkedin.com/in/arvindverma021/

Substack: https://arvindverma021.substack.com/

Medium: https://medium.com/@arvindverma021

Topmate: https://topmate.io/arvindverma021

Explore my DevOps learning resources, interview preparation materials, and enterprise project walkthroughs on Topmate.

Keep Learning. Keep Building. Keep Growing. 🚀