DEV Community: Aisalkyn Aidarova

Lab – Route 53 + Custom Domain + HTTPS (AWS Certificate Manager)

Aisalkyn Aidarova — Mon, 27 Jul 2026 01:41:15 +0000

Lab Goal

So far, your application is running on Amazon ECS behind an Application Load Balancer.

Right now your application URL probably looks like this:

http://restaurant-alb-123456789.us-east-1.elb.amazonaws.com

This URL works, but it doesn't look professional.

Real companies use custom domains such as:

By the end of this lab you will:

Connect your domain to your ALB.
Learn how DNS works.
Create a Route 53 Hosted Zone.
Point your domain to your ALB.
Secure your website with HTTPS.
Request a free SSL certificate using AWS Certificate Manager (ACM).
Redirect HTTP traffic to HTTPS.

Production Architecture

Before this lab

Users

↓

ALB DNS Name

↓

Application Load Balancer

↓

Amazon ECS

↓

Containers

After this lab

Users

↓

www.myrestaurant.com

↓

Route 53

↓

Application Load Balancer (HTTPS)

↓

Amazon ECS

↓

Containers

Why Do Companies Use Route 53?

Imagine opening Amazon.

You type

www.amazon.com

You never type

amazon-alb-8723467.us-east-1.elb.amazonaws.com

That long address belongs to AWS.

Customers don't want to remember long AWS addresses.

Instead,

companies buy a domain.

Route 53 tells the Internet:

"When someone types this domain, send them to my Load Balancer."

What is DNS?

DNS stands for

Domain Name System

Think of DNS as the Internet's phone book.

People remember

www.google.com

Computers understand

142.250.72.206

DNS translates names into addresses.

Without DNS,

people would need to remember IP addresses.

What is Route 53?

Amazon Route 53 is AWS's DNS service.

It allows you to:

Register domains
Manage DNS records
Connect domains to AWS services
Route users to your application

Part 1 – Buy a Domain

If you already own a domain,

you can use it.

Examples:

myrestaurant.com

jumptotech.com

studentproject.net

If you do not own one,

purchase one from:

Route 53
Namecheap
GoDaddy
Squarespace Domains

For this lab we assume you already have one.

Part 2 – Create a Hosted Zone

Open

AWS Console

Route 53

Click

Hosted Zones

Click

Create Hosted Zone

Fill in

Domain Name

myrestaurant.com

Type

Public Hosted Zone

Click

Create Hosted Zone

Why Public Hosted Zone?

A Public Hosted Zone allows anyone on the Internet to reach your website.

Private Hosted Zones are used only inside AWS VPCs.

For websites,

always choose

Public Hosted Zone

Part 3 – Understand the Records

AWS automatically creates:

NS

SOA

Do not delete them.

These records are required for DNS to work.

Part 4 – Create an Alias Record

Click

Create Record

Choose

Record Type

Turn ON

Alias

Alias Target

Choose

Application Load Balancer

Select your ALB.

Example

restaurant-alb

Click

Create Record

Done.

Now

myrestaurant.com

points to your Load Balancer.

Why Do We Use an Alias Record?

Normally,

an A record points to an IP address.

Example

192.168.1.20

But an AWS Load Balancer does not have one fixed IP address.

Its IP addresses can change.

Instead,

AWS provides an Alias Record.

The Alias automatically follows your Load Balancer even if its IP addresses change.

This is why AWS recommends using Alias records with ALBs.

Part 5 – Test the Website

Wait a few minutes.

Open your browser.

Visit

http://myrestaurant.com

Your website should load.

If it does,

Route 53 is working correctly.

Why is the Website Still Not Secure?

Look at your browser.

You will probably see

Not Secure

Why?

Because your website is still using

HTTP

instead of

HTTPS

What is HTTPS?

HTTP sends information without encryption.

Anyone between the user and your website could potentially read the traffic.

HTTPS encrypts all communication.

Examples:

Login information
Credit card numbers
Passwords
Personal information

Modern websites always use HTTPS.

What is AWS Certificate Manager (ACM)?

AWS Certificate Manager creates SSL certificates.

Certificates prove that your website really belongs to you.

Good news:

AWS ACM public certificates are free to use with supported AWS services like an ALB.

Part 6 – Request a Certificate

Open

AWS Console

Certificate Manager

Click

Request Certificate

Choose

Request a Public Certificate

Click

Next

Domain Name

Example

myrestaurant.com

Also add

www.myrestaurant.com

Click

Next

Validation Method

Choose

DNS Validation

Click

Request

Why DNS Validation?

AWS must verify that you own the domain.

Instead of sending an email,

AWS asks you to create a DNS record.

This is easier and renews automatically while the DNS validation record remains in place.

Part 7 – Validate the Certificate

Open the certificate.

Click

Create Records in Route 53

AWS automatically creates the required DNS validation record.

Wait a few minutes.

Certificate status changes from

Pending Validation

Issued

Only after the status becomes Issued can the certificate be attached to your Load Balancer.

Part 8 – Add HTTPS to the ALB

Open

EC2

↓

Load Balancers

Select your ALB.

Open

Listeners and Rules

Click

Add Listener

Choose

HTTPS

Port

Certificate

Select

myrestaurant.com

Default Action

Forward to your existing Target Group.

Click

Create

Done.

Your website now supports HTTPS.

Why Port 443?

Port

is used for HTTP.

Port

is used for HTTPS.

Most websites today use HTTPS on port 443.

Part 9 – Redirect HTTP to HTTPS

Many users will still type

http://myrestaurant.com

We want AWS to automatically redirect them.

Select

HTTP Listener

Port 80

Click

Edit Rules

Default Action

Choose

Redirect

Configure:

Protocol

HTTPS

Port

Status Code

HTTP 301

Save.

Now every HTTP request automatically becomes HTTPS.

What is HTTP 301?

301 means

Permanent Redirect

Browsers remember this redirect.

Users automatically use HTTPS in future visits.

Verify Everything Works

Open

https://myrestaurant.com

Check:

✅ Website loads

✅ Browser shows a lock icon

✅ URL begins with

https://

If you still see "Not Secure," verify that:

The ACM certificate status is Issued.
The HTTPS listener is using the correct certificate.
Your Route 53 Alias record points to the correct ALB.
DNS changes have had time to propagate.

Common Problems

Problem 1

Certificate stuck in

Pending Validation

Possible cause:

DNS validation record was not created correctly or DNS changes have not propagated yet.

Problem 2

Website still opens with HTTP

Possible cause:

No redirect rule on port 80.

Problem 3

Browser says

Certificate Error

Possible causes:

Wrong certificate attached.
Certificate does not include the domain you are visiting.
Certificate is not in the same AWS Region as the ALB.

Problem 4

Website cannot be reached

Possible causes:

Alias record points to the wrong ALB.
Load Balancer is unhealthy.
Security Groups are blocking traffic.

Production Best Practices

Always:

Use HTTPS for public websites.
Redirect HTTP to HTTPS.
Keep DNS records organized.
Use Alias records for ALBs.
Monitor certificate expiration (ACM-managed public certificates renew automatically when validation remains in place and the certificate is still in use).

Lab Checklist

Complete the following:

✅ Create a Public Hosted Zone

✅ Create an Alias Record

✅ Point your domain to the ALB

✅ Request an ACM Public Certificate

✅ Validate the certificate using DNS

✅ Wait for the certificate status to become Issued

✅ Add an HTTPS Listener (443)

✅ Attach the ACM Certificate

✅ Redirect HTTP (80) to HTTPS (443)

✅ Open the website using HTTPS

Interview Questions

1. What is Route 53?

AWS's DNS service that maps domain names to AWS resources and other destinations.

2. What is DNS?

The Domain Name System translates human-readable domain names into network addresses.

3. Why do companies use custom domains?

To provide a professional, memorable address for customers instead of AWS-generated hostnames.

4. What is AWS Certificate Manager?

A service that issues and manages SSL/TLS certificates for supported AWS services.

5. Why do we use HTTPS?

To encrypt communication between users and the application, protecting sensitive data in transit.

6. What is the difference between HTTP and HTTPS?

HTTP sends traffic without encryption. HTTPS uses TLS to encrypt the connection.

7. Why do we use an Alias Record instead of a normal A Record?

Because an Application Load Balancer does not have a fixed IP address. Alias records automatically track the AWS resource.

8. Why do we redirect HTTP to HTTPS?

To ensure all users access the secure version of the website, even if they initially enter an HTTP URL.

Homework

Purchase or use an existing domain.
Create a Public Hosted Zone in Route 53.
Create an Alias A record pointing to your ALB.
Request an ACM public certificate for your domain.
Validate the certificate using DNS.
Add an HTTPS listener (443) to your ALB.
Configure HTTP (80) to redirect to HTTPS.
Verify that your website loads with a valid HTTPS connection.
Take screenshots of:

Hosted Zone
Alias Record
ACM Certificate (Issued)
ALB Listeners
Website showing the HTTPS lock icon

After completing this lab, students will have a professional deployment with a custom domain and encrypted HTTPS traffic, similar to what is commonly used for public-facing applications in AWS.

Lab – Amazon CloudWatch Metrics, Dashboards & Alarms

Aisalkyn Aidarova — Mon, 27 Jul 2026 01:40:03 +0000

Lab Goal

In this lab you will learn how DevOps engineers monitor applications running in production.

By the end of this lab you will be able to:

Understand what CloudWatch Metrics are.
Create a CloudWatch Dashboard.
Monitor your ECS Service.
Monitor your Application Load Balancer.
Create CloudWatch Alarms.
Receive notifications when something goes wrong.
Understand how DevOps engineers detect problems before customers report them.

Production Scenario

Imagine your application is running on ECS.

GitHub

↓

GitHub Actions

↓

Amazon ECR

↓

Amazon ECS

↓

Application Load Balancer

↓

Users

Yesterday everything worked perfectly.

Today users start saying:

"The website is very slow."

As a DevOps Engineer, the first question is:

What changed?

You don't guess.

You look at monitoring.

That is why companies use Amazon CloudWatch.

What is Amazon CloudWatch?

CloudWatch is AWS's monitoring service.

Think of it as a health monitor for your AWS resources.

Instead of waiting for customers to complain, CloudWatch tells you when something is wrong.

CloudWatch collects information such as:

CPU Usage
Memory Usage
Network Traffic
Requests
Response Time
Errors

What is a Metric?

A metric is simply a number measured over time.

Examples:

Metric	Meaning
CPU Utilization	How busy the server is
Memory Utilization	How much RAM is being used
Request Count	Number of users visiting
Response Time	How long requests take
Healthy Host Count	Number of healthy ECS tasks

Think of your smartwatch.

It measures:

Heart Rate
Steps
Calories

CloudWatch does the same thing for AWS resources.

Why Do Companies Monitor?

Imagine this happens:

At 2 AM

CPU becomes

98%

If nobody notices,

the application becomes slow.

Eventually

CPU 100%

↓

Application Stops Responding

Customers cannot use the website.

Monitoring allows DevOps engineers to fix problems before they become outages.

What Can CloudWatch Monitor?

Today we will monitor:

ECS Service
ECS Tasks
Application Load Balancer

Later you can also monitor:

EC2
Lambda
RDS
DynamoDB
API Gateway
S3

Part 1 – Open CloudWatch

Open AWS Console

CloudWatch

Open it.

You will see:

Dashboards
Alarms
Metrics
Logs

Today we will use:

Metrics
Dashboards
Alarms

Part 2 – View Metrics

Click

Metrics

Click

All Metrics

You will see many AWS services.

Examples:

ECS
EC2
ApplicationELB
Lambda
RDS

Part 3 – ECS Metrics

Click

ECS

Then

ClusterName

Choose your cluster.

You should see metrics such as:

CPUUtilization
MemoryUtilization

Click

CPUUtilization

A graph appears.

This graph shows how busy your ECS service has been.

Why CPU Matters

Imagine CPU usage stays around

15%

Everything is healthy.

Now traffic increases.

CPU becomes

95%

The application may:

become slow
stop responding
restart

This is why DevOps engineers always monitor CPU.

Memory Utilization

Return to Metrics.

Choose

MemoryUtilization

Memory shows how much RAM the container is using.

If memory reaches

100%

The container may crash.

Part 4 – Monitor the Load Balancer

Go back.

Choose

ApplicationELB

Select your ALB.

Useful metrics include:

RequestCount

How many requests users are sending.

If it suddenly increases,

your website is getting more traffic.

TargetResponseTime

How long your application takes to respond.

Healthy example:

150 ms

Bad example:

3 seconds

Slow response usually means:

high CPU
database problems
slow application code

HealthyHostCount

Shows how many healthy ECS tasks are receiving traffic.

Example

2 Healthy

Good.

If it becomes

Nobody can use your application.

HTTPCode_Target_5XX_Count

Shows application errors.

Examples

These usually mean something is wrong with the application.

Part 5 – Create a Dashboard

Why create dashboards?

Instead of opening many AWS pages,

DevOps engineers want everything on one screen.

Open

Dashboards

↓

Create Dashboard

Dashboard name

Restaurant-App

Click

Create

Add Widgets

Click

Add Widget

Choose

Line

Add:

Widget 1

CPUUtilization

Widget 2

MemoryUtilization

Widget 3

RequestCount

Widget 4

HealthyHostCount

Widget 5

TargetResponseTime

Save.

Now one screen shows the health of your application.

This is how many DevOps teams monitor production.

Part 6 – CloudWatch Alarms

Monitoring is useful.

But nobody watches dashboards 24 hours a day.

Instead,

CloudWatch sends alerts.

Example

CPU

95%

↓

CloudWatch Alarm

↓

Email

↓

DevOps Engineer

Now someone knows there is a problem.

Part 7 – Create CPU Alarm

Open

CloudWatch

↓

Alarms

↓

Create Alarm

Choose Metric

ECS

↓

CPUUtilization

Condition

Greater Than

80

Meaning

If CPU stays above

80%

CloudWatch creates an alarm.

Evaluation Period

Choose

5 minutes

Why?

CPU can briefly spike.

We don't want false alarms.

Waiting a few minutes helps reduce unnecessary alerts.

Notification

Choose

Create New SNS Topic

Name

DevOpsAlerts

Enter your email.

Click

Create

Check your email.

Click

Confirm Subscription

Without confirming, AWS cannot send notifications.

Alarm Name

High-CPU-Restaurant-App

Click

Create Alarm

Done.

Part 8 – Create Memory Alarm

Repeat the process.

Metric

MemoryUtilization

Threshold

80%

Alarm Name

High-Memory

Part 9 – Create Healthy Host Alarm

Metric

HealthyHostCount

Condition

Less Than

1

Meaning

If no healthy ECS tasks exist,

CloudWatch immediately sends an alert.

This is one of the most important production alarms.

Part 10 – Create Target Response Time Alarm

Metric

TargetResponseTime

Condition

Greater Than

2 Seconds

If users wait too long,

DevOps receives a notification.

Which Alarms Should Every DevOps Engineer Create?

At a minimum:

Alarm	Why It Matters
High CPU	Application is overloaded
High Memory	Prevent container crashes
Healthy Host Count < 1	Application is unavailable
Target Response Time High	Website is slow
HTTP 5XX Errors	Application is failing

As you gain experience, you can add alarms for other AWS services and business-specific metrics.

How DevOps Engineers Use CloudWatch

Imagine your phone rings.

Email says:

High CPU

95%

What should you check?

Is ECS running?
Are tasks healthy?
Open CloudWatch Logs.
Look for application errors.
Check database connectivity.
Decide whether scaling or a code fix is needed.

CloudWatch tells you something is wrong.

CloudWatch Logs usually help explain why it is happened.

Production Tips

✔ Monitor trends, not just current values.

✔ Use dashboards for daily monitoring.

✔ Use alarms for important events.

✔ Don't create hundreds of unnecessary alarms.

✔ Review alarms regularly to remove ones that are noisy or no longer useful.

Lab Checklist

Complete the following:

✅ View ECS CPU metric

✅ View ECS Memory metric

✅ View ALB Request Count

✅ View ALB Healthy Hosts

✅ Create Dashboard

✅ Add CPU Widget

✅ Add Memory Widget

✅ Add Request Widget

✅ Add Healthy Host Widget

✅ Create CPU Alarm

✅ Create Memory Alarm

✅ Create Healthy Host Alarm

✅ Confirm SNS Email

Interview Questions

1. What is CloudWatch?

AWS monitoring service used to collect metrics, logs, dashboards, and alarms.

2. What is the difference between Metrics and Logs?

Metrics are numbers collected over time (CPU, memory, requests). Logs are detailed text records from your application or services that explain what happened.

3. Why do we create Dashboards?

To view the health of multiple AWS resources in one place.

4. Why do we create Alarms?

To notify the DevOps team automatically when a metric crosses a defined threshold.

5. Which metrics do you monitor in ECS?

CPU Utilization
Memory Utilization
Healthy Host Count
Request Count
Target Response Time
HTTP 5XX Errors

6. What happens if Healthy Host Count becomes 0?

The load balancer has no healthy targets to send traffic to, so users are likely to experience application failures.

7. What is Amazon SNS used for in CloudWatch?

SNS sends notifications, such as email, when an alarm changes to the ALARM state.

Homework

Create a CloudWatch Dashboard with at least 5 widgets.
Create 4 CloudWatch Alarms:

High CPU (>80%)
High Memory (>80%)
Healthy Host Count (<1)
High Target Response Time (>2 seconds)
1. Trigger one alarm (if possible) and verify that you receive an email notification.
2. Take screenshots of:
Your Dashboard
Your Alarms
Your SNS subscription confirmation
Your ECS Metrics graph

By completing this lab, students will have a basic monitoring setup similar to what many teams configure for an ECS application in AWS.

LAB – AWS Secrets Manager & CloudWatch Logs

Aisalkyn Aidarova — Mon, 27 Jul 2026 01:38:18 +0000

Goal

Today you will learn how real companies keep passwords secure and how DevOps engineers troubleshoot applications running in Amazon ECS.

By the end of this lab you will:

Store a database password in AWS Secrets Manager.
Connect your ECS application to the secret.
Configure CloudWatch Logs.
View application logs.
Understand how DevOps engineers troubleshoot production issues.

Part 1 – Why do we need AWS Secrets Manager?

Imagine your application needs to connect to a database.

Most beginners write something like this:

DB_HOST=mydatabase.amazonaws.com
DB_USER=admin
DB_PASSWORD=Password123

This works, but it is not secure.

If you push this file to GitHub, anyone who can access the repository could see the password. If an employee leaves the company, the password might also be shared accidentally.

In production

Large companies never store passwords inside:

GitHub repositories
Docker images
Source code
Terraform files

Instead, passwords are stored in AWS Secrets Manager.

The application asks AWS for the password when it starts.

Application

↓

AWS Secrets Manager

↓

Returns Password

This means:

Developers cannot accidentally expose passwords.
Passwords can be changed without changing application code.
Access is controlled using IAM permissions.

Part 2 – Create a Secret

Open the AWS Console.
Search for Secrets Manager.
Click Store a new secret.

Select:

Other type of secret

Add the following key/value pairs:

DB_HOST = your-database-endpoint
DB_USER = postgres
DB_PASSWORD = Password123

Replace these values with your own if you are using an RDS database.

Click Next.

Secret name:

restaurant-app-secret

Click Next until the secret is created.

Part 3 – Why do we give the secret a name?

Your application does not know the actual password.

Instead, it asks AWS:

"Please give me the secret called restaurant-app-secret."

This allows you to change the password later without changing your application code.

Part 4 – Connect ECS to the Secret

Open:

ECS → Task Definitions

Select your task definition.

Click:

Create new revision

Scroll to:

Container

Find the Environment section.

Choose:

Secrets

Click:

Add Secret

Fill in:

Secret name:

DB_PASSWORD

Value from:

Choose

restaurant-app-secret

Save the task definition.

Now update your ECS service to use the newest task definition revision.

Part 5 – Why do we update the Service?

The task definition is only a template.

Updating the ECS Service launches new containers using the latest task definition.

This is how changes are deployed in production.

Part 6 – Verify Everything Works

Open:

ECS → Cluster → Service → Tasks

Wait until the task status is:

Running

If the task stops immediately, something is wrong.

This is when DevOps engineers begin troubleshooting.

Part 7 – CloudWatch Logs

Why do we need CloudWatch Logs?

Imagine a developer says:

"The application doesn't work."

That message is not enough.

A DevOps engineer needs to answer:

Did the application start?
Did it crash?
Why did it crash?
Is the database reachable?
Did the application receive traffic?

CloudWatch Logs answers these questions.

Part 8 – Configure CloudWatch Logs

When creating or updating your task definition, locate the Log configuration section.

Select:

Log driver

awslogs

Fill in:

Log group

/ecs/restaurant-app

Region

us-east-1

Stream prefix

ecs

Save the task definition.

Deploy the new revision.

Part 9 – View Logs

Open:

CloudWatch

↓

Log Groups

↓

/ecs/restaurant-app

↓

Open the newest log stream.

You should see application output such as:

Application started

Server listening on port 3000

Connected to database

If you see these messages, your container started successfully.

Part 10 – Common Production Errors

Example 1

Database connection failed

Possible causes:

Wrong password
Database is stopped
Security Group blocks access

Example 2

Port already in use

Possible cause:

Your application is listening on the wrong port.

Example 3

Cannot find module

Possible cause:

The Docker image is missing required files.

Part 11 – What does a DevOps engineer check first?

When a production incident happens, a typical workflow is:

Check if the ECS service is running.
Check if tasks are healthy.
Open CloudWatch Logs.
Read the first error message.
Identify the root cause.
Fix the issue.
Redeploy if necessary.
Verify the application is healthy.

Logs are often the fastest way to understand why an application failed.

Part 12 – Good Logging Practices

Applications should log useful information, including:

Application startup
Database connection status
API requests
Errors and exceptions
Unexpected shutdowns

Avoid logging:

Passwords
API keys
Access tokens
Sensitive customer data

Lab Checklist

Before finishing this lab, verify that you can:

Create a secret in AWS Secrets Manager.
Update an ECS Task Definition.
Attach a secret to an ECS container.
Deploy the new task definition.
Configure the awslogs log driver.
Find your Log Group.
Open the latest Log Stream.
Identify an application error using CloudWatch Logs.

Interview Questions

Why should passwords not be stored in GitHub?
What problem does AWS Secrets Manager solve?
Why do we update the ECS Service after creating a new task definition revision?
What is CloudWatch Logs used for?
Where do you look first when an ECS task crashes?
What is the difference between an ECS task and a task definition?
What information should never appear in application logs?

CI/CD Pipeline Lecture

Aisalkyn Aidarova — Wed, 22 Jul 2026 00:04:44 +0000

If you look at almost every DevOps job description, you will see requirements like:

Experience with CI/CD
Jenkins
GitHub Actions
GitLab CI
Docker
Kubernetes
AWS
Terraform

Why?

Because a DevOps engineer's main responsibility is to automate how software moves from a developer's computer to production where customers use it.

Without CI/CD, companies would deploy software manually. That process is slow, error-prone, and expensive.

With CI/CD, the entire deployment process can happen automatically in just a few minutes.

What Does CI/CD Mean?

CI/CD consists of two parts.

CI – Continuous Integration

Continuous Integration means developers frequently merge their code into a shared Git repository.

Every time code is pushed, the system automatically:

Downloads the latest code
Builds the application
Runs tests
Checks code quality
Looks for security issues

The goal is to detect problems immediately instead of finding them weeks later.

CD – Continuous Delivery / Continuous Deployment

After CI finishes successfully, CD takes over.

CD automatically prepares the application for deployment.

Depending on the company:

Continuous Delivery:

Deployment waits for manual approval.

Continuous Deployment:

Every successful build is automatically deployed to production.

Why Companies Use CI/CD

Imagine Amazon has 5,000 developers.

Each developer pushes code several times every day.

Without CI/CD:

Someone would need to:

Download code manually
Build it manually
Test it manually
Create Docker images manually
Upload images manually
Deploy manually
Restart servers manually

Imagine doing that hundreds of times every day.

It would be impossible.

Automation solves this problem.

Real Company Scenario

Let's imagine we work for Netflix.

The frontend team creates a new search feature.

The backend team fixes a bug.

The payment team updates billing.

The recommendation team improves suggestions.

All these developers push code to GitHub throughout the day.

Each push automatically starts a CI/CD pipeline.

Nobody has to call the DevOps engineer and ask:

"Can you deploy this?"

The pipeline handles everything automatically.

Who Does What?

Many beginners confuse the responsibilities.

Developer

The developer's responsibility is to:

Write application code
Fix bugs
Add new features
Push code to GitHub

The developer is not responsible for deploying to production in most organizations.

DevOps Engineer

The DevOps engineer creates the automation that deploys the application safely.

Typical responsibilities include:

Writing GitHub Actions workflows
Creating Jenkins pipelines
Building Docker images
Managing Kubernetes or ECS
Configuring AWS infrastructure
Monitoring applications
Managing deployments
Automating repetitive tasks

The Complete CI/CD Pipeline

Developer

↓

Git Push

↓

GitHub Repository

↓

GitHub Actions / Jenkins

↓

Checkout Code

↓

Install Dependencies

↓

Compile / Build

↓

Run Unit Tests

↓

Run Integration Tests

↓

Static Code Analysis (SonarQube)

↓

Security Scan (Trivy)

↓

Docker Build

↓

Push Image to Amazon ECR

↓

Deploy to ECS / Kubernetes

↓

Application Starts

↓

Load Balancer

↓

Customers

↓

Monitoring & Alerts

Every stage has a specific purpose.

Step 1 — Developer Pushes Code

The developer finishes a feature.

For example:

The login page now supports Google authentication.

The developer commits the changes.

git add .

git commit -m "Added Google Login"

git push origin main

At this point nothing has been deployed.

GitHub simply stores the latest version of the project.

What Happens After Git Push?

GitHub constantly watches the repository.

Whenever someone pushes code, GitHub immediately checks whether a workflow exists.

It looks inside:

.github/workflows/

Inside we might have:

deploy.yml

ci.yml

These files tell GitHub exactly what to do.

What is YAML?

A YAML file is simply a list of instructions.

Think of it like a recipe.

Instead of saying:

"Make a cake."

The recipe says:

Step 1

Mix flour.

Step 2

Add eggs.

Step 3

Bake.

CI/CD works exactly the same way.

Instead of cooking, we deploy software.

Step 2 — Runner Starts

GitHub itself cannot build your application.

It needs a computer.

This computer is called a Runner.

There are two types.

GitHub Hosted Runner

GitHub creates a temporary Linux virtual machine.

Example:

ubuntu-latest

Advantages:

Easy to use
No maintenance
Automatically updated
Secure

Disadvantages:

Limited customization
Internet restrictions in some companies
Starts fresh every run

Self Hosted Runner

Many companies prefer their own servers.

Example:

AWS EC2

Azure VM

Physical server

Advantages:

Faster builds
Internal network access
Custom software
Lower cost for large companies

Step 3 — Checkout the Code

The runner is empty.

It knows nothing about our application.

First it downloads the latest version from GitHub.

actions/checkout

Now the runner contains:

Frontend

Backend

Dockerfile

README

package.json

Everything needed for the build is now available.

Step 4 — Install Dependencies

Applications depend on libraries.

NodeJS:

npm install

Python:

pip install

Java:

mvn install

Without these packages, the application cannot run.

Step 5 — Build the Application

Now we compile the application.

React example:

npm run build

Angular:

ng build

Java:

mvn package

The build process creates production-ready files.

Step 6 — Run Automated Tests

Testing is extremely important.

Imagine deploying software that immediately crashes.

Customers cannot use it.

Money is lost.

Automated tests verify:

Login works
Registration works
API works
Payments work
Search works

If even one critical test fails...

Pipeline immediately stops.

Nothing is deployed.

Why Stop the Pipeline?

Because broken software should never reach production.

This is one of the biggest advantages of CI/CD.

Problems are caught early.

Step 7 — SonarQube

Testing verifies functionality.

SonarQube checks code quality.

It looks for:

Bugs
Duplicate code
Poor coding practices
Hardcoded passwords
Memory leaks
SQL injection risks

Example:

password = "admin123";

SonarQube flags this immediately.

Step 8 — Trivy Security Scan

Now we scan the Docker image.

Trivy checks:

Operating system vulnerabilities
Library vulnerabilities
CVEs
Secrets accidentally committed

Example:

Your Docker image contains an outdated OpenSSL version.

Trivy reports:

Critical Vulnerability.

The deployment stops.

Why Scan Security?

Because thousands of new vulnerabilities are discovered every year.

Deploying vulnerable software puts customer data at risk.

Step 9 — Build Docker Image

Now everything passed.

We create a Docker image.

docker build

A Docker image contains:

Linux operating system
Application
Runtime
Libraries
Configuration

Everything needed to run the application anywhere.

Why Docker?

Imagine this situation.

Developer:

"It works on my laptop."

Production server:

"It doesn't work."

Why?

Different environments.

Docker solves this.

The exact same image runs everywhere.

Step 10 — Push Image to Amazon ECR

The image currently exists only on the runner.

If the runner disappears...

The image disappears too.

We store it permanently.

Amazon Elastic Container Registry (ECR)

docker push

Now Kubernetes or ECS can download it.

Why ECR?

Think of ECR as GitHub for Docker images.

Instead of storing source code...

It stores application images.

Step 11 — Deploy

The deployment stage begins.

Depending on the company, deployment may use:

Amazon ECS
Amazon EKS
Kubernetes
Azure AKS
Google GKE

The platform pulls the newest image from ECR.

Old containers are replaced with new ones.

Rolling Deployment

Suppose five containers are running.

The deployment system does not stop all five.

Instead:

Stop one.

Start one.

Health check.

Repeat.

Customers continue using the application with almost no downtime.

Health Checks

After a new container starts, Kubernetes or ECS asks:

"Are you healthy?"

Example:

/health

If the container answers correctly...

Traffic is sent to it.

If not...

It is automatically replaced.

Load Balancer

Customers never connect directly to containers.

Instead:

Users

↓

Application Load Balancer

↓

Container 1

Container 2

Container 3

Container 4

The Load Balancer distributes requests evenly.

If one container crashes...

Traffic automatically goes to the healthy containers.

Monitoring

Deployment is complete.

Now monitoring begins.

Popular tools:

Amazon CloudWatch
Prometheus
Grafana
Datadog

We monitor:

CPU usage
Memory usage
Errors
Response time
Container health
Network traffic

If something goes wrong, alerts notify the DevOps team.

What Does a DevOps Engineer Monitor Every Day?

A DevOps engineer typically checks:

Did the pipeline succeed?
Did deployment complete successfully?
Are all containers healthy?
Is CPU usage too high?
Is memory usage increasing?
Are users reporting errors?
Are logs showing failures?
Is the application responding quickly?

Monitoring is an ongoing responsibility, not something done only during deployment.

Summary

A CI/CD pipeline automates the journey of software from a developer's code commit to a running application in production.

A typical flow is:

Developer pushes code to GitHub.
GitHub triggers a workflow.
A runner downloads the code.
Dependencies are installed.
The application is built.
Automated tests are executed.
SonarQube analyzes code quality.
Trivy scans for security vulnerabilities.
A Docker image is created.
The image is pushed to Amazon ECR.
ECS or Kubernetes deploys the new version.
A Load Balancer routes users to healthy containers.
Monitoring tools watch the application and alert the DevOps team if problems occur.

This end-to-end automation is the foundation of modern DevOps and is one of the most common workflows you'll encounter in real-world engineering teams.

Lab 1 - Build Your First Playwright Automation Framework

Aisalkyn Aidarova — Mon, 20 Jul 2026 20:50:51 +0000

By the end of this lab, you'll be able to answer questions like:

What is Maven?
Why do you use Playwright?
What is Page Object Model?
How do you organize an automation framework?

Business Scenario

You have joined United Airlines as a QA Automation Engineer.

The development team has completed the Login feature for a new customer portal.

Before the application goes to production, your task is to automate the login functionality.

Objective

By the end of this lab, you will:

Create a Java automation framework
Install Playwright
Write your first automated UI test
Push the project to GitHub

Architecture

Developer
      │
      ▼
Application
      │
      ▼
Playwright Automation
      │
      ▼
Test Results

Step 1 – Install Software

Install these tools:

Java 21
IntelliJ IDEA Community Edition
Git
Google Chrome
Maven (or use IntelliJ's bundled Maven)

Verify installation:

java -version
git --version
mvn -version

You should see version numbers for each.

Step 2 – Create a New Project

Open IntelliJ IDEA.

Click New Project.
Select Maven.
Choose Java 21 as the JDK.
Group ID:

   com.company

Artifact ID:

   qa-playwright-framework

Click Create.

Step 3 – Add Playwright

Open pom.xml.

Replace its contents with the official Playwright Maven dependencies (or add them if IntelliJ created a basic project).

Reload the Maven project when IntelliJ prompts you.

Step 4 – Install Playwright Browsers

Open the Terminal inside IntelliJ.

Run:

mvn exec:java -e -Dexec.mainClass=com.microsoft.playwright.CLI -Dexec.args="install"

Wait until Chrome, Firefox, and WebKit are installed.

Step 5 – Create Project Structure

Inside src/test/java, create:

pages
tests
utils

Your project should look like:

qa-playwright-framework
│
├── src
│   └── test
│       └── java
│            ├── pages
│            ├── tests
│            └── utils
│
├── pom.xml

Step 6 – Create Your First Test

Create a class:

LoginTest

Inside it:

Launch Chrome.
Open a demo website (for example, SauceDemo).
Verify the page title.
Close the browser.

Run the test.

Expected Result

Chrome opens.
The website loads.
The title matches the expected value.
The browser closes.
The test passes.

Step 7 – Push to GitHub

In the IntelliJ terminal:

git init

git add .

git commit -m "Initial Playwright framework"

Create a new repository on GitHub named:

qa-playwright-framework

Then push your code.

What You Learned

By completing this lab, you can confidently say:

I created a Maven-based Playwright automation framework.
I organized the project using packages for pages, tests, and utilities.
I installed Playwright browsers.
I wrote and executed my first UI automation test.
I version-controlled the project with Git and GitHub.

Interview Questions

1. Why did you choose Maven?

Answer: Maven manages project dependencies, standardizes the project structure, and simplifies builds using a single pom.xml file.

2. Why Playwright instead of Selenium?

Answer: Playwright provides automatic waiting, faster execution, built-in support for multiple browsers, better handling of modern web applications, and supports parallel execution.

3. Why do you separate `pages` and `tests`?

Answer: This follows the Page Object Model (POM) design pattern. It keeps UI locators and page actions separate from test logic, making the framework easier to maintain and reuse.

4. Why use GitHub?

Answer: GitHub stores the automation framework, enables collaboration, tracks changes, and integrates easily with CI/CD tools like GitHub Actions.

Homework

Add a second test that verifies the login page URL.
Create a HomePage class in the pages package (it can be empty for now).
Push your changes to GitHub with the commit message:

Added initial Playwright tests and project structure

This is the level of detail I'd recommend for each lab: focused on one real-world task, small enough to complete in under an hour, and directly tied to common interview questions.

Deploy a New Version of the Application (v2)

Aisalkyn Aidarova — Mon, 20 Jul 2026 02:05:53 +0000

you deployed version 1 of the application.

Today, Jules (the developer) sends you a message:

"I fixed several bugs and added a new feature. Please deploy Version 2."

As a DevOps Engineer, you do not change the code. You receive the updated code and deploy the new version safely.

Learning Objectives

By the end of this lab, you will:

Pull the latest code from GitHub
Build a new Docker image
Tag the image as v2
Push the new image to Amazon ECR
Update the ECS Task Definition
Deploy the new version to ECS
Verify that the new version is running
Understand rolling deployments

Architecture

Developer
      │
      ▼
Updated Source Code
      │
      ▼
Docker Image v2
      │
      ▼
Amazon ECR
      │
      ▼
New ECS Task Definition
      │
      ▼
ECS Service Update
      │
      ▼
Application Load Balancer
      │
      ▼
Users See Version 2

Step 1 – Receive the Updated Code

The developer pushes new code to GitHub.

Open the updated project.

Why?

Developers continuously improve applications by fixing bugs and adding features.

Step 2 – Build a New Docker Image

docker build -t restaurant-app:v2 .

Verify:

docker images

You should now see:

restaurant-app:v1

restaurant-app:v2

Why?

Every application change requires a new Docker image.

Never overwrite an existing image with the same version tag.

Step 3 – Test Version 2

docker run -p 3000:3000 restaurant-app:v2

Verify the application works.

Why?

Always test before deploying.

Step 4 – Tag the Image

docker tag restaurant-app:v2 ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/restaurant-app:v2

Step 5 – Push Version 2 to Amazon ECR

docker push ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/restaurant-app:v2

Open Amazon ECR.

Verify that both images exist:

v1

v2

Why?

Keeping multiple image versions allows you to roll back if something goes wrong.

Step 6 – Create a New ECS Task Definition Revision

Open Amazon ECS.

Select the existing Task Definition.

Click Create New Revision.

Change only the image URI from:

restaurant-app:v1

restaurant-app:v2

Save the new revision.

Why?

Task Definitions are versioned.

Instead of editing the old one, AWS creates a new revision for each deployment.

Step 7 – Update the ECS Service

Select your ECS Service.

Click Update Service.

Choose the latest Task Definition revision.

Deploy.

Why?

The ECS Service replaces old containers with new ones using the updated image.

Step 8 – Watch the Rolling Deployment

Open the ECS Service.

Observe:

New task starts.
Health checks pass.
Old task stops.
New task becomes active.

Why?

This is called a rolling deployment. It helps reduce downtime because the new container starts before the old one is removed.

Step 9 – Test the Application

Open the ALB DNS name.

Verify that Version 2 is displayed or that the new feature is available.

Lab Complete

You have successfully:

Deployed Version 2
Created a new Docker image
Pushed it to ECR
Created a new Task Definition revision
Updated the ECS Service
Completed a rolling deployment

Questions

Why did we create a new image instead of modifying v1?
Why is a new Task Definition revision required?
What is a rolling deployment?
How does ECS reduce downtime during deployments?
Why is it useful to keep old image versions in ECR?
What would you do if Version 2 failed after deployment?

Deploy a Developer's Application to AWS Using Docker, Amazon ECR, Amazon ECS, and Application Load Balancer

Aisalkyn Aidarova — Mon, 20 Jul 2026 02:02:33 +0000

Objective

In this lab, you will act as a DevOps Engineer.

The developer (Jules) has already written the application and pushed the source code to GitHub.

Your responsibility is not to write the application.

Your responsibility is to package it, deploy it, and make it available to users.

By the end of this lab, you will:

Build a Docker image
Push the image to Amazon ECR
Deploy the container to Amazon ECS (Fargate)
Configure an Application Load Balancer
Access the application through the browser

Architecture

Developer
      │
      ▼
Application Source Code
      │
      ▼
Docker Image
      │
      ▼
Amazon ECR
      │
      ▼
Amazon ECS (Fargate)
      │
      ▼
Application Load Balancer
      │
      ▼
Users

Scenario

Jules is a Software Developer.

He finished developing the application.

He informs the DevOps team:

"The application is ready. Please deploy it."

Now your work begins.

Step 1 – Open the Project

Open the project in VS Code.

Look at the project structure.

Example:

restaurant-app/

Dockerfile
package.json
src/
public/
README.md

Why?

Before deploying an application, a DevOps engineer needs to understand the project structure.

You should identify:

Which programming language is used
Which package manager is used
Which port the application runs on
Whether a Dockerfile already exists

Step 2 – Verify the Application

Run the application locally.

Example:

npm install

npm start

Open

http://localhost:3000

Verify the application works.

Why?

Never deploy an application you haven't tested.

If it doesn't work locally, it won't work in AWS.

Step 3 – Review the Dockerfile

Open the Dockerfile.

Example:

FROM node:20

WORKDIR /app

COPY package*.json .

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm","start"]

Why?

Docker packages the application and all of its dependencies into a container.

This allows the application to run consistently on any machine.

Step 4 – Build the Docker Image

Run:

docker build -t restaurant-app:v1 .

Verify:

docker images

Expected output:

restaurant-app
v1

Why?

A Docker image is a portable package containing:

Operating System
Runtime
Dependencies
Application Code

Amazon ECS runs Docker images, not source code.

Step 5 – Test the Docker Image

Run:

docker run -d -p 3000:3000 restaurant-app:v1

Open

http://localhost:3000

Verify the application loads successfully.

Why?

Always test the Docker image before pushing it to AWS.

This prevents deployment failures later.

Step 6 – Create an Amazon ECR Repository

Open AWS Console.

Navigate to

Amazon ECR

Click

Create Repository

Repository Name

restaurant-app

Click

Create

Why?

Amazon ECR is a private Docker registry.

It stores Docker images.

Amazon ECS downloads images from Amazon ECR.

Step 7 – Authenticate Docker to Amazon ECR

Run:

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

Expected output:

Login Succeeded

Why?

Docker must authenticate before pushing images into Amazon ECR.

Step 8 – Tag the Docker Image

Run:

docker tag restaurant-app:v1 ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/restaurant-app:v1

Why?

Docker needs to know where the image will be stored.

Tagging associates the image with the ECR repository.

Step 9 – Push the Image

Run:

docker push ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/restaurant-app:v1

Open Amazon ECR.

Verify the image appears.

Why?

Amazon ECS cannot deploy images stored only on your laptop.

The image must first be stored in Amazon ECR.

Step 10 – Create an Amazon ECS Cluster

Navigate to

Amazon ECS

Click

Create Cluster

Choose

Networking only (Fargate)

Cluster Name

restaurant-cluster

Create the cluster.

Why?

The cluster is the environment where containers run.

Using AWS Fargate means AWS manages the servers.

As a DevOps engineer, you don't need to install or patch operating systems.

Step 11 – Create a Task Definition

Create a new Task Definition.

Configure:

Launch Type:
Fargate

Container Image

ECR Image URI

CPU

0.5 vCPU

Memory

1 GB

Port

Save the Task Definition.

Why?

The Task Definition is the blueprint for running the container.

It tells ECS:

Which image to use
CPU allocation
Memory allocation
Port mapping

Step 12 – Create an ECS Service

Inside the cluster

Click

Create Service

Select

Task Definition

Desired Tasks

Launch Type

Fargate

Why?

A Task runs only once.

A Service continuously monitors the application.

If the container crashes, ECS automatically starts a new one.

Step 13 – Create an Application Load Balancer

Navigate to

EC2

Load Balancers

Create

Application Load Balancer

Configure:

Internet Facing

HTTP

Port 80

Why?

Containers have private IP addresses.

Users on the internet cannot access them directly.

The Application Load Balancer receives traffic from users and forwards requests to healthy ECS tasks.

Step 14 – Create a Target Group

Create a Target Group.

Type

IP

Health Check Path

Why?

The Target Group monitors the health of the application.

Only healthy containers receive traffic.

Step 15 – Connect ECS Service to the Load Balancer

Edit the ECS Service.

Attach

Application Load Balancer

Select

Target Group

Container Port

Deploy.

Why?

Without connecting ECS to the Load Balancer, users cannot reach the application.

Step 16 – Test the Application

Copy the ALB DNS name.

Example:

http://restaurant-alb-123456.us-east-1.elb.amazonaws.com

Open it in your browser.

Verify that the application loads successfully.

Lab Complete

Congratulations!

You have successfully completed the responsibilities of a DevOps Engineer:

✅ Received application code from the developer
✅ Built a Docker image
✅ Tested the container locally
✅ Created an Amazon ECR repository
✅ Pushed the image to Amazon ECR
✅ Created an Amazon ECS cluster
✅ Created a Task Definition
✅ Created an ECS Service
✅ Created an Application Load Balancer
✅ Deployed the application to AWS

Questions

Why do we use Docker instead of deploying source code directly?
What is the purpose of Amazon ECR?
Why can't Amazon ECS run source code directly?
What information is stored in an ECS Task Definition?
What is the difference between an ECS Task and an ECS Service?
Why do we need an Application Load Balancer?
What happens if an ECS task becomes unhealthy?
Why do we test the Docker container before pushing it to ECR?
What would happen if the security group did not allow traffic from the ALB to ECS?
In your own words, describe the complete deployment flow from the developer's code to the running application.

This is a beginner-friendly lab that closely reflects a real-world DevOps deployment workflow while keeping the scope focused on Docker → ECR → ECS → ALB before introducing CI/CD in later labs.

7-Month Cybersecurity Engineer Roadmap

Aisalkyn Aidarova — Thu, 16 Jul 2026 19:53:28 +0000

Duration: 7 Months (28 Weeks)

Each month includes:

Theory
Hands-on labs
Enterprise project
Interview preparation

By graduation, every student should have:

5 enterprise projects
1 capstone
GitHub portfolio
LinkedIn profile
Resume showing enterprise experience
Experience with 40–50 industry tools

Month 1 — IT & Networking Foundations

Goal

Become a junior system administrator before learning security.

Week 1

Computer Hardware

CPU
RAM
SSD
HDD
BIOS
UEFI
Motherboard
NIC

Networking

IP Address
MAC Address
DNS
DHCP
TCP/IP
OSI Model
HTTP
HTTPS
SSH
VPN

Tools

Wireshark
Nmap
Cisco Packet Tracer

Week 2

Linux Administration

Skills

Linux filesystem
users
groups
permissions
sudo
services
logs
SSH

Tools

Ubuntu
Kali Linux
Bash
Vim

Week 3

Windows Administration

Skills

Windows Server
Active Directory
Group Policy
DNS
DHCP
Event Viewer

Tools

PowerShell
Active Directory Users & Computers

Week 4

Git

GitHub

Python Basics

REST API

JSON

Virtualization

VMware

VirtualBox

Enterprise Project

Build a company network with

Windows Domain Controller
Linux Server
Active Directory
DNS
DHCP
File Server
GitHub Repository

Month 2 — Security Foundations

Goal

Learn how hackers attack systems.

Week 5

Linux Security

SSH hardening
firewall
ufw
iptables

Week 6

Windows Security

Group Policy
Windows Defender
BitLocker
Event Logs

Week 7

Network Security

Firewalls
IDS
IPS
VPN
NAC

Tools

pfSense
Snort
Suricata
Zeek

Week 8

Web Security

OWASP Top 10

SQL Injection
XSS
CSRF
Authentication
Session Hijacking

Tools

Burp Suite
OWASP ZAP
Postman

Enterprise Project

Secure a company network and web application.

Month 3 — SOC & Detection Engineering

Goal

Become a SOC Analyst.

Week 9

SIEM

Splunk

Microsoft Sentinel

Elastic

Week 10

Windows Logging

Sysmon

Windows Events

Event Forwarding

Week 11

Threat Hunting

MITRE ATT&CK

Sigma Rules

IOC

IOA

Threat Intelligence

Week 12

Detection Engineering

Tools

Sigma
YARA
Velociraptor

Students create

detection rules
dashboards
alerts

Enterprise Project

Build an enterprise SOC.

Generate attacks.

Detect them.

Write reports.

Month 4 — Incident Response & Digital Forensics

Goal

Become Incident Responder.

Week 13

Incident Response Lifecycle

NIST

MITRE

Playbooks

Week 14

Memory Forensics

Tools

Volatility

FTK Imager

Autopsy

Week 15

Malware Analysis

Tools

PEStudio

Any.Run

VirusTotal

ProcMon

Process Explorer

Week 16

Threat Intelligence

MISP

Shodan

AbuseIPDB

GreyNoise

AlienVault OTX

Enterprise Project

Simulate ransomware attack.

Contain.

Recover.

Write executive report.

Month 5 — Cloud Security + DevSecOps

Goal

Protect cloud infrastructure.

Week 17

AWS

IAM

VPC

EC2

CloudTrail

CloudWatch

Security Groups

Week 18

AWS Security

GuardDuty

Inspector

Security Hub

AWS Config

KMS

Secrets Manager

Week 19

Containers

Docker

Docker Security

Kubernetes

RBAC

Network Policies

Week 20

DevSecOps

GitHub Actions

Jenkins

Terraform

SonarQube

Trivy

Checkov

Semgrep

OWASP Dependency Check

Enterprise Project

Deploy secure cloud application.

Implement CI/CD.

Add security scanning.

Month 6 — Red Team + Purple Team

Goal

Understand attacker mindset.

Week 21

MITRE ATT&CK

Atomic Red Team

Week 22

Active Directory Attacks

BloodHound

Impacket

Responder

Kerberoasting

Week 23

Ethical Hacking

Metasploit

Burp

Nmap

Hydra

SQLMap

Week 24

Purple Team

Caldera

MITRE

Detection Validation

Enterprise Project

Blue Team detects attacks generated by Red Team.

Month 7 — Enterprise Experience

Goal

Work exactly like a Cybersecurity Engineer.

Week 25

Project 1

Enterprise SOC

Week 26

Project 2

Cloud Security Engineer

Secure AWS infrastructure.

Week 27

Project 3

DevSecOps Engineer

Secure CI/CD pipeline.

Week 28

Capstone

Students build an enterprise security environment.

They present to instructors acting as CIO, CISO, and Security Director.

Interview Preparation (Every Week)

Every week students practice:

Tell me about yourself
Incident response scenarios
SOC analyst questions
Windows troubleshooting
Linux troubleshooting
Cloud troubleshooting
Active Directory
Threat hunting
Malware analysis
Detection engineering
AWS security
DevSecOps
Behavioral interview
Resume review
LinkedIn optimization

Enterprise Projects (Portfolio)

By graduation, each student completes:

Enterprise Windows Active Directory Domain
SOC with Splunk/Sentinel
Ransomware Incident Response
Secure AWS Cloud Environment
DevSecOps Pipeline (GitHub Actions, Terraform, Docker, Kubernetes)
Purple Team Attack & Detection Lab
Capstone Enterprise Security Architecture

Skills After Graduation

Students should be able to:

Build and secure Windows Active Directory environments
Administer Linux servers securely
Analyze network traffic with Wireshark and Zeek
Detect attacks using Splunk, Sentinel, and Sigma rules
Perform threat hunting and digital forensics
Respond to incidents using industry-standard playbooks
Secure AWS workloads using IAM, GuardDuty, Security Hub, Inspector, Config, and KMS
Build secure CI/CD pipelines with GitHub Actions, Jenkins, Terraform, Docker, Kubernetes, SonarQube, Trivy, Checkov, and Semgrep
Conduct vulnerability assessments and web application testing
Collaborate with developers, DevOps engineers, and IT teams
Produce executive reports and communicate technical findings to management
Pass technical interviews for Cybersecurity Engineer, Cloud Security Engineer, SOC Analyst, Incident Response Analyst, Security Engineer, and DevSecOps Engineer roles.

This roadmap is intentionally designed around how enterprise security teams operate, so students are learning workflows and projects that closely resemble real production environments rather than isolated labs.

cybersecurity program

Aisalkyn Aidarova — Thu, 16 Jul 2026 19:49:21 +0000

to get students hired as cybersecurity engineers in the U.S.

If your goal is:

✅ 7 months
✅ Students become employable
✅ Resume with 5 years of experience (through realistic enterprise projects)
✅ Pass technical interviews

then they need to learn much more than what is listed on that poster.

Phase 1. Computer & Networking (Weeks 1-4)

Without this foundation students struggle later.

Operating Systems

Windows 10/11
Windows Server
Active Directory
Linux (Ubuntu)
Kali Linux

Networking

OSI Model
TCP/IP
DNS
DHCP
HTTP/HTTPS
SSH
FTP
SMTP
VPN
Firewalls
Routing
VLAN
NAT

Tools

Wireshark
Nmap
tcpdump
PuTTY
OpenSSH
VirtualBox
VMware

Phase 2. Linux Administration

Students should become comfortable using Linux every day.

Topics

users
groups
permissions
chmod
chown
grep
awk
sed
cron
bash scripting
services
systemctl
journalctl

Tools

Bash
Vim
Nano
Git

Phase 3. Windows Administration

Topics

Active Directory
Group Policy
DNS
DHCP
Certificate Services
PowerShell
Windows Event Logs

Tools

PowerShell
Active Directory Users and Computers
Event Viewer

Phase 4. Python

Students do NOT need to become software developers.

Enough to automate.

Topics

requests
json
csv
API
file automation

Libraries

requests
pandas
psutil

Phase 5. SIEM (SOC)

This is where companies hire.

Tools

✅ Splunk

✅ Microsoft Sentinel

✅ Elastic SIEM

✅ QRadar

Concepts

Log ingestion
Dashboards
Alerts
Correlation Rules
MITRE ATT&CK Mapping

Phase 6. Threat Hunting

Tools

Sysmon
Sigma Rules
Velociraptor
Chainsaw
Hayabusa
KAPE

Students should investigate

malware
persistence
credential dumping
lateral movement

Phase 7. Incident Response

Tools

Velociraptor
FTK Imager
Autopsy
Volatility3
Redline

Students learn

Memory analysis
Disk analysis
Timeline
IOC creation

Phase 8. Malware Analysis

Beginner level

Tools

PEStudio
Detect It Easy
VirusTotal
Any.Run
ProcMon
Process Explorer

Phase 9. Cloud Security

This is extremely important because many companies are moving workloads to the cloud.

AWS

IAM
EC2
VPC
Security Groups
CloudTrail
GuardDuty
Security Hub
Inspector
Config
CloudWatch
S3 Security
KMS

Azure

Azure Defender
Sentinel
Entra ID
Key Vault

Phase 10. DevSecOps

Most bootcamps ignore this.

Tools

Git

GitHub

GitHub Actions

Docker

Kubernetes

Terraform

Jenkins

Trivy

OWASP Dependency Check

SonarQube

Semgrep

Checkov

Snyk

Phase 11. Web Security

Tools

Burp Suite

OWASP ZAP

Postman

ffuf

Gobuster

Nikto

SQLMap

Topics

OWASP Top 10

XSS

SQL Injection

CSRF

Authentication

JWT

API Security

Phase 12. Vulnerability Management

Tools

Tenable Nessus

OpenVAS

Qualys

Nuclei

Phase 13. Email Security

Tools

Microsoft Defender

Proofpoint

Mimecast

Topics

SPF

DKIM

DMARC

Phishing

BEC

Phase 14. Identity Security

Tools

Microsoft Entra ID

Okta

Duo

CyberArk

HashiCorp Vault

Phase 15. Threat Intelligence

Tools

MISP

VirusTotal

AbuseIPDB

Shodan

GreyNoise

AlienVault OTX

Phase 16. Detection Engineering

Tools

Sigma

YARA

Suricata

Snort

Zeek

Students should write

Sigma rules
YARA rules
Detection logic

Phase 17. Purple Team

Exactly what your tutor teaches.

Tools

MITRE ATT&CK

Atomic Red Team

Caldera

Metasploit

BloodHound

CrackMapExec

Responder

Impacket

Phase 18. Reporting

Students should know how to write

Incident Reports
Executive Summary
Risk Assessment
Vulnerability Reports
Remediation Plans

Phase 19. Professional Skills

Recruiters care about these too.

Students should learn

Resume
LinkedIn
Technical interview
Behavioral interview
STAR method
Communication
Documentation

Enterprise Projects (This is what creates "5 years of experience")

Instead of only labs, students should complete projects that resemble real work:

Project 1 – Enterprise SOC

Build a Windows Active Directory domain
Generate attack traffic
Collect logs in Splunk
Create alerts
Investigate incidents

Project 2 – Ransomware Incident Response

Simulate ransomware
Contain affected hosts
Recover systems
Produce an executive report

Project 3 – AWS Cloud Security

Deploy an application in AWS
Configure CloudTrail, GuardDuty, Security Hub, IAM least privilege
Detect and investigate suspicious activity

Project 4 – DevSecOps Pipeline

Build a CI/CD pipeline with GitHub Actions or Jenkins
Integrate SonarQube, Trivy, Semgrep, and Checkov
Deploy to Docker/Kubernetes
Remediate vulnerabilities and redeploy

Project 5 – Purple Team Capstone

Use Atomic Red Team or Caldera to emulate attacks
Detect them with Splunk or Microsoft Sentinel
Hunt threats, perform incident response, and present findings to "management"

Recommended tool stack for a 2026 job-ready cybersecurity bootcamp

Category	Primary Tools
Operating Systems	Windows Server, Ubuntu, Kali
Networking	Wireshark, Nmap
SIEM	Splunk, Microsoft Sentinel
Threat Hunting	Sysmon, Sigma, Velociraptor
Incident Response	Autopsy, FTK Imager, Volatility3
Vulnerability Scanning	Nessus, OpenVAS
Web Security	Burp Suite, OWASP ZAP, Postman
Cloud Security	AWS (CloudTrail, GuardDuty, Security Hub, IAM)
DevSecOps	Git, GitHub, Docker, Kubernetes, Terraform, Jenkins, SonarQube, Trivy, Semgrep, Checkov
Threat Intelligence	VirusTotal, MISP, Shodan, AbuseIPDB
Detection Engineering	Sigma, YARA, Zeek, Suricata

This combination gives students exposure to the tools and workflows commonly encountered in SOC Analyst, Incident Response, Cloud Security, Security Engineer, and DevSecOps roles. Combined with strong enterprise-style projects and interview preparation, it provides a much stronger foundation for entering the cybersecurity job market than the Purple Team curriculum alone.

strong senior-level DevOps/Platform Engineer answers.

Aisalkyn Aidarova — Thu, 16 Jul 2026 14:38:59 +0000

Based on this interview transcript, these are the questions the interviewers asked (or were trying to ask), along with strong senior-level DevOps/Platform Engineer answers.

1. Tell me about yourself.

What they are testing

Communication
Career progression
Why you are changing jobs

Strong Answer

I have around eight years of experience in infrastructure, cloud, and DevOps engineering. I started my career as a System Administrator, which gave me a strong Linux, networking, and infrastructure foundation. From there I moved into Cloud Engineering where I worked extensively with AWS, GCP, Kubernetes, CI/CD automation, and Infrastructure as Code.

During my career I've helped modernize deployment processes, automate infrastructure with Terraform, migrate applications to Kubernetes, and improve software delivery through GitHub Actions and GitOps practices.

In my current role I work closely with developers, security teams, and platform engineers to maintain production Kubernetes clusters, build CI/CD pipelines, improve observability, and support cloud infrastructure.

I'm now looking for a role where I can work on larger platform engineering challenges, contribute to architectural decisions, and continue growing technically.

2. Your resume says deployments became 40% faster. What exactly made them faster?

What they are testing

Did YOU understand the improvement?

Strong Answer

The speed improvement wasn't simply because we moved from Jenkins to GitHub Actions. The improvement came from redesigning the entire delivery process.

We reduced manual steps, optimized pipeline stages, introduced parallel execution where possible, improved dependency caching, reduced unnecessary Docker rebuilds, and integrated directly with GitHub instead of maintaining separate Jenkins jobs.

GitHub Actions also simplified authentication and repository integration, reducing operational overhead.

Overall deployment time improved because the pipeline became more efficient, easier to maintain, and required less manual intervention.

3. Why did moving from Jenkins to GitHub Actions improve deployment?

Strong Answer

GitHub Actions integrates directly with GitHub repositories, so there is no need to manage separate Jenkins jobs, webhooks, or credentials in many cases.

The workflows are stored as YAML alongside the application code, making version control and code review much easier.

GitHub-hosted or self-hosted runners scale more easily than maintaining Jenkins agents.

We also eliminated plugin management, which was one of the biggest maintenance burdens in Jenkins.

The improvement wasn't because Jenkins is bad—Jenkins is extremely powerful—but GitHub Actions was a better fit for our GitHub-centric development workflow.

4. Suppose your manager says:

Jenkins works fine. Why should we migrate?

Strong Answer

I wouldn't argue that Jenkins is wrong. Instead I'd present measurable business benefits.

I'd compare:

maintenance effort

plugin upgrades

security patching

onboarding time

pipeline reliability

deployment speed

operational cost

Then I'd propose a proof of concept by migrating one application first.

If the pilot demonstrates lower maintenance, faster deployments, and improved developer experience, then we can gradually migrate additional projects.

Senior engineers convince people with data, not opinions.

5. What arguments would you use to convince someone to migrate?

Strong Answer

I would explain that:

GitHub Actions keeps CI/CD configuration inside the repository.

Developers own their pipelines.

Less infrastructure maintenance.

Fewer Jenkins plugins.

Better GitHub integration.

Easier secrets management.

Easier code reviews.

Better scalability with runners.

Reduced operational overhead.

I would also present metrics from a pilot project instead of relying on personal preference.

6. Do you use GitHub-hosted runners or self-hosted runners?

Strong Answer

We use self-hosted runners connected to our internal infrastructure because many deployments require access to private Kubernetes clusters, internal services, private container registries, and corporate networks.

Self-hosted runners also provide more control over installed software and security policies.

7. How do you know if your CI/CD pipeline is healthy?

This was one of their favorite questions.

Strong Answer

A healthy pipeline isn't just one that passes.

I monitor several indicators:

Success rate

Pipeline duration

Failure trends

Queue times

Runner availability

Deployment success rate

Rollback frequency

Test stability

Security scan completion

I also monitor infrastructure supporting the pipeline, including runner CPU, memory, disk space, Kubernetes cluster health, network connectivity, and artifact repositories.

Finally, I verify post-deployment health using monitoring dashboards, application logs, readiness probes, and production alerts.

8. How do you know if a failing pipeline is caused by infrastructure instead of developer code?

This is actually a very senior Platform Engineering question.

Strong Answer

I start by identifying where the failure occurred.

If compilation or unit tests fail immediately after a code change, it's likely an application issue.

If unrelated pull requests suddenly begin failing at the same stage, that's a strong indicator of infrastructure or shared environment issues.

I compare:

Recent pipeline history

Multiple PR failures

Runner logs

Kubernetes cluster health

Network connectivity

Container registry availability

Cloud service status

If many unrelated builds fail simultaneously, I investigate the CI infrastructure rather than the application code.

9. Suppose you have 100 pull requests and tests randomly fail. How do you identify flaky tests?

Excellent question.

Strong Answer

I first review historical execution data.

If the same test fails across unrelated code changes and passes when rerun without modifications, it's likely flaky.

I analyze:

Failure frequency

Test duration

Retry success rate

Environment consistency

Infrastructure logs

I compare failures across multiple pull requests.

If unrelated changes fail the same test, the problem is likely the test or environment rather than the application.

10. How do you distinguish infrastructure failures from flaky tests?

Strong Answer

Infrastructure failures usually affect many pipelines simultaneously.

Examples include:

Kubernetes unavailable

Docker registry unavailable

DNS failures

Runner offline

Network outages

Cloud API failures

Flaky tests usually:

Fail inconsistently

Pass after rerun

Fail without code changes

Are isolated to specific test suites

Looking at historical patterns helps distinguish between the two.

11. How do you manage technical debt?

Strong Answer

Technical debt should be managed continuously rather than postponed indefinitely.

During sprint planning we reserve capacity specifically for technical improvements.

We prioritize debt based on business impact, operational risk, and engineering productivity.

Larger items become backlog stories with estimated effort, while smaller improvements are completed alongside feature work.

This prevents technical debt from accumulating to the point where it slows future delivery.

12. How do you convince management to spend time reducing technical debt?

Strong Answer

I connect technical debt to business outcomes.

For example:

slower deployments

increased outages

higher maintenance costs

slower feature delivery

increased operational risk

Rather than saying "the code needs cleaning," I explain how reducing technical debt improves delivery speed, reliability, and customer experience.

13. Should technical debt always be fixed immediately?

Strong Answer

No.

We prioritize technical debt based on risk and business value.

Critical security issues or production stability problems should be addressed immediately.

Lower-priority improvements are scheduled into future sprints to balance feature delivery with long-term maintainability.

14. Why do companies migrate from Jenkins to GitHub Actions?

Strong Answer

Companies migrate when:

Source code is already hosted in GitHub.

They want simpler pipeline management.

They want Infrastructure as Code for CI/CD.

They want fewer plugins.

They want easier maintenance.

They want tighter GitHub integration.

They want better developer experience.

However, organizations with very complex enterprise workflows often continue using Jenkins because it provides greater flexibility and plugin extensibility.

These are classic senior DevOps/Platform Engineering interview questions. The interviewers were less interested in tool names and more interested in your engineering reasoning, troubleshooting approach, and ability to justify technical decisions with operational and business benefits.

interveiw questions

Aisalkyn Aidarova — Tue, 14 Jul 2026 22:49:21 +0000

What is Docker?
What is a Docker image?
What is a Docker container?
What is the difference between a Docker image and a Docker container?
Why do companies use Docker?
What problem does Docker solve?
Which command lists running Docker containers?
Which command lists all Docker containers?
Which command lists Docker images?
Which command builds a Docker image?
Which command starts a Docker container?
Which command stops a Docker container?
Which command removes a Docker container?
Which command removes a Docker image?
Which command downloads an image from Docker Hub?
Which command uploads an image to Docker Hub?
What is a Dockerfile?
What is the purpose of a Dockerfile?
Which instruction specifies the base image in a Dockerfile?
Which instruction copies files into a Docker image?
Which instruction installs software during the image build?
Which instruction specifies the default command to run?
What is the purpose of EXPOSE in a Dockerfile?
What is a Docker volume?
Why are Docker volumes important?
What is Docker networking?
What is the bridge network in Docker?
What happens when a Docker container stops?
Do Docker containers share the host operating system kernel?
Why are containers faster than virtual machines?
What is Docker Hub?
Why do developers use Docker Hub?
What is a Docker registry?
Is Docker Hub public or private?
What is an official Docker image?
Why should you use official Docker images?
What command logs into Docker Hub?
What command pushes an image to Docker Hub?
What command pulls an image from Docker Hub?
Why would a company use private repositories in Docker Hub?
What does ECR stand for?
What is Amazon ECR?
Why do companies use Amazon ECR instead of Docker Hub?
Is Amazon ECR public or private by default?
Which AWS service commonly pulls images from ECR?
Can Amazon ECR scan images for vulnerabilities?
How do you authenticate Docker with ECR?
What happens if ECR authentication expires?
Why is image scanning important?
What does ECR store?
What does EC2 stand for?
What is an EC2 instance?
Why do companies use EC2?
What operating systems can run on EC2?
What is a key pair in EC2?
Why is SSH used?
What is the default SSH port?
What is the default HTTP port?
What is the default HTTPS port?
What is an Elastic IP?
What is Amazon EBS?
Why are EBS volumes important?
What is an EC2 Security Group?
Why do we use Security Groups?
What happens if port 22 is blocked?
What happens if port 80 is blocked?
What is User Data in EC2?
What is an EC2 AMI?
Why do companies create custom AMIs?
What is the difference between stopping and terminating an EC2 instance?
What does ALB stand for?
What is an Application Load Balancer?
Why do companies use an ALB?
Which OSI layer does ALB operate on?
What protocols does ALB support?
What is a Target Group?
What is a Health Check?
Why are Health Checks important?
What happens if one EC2 instance becomes unhealthy?
Can one ALB route traffic to multiple applications?
What is path-based routing?
What is host-based routing?
Why does an ALB improve availability?
What happens if there is no Load Balancer?
Can ALB distribute traffic across multiple Availability Zones?
What does ASG stand for?
What is an Auto Scaling Group?
Why do companies use Auto Scaling?
What is Scale Out?
What is Scale In?
What is Desired Capacity?
What is Minimum Capacity?
What is Maximum Capacity?
Which AWS service provides metrics for Auto Scaling?
Which metric commonly triggers Auto Scaling?
What happens when CPU usage reaches 90%?
What happens when traffic decreases?
How does Auto Scaling help reduce costs?
Can Auto Scaling replace failed EC2 instances automatically?
Why is Auto Scaling important for production?
What is a CPU?
What is the main function of a CPU?
What does CPU utilization mean?
What happens when CPU usage reaches 100%?
What is RAM?
Why is RAM important?
What happens when RAM is full?
What is swapping?
What is SSD?
What is the difference between SSD and HDD?
Which is faster: SSD or HDD?
Why do companies prefer SSDs?
Which component stores files permanently?
Which component temporarily stores running applications?
Which component performs calculations?
What is hardware?
What is software?
What is firmware?
What is a motherboard?
What is BIOS?
What is UEFI?
What is a GPU?
What is a Network Interface Card (NIC)?
What is a power supply (PSU)?
What is a server?
What is a workstation?
What is a laptop?
What is a peripheral device?
Which components are considered hardware?
Which are examples of software?
What is a network?
What is an IP address?
What is a private IP address?
What is a public IP address?
What is a MAC address?
What is DNS?
What is DHCP?
What is a router?
What is a switch?
What is a firewall?
What is a subnet?
What is a gateway?
What is NAT?
What is ping used for?
What is traceroute used for?
What is latency?
What is bandwidth?
What is packet loss?
What is TCP?
What is UDP?
What is HTTP?
What is HTTPS?
What is FTP?
What is SSH?
What is SSL/TLS?
What is port 22 used for?
What is port 80 used for?
What is port 443 used for?
What is port 53 used for?
What is port 3306 commonly used for?
What does API stand for?
What is an API?
Why do developers use APIs?
What is an API endpoint?
What is a REST API?
What is JSON?
What is XML?
What is an HTTP request?
What is an HTTP response?
What does the GET method do?
What does the POST method do?
What does the PUT method do?
What does the DELETE method do?
What does the PATCH method do?
What is an API client?
What is an API server?
What does HTTP status code 200 mean?
What does HTTP status code 201 mean?
What does HTTP status code 400 mean?
What does HTTP status code 401 mean?
What does HTTP status code 403 mean?
What does HTTP status code 404 mean?
What does HTTP status code 500 mean?
What is authentication?
What is authorization?
What is an API token?
What is a Bearer Token?
What is Postman used for?
What is Swagger/OpenAPI?
Why is API documentation important?
What happens when a developer pushes code to GitHub?
Why is CI/CD important?
What is a build?
What is testing in CI/CD?
What is deployment?
Why do companies use Docker with CI/CD?
Why do companies use ECR with ECS?
Why do companies use ALB with EC2?
How do Auto Scaling and ALB work together?
How do Docker, ECR, EC2, ALB, ASG, APIs, networking, hardware, and software work together in a modern cloud application?

Architecture

                Developer
                    │
            git add .
            git commit
            git push
                    │
                    ▼
              GitHub Repository
                    │
                    ▼
             GitHub Actions (CI/CD)
                    │
        ┌───────────┼────────────┐
        ▼           ▼            ▼
 Build Frontend  Build Backend  Build AI Service
        │           │            │
        ▼           ▼            ▼
 Push to ECR    Push to ECR   Push to ECR
        │           │            │
        └───────────┼────────────┘
                    ▼
              Amazon ECR
                    │
                    ▼
            Amazon ECS Cluster
                    │
        ┌───────────┼────────────┐
        ▼           ▼            ▼
 frontend-service backend-service ai-service
        │           │            │
        ▼           ▼            ▼
     New Tasks   New Tasks    New Tasks

Developer

The developer only does:

git add .

git commit -m "Deploy to Dev"

git push origin main

GitHub Actions

Automatically executes:

Step 1

Checkout latest code

GitHub
↓

Latest Source Code

Step 2

AWS Credentials
↓

Authenticate

Step 3

Docker Login
↓

Amazon ECR

Step 4

Build Frontend

docker build -t frontend ./frontend

Step 5

Tag Frontend

docker tag frontend:latest \
230026708124.dkr.ecr.us-east-1.amazonaws.com/frontend:latest

Step 6

Push Frontend

docker push \
230026708124.dkr.ecr.us-east-1.amazonaws.com/frontend:latest

Step 7

Build Backend

docker build -t backend ./backend

Step 8

Tag Backend

docker tag backend:latest \
230026708124.dkr.ecr.us-east-1.amazonaws.com/backend:latest

Step 9

Push Backend

docker push \
230026708124.dkr.ecr.us-east-1.amazonaws.com/backend:latest

Step 10

Build AI Service

docker build -t ai-service ./ai-service

Step 11

Tag AI Service

docker tag ai-service:latest \
230026708124.dkr.ecr.us-east-1.amazonaws.com/ai-service:latest

Step 12

Push AI Service

docker push \
230026708124.dkr.ecr.us-east-1.amazonaws.com/ai-service:latest

Step 13

Deploy to Dev

aws ecs update-service \
--cluster fde-ai-service \
--service frontend-service \
--force-new-deployment

aws ecs update-service \
--cluster fde-ai-service \
--service backend-service \
--force-new-deployment

aws ecs update-service \
--cluster fde-ai-service \
--service ai-service \
--force-new-deployment

ECS

Amazon ECS notices the deployment.

Old Container

↓

Stop

↓

Pull New Image

↓

Start New Container

This happens independently for:

frontend-service
backend-service
ai-service

Result

Developer

↓

Git Push

↓

GitHub Actions

↓

Docker Build

↓

Amazon ECR

↓

Amazon ECS

↓

Dev Environment Updated

How to explain it in your YouTube video

"The developer never logs into AWS to deploy code. They simply push their changes to GitHub. GitHub Actions builds Docker images for the frontend, backend, and AI service, pushes those images to Amazon ECR, and tells Amazon ECS to start a new deployment. ECS pulls the latest images from ECR, replaces the running containers, and the Dev environment is updated automatically."

One recommendation before you record

For the next version of the project, consider using a dedicated dev branch instead of deploying from main:

feature/login
        │
        ▼
      dev
        │
   GitHub Actions
        │
   Deploy to Dev (ECS)
        │
   Testing / QA
        │
      main
        │
   Production Deployment

That lets you demonstrate a more realistic enterprise workflow where developers merge to dev for testing, and only approved changes reach main for production.

LEVEL 2 – CI/CD Production Deployment with GitHub Actions

Aisalkyn Aidarova — Sat, 11 Jul 2026 00:51:36 +0000

Production Scenario

You joined ABC Financial Bank as a Junior DevOps Engineer.

Developers don't want to send ZIP files anymore.

They don't want you to SSH into servers every day.

Every time a developer pushes code to GitHub:

The application should automatically build.

Tests should run.

A Docker image should be created.

The application should automatically deploy to AWS EC2.

Users should immediately see the new version.

This is Continuous Integration (CI) and Continuous Deployment (CD).

What Students Will Learn

Git

Repository
Commit
Branch
Merge
Clone
Pull
Push
Remote
HEAD
Merge conflicts

GitHub

Repository
Branch protection
Pull Requests
Issues
Secrets
Actions
Collaboration
Forks

GitHub Actions

Workflow
Runner
Jobs
Steps
Events
Triggers
Secrets
Variables
SSH Deployment

Docker

Dockerfile
Image
Container
Build
Push
Pull
Restart
Remove
Volumes
Networks

AWS

EC2
Security Groups
Elastic IP
IAM
SSH Keys
CloudWatch (introduction)

Linux

SSH
chmod
chown
systemctl
apt
nano
vim
journalctl
docker logs
ps
top

Networking

IP
DNS
HTTP
HTTPS
TCP
Ports
SSH
NAT
Security Groups
Load Balancer (preview)

API

REST
HTTP Methods
JSON
Headers
Status Codes
curl
Postman

DevOps Concepts

CI
CD
Automation
Build
Test
Release
Deployment
Rollback
Monitoring

Final Architecture

Developer

↓

Git

↓

GitHub Repository

↓

GitHub Actions

↓

Ubuntu Runner

↓

SSH

↓

AWS EC2

↓

Docker Build

↓

Docker Container

↓

Application

↓

Browser

Module 1 – Introduction

What is Hardware?

Hardware is the physical equipment.

Examples

CPU
RAM
SSD
Motherboard
Network Card

Explain

Without hardware nothing can run.

What is Software?

Software is instructions.

Examples

Linux

Docker

Git

Python

Chrome

Nginx

Question

Can software exist without hardware?

No.

Can hardware work without software?

No.

Module 2 – How Internet Works

Show

Browser

↓

Internet

↓

AWS

↓

Linux Server

↓

Docker

↓

Application

Explain every layer.

Students understand what happens after pressing Enter.

Module 3 – Client Server

Client

↓

Requests information

Server

↓

Returns information

Example

Browser

↓

Amazon

↓

Product page

Module 4 – HTTP

Teach

GET

POST

PUT

PATCH

DELETE

Explain real examples.

Amazon

Facebook

Netflix

Banking

Status Codes

200

201

301

400

401

403

404

500

502

503

Module 5 – REST API

Students build

GET

/products

POST

/products

DELETE

/products

Test

Postman

curl

Browser

Module 6 – Git

Explain

Git is local.

GitHub is remote.

Diagram

Laptop

↓

Git

↓

GitHub

Commands

git init

git status

git add

git commit

git log

git diff

git restore

git branch

git switch

git merge

git clone

git fetch

git pull

git push

Explain every command.

Why it exists.

Where companies use it.

Module 7 – GitHub

Repository

Branch

Pull Request

Review

Merge

Actions

Secrets

Students create

Production branch

Development branch

Feature branch

Workflow

Developer

↓

feature/login

↓

Pull Request

↓

Review

↓

Merge

↓

main

Module 8 – Docker

Explain

Why Docker exists.

Problem before Docker.

"It works on my machine."

Docker solves

Different operating systems.

Different libraries.

Different environments.

Students build

Dockerfile

Build Image

Run Container

Stop Container

Remove Container

Volumes

Networks

Explain difference

Image

Container

Registry

Module 9 – AWS

Launch EC2

Ubuntu

Security Groups

SSH

Elastic IP

Docker installation

Git installation

Explain

Why cloud?

Why not physical servers?

Module 10 – SSH

Generate keys

ssh-keygen

Explain

Private key

Public key

Encryption

Authentication

Students login

ssh ubuntu@EC2-IP

Module 11 – GitHub Secrets

Create

HOST

USERNAME

SSH_KEY

Explain

Why passwords should never be in workflows.

Module 12 – GitHub Actions

Explain

GitHub Actions is a CI/CD platform.

Workflow

↓

Runner

↓

Job

↓

Step

Students create

.github/

workflows/

deploy.yml

Trigger

on:

push:

branches:

- main

Explain

Developer pushes.

Workflow starts.

Module 13 – Build Pipeline

Steps

Checkout

Install

Build

Test

Deploy

Explain each stage.

Students write

Checkout

↓

Docker Build

↓

SSH

↓

Deploy

Module 14 – Deployment Pipeline

Workflow

Developer

↓

git push

↓

GitHub

↓

GitHub Actions

↓

SSH

↓

EC2

↓

docker stop

↓

docker rm

↓

docker build

↓

docker run

Students understand

No manual deployment.

Module 15 – Linux Production

Students practice

systemctl

journalctl

docker logs

docker ps

top

free

netstat

kill

pkill

tail

cat

less

nano

chmod

Explain when DevOps engineers use each command.

Module 16 – Docker Logs

Students break application.

Read logs.

Fix application.

Deploy again.

Exactly what companies do.

Module 17 – Rollback

Bad deployment.

Website broken.

Restore previous version.

Students understand

Rollback.

Module 18 – Versioning

Deploy

Rollback

Students finally understand Docker tags.

Module 19 – Production Security

Secrets

SSH Keys

Least Privilege

IAM

Security Groups

HTTPS overview

Never expose credentials

Module 20 – Troubleshooting Scenarios

Students solve real incidents.

Scenario 1

GitHub Action failed.

Find logs.

Scenario 2

Docker build failed.

Fix Dockerfile.

Scenario 3

SSH permission denied.

Fix key.

Scenario 4

Website unavailable.

Check

EC2

↓

Docker

↓

Container

↓

Logs

↓

Ports

↓

Security Groups

Scenario 5

Container exited.

Read logs.

Restart.

Scenario 6

Application running

Browser doesn't open

Check

Port mapping

Security Group

Firewall

Scenario 7

Developer says

"I pushed code."

Production unchanged.

Investigate

GitHub Actions

↓

Deployment

↓

Container

↓

Browser cache

Final Enterprise Workflow

Developer

↓

Git Add

↓

Git Commit

↓

Git Push

↓

GitHub Repository

↓

GitHub Actions Trigger

↓

GitHub Runner

↓

Checkout Code

↓

Build Docker Image

↓

(Optional: Run Unit Tests)

↓

SSH to EC2

↓

Pull Latest Code

↓

Stop Old Container

↓

Remove Old Container

↓

Build New Docker Image

↓

Run New Container

↓

Health Check

↓

Users Access Website

You're absolutely right. What I gave you was the curriculum, not the project.

A DevOps engineer learns best by working on one realistic project from start to finish. The project should evolve as new technologies are introduced, just like it does in a real company.

Level 2 Project

Project: FreshMart Online Grocery Store

Instead of deploying a simple HTML page, students deploy a small application that looks like a real business.

Company Story

FreshMart is an online grocery company.

Developers built a new version of the website.

Customers use the website every day.

Your DevOps team is responsible for deploying every new release safely and automatically.

Final Architecture

                     Customer

                        │

                        ▼

                Internet Browser

                        │

                        ▼

                  AWS EC2 Ubuntu

                        │

                Docker Container

                        │

              Flask API Application

                        │

                products.json

                        │

                 GitHub Repository

                        ▲

                        │

              GitHub Actions CI/CD

                        ▲

                        │

                 Developer Laptop

Notice there is now an application, not just static HTML.

What Students Build

freshmart-app/

│

├── app.py

├── products.json

├── templates/

│      index.html

├── static/

│      style.css

│

├── Dockerfile

├── requirements.txt

├── .github/

│      workflows/

│             deploy.yml

└── README.md

This is exactly what many small production applications look like.

What Does the Application Do?

Customers open

http://server-ip

They see

FreshMart Grocery

--------------------------

Apple

Milk

Eggs

Rice

Orange Juice

Chicken

Bread

The page loads data from an API.

API Endpoints

Students create

GET /products

Returns

[
  {
    "id":1,
    "name":"Milk",
    "price":4.99
  },
  {
    "id":2,
    "name":"Apple",
    "price":1.29
  }
]

Second endpoint

GET /health

Returns

{
   "status":"healthy"
}

Explain

Production companies use health endpoints.

Load Balancers check

/health

every few seconds.

Third endpoint

GET /

Displays HTML page.

Developer Workflow

Developer changes

products.json

Adds

{
"id":8,
"name":"Watermelon",
"price":7.99
}

Commits

git add .

git commit

git push

DevOps Workflow

GitHub detects

git push

↓

Starts GitHub Actions

↓

Checks out repository

↓

Builds Docker image

↓

Runs syntax check

↓

SSH into EC2

↓

Stops old container

↓

Deletes old container

↓

Builds new image

↓

Runs new container

↓

Deployment complete

Students refresh browser.

Watermelon appears.

Nobody logged into the server manually.

Dockerfile

Students write

FROM python:3.12-slim

WORKDIR /app

COPY . .

RUN pip install -r requirements.txt

EXPOSE 5000

CMD ["python","app.py"]

Now they understand why every line exists.

requirements.txt

Flask

Application

Students write Flask routes.

/

↓

HTML

/products

↓

JSON

/health

↓

Health Check

Now they understand

Frontend

Backend

API

JSON

Browser

CI/CD Workflow

Students create

.github/workflows/deploy.yml

Workflow

Developer Push

↓

GitHub

↓

GitHub Actions

↓

Ubuntu Runner

↓

SSH

↓

EC2

↓

docker stop

↓

docker rm

↓

docker build

↓

docker run

Exactly like production.

Real DevOps Tasks During the Lab

Task 1

Developer says

"I changed prices."

Deploy new version.

Task 2

Developer broke application.

GitHub Action fails.

Find error.

Task 3

Docker container won't start.

Read

docker logs

Task 4

Application works locally.

Not working on EC2.

Investigate.

Students check

Security Group
Port mapping
Flask host
Docker container
EC2 firewall

Task 5

Developer accidentally deleted

products.json

Deployment failed.

Restore using Git.

Task 6

Deploy Version 2

Website header changes

FreshMart Grocery

↓

FreshMart Grocery v2

Students understand versioning.

Task 7

Rollback

Deploy

v1

again.

Explain

Production engineers rollback all the time.

New Features Every Week

Instead of changing projects, students continue improving the same application.

Week 1

Display products

Week 2

Search products

Week 3

Add categories

Week 4

Shopping cart

Week 5

User login

Week 6

Admin dashboard

Week 7

Database

Week 8

Docker Compose

Week 9

Terraform

Week 10

Kubernetes

Why This Project Works

Many bootcamps make students build a new project every week, so they spend more time understanding the business than learning DevOps.

A more realistic approach is to use one application throughout the entire course. As students learn Git, Docker, AWS, CI/CD, Terraform, Kubernetes, and monitoring, they keep enhancing the same project. This mirrors what happens in real companies, where DevOps engineers support and improve an existing application over months or years rather than constantly starting from scratch.