Forem: Rahul Joshi

Day 8 — IAM & AWS CLI

Rahul Joshi — Tue, 19 May 2026 05:27:58 +0000

Cloud security starts with one thing:

Who can access what?

That’s exactly where IAM (Identity and Access Management) comes in.

Whether you're:

a Cloud Engineer ☁️
DevOps Engineer ⚙️
Security Engineer 🛡️
Backend Developer 👨‍💻
or preparing for AWS certifications 📚

Understanding IAM is absolutely mandatory.

And once IAM is understood, the next powerful step is using the AWS CLI to interact with AWS directly from your terminal like a real cloud engineer.

In this guide we'll cover:

What IAM is
IAM Users
IAM Roles
IAM Policies
MFA (Multi-Factor Authentication)
AWS CLI setup
Real-world best practices
Security mistakes beginners make

🔗 Resources

GitHub Repo:
https://github.com/17J/30-Days-Cloud-DevSecOps-Journey
AWS Command Sheet:
https://aws-command.vercel.app/

☁️ What is IAM?

IAM stands for:

Identity and Access Management

It is the AWS service used to control:

Authentication → Who are you?
Authorization → What can you do?

Think of IAM as the security guard of AWS.

Without IAM, anyone could access:

EC2 servers
S3 buckets
Databases
Secrets
Billing data

And that would become a disaster very quickly.

🏢 Real-World Example

Imagine a company has:

Developers
DevOps Engineers
Security Team
Finance Team
Interns

Should everyone get full AWS admin access?

❌ Absolutely not.

Instead:

Team	Access
Developers	EC2 + Logs
DevOps	Infrastructure
Finance	Billing only
Security	Audit + Monitoring
Interns	Read-only

IAM makes this possible.

🧠 Core IAM Components

AWS IAM mainly consists of:

IAM
├── Users
├── Groups
├── Roles
├── Policies
└── MFA

👤 IAM Users

An IAM User represents a person or application that needs access to AWS.

Examples:

Rahul
DevOps Engineer
CI/CD Pipeline
Jenkins Server
Terraform Automation

Each IAM user can have:

Password
Access Keys
Permissions
MFA

🔑 Types of IAM Access

1️⃣ Console Access

Used for:

AWS Web Dashboard login

Example:

https://aws.amazon.com/console/

Uses:

Username
Password
MFA

2️⃣ Programmatic Access

Used for:

AWS CLI
SDKs
Terraform
CI/CD Pipelines

Uses:

Access Key ID
Secret Access Key

Example:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

⚠️ Important Security Rule

Never use the Root Account for daily work.

Root account has unlimited permissions.

If compromised:

💀 Entire AWS account can be destroyed.

Instead:

✅ Create IAM users.

👥 IAM Groups

Groups help manage permissions more easily.

Instead of assigning permissions individually:

Rahul → EC2 Access
Aman → EC2 Access
Riya → EC2 Access

You create:

Developers Group → EC2 Access

Then add users to the group.

Much cleaner.

🛡️ IAM Policies

Policies define permissions.

They are written in JSON.

Policies answer:

What actions are allowed or denied?

📄 Example IAM Policy

This policy gives read-only access to S3 buckets:

🧠 Understanding Policy Structure

Component	Meaning
Effect	Allow or Deny
Action	AWS API actions
Resource	Which resources
Statement	Permission block

🚫 Principle of Least Privilege

One of the most important cloud security principles.

Meaning:

Give only the permissions that are actually required.

Bad Example ❌

"Action": "*",
"Resource": "*"

This gives full admin access.

Good Example ✅

"s3:GetObject"

Only specific access.

🎭 IAM Roles

Roles are extremely important in AWS.

A Role is a temporary identity with permissions.

Unlike users:

Roles do NOT have passwords
Roles do NOT have permanent access keys

Instead:

✅ AWS provides temporary credentials automatically.

🧠 Why Roles Matter

Roles are heavily used for:

EC2 instances
Lambda functions
ECS containers
Cross-account access
Kubernetes workloads
CI/CD systems

🚀 Example: EC2 Accessing S3

Suppose an EC2 server needs access to an S3 bucket.

❌ Wrong Approach:

Store AWS keys inside server files.

Huge security risk.

✅ Correct Approach:

Attach an IAM Role to EC2.

AWS automatically provides temporary credentials securely.

🔄 User vs Role

IAM User	IAM Role
Permanent identity	Temporary identity
Has password/access keys	Temporary credentials
Used by humans	Used by services/apps
Long-term access	Short-term access

🔐 MFA (Multi-Factor Authentication)

MFA adds an extra security layer.

Instead of only:

Password

You also need:

OTP / Authenticator Code

📱 Common MFA Methods

MFA Type	Example
Authenticator App	Google Authenticator
Hardware Key	YubiKey
SMS	OTP Messages

⚠️ Why MFA is Critical

Even if hackers steal passwords:

✅ They still cannot login without MFA.

AWS strongly recommends enabling MFA for:

Root Account
Admin Users
Production Accounts

🔥 Real Industry Fact

Many cloud breaches happen because:

Access keys leaked
No MFA enabled
Over-permissioned IAM users

Cloud security failures are often identity failures.

💻 What is AWS CLI?

AWS CLI stands for:

AWS Command Line Interface

It allows you to manage AWS directly from the terminal.

Instead of clicking in the console:

You can automate everything:

aws s3 ls

🚀 Why AWS CLI is Powerful

With CLI you can:

Automate infrastructure
Create scripts
Manage EC2
Upload to S3
Configure IAM
Integrate CI/CD
Manage Kubernetes
Use Terraform pipelines

Professional cloud engineers use CLI daily.

🛠️ Installing AWS CLI

🐧 Linux

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

unzip awscliv2.zip

sudo ./aws/install

🪟 Windows

Download from:

AWS CLI Official Installer

🍎 macOS

brew install awscli

✅ Verify Installation

Run:

aws --version

Example:

aws-cli/2.27.0 Python/3.x

⚙️ Configure AWS CLI

📁 AWS CLI Configuration Files

AWS stores credentials here:

~/.aws/credentials

And config here:

~/.aws/config

⚠️ Never Commit AWS Keys to GitHub

One of the biggest beginner mistakes.

If keys leak publicly:

Attackers can use your AWS account
Crypto mining attacks happen
Huge AWS bills occur

Use:

IAM Roles
Secrets Managers
Environment Variables

Instead.

🧪 Useful AWS CLI Commands

List S3 Buckets

aws s3 ls

List EC2 Instances

aws ec2 describe-instances

List IAM Users

aws iam list-users

Get Current Identity

aws sts get-caller-identity

This is extremely useful for debugging permissions.

🧠 AWS STS (Security Token Service)

STS provides temporary credentials.

Used heavily with:

IAM Roles
Federation
Kubernetes IAM
Cross-account access

This is one of the most important concepts in enterprise AWS security.

🏢 Real Enterprise IAM Practices

Large companies usually implement:

✅ SSO (Single Sign-On)
✅ MFA everywhere
✅ Role-based access
✅ Temporary credentials
✅ Permission boundaries
✅ IAM Access Analyzer
✅ Audit logging with CloudTrail

🔥 Common IAM Mistakes

❌ Using Root Account Daily

Very dangerous.

❌ Giving AdminAccess to Everyone

Creates massive attack surface.

❌ Hardcoding AWS Keys

Common breach reason.

❌ No MFA

Huge security risk.

❌ Overly Permissive Policies

Avoid:

"Action": "*"

☁️ IAM + DevOps + Security

IAM connects with almost everything in AWS:

Service	IAM Usage
EC2	Instance Roles
Lambda	Execution Roles
Kubernetes (EKS)	IAM Service Accounts
Terraform	Automation Access
CI/CD	Pipeline Permissions
CloudTrail	Audit Logs

IAM is the backbone of AWS security.

🧠 Final Thoughts

If networking is the foundation of cloud…

Then IAM is the foundation of cloud security.

Most real-world AWS problems are not caused by:

EC2
Kubernetes
Lambda

They’re caused by:

❌ Wrong permissions
❌ Exposed credentials
❌ Weak access control

Mastering IAM early will make you a much stronger:

Cloud Engineer
DevOps Engineer
Security Engineer
Platform Engineer

And AWS CLI will help you automate everything professionally.

Day 7 — Cloud Computing & AWS Fundamentals

Rahul Joshi — Mon, 18 May 2026 05:53:08 +0000

Cloud computing is no longer optional.

Whether you're building modern applications, deploying containers, running AI workloads, hosting websites, automating DevOps pipelines, or scaling startups — cloud platforms power almost everything today.

If you're entering:

DevOps
Cloud Engineering
Cybersecurity
Backend Development
Platform Engineering
AI Infrastructure

then understanding cloud fundamentals is one of the best investments you can make.

Let’s start from the foundation.

🔗 Resources

GitHub Repo: https://github.com/17J/30-Days-Cloud-DevSecOps-Journey

🌍 What is Cloud Computing?

Cloud computing means using computing resources over the internet instead of managing physical infrastructure yourself.

Instead of buying:

physical servers
networking hardware
storage devices
cooling systems
data center space

you rent resources from cloud providers on-demand.

Think of cloud like electricity.

You don’t build a power plant to use electricity.

Similarly, you don’t need to build a data center to run applications anymore.

⚡ Why Cloud Computing Became So Popular

Traditional infrastructure had many problems:

High upfront costs
Scaling issues
Slow provisioning
Hardware maintenance
Downtime risks
Complex disaster recovery

Cloud solved this by introducing:

✅ Pay-as-you-go pricing
✅ Global scalability
✅ High availability
✅ Fast deployments
✅ Managed services
✅ Built-in security tooling
✅ Infrastructure automation

This completely changed how software is built and deployed.

🧠 Core Cloud Computing Service Model

Before jumping into AWS, understand these important Service Models.

🖥 Infrastructure as a Service (IaaS)

You rent infrastructure components like:

virtual machines
networking
storage
load balancers

Example:

Amazon EC2
Azure Virtual Machines
Google Compute Engine

You manage:

OS
applications
runtime
security patches

Cloud provider manages:

hardware
networking
physical security

⚙️ Platform as a Service (PaaS)

The cloud provider manages the infrastructure and runtime.

You focus only on your application code.

Examples:

AWS Elastic Beanstalk
Azure App Service
Google App Engine

🚀 Software as a Service (SaaS)

Fully managed software delivered over the internet.

Examples:

Gmail
Slack
Zoom
Microsoft 365

You simply use the software.

No infrastructure management needed.

☁️ Types of Cloud Computing

🌐 Public Cloud

Public cloud means infrastructure is owned and managed by cloud providers.

Examples:

Amazon Web Services (AWS)
Microsoft Azure
Google Cloud Platform (GCP)

You share underlying infrastructure with other customers but your workloads remain logically isolated.

Advantages

✅ Cost effective
✅ Highly scalable
✅ Global infrastructure
✅ Massive service ecosystem
✅ Fast deployment

Best For

Startups
Modern applications
SaaS platforms
DevOps environments
AI workloads

🏢 Private Cloud

Private cloud is dedicated infrastructure used by a single organization.

It can be hosted:

on-premises
in private data centers
through dedicated cloud setups

Advantages

✅ More control
✅ Custom security policies
✅ Regulatory compliance
✅ Better for sensitive workloads

Best For

Banks
Government systems
Healthcare organizations
Large enterprises

🔀 Hybrid Cloud

Hybrid cloud combines:

public cloud
private cloud
on-premises infrastructure

Organizations keep sensitive systems private while scaling workloads in public cloud.

This is extremely common in enterprises today.

📊 Cloud Providers in Market

The cloud industry is dominated by three major players:

Together, these providers control nearly 70% of the global cloud market.

🥇 Amazon Web Services (AWS)

Amazon Web Services remains the market leader in 2026.

Why?

Because AWS offers:

200+ cloud services
massive global infrastructure
mature ecosystem
strongest community support
enterprise adoption
startup friendliness
powerful DevOps integrations

AWS also dominates cloud-related job postings globally. ([CloudPros][1])

🔵 Microsoft Azure

Microsoft Azure is extremely strong in enterprise environments.

Its biggest strengths are:

Microsoft ecosystem integration
Active Directory
Office 365 integration
enterprise compliance
hybrid cloud support

Large corporations heavily prefer Azure.

🔴 Google Cloud Platform (GCP)

Google Cloud Platform is famous for:

Kubernetes leadership
BigQuery
AI/ML tooling
data engineering
global networking

Many AI-first companies choose GCP because of its data and machine learning ecosystem. ([Reddit][2])

🚀 Why Beginners Usually Start with AWS

Most beginners start with AWS because:

✅ Largest job market
✅ Massive learning resources
✅ Huge community
✅ Strong free tier
✅ Broadest service coverage
✅ Industry-standard cloud concepts

Learning AWS fundamentals also makes learning Azure and GCP easier later.

🧾 AWS Prerequisites Before Learning

Before starting AWS seriously, you should have:

💻 Basic Linux Knowledge

Understand:

file systems
permissions
package management
shell commands

Important commands:

ls
cd
mkdir
rm
chmod
chown
grep
cat

🌐 Basic Networking Concepts

You should know:

IP addresses
DNS
HTTP/HTTPS
ports
firewalls
routing

These concepts become critical in cloud networking.

🔐 Basic Security Understanding

Learn:

IAM basics
authentication
authorization
SSH keys
least privilege principle

Cloud security is one of the most important skills today.

🐳 Optional but Helpful

These are not mandatory but highly useful:

Git & GitHub
Docker
CI/CD basics
Kubernetes basics

🪪 Step 1: Create an AWS Account

To start learning AWS:

Go to AWS official website
Create a free-tier account
Add billing information
Enable MFA (Multi-Factor Authentication)
Create an IAM user instead of using root account daily

Using the root account regularly is considered bad practice.

🌍 AWS Regions & Availability Zones

This is one of the MOST important AWS concepts.

📍 AWS Region

A Region is a geographical location where AWS has data centers.

Examples:

us-east-1
ap-south-1
eu-west-1

Each region is isolated from others.

🏢 Availability Zone (AZ)

An Availability Zone is one or more physically separate data centers inside a region.

Example:

Region: ap-south-1 (Mumbai)

AZs:
- ap-south-1a
- ap-south-1b
- ap-south-1c

Applications are deployed across multiple AZs for:

✅ High availability
✅ Fault tolerance
✅ Disaster recovery

🧠 Easy Analogy

Think of it like this:

Country → State → Buildings

Region → Availability Zones → Data Centers

⚙️ Core AWS Services Every Beginner Should Learn

🖥 Amazon EC2 (Elastic Compute Cloud)

Virtual machines in AWS.

Used for:

hosting applications
web servers
backend APIs
databases

EC2 is foundational AWS knowledge.

🪣 Amazon S3 (Simple Storage Service)

Object storage service.

Used for:

backups
static websites
media storage
logs
data lakes

S3 is one of the most widely used AWS services.

🌐 Amazon VPC (Virtual Private Cloud)

Allows you to create isolated cloud networks.

You control:

subnets
routing tables
firewalls
internet access

This is where networking becomes important.

🔐 IAM (Identity and Access Management)

Controls permissions in AWS.

You manage:

users
roles
groups
policies

IAM is the heart of AWS security.

⚖️ Elastic Load Balancer (ELB)

Distributes traffic across multiple servers.

Benefits:

✅ High availability
✅ Scalability
✅ Better fault tolerance

📈 Auto Scaling

Automatically increases or decreases infrastructure based on traffic.

This is one of cloud computing’s biggest advantages.

🗄 Amazon RDS

Managed relational database service.

Supports:

MySQL
PostgreSQL
MariaDB
SQL Server

AWS handles backups, patching, and maintenance.

🧱 CloudFormation

Infrastructure as Code (IaC) service.

You define infrastructure using templates.

Modern cloud engineering heavily depends on automation.

Cloud Formation Templates
Terraform

🔐 AWS Shared Responsibilty Model:

This concept is VERY important.

Many beginners misunderstand cloud security.

🤝 What AWS Handles

AWS is responsible for:

✅ Physical servers
✅ Data centers
✅ Networking hardware
✅ Hypervisors
✅ Physical security

👨‍💻 What YOU Handle

You are responsible for:

✅ IAM permissions
✅ Application security
✅ OS patching (EC2)
✅ Data encryption
✅ Security groups
✅ Network configuration

🧠 Simple Rule

Security OF the cloud → AWS
Security IN the cloud → You

This is the core idea behind the shared responsibility model.

🎯 Final Thoughts

Cloud computing is now the backbone of modern technology.

Every major industry today relies on cloud platforms for:

scalability
automation
security
AI workloads
application hosting
global infrastructure

If you're serious about DevOps, backend engineering, cybersecurity, platform engineering, or modern software development — cloud fundamentals are non-negotiable.

Start small.

Learn the basics deeply.

Understand networking.

Understand security.

Then build projects consistently.

Because in 2026, cloud knowledge is no longer a bonus skill.

It’s a core engineering skill.

Day 6 — Docker & Containerization

Rahul Joshi — Sun, 17 May 2026 10:46:14 +0000

Modern software development has changed completely.

Applications are no longer deployed directly on servers like before.

Today, companies package applications into containers so they can run consistently anywhere:

Developer laptop
Cloud servers
Kubernetes clusters
CI/CD pipelines
Edge infrastructure

🔗 Resources

GitHub Repo:
https://github.com/17J/30-Days-Cloud-DevSecOps-Journey
Docker Command Sheet:
https://docker-command.vercel.app/

🧠 What is a Container?

A container is a lightweight isolated environment that includes:

Application code
Runtime
Libraries
Dependencies
Environment variables
System tools

Everything required to run the application is packaged together.

That means:

Same behavior everywhere
Faster deployments
Portable infrastructure
Easy scaling

⚔️ Containers vs Virtual Machines

This is one of the most important concepts in DevOps.

Both Containers and VMs isolate applications — but in very different ways.

🖥️ Virtual Machines (VMs)

A VM includes:

Full Operating System
Guest Kernel
Hypervisor
Application

Problems with VMs

High memory usage
Slow startup time
Large storage consumption
Less efficient scaling

🐳 Containers

Containers share the host OS kernel.

They only package:

Application
Dependencies
Runtime

This makes them:

Lightweight
Fast
Portable
Efficient

📊 Containers vs VMs Comparison

Feature	Containers	Virtual Machines
Startup Time	Seconds	Minutes
Size	MBs	GBs
Performance	Near-native	Heavy overhead
Isolation	Process-level	Full OS-level
Resource Usage	Low	High
Portability	Excellent	Moderate

📦 What is Docker?

Docker is a platform used to:

Build applications
Package applications
Ship applications
Run applications in isolated environments called containers

Docker ensures:

“It works the same everywhere.”

This solves the classic developer problem:

“It works on my machine.”

🏗️ Docker Architecture

Docker mainly consists of 3 components:

1️⃣ Docker Client

The CLI where commands are executed.

Example:

docker build
docker run
docker ps

2️⃣ Docker Daemon

The background service (dockerd) responsible for managing:

Containers
Images
Networks
Volumes

3️⃣ Docker Registry

A place where Docker images are stored.

Popular registries include:

Docker Hub
GitHub Container Registry
AWS ECR
Google Artifact Registry

🧱 What is a Docker Image?

A Docker Image is a:

Read-only blueprint used to create containers.

It contains:

Application code
Dependencies
Runtime
Configuration
Libraries

🧠 Simple Analogy

Concept	Real World Example
Docker Image	Recipe
Docker Container	Cooked Food

The image is the template.

The container is the running instance.

🔍 Popular Docker Images

Some commonly used images:

nginx
ubuntu
node
python
mysql
redis
postgres

Pull an image:

docker pull nginx

Run a container:

docker run nginx

📝 What is a Dockerfile?

A Dockerfile is a text file containing instructions used to build a Docker image.

This is where containerization begins.

🧱 Example Dockerfile

FROM node:20-alpine

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "app.js"]

🔬 Dockerfile Explained

`FROM`

Defines the base image.

FROM node:20-alpine

`WORKDIR`

Sets the working directory inside the container.

WORKDIR /app

`COPY`

Copies files from local system into the container.

COPY . .

`RUN`

Executes commands during image build.

RUN npm install

`EXPOSE`

Documents which port the application uses.

EXPOSE 3000

`CMD`

Defines the default startup command.

CMD ["node", "app.js"]

🚀 Building Docker Images

Build image:

docker build -t myapp .

Explanation

Part	Meaning
`docker build`	Build Docker image
`-t`	Tag image
`myapp`	Image name
`.`	Current directory

▶️ Running Containers

Run container:

docker run -p 3000:3000 myapp

🔍 Understanding Port Mapping

-p 3000:3000

Means:

Host Machine	Container
3000	3000

Access app on:

http://localhost:3000

📂 Containerizing a Node.js Application

📁 Project Structure

project/
│
├── app.js
├── package.json
└── Dockerfile

📄 app.js

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.send("Docker is working!");
});

app.listen(3000);

📄 package.json

{
  "dependencies": {
    "express": "^4.18.2"
  }
}

📄 Dockerfile

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

EXPOSE 3000

CMD ["node", "app.js"]

🏗️ Build the Image

docker build -t node-docker-demo .

▶️ Run the Container

docker run -p 3000:3000 node-docker-demo

Now open:

http://localhost:3000

You should see:

Docker is working!

📦 Docker Image Layers

Docker images are layered.

Each instruction creates a new layer.

Example:

FROM ubuntu:24.04
RUN apt update
RUN apt install nginx
COPY . .

Each line becomes a cached layer.

This makes builds:

Faster
Efficient
Reusable

⚡ Docker Caching

Docker rebuilds only changed layers.

That’s why Dockerfiles should be optimized carefully.

✅ Cache-Friendly Pattern

COPY package.json .
RUN npm install

COPY . .

Why?

Dependencies are cached separately.

If only source code changes, Docker skips reinstalling packages.

❌ Bad Pattern

COPY . .
RUN npm install

Any file change invalidates cache.

Build becomes slower.

📁 Docker Volumes

Containers are ephemeral.

Data disappears after container removal.

Volumes solve this problem.

Create Volume

docker volume create mydata

Use volume:

docker run -v mydata:/data nginx

🌐 Docker Networking

Containers communicate using Docker networks.

Create network:

docker network create mynetwork

Run containers inside same network.

Useful for:

APIs
Databases
Microservices
Internal communication

🧹 Essential Docker Commands

📦 Images

docker images
docker pull nginx
docker build -t myapp .
docker push username/myapp:v1
docker rmi image_id

🐳 Containers

docker ps
docker ps -a
docker stop container_id
docker rm container_id
docker logs -f container_id
docker exec -it container_id sh

🧽 Cleanup

docker system prune
docker volume prune

🔥 Why Docker Became So Popular

Docker transformed software deployment because it provides:

Environment consistency
Faster deployments
Infrastructure portability
Easy CI/CD integration
Better scalability
Microservices support
Cloud-native compatibility

☁️ Docker in Modern DevOps

Docker is now everywhere.

Technology	Docker Usage
Kubernetes	Runs containers
CI/CD	Build & deploy
Cloud Platforms	Container hosting
DevSecOps	Isolated workloads
Microservices	Service packaging

🔐 Docker Security Basics

Important security practices:

Use minimal base images
Avoid running as root
Scan images regularly
Keep dependencies updated
Use signed images
Remove unused containers/images

🏭 Real-World Docker & K8s Workflow

🚀 Docker Best Practices

✅ Use Smaller Images

Prefer:

FROM node:20-alpine

Instead of huge base images.

Smaller images:

Pull faster
Reduce attack surface
Save storage

✅ Always Use `.dockerignore`

Example:

node_modules
.git
.env
*.log

This reduces build size and prevents accidental secret leaks.

✅ Multi-Stage Builds

Use one stage for building.

Use another minimal stage for production.

✅ Tag Images Properly

Bad:

latest

Good:

v1.0.2

✅ Don’t Run Containers as Root

Example:

RUN adduser -S appuser
USER appuser

🎭 Multi-Stage Build Example

# Stage 1 — Build
FROM node:20-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build

# Stage 2 — Production
FROM node:20-alpine

WORKDIR /app

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules

EXPOSE 3000

CMD ["node", "dist/index.js"]

📚 Final Thoughts

Docker completely changed how modern applications are built and deployed.

Understanding:

Containers
Docker Images
Dockerfiles
Layers
Volumes
Networking

is now a fundamental engineering skill.
Because modern infrastructure runs on containers.

most popular alternatives to Docker for containerization and container runtime workflows:

Podman
containerd
CRI-O

🎯 Quick Recap

Concept	Meaning
Container	Isolated runtime
Docker Image	Blueprint/template
Dockerfile	Build instructions
Container	Running image instance
Volume	Persistent storage
Network	Container communication

Day 5 — Bash Scripting for Automation

Rahul Joshi — Sat, 16 May 2026 10:36:53 +0000

Modern infrastructure runs on automation.

Whether you're a:

DevOps Engineer
Linux Administrator
Cloud Engineer
Cybersecurity Professional
Backend Developer

You will eventually write Bash scripts.

From automating backups to deploying servers, monitoring systems, managing logs, and running CI/CD pipelines — Bash is everywhere.

If Linux is the operating system of the internet, then Bash is its automation language.

🔗 Resources

GitHub Repo:
https://github.com/17J/30-Days-Cloud-DevSecOps-Journey
Command Sheet:
https://bash-command-sheets-k51c.vercel.app/
Linux Cron Job Scheduler:
https://crontab.guru/

many beginners get confused between:

Bash
SH
ZSH
Fish
Dash
Yum
Apt
DNF

So before learning Bash scripting, let’s first understand the Linux shell ecosystem.

🧠 Understanding Linux Shells & Package Managers

Linux has multiple shells.

A shell is simply a command interpreter that lets users communicate with the operating system.

Think of it like:

User → Shell → Linux Kernel → Hardware

🐚 Popular Linux Shells

📦 Linux Package Managers

Package managers install software.

Different Linux distributions use different package managers.

Distribution	Package Manager	Example
Ubuntu	APT	`apt install nginx`
Debian	APT	`apt update`
CentOS 7	YUM	`yum install docker`
RHEL	YUM/DNF	`dnf install git`
Fedora	DNF	`dnf update`
Arch Linux	Pacman	`pacman -S nginx`
Alpine Linux	APK	`apk add curl`

🚀 What is Bash?

Bash stands for:

Bourne Again SHell

It is the default shell for most Linux distributions.

A shell is simply a program that allows users to interact with the operating system.

Example:

pwd
ls
mkdir project

These commands are executed through the shell.

🧠 What is Bash Scripting?

A Bash script is a file containing Linux commands executed sequentially.

Instead of manually typing commands repeatedly, you automate them inside a script.

Example:

#!/bin/bash

echo "Hello Rahul"
date
uptime

Save as:

hello.sh

Make executable:

chmod +x hello.sh

Run:

./hello.sh

⚡ Why Bash Automation Matters

Without automation:

❌ Manual server setup
❌ Repetitive deployments
❌ Manual backups
❌ Human errors
❌ Slow operations

With Bash automation:

✅ Faster workflows
✅ Repeatable processes
✅ Infrastructure consistency
✅ Reduced human mistakes
✅ Better productivity

📂 Bash Script Structure

Basic structure:

#!/bin/bash

# Comments start with #

echo "Starting Script"

# Commands here

🔥 Variables in Bash

Variables store data.

✅ Creating Variables

name="Rahul"
age=22
city="Delhi"

Access variables using $.

echo $name
echo $age

⚠️ Important Rule

No spaces around =.

❌ Wrong:

name = "Rahul"

✅ Correct:

name="Rahul"

🧾 User Input

Take input dynamically.

#!/bin/bash

echo "Enter your name:"
read name

echo "Welcome $name"

📌 Command Line Arguments

Arguments passed while running scripts.

#!/bin/bash

echo "First argument: $1"
echo "Second argument: $2"

Run:

./script.sh Rahul Linux

Output:

First argument: Rahul
Second argument: Linux

🔍 Conditional Statements

Conditions allow decision-making.

✅ If Statement

#!/bin/bash

age=20

if [ $age -ge 18 ]
then
    echo "Adult"
fi

✅ If-Else

#!/bin/bash

num=5

if [ $num -gt 10 ]
then
    echo "Greater than 10"
else
    echo "Less than or equal to 10"
fi

✅ If-Elif-Else

#!/bin/bash

marks=75

if [ $marks -ge 90 ]
then
    echo "Grade A"
elif [ $marks -ge 70 ]
then
    echo "Grade B"
else
    echo "Grade C"
fi

🧠 Comparison Operators

Operator	Meaning
`-eq`	Equal
`-ne`	Not equal
`-gt`	Greater than
`-lt`	Less than
`-ge`	Greater or equal
`-le`	Less or equal

🔁 Loops in Bash

Loops repeat tasks automatically.

✅ For Loop

#!/bin/bash

for i in 1 2 3 4 5
do
    echo "Number: $i"
done

✅ Range Loop

for i in {1..10}
do
    echo $i
done

✅ While Loop

#!/bin/bash

count=1

while [ $count -le 5 ]
do
    echo $count
    ((count++))
done

✅ Infinite Loop

while true
do
    echo "Running..."
    sleep 2
done

🔨 Functions in Bash

Functions help organize reusable code.

#!/bin/bash

greet() {
    echo "Hello $1"
}

greet Rahul

📦 Arrays in Bash

#!/bin/bash

fruits=("apple" "banana" "mango")

echo ${fruits[0]}
echo ${fruits[1]}

Loop through array:

for fruit in "${fruits[@]}"
do
    echo $fruit
done

📁 File Operations

✅ Check if File Exists

#!/bin/bash

if [ -f test.txt ]
then
    echo "File exists"
else
    echo "File not found"
fi

✅ Create File

touch file.txt

✅ Append to File

echo "New Log Entry" >> logs.txt

⚙️ Process Automation

✅ Kill Process

pkill nginx

✅ Restart Service

systemctl restart nginx

✅ Check Service Status

systemctl status docker

🕒 Cron Jobs for Scheduling

Cron automates scripts at scheduled times.

Open cron:

crontab -e

✅ Run Every Day at Midnight

0 0 * * * /home/ubuntu/backup.sh

✅ Run Every 5 Minutes

*/5 * * * * /home/ubuntu/monitor.sh

🚀 Real-World Automation Scripts

Now the fun begins.

🔥 1️⃣ Automated Backup Script

#!/bin/bash

SOURCE="/home/ubuntu/data"
DEST="/backup"

DATE=$(date +%Y-%m-%d)

tar -czf $DEST/backup-$DATE.tar.gz $SOURCE

echo "Backup completed"

What it does:

✅ Compresses files
✅ Creates timestamp backup
✅ Automates backup process

🔥 2️⃣ Disk Usage Monitoring Script

#!/bin/bash

THRESHOLD=80

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

if [ $USAGE -gt $THRESHOLD ]
then
    echo "Disk usage exceeded threshold!"
else
    echo "Disk usage normal"
fi

Useful for:

Servers
Cloud VMs
Production systems

🔥 3️⃣ Website Monitoring Script

#!/bin/bash

URL="https://example.com"

STATUS=$(curl -o /dev/null -s -w "%{http_code}" $URL)

if [ $STATUS -eq 200 ]
then
    echo "Website is UP"
else
    echo "Website is DOWN"
fi

🔥 4️⃣ Auto Deployment Script

#!/bin/bash

echo "Pulling latest code..."

git pull origin main

echo "Installing dependencies..."

npm install

echo "Restarting application..."

pm2 restart app

Used heavily in:

DevOps
CI/CD
Production deployments

🔥 5️⃣ Log Cleanup Script

#!/bin/bash

find /var/log -type f -name "*.log" -mtime +7 -delete

echo "Old logs deleted"

Deletes logs older than 7 days.

🛡️ Error Handling in Bash

Always validate failures.

#!/bin/bash

mkdir test

if [ $? -eq 0 ]
then
    echo "Directory created"
else
    echo "Failed"
fi

$? stores previous command status.

0 = success
Non-zero = failure

📌 Exit Codes

exit 0

Success.

exit 1

Failure.

🧪 Debugging Bash Scripts

✅ Run in Debug Mode

bash -x script.sh

Shows command execution step-by-step.

✅ Strict Mode (Highly Recommended)

#!/bin/bash

set -euo pipefail

This helps catch:

Undefined variables
Failed commands
Pipeline failures

⚡ Bash Automation in DevOps

Bash is heavily used in:

Area	Usage
CI/CD	Build automation
Kubernetes	Cluster scripts
Docker	Container automation
AWS	EC2 setup scripts
Monitoring	Health checks
Security	Log scanning
Linux	System administration

🔐 Security Best Practices

Never write insecure scripts.

❌ Avoid Hardcoding Passwords

Bad:

password="admin123"

Better:

read -s password

✅ Quote Variables

Bad:

rm -rf $dir

Good:

rm -rf "$dir"

✅ Validate Inputs

Always sanitize user input.

📚 Important Bash Commands Every Engineer Should Know

Command	Purpose
`grep`	Search text
`awk`	Text processing
`sed`	Stream editing
`cut`	Extract columns
`find`	Search files
`xargs`	Command chaining
`curl`	API requests
`tar`	Archive files
`cron`	Scheduling
`systemctl`	Manage services

🚀 Bash vs Python for Automation

Bash	Python
Best for Linux automation	Best for complex logic
Fast scripting	Better readability
Native shell access	Huge libraries
Lightweight	Cross-platform

Most DevOps engineers use both.

🎯 Best Practices for Bash Scripting

✅ Use meaningful variable names
✅ Add comments
✅ Use functions
✅ Handle errors properly
✅ Use strict mode
✅ Keep scripts modular
✅ Log important actions
✅ Test before production

🧠 Final Thoughts

Bash scripting is one of the most valuable skills in Linux, DevOps, Cloud, and Cybersecurity.

The engineers who automate repetitive tasks become exponentially more productive.

Start small:

Automate backups
Monitor servers
Deploy applications
Clean logs
Schedule tasks

Over time, Bash becomes your operational superpower.

Day 4 — Git & GitHub Fundamentals

Rahul Joshi — Fri, 15 May 2026 06:36:44 +0000

Modern software development is impossible without version control. Whether you're building applications alone, working in a startup, contributing to open source, or managing enterprise infrastructure — Git and GitHub are at the center of everything.

From tracking code changes to handling production deployments, Git powers modern engineering workflows.

In this guide, we’ll deeply cover:

What Git actually is
How Git works internally
Git basics
Branching strategies
Pull Requests
Merge conflicts
Git workflows
Essential Git commands
Best practices used by professional teams

🔗 Resources

GitHub Repo:
https://github.com/17J/30-Days-Cloud-DevSecOps-Journey
Command Sheet:
https://git-command-sheet-sigma.vercel.app/

🌍 What is Git?

Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005.

Git helps developers:

Track changes in code
Collaborate safely
Maintain project history
Revert mistakes
Manage releases
Work on multiple features simultaneously

🧠 Why Git Was Created

Before Git, developers mainly used centralized systems like:

These systems had problems:

Slow performance
Central server dependency
Difficult branching
Risk of losing history

Git solved these issues by making every developer’s machine a complete copy of the repository.

That means:

Faster operations
Offline work
Safer collaboration
Better branching support

🔥 What Makes Git Powerful?

Feature	Why It Matters
Distributed architecture	Every developer has full repository history
Fast branching	Lightweight feature development
Snapshots	Tracks repository states efficiently
Data integrity	Uses SHA hashing
Collaboration	Multiple developers work safely

🌐 What is GitHub?

GitHub is a cloud-based platform that hosts Git repositories.

GitHub adds:

Remote repository hosting
Collaboration tools
Pull Requests
CI/CD integration
Code review systems
Security scanning
Issue tracking
Open-source collaboration

Think of it like this:

Tool	Purpose
Git	Version control engine
GitHub	Collaboration platform

⚙️ Understanding How Git Works Internally

Many beginners struggle here, but once you understand Git’s internal workflow, everything becomes easier.

Git has three main areas:

1️⃣ Working Directory

This is your actual project folder.

Example:

app.js
package.json
README.md

You edit files here.

2️⃣ Staging Area (Index)

This is Git’s preparation area.

You choose which changes should go into the next commit.

Example:

git add app.js

Now app.js is staged.

3️⃣ Repository (.git)

This stores:

Commit history
Branches
Metadata
References

This is Git’s database.

📦 Git Repository Structure

When you initialize Git:

git init

Git creates:

.git/

Inside .git:

Objects
References
Commit history
Configuration
Branch metadata

⚠️ Never manually modify .git.

🚀 Git Basics

📁 Initializing a Repository

git init

This turns your project into a Git repository.

📥 Cloning a Repository

git clone https://github.com/user/project.git

This downloads:

Files
Commit history
Branches
Remote configuration

📊 Checking Repository Status

git status

Shows:

Modified files
Staged changes
Untracked files

This command becomes your best friend.

➕ Staging Changes

Stage everything:

git add .

Stage a single file:

git add server.js

💾 Creating Commits

git commit -m "Added authentication middleware"

A commit is:

A snapshot
A checkpoint
A historical record

🧾 Good Commit Messages

❌ Bad:

git commit -m "fix"

✅ Good:

git commit -m "Fixed JWT token expiration handling"

Professional teams use:

Clear descriptions
Small commits
Atomic changes

🌿 Understanding Branches

Branches are one of Git’s biggest strengths.

A branch is simply a movable pointer to commits.

🏗️ Why Branches Matter

Without branches:

Everyone edits the same code
Features collide
Production becomes unstable

Branches solve this.

🔹 Creating Branches

git branch feature-login

Switch to branch:

git checkout feature-login

Modern shortcut:

git checkout -b feature-login

🔍 Viewing Branches

git branch

Current branch shows:

* main

🔀 Merging Branches

Merge feature into main:

git checkout main
git merge feature-login

Git combines histories.

⚠️ Merge Conflicts

Conflicts happen when:

Two developers edit the same lines
Git cannot automatically decide

Example conflict:

<<<<<<< HEAD
console.log("Old Code");
=======
console.log("New Code");
>>>>>>> feature-login

You must manually resolve it.

🌳 Branching Strategies

1️⃣ Feature Branch Workflow

Each feature gets a separate branch.

Example:

feature-payment
feature-auth
feature-dashboard

Flow

Create branch
Develop feature
Open Pull Request
Review
Merge

Advantages

Cleaner history
Safer development
Easy rollback

Most startups use this.

2️⃣ Git Flow

One of the most famous workflows.

Popularized by Vincent Driessen.

Git Flow Branches

Branch	Purpose
`main`	Production-ready
`develop`	Integration branch
`feature/*`	New features
`release/*`	Release preparation
`hotfix/*`	Emergency fixes

Git Flow Lifecycle

🔹 Feature Development

git checkout develop
git checkout -b feature-auth

🔹 Release Creation

git checkout -b release-v1.0

🔹 Hotfix Production Bugs

git checkout main
git checkout -b hotfix-login

✅ Advantages

Organized releases
Stable production
Enterprise friendly

❌ Disadvantages

Complex workflow
Too many branches
Slower deployments

3️⃣ Trunk-Based Development

Used heavily in:

DevOps teams
CI/CD environments
Cloud-native engineering

Core idea:

Small commits
Frequent merges
Short-lived branches

Main branch = trunk.

✅ Benefits

Faster deployments
Smaller conflicts
Continuous integration friendly

Popular in:

Google
Netflix
Meta

🔄 Pull Requests (PRs)

A Pull Request is a proposal to merge code changes.

PRs are central to modern collaboration.

🧩 Pull Request Lifecycle

Step 1 — Create Branch

git checkout -b feature-auth

Step 2 — Push Branch

git push origin feature-auth

Step 3 — Open PR on GitHub

GitHub compares:

Source branch
Target branch

Step 4 — Code Review

Teams review:

Logic
Security
Readability
Performance

Step 5 — CI/CD Runs

Automated checks:

Tests
Linting
Security scans

Step 6 — Merge PR

Once approved:

Squash merge
Rebase merge
Standard merge

🔐 Why Pull Requests Matter

PRs improve:

Code quality
Security
Team collaboration
Knowledge sharing

They act like a checkpoint before production.

🧠 Types of Git Merges

🔹 Fast Forward Merge

Simple linear merge.

Occurs when no divergence exists.

🔹 Three-Way Merge

Git creates a merge commit.

Most common in teams.

🔹 Squash Merge

Combines all commits into one.

Creates cleaner history.

🔹 Rebase

Moves commits on top of the latest branch.

Example:

git rebase main

Benefits

Linear history
Cleaner logs

Risk

Can rewrite history

⚙️ Common Git Workflows

1️⃣ Centralized Workflow

Everyone pushes to the same branch.

Simple but risky.

Best for:

Small teams
Learning

2️⃣ Feature Branch Workflow

Separate branches for features.

Most commonly used workflow today.

3️⃣ Forking Workflow

Mostly used in open source.

Flow

Fork repository
Clone fork
Create branch
Push changes
Open PR to original repo

Used heavily on GitHub.

🚨 Common Git Problems

❌ Detached HEAD State

Occurs when checking out commits directly.

Example:

git checkout 93f4c2

You are no longer on a branch.

❌ Force Push Problems

git push --force

Dangerous because:

Rewrites history
Can delete teammates’ work

Use carefully.

❌ Huge Commits

Huge commits are bad because:

Hard to review
Hard to debug
Hard to revert

🧹 Git Best Practices

✅ Commit Frequently

Small commits = easier debugging.

✅ Use Meaningful Branch Names

✅ Good:

feature-payment-api
bugfix-auth-timeout

❌ Bad:

test123
newbranch

✅ Protect Main Branch

Never directly push production-breaking code.

✅ Pull Before Push

git pull origin main

Avoids conflicts.

✅ Use `.gitignore`

Prevent sensitive or unnecessary files.

Example:

node_modules/
.env
dist/
coverage/

🔐 Git in DevOps & CI/CD

Git is deeply integrated into:

CI/CD pipelines
Infrastructure as Code
Kubernetes deployments
DevSecOps automation

Modern pipelines trigger automatically when:

Code is pushed
PRs are merged
Releases are tagged

Popular integrations:

GitHub Actions
GitLab CI/CD
Jenkins
CircleCI

🚀 Final Thoughts

Git is more than just commands.

It’s a system that enables:

Safe collaboration
Scalable development
Reliable deployments
Modern DevOps practices

Once you truly understand:

Branching
Commits
PRs
Workflows
Collaboration strategies

…you stop being just a coder and start working like a professional software engineer.

The best way to master Git is:

Use it daily
Break things
Resolve conflicts
Work on real projects

Because every professional developer spends a huge part of their career inside Git.

Day 3 — Networking Fundamentals

Rahul Joshi — Thu, 14 May 2026 04:57:58 +0000

🌐 Networking Fundamentals for DevOps & DevSecOps Engineers

If you’re entering the world of DevOps, Cloud, Cybersecurity, or DevSecOps, there’s one thing you simply cannot escape:

👉 Networking.

You can automate Kubernetes deployments, build CI/CD pipelines, scan containers, or secure APIs all day long…
But if you don’t understand how systems communicate over a network, eventually things will break — and debugging becomes pure pain.

And trust me…

Every DevOps engineer has faced moments like:

“Why is the service unreachable?”
“Why is DNS failing?”
“Why is port 443 blocked?”
“Why is the pod timing out?”
“Why does curl work but browser doesn’t?”
“Why is UDP packet loss happening?”

At that moment, networking fundamentals stop being “theory” and become survival skills.

Github Repo: https://github.com/17J/30-Days-Cloud-DevSecOps-Journey

🚀 Why Networking Matters in Modern Tech

Today everything is connected:

Cloud servers
Kubernetes clusters
APIs
Microservices
Databases
CI/CD runners
Containers
Security tools
VPNs
CDNs

Even your Git push travels through multiple networking layers before reaching GitHub.

Understanding networking helps you:

✅ Debug faster
✅ Secure systems properly
✅ Understand cloud architecture
✅ Configure firewalls
✅ Work with Kubernetes confidently
✅ Handle load balancers & reverse proxies
✅ Understand attacks like DDoS, MITM, spoofing, scanning, etc.

🧠 What is Networking?

In simple words:

Networking is the communication between devices.

When two systems exchange data, they follow a set of rules called protocols.

Example:

Your browser requests a website
DNS converts domain → IP
TCP establishes connection
HTTPS encrypts communication
Server sends response

All this happens in milliseconds.

Crazy, right?

🏢 OSI Model — The Foundation of Networking

The OSI Model (Open Systems Interconnection) is a conceptual framework used to understand how data travels across a network.

It has 7 layers.

Think of it like delivering a package through multiple departments.

📚 The 7 Layers of OSI Model

🔍 Understanding Each Layer

7️⃣ Application Layer

This is where users interact.

Protocols:

HTTP
HTTPS
DNS
FTP
SMTP

Example:
When you open YouTube in browser.

6️⃣ Presentation Layer

Handles:

Encryption
Compression
Data formatting

Examples:

SSL/TLS encryption
JPEG/PNG formatting

This layer makes HTTPS secure.

5️⃣ Session Layer

Responsible for:

Opening sessions
Maintaining sessions
Closing sessions

Example:
Keeping your login session active.

4️⃣ Transport Layer

This is where TCP and UDP live.

Responsibilities:

Data delivery
Error checking
Packet sequencing

Protocols:

This layer is extremely important in DevOps and Security.

3️⃣ Network Layer

This layer handles:

IP addressing
Routing

Protocol:

IP (Internet Protocol)

Routers operate here.

2️⃣ Data Link Layer

Handles:

MAC addresses
Local network communication

Switches operate here.

1️⃣ Physical Layer

The actual hardware:

Cables
Fiber optics
Wi-Fi signals

This is the physical transmission layer.

⚡ TCP/IP Model — The Real Internet Model

Now here’s the interesting part:

The internet doesn’t actually use the full OSI model directly.

It mainly follows the TCP/IP Model.

📚 TCP/IP Layers

TCP/IP Layer	OSI Equivalent
Application	OSI 5,6,7
Transport	OSI 4
Internet	OSI 3
Network Access	OSI 1,2

🤔 OSI vs TCP/IP

OSI	TCP/IP
Theoretical model	Practical model
7 layers	4 layers
Used for understanding	Used in real internet
More detailed	More implementation-focused

🌍 What is an IP Address?

Every device connected to a network needs an identity.

That identity is called an IP Address.

Example:

192.168.1.1

Think of IP like a house address for devices.

Without IP addresses:
❌ Internet communication is impossible.

🧩 Types of IP Addresses

IPv4

Example:

192.168.0.1

32-bit addressing.

Limited addresses.

IPv6

Example:

2001:0db8:85a3::8a2e:0370:7334

128-bit addressing.

Created because IPv4 addresses were running out.

🏠 Public vs Private IP

Type	Usage
Public IP	Internet-facing
Private IP	Internal networks

Private ranges:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

🌐 What is DNS?

DNS = Domain Name System

DNS converts human-friendly names into IP addresses.

Example:

google.com → 142.250.x.x

Because humans remember names better than numbers.

🔥 DNS Flow

🛠 Common DNS Record Types

Record	Purpose
A	Maps domain → IPv4
AAAA	Maps domain → IPv6
CNAME	Alias
MX	Mail server
TXT	Verification/security

🌍 What is HTTP?

HTTP = HyperText Transfer Protocol

Used for communication between:

Browser
Server

HTTP is stateless.

📦 Example HTTP Request

GET /index.html HTTP/1.1
Host: example.com

🔒 What is HTTPS?

HTTPS = HTTP + SSL/TLS encryption.

This secures:
✅ Passwords
✅ Payments
✅ Tokens
✅ Sensitive data

Without HTTPS:
Attackers can sniff traffic.

🔥 HTTP vs HTTPS

HTTP	HTTPS
Unencrypted	Encrypted
Port 80	Port 443
Insecure	Secure

🚪 What are Ports?

Ports are logical communication endpoints.

Think of IP as:
🏢 Building Address

And ports as:
🚪 Room Numbers

📚 Common Ports

Port	Service
22	SSH
53	DNS
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
27017	MongoDB

⚔️ TCP vs UDP

This is one of the most important networking concepts.

📦 TCP (Transmission Control Protocol)

TCP is:
✅ Reliable
✅ Connection-oriented
✅ Ordered matters
✅ Error-checked

Used when data integrity matters.

Examples:

HTTPS
SSH
FTP
Database communication

🚀 UDP (User Datagram Protocol)

UDP is:
✅ Fast
✅ Lightweight
❌ No guarantee of delivery

Used when speed matters more than perfection.

Examples:

Gaming
Live streaming
VoIP
DNS queries

🔥 TCP vs UDP Comparison

Feature	TCP	UDP
Reliable	✅	❌
Fast	❌	✅
Ordered	✅	❌
Connection	Yes	No
Error Recovery	Yes	No

🔥 3-Way Handshake

Before TCP communication begins, client and server establish connection using the famous:

This ensures both systems are ready.

📡 Step 1 — SYN

Client sends:

SYN

Meaning:

“Hey server, can we communicate?”

📡 Step 2 — SYN-ACK

Server replies:

SYN-ACK

Meaning:

“Yes, I’m ready.”

📡 Step 3 — ACK

Client sends:

ACK

Meaning:

“Perfect, let’s start.”

Connection established ✅

After this:
Actual data transfer begins.

🔥 Why 3-Way Handshake Matters in Security

Understanding handshake helps detect:

SYN Flood attacks
Connection hijacking
Network scanning
Reconnaissance

This is heavily used in:

SOC operations
Threat detection
DevSecOps monitoring

☁️ Networking in Cloud & Kubernetes

Now comes the modern world.

In Kubernetes and Cloud:

Networking becomes even more important.

You deal with:

Pod networking
Service discovery
Ingress controllers
Load balancers
DNS resolution
Service mesh
Internal routing

One small DNS issue can break entire production systems.

🔐 Networking + DevSecOps

DevSecOps engineers constantly work with:

WAFs
Firewalls
Reverse proxies
TLS certificates
Network policies
VPNs
Zero Trust networking

Without networking knowledge:
Security becomes guesswork.

🧪 Essential Networking Commands Every Engineer Should Know

ping

Checks connectivity.

ping google.com

nslookup

Checks DNS resolution.

nslookup google.com

curl

Tests HTTP requests.

curl https://example.com

traceroute

Shows network path.

traceroute google.com

netstat

Shows active connections.

netstat -tulnp

ss

Modern replacement for netstat.

ss -tulnp

🧠 Real Industry Truth

A lot of engineers jump directly into:

Kubernetes
Docker
Cloud
Terraform
Security tools

But skip networking fundamentals.

Then later:
everything becomes confusing.

The best DevOps and Security engineers usually have:
✅ Strong Linux basics
✅ Strong networking understanding
✅ Strong debugging mindset

Because infrastructure is ultimately just:

Systems communicating with systems.

🎯 Final Thoughts

Networking is not optional anymore.

Whether you're:

DevOps Engineer
Cloud Engineer
Backend Developer
DevSecOps Engineer
Security Researcher
SRE

You must understand:

IP
DNS
HTTP/HTTPS
TCP/UDP
Ports
OSI Model
TCP/IP Model
3-Way Handshake

These concepts are the backbone of modern infrastructure.

Once networking clicks in your brain…

Cloud starts making sense.
Kubernetes starts making sense.
Security starts making sense.
Even debugging becomes easier.

And honestly?

Most “complex production issues” eventually come down to:

Networking somewhere broke.

10 DevSecOps Engineer Habits That Separate Good From Great

Rahul Joshi — Wed, 13 May 2026 10:33:52 +0000

Every company today says they want DevSecOps.
But very few teams actually build a security-first engineering culture.

Why?

Because tools alone don’t create great DevSecOps engineers.

You can install scanners, buy expensive security platforms, and automate CI/CD pipelines all day long… but the engineers who truly stand out are the ones who build powerful habits behind the scenes.

And honestly?

The difference between a good DevSecOps engineer and a great one is usually not intelligence.
It’s consistency.

So if you're trying to grow from:

“the person who runs scans” to
“the engineer teams trust with production security”

then these habits matter more than any certification.

Let’s dive in 👇

🛡️ 1️⃣ They Shift Security Left — Automatically

Good engineers run security scans.

Great engineers make security invisible inside the developer workflow.

They don’t wait for:

staging deployments
QA testing
production incidents

Instead, they integrate security into:

Git hooks
Pull Requests
CI/CD pipelines
Container builds
IaC deployments

Because the earlier you catch a problem, the cheaper it is to fix.

A great DevSecOps engineer thinks:

“How do I stop insecure code from ever reaching production?”

Not:

“How do I detect it later?”

⚡ 2️⃣ They Treat Automation Like Oxygen

If something repetitive exists… they automate it.

Great DevSecOps engineers hate manual processes because:

humans forget things
humans skip steps
humans get tired

Automation creates consistency.

That means automating:

secret scanning
dependency checks
image scanning
policy enforcement
patch management
compliance reporting

The goal is simple:

Reduce human error as much as possible.

And in modern cloud-native environments, that habit becomes priceless.

🔍 3️⃣ They Read Logs Before Dashboards

Dashboards are beautiful.

Logs tell the truth.

Good engineers rely only on monitoring tools.

Great engineers investigate:

raw logs
Kubernetes events
authentication failures
container crashes
unusual traffic patterns
runtime anomalies

Because security incidents rarely announce themselves clearly.

Sometimes the first sign of compromise is:

a strange API request
a suspicious outbound connection
an unexpected container restart

The best DevSecOps engineers develop an investigator mindset.

☁️ 4️⃣ They Understand Cloud Before Security Tools

One of the biggest mistakes in DevSecOps is learning tools before infrastructure.

A great engineer deeply understands:

networking
IAM
Kubernetes
containers
Linux internals
cloud architecture

Because if you don’t understand the system…

you can’t secure it properly.

A scanner might tell you:

“Port exposed.”

But experience tells you:

“This network design itself is dangerous.”

That difference changes careers.

🐳 5️⃣ They Think in Attack Paths, Not Alerts

Beginners focus on alerts.

Experts focus on attack chains.

Great DevSecOps engineers constantly ask:

“If this secret leaks… what happens next?”
“If this pod gets compromised… what can it access?”
“Can lateral movement happen here?”
“What is the blast radius?”

This mindset separates checkbox security from real security engineering.

Because attackers don’t exploit one thing.

They chain weaknesses together.

🔐 6️⃣ They Protect Secrets Like Production Data

API keys. Tokens. SSH keys. Cloud credentials.

These are gold mines for attackers.

Great DevSecOps engineers:

rotate secrets regularly
avoid hardcoded credentials
use secret managers
enforce least privilege access
monitor secret exposure continuously

And most importantly…

they assume secrets will eventually leak.

So they design systems that minimize damage when it happens.

That mindset is mature security engineering.

📦 7️⃣ They Scan Containers — But Also Understand Them

Many engineers run container scans without understanding containers themselves.

Great engineers know:

how container layers work
image minimization strategies
runtime isolation
capabilities
namespaces
root vs non-root execution

Because real container security is not:

“Run scanner and pray.”

It’s understanding:

what’s inside the image
how it behaves at runtime
what permissions it has
how attackers may escape it

That deeper knowledge matters massively in Kubernetes environments.

📉 8️⃣ They Reduce Noise Ruthlessly

One of the hardest parts of DevSecOps isn’t finding alerts.

It’s surviving alert fatigue.

Great engineers continuously tune:

SAST rules
DAST policies
SIEM alerts
runtime detections
vulnerability thresholds

Because if everything is critical…

nothing is critical.

Security systems should help developers focus — not overwhelm them.

The best DevSecOps engineers know how to balance:

security
developer productivity
operational reality

That balance is incredibly valuable.

🤝 9️⃣ They Build Relationships With Developers

This one changes everything.

Good DevSecOps engineers enforce policies.

Great DevSecOps engineers enable developers.

They don’t become “the security blocker.”

Instead, they:

explain risks clearly
help fix issues
simplify secure workflows
educate teams
create reusable templates

Because DevSecOps is not only about technology.

It’s about culture.

And developers listen to engineers who help them succeed.

📚 🔟 They Never Stop Learning

The security world changes ridiculously fast.

New:

CVEs
cloud attack vectors
supply chain risks
AI threats
Kubernetes exploits
ransomware techniques

appear constantly.

Great DevSecOps engineers stay curious.

They:

read incident reports
study breaches
experiment in labs
break things safely
learn offensive security concepts
follow cloud-native trends

And honestly…

this habit alone may be the biggest differentiator of all.

Because the engineers who stop learning eventually become outdated.

🧠 Final Thoughts

DevSecOps isn’t just:

running scanners
writing YAML
configuring pipelines

The great engineers think differently.

They:

automate relentlessly
understand systems deeply
anticipate attack paths
reduce friction
learn continuously
build security into culture

That’s what separates someone who uses DevSecOps tools…

from someone who truly engineers secure systems.

And in 2026, companies desperately need the second type.

💬 What About You?

Which DevSecOps habit do you think matters the most?

Automation?
Cloud knowledge?
Security mindset?
Communication?
Continuous learning?

Drop your thoughts below 👇

Day 2 — Linux Fundamentals

Rahul Joshi — Wed, 13 May 2026 05:07:30 +0000

🐧 Linux Fundamentals Every DevSecOps & Cloud Engineer Should Know

There’s a funny truth in tech:

You can spend years learning Kubernetes, Docker, Terraform, CI/CD, and cloud platforms…
but sooner or later, everything still comes back to one thing:

Linux.

Servers run on Linux.
Containers run on Linux.
Most cloud systems rely on Linux.
Even modern DevSecOps pipelines silently depend on Linux permissions, users, file systems, and shell commands working correctly.

And yet many beginners jump directly into “advanced DevOps” without understanding the basics.

That’s like trying to fly a fighter jet before learning how steering works.

So in this blog, let’s break down Linux Fundamentals in a practical, beginner-friendly, and industry-focused way.

Github Repo: https://github.com/17J/30-Days-Cloud-DevSecOps-Journey
Command Sheet: https://bash-command-sheets-k51c.vercel.app/

🚀 Why Linux Matters So Much

If you enter any of these fields:

DevOps
Cloud Engineering
Cybersecurity
Site Reliability Engineering (SRE)
Backend Development
Platform Engineering
Kubernetes Administration

…Linux becomes unavoidable.

Most production servers worldwide run Linux because it is:

Stable
Lightweight
Secure
Open-source
Highly customizable
Automation friendly

That’s why companies like:

Google
Amazon
Netflix
Meta

all heavily rely on Linux infrastructure.

🖥️ Understanding Linux Basics

Linux is an operating system kernel that powers many distributions (distros) like:

Ubuntu
Debian
CentOS
Fedora
Arch Linux

Think of Linux as the “engine” and distributions as different car models built around it.

In DevOps, the most commonly used distro is usually:

Ubuntu Server
Debian
RHEL / Rocky Linux

📂 Linux File System Explained

One of the first things beginners notice:

Linux does NOT use drives like:

C:\
D:\

Instead, Linux starts from a single root directory:

Everything exists under this root.

📁 Important Linux Directories

Directory	Purpose
`/`	Root directory
`/home`	User files
`/etc`	Configuration files
`/var`	Logs and variable data
`/bin`	Essential commands
`/tmp`	Temporary files
`/root`	Root user home
`/usr`	Applications and utilities

Example:

/home/rahul/projects

means:

home directory
inside it → user rahul
inside it → folder projects

⚡ Essential Linux Commands

📍 1. Check Current Directory

pwd

Output:

/home/ubuntu

This tells you where you currently are.

📍 2. List Files

ls

Detailed list:

ls -la

This shows:

hidden files
permissions
ownership
timestamps

📍 3. Change Directory

cd /var/log

Go back:

cd ..

Go to home:

cd ~

📍 4. Create Files & Folders

Create folder:

mkdir devops

Create file:

touch notes.txt

📍 5. Copy, Move & Delete

Copy:

cp file.txt backup.txt

Move:

mv old.txt new.txt

Delete:

rm file.txt

Delete folder recursively:

rm -rf foldername

⚠️ Be careful with rm -rf.

One wrong command can destroy an entire server.

Yes… this has happened in real companies.

🔍 Viewing File Content

View file:

cat file.txt

Large files:

less file.txt

Real-time logs:

tail -f app.log

This is extremely common in DevOps troubleshooting.

🔐 Linux Permissions Explained

This is where Linux becomes VERY important for security.

Run:

ls -l

You may see:

-rwxr-xr--

Looks scary at first.

But it’s simple once broken down.

🧠 Permission Structure

Example:

-rwxr-xr--

Split it:

rwx | r-x | r--

These represent:

Section	Meaning
First	Owner permissions
Second	Group permissions
Third	Others permissions

📌 Permission Types

Symbol	Meaning
r	Read
w	Write
x	Execute

🔧 Changing Permissions

Give execute permission:

chmod +x script.sh

Specific permissions:

chmod 755 script.sh

🤔 What is 755?

Numbers represent permissions:

Number	Permission
7	rwx
5	r-x
5	r-x

So:

means:

Owner → full access
Group → read & execute
Others → read & execute

This is very common for scripts and applications.

👤 Users & Groups in Linux

Linux is a multi-user operating system.

That means multiple users can work on the same machine securely.

👥 Create a User

sudo adduser rahul

Set password and details.

👥 Create a Group

sudo groupadd developers

🔗 Add User to Group

sudo usermod -aG developers rahul

This is heavily used in:

DevOps teams
Shared servers
Kubernetes nodes
CI/CD runners

👑 The Root User

Linux has a superuser called:

root

Root can do EVERYTHING.

That’s why production systems usually avoid direct root access.

Instead, admins use:

sudo

Example:

sudo apt update

This temporarily gives admin privileges.

📦 Package Management

Linux installs software using package managers.

Ubuntu:

sudo apt install nginx

CentOS/RHEL:

sudo yum install nginx

sudo dnf install nginx

🌐 Real DevOps Connection

Here’s the reality:

When CI/CD pipelines fail…

You often debug Linux.

When containers crash…

You inspect Linux logs.

When Kubernetes breaks…

You SSH into Linux nodes.

When cloud servers slow down…

You monitor Linux processes.

Linux is not “optional knowledge” anymore.

It is the foundation layer of modern infrastructure.

🔥 Linux Skills That Make You Valuable

Companies LOVE engineers who can:

✅ Navigate servers confidently
✅ Debug issues quickly
✅ Understand permissions
✅ Manage users securely
✅ Read logs efficiently
✅ Automate shell tasks
✅ Work comfortably in terminal environments

Because these skills directly impact:

uptime
security
deployments
incident response
infrastructure stability

Some Examples

🔹 Create users & groups

adduser testuser

🔹 Change permissions

chmod 700 secret.txt

🔹 Explore logs

cd /var/log

🔹 Install software

sudo apt install nginx

🔹 Create shell scripts

#!/bin/bash
echo "Hello Linux"

💡 Final Thoughts

Most people try to skip Linux fundamentals because they look “basic.”

But experienced engineers know the truth:

The stronger your Linux foundation,
the easier DevOps, Cloud, Security, Docker, and Kubernetes become.

Linux is one of those skills that compounds over time.

At first, commands feel confusing.

Then one day, you realize you’re managing servers, automating deployments, debugging production issues, and writing shell scripts without even thinking.

That’s when Linux stops feeling like an operating system…

…and starts feeling like a superpower. 🚀

Day 1 — Introduction to DevOps & DevSecOps

Rahul Joshi — Tue, 12 May 2026 06:04:09 +0000

A few years ago, software teams had one major goal:

“Ship faster.”

Today?

The goal has changed to:

“Ship faster… without breaking security.”

And that single shift is exactly why the industry moved from DevOps to DevSecOps.

Modern applications are no longer simple.
A single deployment may include:

Containers
Kubernetes clusters
CI/CD pipelines
Cloud infrastructure
APIs
Open-source dependencies
AI integrations
Infrastructure as Code (IaC)

That means speed alone is not enough anymore.

Because if your pipeline deploys vulnerable code in seconds…
you’ve simply automated the breach.

So let’s break this down properly 👇

📂 GitHub Repository:
30 Days Cloud & DevSecOps Journey GitHub Repo

⚙️ What is DevOps?

DevOps is a combination of:

Development (Dev)
Operations (Ops)

It’s a culture and engineering practice focused on improving collaboration between developers and operations teams.

The main goal of DevOps is:

✅ Faster software delivery
✅ Automation
✅ Continuous Integration & Deployment
✅ Better reliability
✅ Reduced manual work

Before DevOps, development and operations teams often worked separately.

Developers would say:

“The code works on my machine.”

Operations teams would respond:

“Then why is production down?”

Classic problem 😅

DevOps solved this by introducing automation, collaboration, and shared ownership.

🔄 Core Principles of DevOps

1️⃣ Continuous Integration (CI)

Developers continuously merge code into a shared repository.

Every commit automatically triggers:

Builds
Tests
Validation checks

Tools commonly used:

GitHub Actions
GitLab CI/CD
Jenkins
CircleCI

2️⃣ Continuous Delivery / Deployment (CD)

Once code passes testing, it can automatically move into staging or production.

This reduces:

Human error
Delays
Deployment friction

3️⃣ Infrastructure as Code (IaC)

Infrastructure is managed using code instead of manual setup.

Examples:

HashiCorp Terraform
Red Hat Ansible

4️⃣ Monitoring & Observability

Teams continuously monitor systems for:

Performance
Errors
Downtime
Resource usage

Popular tools:

Datadog
Grafana Labs
New Relic

🔐 What is DevSecOps?

DevSecOps stands for:

Development + Security + Operations

It extends DevOps by integrating security into every stage of the software lifecycle.

Instead of security being checked after deployment, DevSecOps makes security part of the pipeline itself.

The philosophy becomes:

“Security is everyone’s responsibility.”

Not just the security team.

🧠 Traditional Security vs DevSecOps

Old security model:

Develop → Deploy → Security Team Checks Later

Modern DevSecOps model:

Develop → Scan → Test → Secure → Deploy → Monitor

That difference is massive.

Because vulnerabilities found late are:

❌ More expensive
❌ Harder to fix
❌ Riskier in production

⚡ Why DevSecOps Became Necessary

Software delivery became incredibly fast.

Teams now deploy:

Multiple times per day
Across cloud-native environments
Using automated pipelines

But attackers also evolved.

Modern threats include:

Supply chain attacks
Secret leaks
Vulnerable containers
Dependency poisoning
Misconfigured cloud infrastructure
CI/CD compromise

Without built-in security, fast delivery becomes dangerous delivery.

🛡️ What DevSecOps Adds to DevOps

1️⃣ Automated Security Scanning

Security checks run automatically inside pipelines.

Examples:

Secret scanning
Dependency scanning
Container scanning
Static code analysis
IaC security scanning

Popular tools include:

Snyk
SonarSource
Aqua Security
Checkmarx

2️⃣ Shift-Left Security

“Shift Left” means moving security earlier into development.

Instead of finding vulnerabilities in production:

✅ Detect them during coding
✅ Detect them during pull requests
✅ Detect them during CI builds

This dramatically reduces remediation cost.

3️⃣ Secure CI/CD Pipelines

Pipelines themselves are now protected.

Because attackers increasingly target:

Build systems
CI runners
Deployment tokens
GitHub Actions workflows
Artifact registries

⚔️ DevOps vs DevSecOps

Feature	DevOps	DevSecOps
Main Focus	Speed & Automation	Speed + Security + Automation
Security Timing	Often later	Integrated early
Responsibility	Dev + Ops	Dev + Sec + Ops
Pipeline Checks	Build & Test	Build + Test + Security
Goal	Faster delivery	Secure faster delivery

🔥 Why Security Matters in CI/CD

This is where things get serious.

Your CI/CD pipeline is basically the “factory” producing software.

If attackers compromise the factory…

they compromise everything.

🚨 Real Risks Inside CI/CD

Exposed Secrets

Hardcoded API keys or cloud credentials inside repositories.

This is still one of the most common breaches.

Vulnerable Dependencies

Developers install open-source packages daily.

One compromised dependency can infect the entire application.

This became widely discussed after supply chain attacks like:

SolarWinds cyberattack
Log4Shell

🐳 Insecure Containers

A container image may include:

Outdated libraries
Root privileges
Critical CVEs

Without scanning, vulnerable containers reach production easily.

☁️ Cloud Misconfigurations

Simple mistakes like:

Public S3 buckets
Open databases
Weak IAM permissions

can expose entire infrastructures.

🔄 Why Automation Matters

Manual security reviews cannot keep up with modern deployment speed.

A team deploying 50 times daily cannot rely on:

❌ Spreadsheets
❌ Manual approvals
❌ Occasional audits

Security must become automated.

That’s the heart of DevSecOps.

🧪 Typical DevSecOps CI/CD Pipeline

A modern secure pipeline often looks like this:

Developer Pushes Code
        ↓
CI Build Starts
        ↓
Static Code Analysis
        ↓
Dependency Scan
        ↓
Secret Scan
        ↓
Container Scan
        ↓
IaC Security Check
        ↓
Automated Testing
        ↓
Deployment
        ↓
Runtime Monitoring

Security exists at every layer.

📈 Benefits of DevSecOps

✅ Faster Vulnerability Detection

Issues are caught before production.

✅ Lower Breach Risk

Automated scanning reduces human oversight gaps.

✅ Better Compliance

Helps organizations align with:

SOC2
ISO 27001
PCI-DSS
HIPAA

✅ Improved Developer Awareness

Developers become more security-conscious over time.

🤖 AI Is Changing DevSecOps Too

AI-powered tools now help with:

Vulnerability prioritization
Threat detection
Misconfiguration analysis
Automated remediation suggestions

Modern platforms increasingly combine:

AI
Observability
Runtime security
Automated policy enforcement

into one ecosystem.

🧠 Final Thoughts

DevOps changed how software is delivered.

DevSecOps changed how software is protected.

And in today’s world, speed without security is a liability.

Because modern attackers don’t wait for yearly audits anymore.

They target:

Pipelines
Dependencies
Containers
Cloud infrastructure
Secrets
Automation systems

That’s why security inside CI/CD is no longer “optional.”

It’s part of the deployment process itself.

The companies succeeding in 2026 are not just the fastest.

They are the ones that can:

✅ Build fast
✅ Deploy fast
✅ Recover fast
✅ Stay secure while doing all of it

And that’s the real evolution from DevOps to DevSecOps.

🚀 30 Days Cloud & DevSecOps Journey

Rahul Joshi — Mon, 11 May 2026 12:47:46 +0000

The cloud world is evolving fast.
DevOps is no longer enough. Security is no longer optional.

That’s exactly why I’m starting this 30 Days Cloud & DevSecOps Journey — building publicly while learning cloud infrastructure, automation, Kubernetes, CI/CD, and security engineering.

For the next 30 days, I’ll be documenting everything on Dev.to 🚀

📂 GitHub Repository:
30 Days Cloud & DevSecOps Journey GitHub Repo

🎯 Why I’m Doing This

I wanted a structured path to learn:

Cloud Computing
AWS
Docker & Kubernetes
CI/CD Pipelines
DevSecOps
Infrastructure as Code
Monitoring & Observability
Security Automation

📚 What This Journey Covers

Over the next 30 days, I’ll be creating and building around:

☁️ Cloud & AWS

IAM
S3
VPC
EC2
Lambda
CloudWatch
Billing & Cost Optimization

🐳 Containers & Kubernetes

Docker
Dockerfiles
Kubernetes Fundamentals
EKS
Helm
Kubernetes Security

🔐 DevSecOps & Security

SAST
DAST
SCA
Container Security
Runtime Security
Secrets Management

⚙️ CI/CD & Automation

GitHub Actions
Secure Pipelines
Bash Scripting
Terraform

📊 Monitoring & Observability

Prometheus
Grafana
Logs & Alerts

🛠️ Tools I’ll Use

AWS
Docker
Kubernetes
Terraform
GitHub Actions
Snyk
SonarQube
OWASP ZAP
Trivy
Falco
Kyverno
HashiCorp Vault

🚀 End Goal

By the end of these 30 days:

Build secure CI/CD pipelines
Deploy cloud-native applications
Improve Kubernetes & AWS skills
Learn real-world DevSecOps practices
Become more confident in cloud security & automation

🔥 Let’s See Where This Goes

If you’re interested in Cloud, AWS, DevOps, or DevSecOps — feel free to join the journey 🚀

Day 1 drops tomorrow 👀

⚠️ Disclaimer

This journey is not enough to fully master DevSecOps in 30 days.

DevSecOps is a vast field that requires continuous learning, hands-on practice, real-world experience, and deep understanding of security, cloud, automation, and infrastructure.

This journey is simply a starting point to build strong fundamentals, improve consistency, and gain practical exposure to modern Cloud & DevSecOps workflows.

The goal is to learn step-by-step, build projects, and grow over time — not to become an expert overnight 🚀

🚨 I Secured My Compromised AWS Account : Here’s the Incident Response Playbook

Rahul Joshi — Tue, 05 May 2026 11:44:06 +0000

“It started with a small billing spike… and ended with an AWS Abuse Report.”

One morning, I noticed something unusual in my AWS billing dashboard.

At first glance, it didn’t look huge — around $20.
But something felt off.

⚠️ The Red Flag

When I checked deeper:

Most charges were from data transfer
Traffic originated from ap-south-1 (Mumbai)
Data was being sent to Middle East (Bahrain) region
And the scary part…

👉 This activity happened at night — when I wasn’t even using AWS

💣 Then Came the Real Shock

During the same time window…

I received an AWS Abuse Report email.

It said:

My EC2 instance was involved in suspicious activity
Possibly Denial of Service (DoS)-like behavior
AWS warned my environment might be compromised

👉 That’s when it was clear:

This wasn’t just billing. This was an active compromise.

⚠️ Phase 0: What Actually Happened

📊 Key Indicators:

~209 GB data transfer to Bahrain
Unexpected outbound traffic charges
Activity during inactive hours
AWS Abuse Report notification

💡 Interpretation:
This strongly indicates:

Your instance was likely used as a bot / relay server
Or part of malicious traffic / scanning / DoS activity

🛑 Phase 1: Immediate Containment

🔒 Step 1: Lock Access

Changed root password
Verified MFA was already enabled and re-authenticated all sessions to ensure no unauthorized access persisted.
Logged out all sessions

🔐 Step 2: Kill Entry Points

Revoked all IAM access keys
Deleted unknown users (if any)
Checked roles for misuse

💻 Step 3: Stop the Attack Source

Terminated the EC2 instance (important)
Stopped all suspicious services
Restricted outbound traffic in Security Groups

💡 In your case:

The EC2 instance itself was the attack vector.

🔍 Phase 2: Investigation

📜 What I Checked:

CloudTrail logs
VPC Flow Logs (for traffic pattern)
EC2 instance activity

🔎 Findings:

High outbound traffic to external IPs
Data routed from Mumbai → Bahrain
Pattern matched automated traffic behavior

💡 Most likely cause:

Compromised EC2 (open ports / weak SSH / exposed key)

🧹 Phase 3: Eradication

🔥 Actions Taken:

Terminated compromised EC2
Removed unused security group rules
Closed open ports (like 0.0.0.0/0 on SSH)
Rotated all credentials

🔐 Security Fixes:

Disabled password-based SSH
Enforced key-based login only
Removed unnecessary public access

🛡️ Phase 4: Recovery & Hardening

✅ What I Implemented:

1. Strict Security Groups

No open ports to the world
Only whitelisted IPs

2. Monitoring Enabled

CloudWatch alerts
Billing alarms

3. GuardDuty Turned On

Real-time threat detection

4. IAM Hardening

Least privilege roles
No long-term access keys

📧 AWS Abuse Report: What It Meant

That email was critical.

It basically confirmed:

Your infrastructure was being misused
AWS had detected malicious patterns
Action was required immediately

💡 Important:

Ignoring this email can lead to account suspension

⚔️ Final Playbook (Based on Real Incident)

If you see:

Unexpected data transfer
Unknown regions involved
AWS abuse email

👉 Do THIS immediately:

Terminate suspicious EC2
Revoke all access keys
Enable MFA
Check CloudTrail
Lock down Security Groups
Rotate secrets
Enable GuardDuty

🧠 Real Lesson

“It wasn’t a hack of AWS… it was a misconfigured EC2.”

Most likely reasons:

Open SSH port (0.0.0.0/0)
Weak credentials or leaked key
No monitoring in place

🔥 Final Thought

This incident cost me:

Money 💸
Time ⏱️
Stress 😓

But it gave me something more valuable:

👉 Real-world cloud security experience

🤖 Agentic Security: Your AI Got Autonomy. Did Your Security Catch Up?

Rahul Joshi — Fri, 01 May 2026 12:59:51 +0000

Let me set a scene.

You deploy an AI agent to handle your customer data pipeline. It calls APIs, queries databases, writes files, even spawns subtasks. It’s fast. Efficient. Your manager is thrilled.

Then someone slips a malicious instruction inside a CSV file.

Your agent reads it… trusts it… and exports 45,000 customer records to an attacker-controlled endpoint.

The agent didn’t break.
It didn’t hallucinate.
It did exactly what it was designed to do—just for the wrong person.

This isn’t sci-fi. Variations of this pattern have already shown up in real-world enterprise environments.

Welcome to agentic security.

🧠 What “agentic AI” actually means

Traditional AI:

You ask → it answers

Agentic AI:

It decides
It plans
It acts

These systems:

Use tools (APIs, DBs, file systems)
Maintain memory across sessions
Execute multi-step workflows
Collaborate with other agents

This isn’t a chatbot anymore.

It’s a system actor with autonomy.

📊 The reality check

Recent industry surveys and enterprise reports paint a pretty uncomfortable picture:

~70% of enterprises are experimenting with or deploying AI agents
<25% have meaningful visibility into what those agents are doing
Continuous monitoring of agent interactions is still rare (~15–20%)
A majority of teams report unexpected or unauthorized agent actions
Logging and auditability remain one of the top unsolved problems

And the big one:

Most teams are deploying agents faster than they can secure them.

🚨 Why your existing security model breaks

Your current stack—SIEM, EDR, alerts—is built around:

human behavior
predictable workflows
discrete events

Agentic systems break all three.

An agent can:

execute 10,000 “valid” actions in sequence
follow instructions that look legitimate
operate across tools, memory, and time

From the outside, everything looks normal.

From the inside, it could be a fully automated breach.

🧩 Where things go wrong (the real attack surface)

Here’s a simple mental model:

User Input → Agent Core → Tools / APIs
                   ↕
                Memory
                   ↕
            Other Agents (A2A)

Every arrow is an attack surface.

⚠️ The Big Six threats

1. Memory Poisoning

What happens:
An attacker injects malicious context into memory that influences future decisions.

Real-world symptom:
Agent starts making consistently wrong or risky decisions based on past context.

How to detect it:

Track memory writes using tracing tools like:
- LangSmith
- OpenTelemetry
Log memory diffs:
- before vs after each interaction
Add anomaly detection:
- sudden change in memory patterns → alert

2. Tool Misuse

What happens:
Agent uses legitimate tools in unintended ways.

Example:
“Export filtered data” → becomes “export everything”

How to detect it:

Runtime monitoring with:
- Falco → detect suspicious system/API calls
API-level logging via:
- Kong Gateway
- AWS CloudTrail
Define rules:
- “Agent X should never call bulk export endpoint”

3. Goal Hijacking

What happens:
Agent’s objective is subtly altered via input or context.

How to detect it:

Trace reasoning chains using:
- LangSmith
- Weights & Biases
Compare:
- original goal vs executed actions
Add policy validation:
- enforce allowed intents using engines like:
- Open Policy Agent

4. Privilege Escalation

What happens:
Agent operates with excessive permissions.

How to detect it:

IAM monitoring via:
- AWS IAM
- Azure Active Directory
Audit logs:
- privilege usage vs expected scope
Alert on:
- role assumption spikes
- access to sensitive resources

5. Supply Chain Attacks

What happens:
Malicious models, packages, or integrations get loaded.

How to detect it:

Scan dependencies using:
- Snyk
- Dependabot
Static analysis:
- SonarQube
Runtime validation:
- hash verification of models/plugins

6. Agent-to-Agent (A2A) Trust Abuse

What happens:
One agent manipulates another through hidden instructions.

How to detect it:

Trace inter-agent communication:
- Jaeger
- OpenTelemetry
Log:
- message payloads between agents
- tool calls triggered downstream
Detect:
- unexpected cascades of actions

🔁 Multi-turn attacks are the real problem

Single prompt attacks are old news.

What’s working now:

slow manipulation
context shaping
multi-step influence

Across multiple turns, attackers can:

bypass guardrails
reshape agent goals
trigger unsafe actions

Per-request filtering isn’t enough anymore.

Security has to persist across:

sessions
memory
workflows

🔌 MCP: the next big risk layer

Model Context Protocol (MCP) is becoming the standard way to connect agents to tools.

That’s great for developers.

Also… a massive expansion of the attack surface.

Common issues emerging:

overprivileged tool access
hardcoded credentials (still!)
tool poisoning
unsafe execution environments

Think of MCP like USB for AI.

And remember how secure USB devices used to be? 😬

🛠️ What you should actually do

Let’s keep this practical.

1. Enforce least privilege

Scope API keys tightly
Separate read/write capabilities
Avoid “god-mode” agents

If an agent only needs to read → don’t let it write.

2. Make actions observable

You need:

full execution traces
tool call logs
decision tracking

If you can’t answer:

“Why did the agent do this?”

You have a problem.

3. Monitor agent interactions

Track:

which agents talk to which
what data flows between them
how authority is delegated

Most teams are blind here.

4. Add policy layers

Use:

rule engines (like OPA-style policies)
allow/deny lists for tool usage
contextual validation before execution

Don’t rely on the model to self-regulate.

5. Validate memory

Treat memory like user input:

sanitize it
validate it
expire it when needed

Persistent context = persistent risk.

6. Treat agents like insiders

Not malicious.

But:

trusted
privileged
and easily manipulated

That’s exactly what insider threat models are built for.

🧠 Final thought

We built agents to automate work.

But in doing that, we also automated:

trust
access
decision-making

And we didn’t redesign security for any of it.

We didn’t just give AI autonomy.
We gave it authority—without accountability.

That’s the gap.

Have you seen weird or unexpected agent behavior in production? Drop your war stories below 👇

And if you’re building guardrails—what’s actually working?