DEV Community: Syed Kashif Ali

Day -1: Building the Foundation for My AWS DevOps Journey

Syed Kashif Ali — Fri, 14 Aug 2026 15:49:46 +0000

Every DevOps journey starts with tools.
But before learning Kubernetes, Terraform, containers, or complex CI/CD pipelines, I believe it is important to understand the fundamentals that connect everything together.
That is what I focused on during Day -1 of my AWS DevOps learning journey.
🎯 The Goal
The goal was not to master every AWS service.
It was to understand the foundation:
Linux → Git → GitHub → CI/CD → AWS
Once these pieces are clear, learning more advanced DevOps technologies becomes much easier.

Understanding DevOps
DevOps is more than just a collection of tools.
It brings together:
Development
Operations
Automation
Collaboration
Continuous delivery
Monitoring
The basic idea is to create a reliable path from writing code to running that code in production.
A simplified workflow looks like:
This workflow became the foundation for the topics I want to explore in the coming days.
Linux — The DevOps Foundation
Linux is one of the most important foundations for DevOps engineers.
I focused on understanding:
File and directory structure
Permissions
Users and groups
Processes
Package management
SSH
Environment variables
Basic networking commands
Log investigation
Some commands that every DevOps engineer should become comfortable with include:
These commands become extremely useful when troubleshooting EC2 instances, containers, CI/CD runners, and Kubernetes nodes.
Git and GitHub
The next foundation is version control.
Git allows us to track changes to our code and collaborate with other engineers.
A basic workflow is:
For example:
But Git becomes much more powerful when combined with CI/CD.
A simple git push can become the trigger for an entire automated delivery process.
AWS Fundamentals
I also revisited some of the core AWS concepts that are important for DevOps.
AWS Region
A geographical area containing multiple Availability Zones.
Availability Zone
An isolated location within an AWS Region.
VPC
The networking boundary for AWS resources.
EC2
Virtual compute instances that can run applications, Docker, GitLab Runners, and many other workloads.
S3
Object storage commonly used for application files, backups, Terraform state, artifacts, and logs.
IAM
The authorization layer that controls what users, applications, and AWS services can access.
CloudWatch
Used for monitoring, metrics, logs, and operational visibility.
Understanding these services gives us the basic AWS vocabulary required for designing DevOps architectures.
IAM — A Critical DevOps Concept
One important lesson is that DevOps is not only about automation.
Security must be part of the automation.
IAM determines:
For example, a CI/CD pipeline should not simply receive unrestricted AWS credentials.
A better approach is to use short-lived credentials and role-based access.
This becomes particularly important when we connect GitLab CI/CD with AWS.
That will be one of the areas I explore further in this journey.
CI/CD Fundamentals
The next concept was understanding the basic CI/CD lifecycle.
A simplified pipeline looks like:
Instead of manually performing every step, the pipeline automates the process.
For example:
This is where DevOps starts becoming powerful.
How Everything Connects
The most important takeaway from Day -1 was understanding how individual technologies fit together.
Each technology has a role.
Git manages source-code history.
GitHub/GitLab hosts and collaborates on code.
CI/CD automates delivery.
Terraform automates infrastructure.
Docker packages applications.
AWS provides the infrastructure.
EKS runs containerized workloads using Kubernetes.
What I Learned
The biggest lesson from Day -1 is that learning DevOps shouldn't be about memorizing commands.
It should be about understanding how the pieces connect.
For example:
Why do we need Git?
To track and collaborate on code.
Why do we need CI/CD?
To automate software delivery.
Why do we need Terraform?
To automate infrastructure.
Why do we need Docker?
To package applications consistently.
Why do we need Kubernetes?
To orchestrate containers at scale.
Why do we need AWS?
To provide scalable cloud infrastructure and managed services.
Once we understand the "why", the tools become much easier to learn.

🚀 What's Next?
With the foundation in place, the next step is Amazon EKS.
I'll explore:
EKS architecture
Control plane
Worker nodes
Pods
Deployments
Services
Ingress
EKS networking
Container deployment
Application-to-database communication
The goal is to move from:
Understanding DevOps → Building DevOps systems

Final Takeaway
A strong DevOps foundation is not built by learning 50 tools at once.
It is built by understanding how a small number of fundamental technologies work together.
My current learning path is:
Day -1 complete.
Next stop: Amazon EKS Fundamentals. ☸️
Learn. Build. Automate. Deploy. Repeat.

AWS #AWSCommunityBuilders #DevOps #AmazonEKS #Git #GitHub #GitLab #Terraform #Docker #Linux #CICD #CloudComputing #LearningInPublic

🚀 Amazon EKS: Stateful vs Stateless Applications — Services, Deployments, StatefulSets & Persistent Storage

Syed Kashif Ali — Mon, 10 Aug 2026 05:33:22 +0000

Stateless application in EKS

A stateless application does not store important data inside the Pod.

Examples:

Nginx
React frontend
Node.js API
Python Flask API
Java Spring Boot API

If a Pod dies, Kubernetes can create a new Pod and the application continues working because there is no important state inside the old Pod.

selector:
matchLabels:
app: nginx

template:
metadata:
labels:
app: nginx

spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

Here Kubernetes manages 3 interchangeable Pods.

If nginx-abc dies:

Before:

nginx-abc
nginx-def
nginx-ghi

      ↓ Pod-abc crashes

After:

nginx-new
nginx-def
nginx-ghi

The new Pod doesn't need the old Pod's identity or filesystem.

Service for Stateless application

The Service provides a stable network endpoint for the changing Pods.

apiVersion: v1
kind: Service
metadata:
name: nginx-service

spec:
type: ClusterIP

selector:
app: nginx

ports:
- port: 80
targetPort: 80

The Service finds Pods using:

labels:
app: nginx

So:

Client
|
v
nginx-service:80
|
+----> nginx Pod 1
|
+----> nginx Pod 2
|
+----> nginx Pod 3

The Service provides load balancing across the matching Pods.

Stateful application in EKS

A stateful application needs persistent identity and/or persistent storage.

Examples:

MySQL
PostgreSQL
MongoDB
Redis
Kafka
Elasticsearch

For example, imagine MySQL:

MySQL Pod
|
+---- Database files
+---- Users
+---- Orders
+---- Transactions

If the Pod disappears, you cannot simply create an empty new MySQL Pod.

You need the data to survive.

That's where:

StatefulSet
PersistentVolumeClaim
PersistentVolume
EBS/EFS
Headless Service

come into the picture.

StatefulSet

For Kubernetes-native stateful workloads, we commonly use a StatefulSet instead of a Deployment.

Example:

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql

spec:
serviceName: mysql
replicas: 1

selector:
matchLabels:
app: mysql

template:
metadata:
labels:
app: mysql

spec:
  containers:
    - name: mysql
      image: mysql:8.0

      env:
        - name: MYSQL_ROOT_PASSWORD
          value: "mypassword"

      ports:
        - containerPort: 3306

      volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql

volumeClaimTemplates:
- metadata:
name: mysql-data

  spec:
    accessModes:
      - ReadWriteOnce

    resources:
      requests:
        storage: 20Gi

The important part is:

volumeClaimTemplates:

Kubernetes creates a PVC for the StatefulSet.

What happens in EKS?

Suppose you have:

StatefulSet
|
v
mysql-0
|
v
PVC
|
v
PV
|
v
AWS EBS Volume

For example:

mysql-0
|
+---- mysql-data-mysql-0
|
v
EBS 20 GB

The MySQL data is stored on the persistent volume rather than only inside the container.

What happens if MySQL Pod crashes?

This is the important part.

Initially:

mysql-0
|
v
EBS Volume
|
+---- customer data
+---- orders
+---- database

Suppose:

mysql-0
X
CRASH

StatefulSet recreates:

mysql-0
|
v
Existing PVC
|
v
Existing EBS
|
+---- customer data
+---- orders
+---- database

So the new Pod can mount the existing persistent storage.

The Pod name remains:

mysql-0

This stable identity is one of the major differences from a normal Deployment.

StatefulSet vs Deployment Feature Deployment StatefulSet Used for Stateless apps Stateful apps Pod identity Temporary Stable Pod names Random-ish suffix Ordered names Example api-7d9f... mysql-0 Persistent storage Optional Common PVC Usually separate Can use volumeClaimTemplates Scaling Easy Ordered Pod replacement Interchangeable Identity preserved Example Node.js API MySQL
Stateful Service

Stateful applications often use a Headless Service.

Example:

apiVersion: v1
kind: Service
metadata:
name: mysql

spec:
clusterIP: None

selector:
app: mysql

ports:
- port: 3306
targetPort: 3306

Notice:

clusterIP: None

This makes it a Headless Service.

Instead of giving one virtual IP, Kubernetes DNS can resolve individual StatefulSet Pods.

For example:

mysql-0.mysql.default.svc.cluster.local

If you had:

mysql-0
mysql-1
mysql-2

they can have stable DNS identities:

mysql-0.mysql
mysql-1.mysql
mysql-2.mysql

Why StatefulSet needs Service?

Consider a database cluster:

             mysql-service
                   |
      +------------+------------+
      |            |            |
      v            v            v
   mysql-0      mysql-1      mysql-2
      |            |            |
     PVC          PVC          PVC
      |            |            |
     EBS          EBS          EBS

The Service provides stable networking.

The StatefulSet provides:

stable Pod identity
ordered deployment
ordered termination
persistent storage association

Stateless EKS example — Node.js API

Imagine your ecommerce application:

                Internet
                   |
                   v
             AWS ALB
                   |
                   v
            Kubernetes Service
                   |
      +------------+------------+
      |            |            |
      v            v            v
   API Pod      API Pod      API Pod
      |            |            |
      +------------+------------+
                   |
                   v
                Amazon RDS
                   |
                   v
                MySQL

Your Node.js API is stateless.

Why?

Because:

User
|
v
API Pod
|
v
RDS

The API doesn't permanently store the user's orders inside its own filesystem.

If:

API Pod 1 → crashes

Kubernetes creates:

API Pod 4

and the application continues.

Stateful EKS example — MySQL

Now imagine MySQL running inside EKS:

         MySQL Service
               |
               v
            mysql-0
               |
               v
              PVC
               |
               v
          EBS Volume
               |
               v
         Database Data

If:

mysql-0 → crashes

Kubernetes recreates:

mysql-0

and attaches the persistent storage.

Very important: EKS + RDS

In production, you generally don't need to run MySQL yourself inside EKS if you can use Amazon RDS/Aurora.

A common architecture is:

                Internet
                   |
                   v
                 ALB
                   |
                   v
          Kubernetes Service
                   |
      +------------+------------+
      |            |            |
      v            v            v
   API Pod      API Pod      API Pod
      |            |            |
      +------------+------------+
                   |
                   v
             Amazon RDS
              MySQL/Postgres

Here:

EKS

Runs your stateless application:

Frontend
Backend
API
Microservices
RDS

Runs your stateful database:

MySQL
PostgreSQL

AWS handles much of the database infrastructure for you.

This is usually preferable to running production MySQL directly inside EKS unless you have a specific reason to do so.

Easy way to remember Stateless Deployment ↓ Pods ↓ Service ↓ External database

Pods are replaceable.

Pod dies
↓
New Pod
↓
Continue
Stateful
StatefulSet
↓
Pod
↓
PVC
↓
PV
↓
EBS/EFS

Pod identity and data persistence matter.

Pod dies
↓
Same identity
↓
Same persistent storage
↓
Continue with data
Interview answer

If an interviewer asks "What is the difference between StatefulSet and Deployment in EKS?", you can say:

Deployment is mainly used for stateless applications where Pods are interchangeable. StatefulSet is used for stateful applications that require stable Pod identity, predictable naming, and persistent storage. In EKS, a Deployment might run Node.js API replicas behind a Service, while a StatefulSet could run MySQL with PVCs backed by EBS. For production databases, however, I would generally prefer Amazon RDS/Aurora rather than managing the database inside EKS.

🚀 Amazon EKS with MCP — AI-Powered Kubernetes Management on AWS

Syed Kashif Ali — Sun, 09 Aug 2026 13:27:03 +0000

🚀 Amazon EKS — Zero to Production Roadmap

Architecture

Core components:

EKS Control Plane
Managed Node Groups
VPC
Private/Public Subnets
VPC CNI
CoreDNS
kube-proxy
AWS Load Balancer Controller
EBS CSI Driver
IAM / EKS Access Entries
Kubernetes RBAC

Create EKS with Terraform

Recommended structure:

eks-project/
├── main.tf
├── variables.tf
├── outputs.tf
├── providers.tf
├── terraform.tfvars
└── modules/
├── vpc/
└── eks/

Your Terraform should create:

VPC
├── Internet Gateway
├── NAT Gateway
├── Public Subnets
├── Private Subnets
└── Route Tables

EKS
├── Control Plane
├── IAM Roles
├── Managed Node Group
└── EKS Add-ons

For production, place worker nodes in private subnets.

Verify AWS Authentication

Before touching Kubernetes:

aws sts get-caller-identity

You should get your AWS identity.

Then:

aws eks update-kubeconfig \
--region ap-south-1 \
--name

Verify:

kubectl config current-context

Then:

kubectl get nodes

Expected:

NAME STATUS ROLES
ip-10-0-1-xxx.ec2.internal Ready
ip-10-0-2-xxx.ec2.internal Ready

EKS Authentication

Think about authentication in two layers:

IAM
│
│ Authentication
▼
EKS API Server
│
│ Authorization
▼
Kubernetes RBAC
Authentication

AWS asks:

Who are you?

Example:

aws sts get-caller-identity
Authorization

Kubernetes asks:

What are you allowed to do?

Example:

kubectl auth can-i get pods

This distinction is very important in EKS interviews.

EKS Access Entry

For modern EKS clusters, use EKS Access Entries where possible.

Conceptually:

IAM User / IAM Role
│
▼
EKS Access Entry
│
▼
Access Policy / Kubernetes permissions
│
▼
Kubernetes API

For example, an IAM role can be granted administrative access to the cluster.

Kubernetes RBAC

RBAC controls permissions inside Kubernetes.

There are four important objects:

Role
ClusterRole
RoleBinding
ClusterRoleBinding
Role

Namespace-specific permissions.

Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer-role
namespace: dev
rules:

apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]

This allows a user to:

GET pods
LIST pods
WATCH pods

but not:

DELETE pods
CREATE pods

RoleBinding

Connect the user to the Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-binding
namespace: dev
subjects:

kind: User name: ali apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: developer-role apiGroup: rbac.authorization.k8s.io

Apply:

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

Test:

kubectl auth can-i get pods -n dev --as=ali

Expected:

yes

Test something unauthorized:

kubectl auth can-i delete deployment -n dev --as=ali

Expected:

VPC CNI

This is one of the most important EKS concepts.

AWS VPC CNI gives Kubernetes pods networking through the AWS VPC.

EKS Node
│
├── Primary ENI
│
├── Secondary ENI
│
├── Pod IP
│
├── Pod IP
│
└── Pod IP

Check it:

kubectl get pods -n kube-system

Look for:

aws-node-xxxxx

Check:

kubectl get daemonset aws-node -n kube-system

Why VPC CNI Matters

Suppose your node has:

10.0.1.10

A pod may receive:

10.0.1.50

That IP comes from the VPC networking system.

Therefore your pods can communicate with AWS resources such as:

RDS
ElastiCache
ALB
S3 via VPC endpoints
Secrets Manager via VPC endpoints

Deploy an Application

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80

Apply:

kubectl apply -f deployment.yaml

Check:

kubectl get pods

Service

Expose the pods internally:

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
type: ClusterIP

Then:

kubectl apply -f service.yaml

Check:

kubectl get svc

ALB Ingress

For external traffic:

Internet
│
▼
AWS ALB
│
▼
Kubernetes Ingress
│
▼
Service
│
▼
Pods

You'll normally use the AWS Load Balancer Controller for this.

Production Application Architecture

For your DevOps project, a good architecture is:

                Internet
                   │
                   ▼
                Route 53
                   │
                   ▼
                AWS ALB
                   │
             ┌─────┴─────┐
             │   Ingress │
             └─────┬─────┘
                   │
          ┌────────┴────────┐
          │                 │
      Frontend           Backend
          │                 │
          │            ┌────┴────┐
          │            │         │
          │           RDS      Redis
          │
          ▼
         Pods

CI/CD

Your final pipeline can be:

Developer
│
▼
GitHub
│
▼
GitHub Actions
│
├── Test
├── SonarQube
├── Docker Build
├── Docker Push
│
▼
Amazon ECR
│
▼
EKS
│
▼
Rolling Deployment

Use GitHub OIDC → AWS IAM Role rather than storing long-lived AWS access keys.

Final Production Flow GitHub │ ▼ GitHub Actions │ OIDC Authentication │ ▼ AWS IAM │ ┌──────────┴──────────┐ │ │ ▼ ▼ ECR EKS │ │ Docker Image Kubernetes │ ┌────────┴────────┐ │ │ Ingress Services │ │ └────────┬────────┘ │ ▼ Pods │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ RDS Redis AWS APIs