AWS DevOps Engineer Roadmap 2026: A Complete Beginner-to-Job-Ready Guide

Introduction

Are you interested in becoming an AWS DevOps Engineer but don't know where to start?

Are you a fresher with little or no technical experience, confused about which technologies to learn, what order to follow, and how to gain practical experience?

You're not alone.

DevOps is one of the important practices in modern software development. It brings development and operations teams together to improve collaboration, automate repetitive tasks, accelerate software delivery, and maintain reliable applications.

AWS (Amazon Web Services) provides cloud infrastructure and services that help organizations build, deploy, manage, and scale applications. When AWS is combined with DevOps practices and tools such as Linux, Git, Python, Terraform, Docker, Kubernetes, and CI/CD platforms, engineers can automate much of the software delivery lifecycle.

However, learning all these technologies without a proper sequence can be overwhelming.

That's why this guide provides a structured 12–15 month AWS DevOps learning roadmap, designed for beginners who want to progress from computer fundamentals to building and managing production-style cloud environments.

Throughout this roadmap, you'll discover:

• What an AWS DevOps Engineer does.
• Which technical fundamentals you should learn first.
• How to learn Linux, networking, Git, and scripting.
• How to work with AWS cloud services.
• How to automate infrastructure using Terraform.
• How to containerize applications using Docker.
• How to build CI/CD pipelines.
• How to deploy applications using Kubernetes.
• How to implement monitoring, logging, and security.
• Which hands-on projects can help you demonstrate your skills.
• How to prepare for AWS DevOps interviews as a fresher.

Who should read this guide?

This roadmap is suitable for:

• Freshers starting their IT careers.
• Students and recent graduates.
• System administrators interested in cloud technologies.
• Developers interested in learning DevOps.
• Anyone who wants to understand AWS DevOps from the fundamentals.

A quick note: You don't need to learn every tool in the DevOps ecosystem to get your first job. Focus on understanding fundamentals, developing practical skills, and building projects that demonstrate what you know.

Table of Contents

1. What Is DevOps?
2. What Does an AWS DevOps Engineer Do?
3. Computer Fundamentals
4. Linux Administration
5. Networking Fundamentals
6. Git and GitHub
7. Python and Bash Scripting
8. AWS Fundamentals
9. Advanced AWS Services and Cloud Architecture
10. Terraform and Infrastructure as Code
11. Docker and Containerization
12. CI/CD Pipelines and Automation
13. Kubernetes and Container Orchestration
14. AWS Container Services
15. Monitoring, Logging, and Observability
16. Security and DevSecOps
17. Advanced DevOps, GitOps, and SRE
18. Real-World AWS DevOps Project Portfolio
19. Resume, GitHub, Interview Preparation, and Job Search

1. What Is DevOps?

DevOps is a combination of two words: Development (Dev) and Operations (Ops).

It is a set of practices, principles, cultural philosophies, and tools that help development and IT operations teams work together throughout the software development lifecycle.

The primary goal of DevOps is to deliver software faster, improve collaboration, automate repetitive tasks, and maintain application reliability.

1.1 Understanding Traditional Software Development

Before DevOps became widely adopted, many organizations followed a traditional approach in which development and operations teams worked separately.

• Development team: Responsible for writing application code, developing features, and fixing bugs.
• Operations team: Responsible for servers, infrastructure, deployments, application availability, and maintenance.

This separation often created communication gaps.

For example:

1. Developers completed an application and handed it over to the operations team.
2. The operations team attempted to deploy the application.
3. The application failed because of differences between development and production environments.
4. Both teams spent time identifying who was responsible for the issue.

This type of problem is commonly described as the "It works on my machine" problem.

1.2 Why Do We Need DevOps?

DevOps helps organizations overcome these challenges through collaboration and automation.

Some important benefits include:

• Faster software delivery.
• Improved collaboration between teams.
• Continuous Integration and Continuous Delivery (CI/CD).
• Reduced manual work through automation.
• Consistent deployment environments.
• Faster identification and resolution of failures.
• Better application reliability.

1.3 How Does DevOps Work?

DevOps encourages teams to follow a continuous lifecycle.

The commonly represented DevOps lifecycle includes these stages:

1. Plan: Define requirements, tasks, and development goals.
2. Code: Write and maintain application source code.
3. Build: Convert source code into deployable artifacts.
4. Test: Validate application functionality and quality.
5. Release: Prepare an application version for deployment.
6. Deploy: Deliver the application to the target environment.
7. Operate: Manage and maintain the running application.
8. Monitor: Track application performance, availability, and errors.

These stages form a continuous feedback loop. Monitoring results and user feedback help teams plan future improvements.

1.4 Real-World Example

Imagine an organization developing an online shopping application.

Without DevOps, developers might manually send application files to the operations team, who then deploy them to servers.

With DevOps practices:

1. Developers push code to GitHub.
2. A CI/CD pipeline automatically starts.
3. The pipeline builds the application.
4. Automated tests check the application.
5. Docker packages the application into a container.
6. The container image is stored in Amazon ECR.
7. The application is deployed to Amazon EKS.
8. Prometheus and Grafana help monitor application health and performance.

This workflow reduces manual effort and makes application delivery more consistent.

1.5 DevOps Is More Than Just Tools

One common misconception among beginners is that DevOps means simply learning Docker, Kubernetes, Jenkins, and AWS.

However, DevOps is not just a collection of tools.

It also involves:

• Collaboration and communication.
• Automation.
• Continuous improvement.
• Shared responsibility.
• Infrastructure as Code.
• Monitoring and feedback.
• Security throughout the delivery lifecycle.

Key takeaway: DevOps combines people, processes, and technology to help organizations deliver reliable software efficiently and continuously.

2. What Does an AWS DevOps Engineer Do?

An AWS DevOps Engineer is responsible for automating, managing, deploying, and maintaining applications and infrastructure using Amazon Web Services (AWS) and DevOps practices.

The role combines cloud computing, infrastructure management, automation, software deployment, monitoring, and security.

An AWS DevOps Engineer helps development teams deliver applications reliably while ensuring that the underlying infrastructure is scalable, secure, and available.

2.1 Key Responsibilities of an AWS DevOps Engineer

Let's understand the major responsibilities.

1. Cloud Infrastructure Management

AWS DevOps Engineers create and manage cloud infrastructure using services such as:

• Amazon EC2 – Virtual servers.
• Amazon S3 – Object storage.
• Amazon VPC – Network isolation and configuration.
• AWS IAM – Identity and access management.
• Amazon RDS – Managed relational databases.
• Elastic Load Balancing – Distributes incoming application traffic.

2. Infrastructure as Code (IaC)

Instead of creating infrastructure manually through the AWS Management Console, engineers use Infrastructure as Code tools to define and provision resources.

Common tools include:

• Terraform.
• AWS CloudFormation.
• AWS CDK.

For example, Terraform can be used to create an AWS VPC, subnets, security groups, and EC2 instances through configuration files.

3. CI/CD Pipeline Automation

AWS DevOps Engineers build automated pipelines to test, build, and deploy applications.

Common tools include:

• Jenkins.
• GitHub Actions.
• GitLab CI/CD.
• AWS CodePipeline.
• AWS CodeBuild.

4. Containerization

Applications can be packaged with their dependencies using containers.

Common technologies include:

• Docker.
• Amazon Elastic Container Registry (ECR).
• Amazon Elastic Container Service (ECS).
• Amazon Elastic Kubernetes Service (EKS).

5. Configuration Management and Automation

Engineers automate server configuration, software installation, and repetitive administrative tasks.

Common tools include:

• Ansible.
• Python.
• Bash scripting.

6. Monitoring and Logging

Monitoring helps engineers understand application and infrastructure health.

Common tools include:

• Amazon CloudWatch.
• Prometheus.
• Grafana.
• OpenSearch.
• Elasticsearch and Kibana.

7. Security and Access Management

Security is an important responsibility throughout the DevOps lifecycle.

Engineers work with:

• IAM roles and policies.
• Least-privilege access.
• Secrets Manager.
• AWS KMS.
• Security groups.
• Vulnerability scanning tools.

2.2 A Typical Day in the Life of an AWS DevOps Engineer

Here is an example of what an AWS DevOps Engineer might do during a normal working day:

1. Check application health and infrastructure monitoring dashboards.
2. Review code changes and deployment requests.
3. Investigate build or deployment failures.
4. Update infrastructure using Terraform.
5. Maintain CI/CD pipelines.
6. Troubleshoot Docker containers or Kubernetes workloads.
7. Review logs and resolve application issues.
8. Coordinate with developers and other engineering teams.

Responsibilities vary depending on the organization, team size, infrastructure, and seniority of the engineer.

2.3 Skills Required to Become an AWS DevOps Engineer

A beginner should gradually develop skills in the following areas:

Skill area	Technologies
Operating systems	Linux
Networking	TCP/IP, DNS, HTTP, HTTPS
Version control	Git, GitHub
Programming and scripting	Python, Bash
Cloud computing	AWS
Infrastructure as Code	Terraform
Containers	Docker
Container orchestration	Kubernetes
CI/CD	Jenkins, GitHub Actions
Monitoring	CloudWatch, Prometheus, Grafana
Security	IAM, KMS, Secrets Manager

Key takeaway: An AWS DevOps Engineer is not expected to know every tool from day one. The goal is to understand the fundamentals first and gradually develop practical skills through hands-on experience and real-world projects.

3. Phase 1: Computer Fundamentals (Weeks 1–2)

Before learning cloud computing and DevOps tools, it is important to understand basic computer concepts.

You do not need to become a computer hardware expert. However, understanding how computers work will make it easier to learn operating systems, networking, cloud infrastructure, and application deployment.

3.1 Understanding Computer Hardware

A computer consists of several physical components that work together to execute instructions and process information.

The most important components are:

1. CPU (Central Processing Unit)

The CPU is commonly called the brain of a computer.

It executes instructions, performs calculations, and processes data.

In a cloud environment, an AWS EC2 instance uses virtualized computing resources, including CPU capacity, to run applications.

2. RAM (Random Access Memory)

RAM is temporary memory used by a computer to store data and instructions that are currently being processed.

For example, when you run a web server, the operating system and application use RAM while executing.

RAM is volatile, which means its contents are lost when power is removed.

3. Storage

Storage is used to save data permanently, even after a computer is switched off.

Common storage technologies include:

• HDD (Hard Disk Drive).
• SSD (Solid State Drive).
• NVMe SSD.

In AWS, Amazon EBS provides block storage volumes that can be attached to EC2 instances.

4. Network Interface Card (NIC)

A Network Interface Card allows a computer to communicate with other devices over a network.

It can provide wired or wireless network connectivity.

In AWS, an EC2 instance communicates with other resources through virtual network interfaces.

3.2 Understanding Software

Software is a collection of programs and instructions that tell a computer what to do.

Software can be broadly classified into two categories.

1. System Software

System software manages computer hardware and provides the environment required to run applications.

Examples:

• Windows.
• Linux.
• macOS.
• Device drivers.

2. Application Software

Application software helps users perform specific tasks.

Examples:

• Google Chrome.
• Visual Studio Code.
• Microsoft Word.
• Web applications.

3.3 What Is an Operating System?

An Operating System (OS) is system software that manages computer hardware and software resources.

It acts as an interface between users, applications, and computer hardware.

Major responsibilities include:

• Process management.
• Memory management.
• File system management.
• Device management.
• User management.
• Security and access control.

Popular operating systems include:

• Windows.
• Linux.
• macOS.
• Unix.

Why is Linux important for DevOps?

Linux is widely used in cloud infrastructure, servers, containers, and automation environments.

AWS EC2 instances frequently run Linux distributions such as Amazon Linux, Ubuntu, and Red Hat Enterprise Linux.

Therefore, Linux administration is one of the most important foundational skills for an AWS DevOps Engineer.

3.4 Understanding Files, Directories, and File Systems

A file is a collection of information stored on a computer.

A directory (also called a folder) is used to organize files and other directories.

For example, a Linux system contains directories such as:

• /home – User home directories.
• /etc – System and application configuration files.
• /var – Variable data such as logs.
• /tmp – Temporary files.
• /opt – Optional application software.

Understanding the Linux file system will become important when working with servers and troubleshooting applications.

3.5 Understanding Processes and Services

A process is a program that is currently executing.

For example, when you start a Python application, the operating system creates a process to execute it.

A service is a program designed to perform a specific function, often running in the background.

Examples include:

• Web servers.
• Database servers.
• SSH services.
• Monitoring agents.

In DevOps, engineers regularly inspect processes, manage services, and troubleshoot applications that fail to start or consume excessive resources.

3.6 Understanding Client-Server Architecture

Client-server architecture is a computing model in which a client requests a service or resource from a server.

The server receives the request, processes it, and sends a response.

Example: Opening a website

1. A user opens a browser.
2. The browser sends a request to a web server.
3. The web server processes the request.
4. The server sends the requested web page.
5. The browser displays the page to the user.

This architecture is fundamental to understanding web applications, cloud infrastructure, load balancers, and application deployment.

3.7 Understanding Virtualization

Virtualization is a technology that allows multiple virtual computing environments to run on a single physical machine.

A Hypervisor is software that creates and manages virtual machines.

Each virtual machine can have its own operating system and allocated computing resources.

Common examples include:

• VMware.
• Oracle VirtualBox.
• Microsoft Hyper-V.

Why is virtualization important for AWS?

Cloud providers use virtualization and other resource-isolation technologies to provide computing resources to customers.

For example, Amazon EC2 allows users to create virtual server instances without purchasing and maintaining physical servers themselves.

3.8 Introduction to Cloud Computing

Cloud computing is the delivery of computing resources over a network, typically the internet.

Instead of purchasing physical servers, organizations can obtain computing resources from cloud providers.

Popular cloud providers include:

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

Common cloud service models include:

Infrastructure as a Service (IaaS): Provides computing infrastructure such as virtual machines, storage, and networking.

Example: Amazon EC2.

Platform as a Service (PaaS): Provides a managed environment for developing and deploying applications without managing all the underlying infrastructure.

Software as a Service (SaaS): Provides ready-to-use software applications over the internet.

Example: Google Workspace.

3.9 Hands-On Practice

Beginners should perform the following activities:

1. Identify CPU, RAM, and storage details on their computer.
2. Understand the difference between system software and application software.
3. Explore the Windows or Linux file system.
4. Open Task Manager on Windows and identify running processes.
5. Understand how a browser communicates with a web server.
6. Install Oracle VirtualBox and explore how virtual machines work (optional).
7. Explore the AWS website and understand its major service categories.

3.10 Learning Resources

• Computer Fundamentals – GeeksforGeeks
• Linux Documentation
• AWS Cloud Computing Concepts

3.11 Phase 1 Completion Checklist

Before moving to the next phase, make sure you can explain:

• What are CPU, RAM, and storage?
• What is the difference between hardware and software?
• What is an operating system?
• What is the difference between a process and a service?
• What is client-server architecture?
• What is virtualization?
• What is cloud computing?
• What are IaaS, PaaS, and SaaS?

Expected outcome:

By the end of this phase, you should understand basic computer architecture, operating system concepts, virtualization, and cloud computing fundamentals.

These concepts will prepare you for the next phase: Linux Administration.

4. Phase 2: Linux Administration (Weeks 3–6)

Linux is one of the most important operating systems in the DevOps ecosystem.

Many organizations use Linux-based servers to host applications, databases, containers, and cloud infrastructure.

An AWS DevOps Engineer should understand how to work with Linux servers, manage users, configure permissions, troubleshoot processes, analyze logs, and automate administrative tasks.

In this phase, beginners will learn Linux administration from the fundamentals to practical server management.

4.1 What Is Linux?

Linux is an open-source, Unix-like operating system kernel.

Linux distributions combine the Linux kernel with system utilities, package managers, libraries, and other software to provide a complete operating system.

Popular Linux distributions include:

• Ubuntu.
• Amazon Linux.
• Red Hat Enterprise Linux (RHEL).
• Debian.
• Rocky Linux.
• AlmaLinux.

Which Linux distribution should beginners learn?

Ubuntu is a good starting point because it is beginner-friendly and has extensive documentation.

You should also become familiar with Amazon Linux because it is commonly used with AWS EC2 instances.

4.2 Understanding Linux Architecture

A simplified Linux architecture consists of the following layers:

1. Hardware: CPU, RAM, storage, and network devices.
2. Kernel: Manages hardware resources, processes, memory, and device communication.
3. System Libraries: Provide interfaces that applications can use to interact with the kernel.
4. Shell: Provides a command-line interface for executing commands.
5. User Applications: Programs and services running on the operating system.

Understanding these components helps engineers troubleshoot Linux systems effectively.

4.3 Linux File System Hierarchy

Linux organizes files and directories through a hierarchical file system.

Important directories include:

Directory	Purpose
/	Root of the file system
/home	User home directories
/root	Root user's home directory
/etc	System configuration files
/var	Variable data, including logs
/var/log	System and application logs
/tmp	Temporary files
/opt	Optional application software
/usr	User-space programs and shared resources
/bin	Essential user commands
/dev	Device files
/proc	Virtual file system containing process and kernel information
/boot	Files required for booting

An AWS DevOps Engineer frequently works with configuration files, application logs, and system directories.

4.4 Essential Linux Commands

Beginners should become comfortable with command-line operations.

Navigation commands

• pwd – Display the current working directory.
• ls – List files and directories.
• cd – Change the current directory.

File and directory management

• mkdir – Create a directory.
• touch – Create an empty file or update its timestamp.
• cat – Display file contents.
• cp – Copy files and directories.
• mv – Move or rename files and directories.
• rm – Remove files or directories.

File viewing commands

• head – Display the beginning of a file.
• tail – Display the end of a file.
• less – View large files page by page.
• grep – Search for matching text.
• find – Search for files and directories.

System information commands

• uname – Display system information.
• hostname – Display the system hostname.
• whoami – Display the current username.
• df -h – Display file system disk usage.
• free -h – Display memory usage.
• uptime – Display how long the system has been running.

4.5 Linux File Permissions

Linux uses permissions to control who can read, modify, and execute files.

There are three basic permission categories:

• Owner: The user who owns the file.
• Group: Users belonging to the file's group.
• Others: All other users.

The three main permissions are:

Permission	Symbol	Numeric value
Read	r	4
Write	w	2
Execute	x	1

For example:

chmod 755 script.sh

This grants:

• Owner: Read, write, and execute.
• Group: Read and execute.
• Others: Read and execute.

Other important commands include:

• chmod – Change file permissions.
• chown – Change file ownership.
• chgrp – Change group ownership.
• umask – Set default permission restrictions for newly created files.

Understanding permissions is important when troubleshooting application deployment failures and access-related errors.

4.6 Linux User and Group Management

Linux supports multiple users and groups.

User and group management is important for controlling access to servers and applications.

Important commands include:

• useradd – Create a user.
• passwd – Set or change a user's password.
• usermod – Modify user account properties.
• userdel – Delete a user.
• groupadd – Create a group.
• groupdel – Delete a group.
• id – Display user and group IDs.
• groups – Display group memberships.
• sudo – Execute permitted commands with elevated privileges.
• su – Switch to another user.

Important Linux account files:

• /etc/passwd – Stores user account information.
• /etc/shadow – Stores password hashes and password-related information.
• /etc/group – Stores group information.

Never share password hashes or sensitive account information.

4.7 Process Management

A process is an instance of a running program.

DevOps Engineers need to identify running processes, monitor resource consumption, and troubleshoot processes that behave unexpectedly.

Important commands:

• ps – Display process information.
• top – Monitor running processes and resource usage.
• htop – Interactive process monitoring tool, when installed.
• pgrep – Find processes by name or other attributes.
• kill – Send a signal to a process.
• kill -9 – Forcefully terminate a process using SIGKILL.
• nice – Start a process with a specified scheduling priority.
• renice – Change the priority of an existing process.

Use forceful termination carefully because it does not allow a process to perform its normal cleanup.

4.8 Linux Services and Systemd

A service is a program that provides functionality in the background.

Examples include SSH servers, web servers, database servers, and monitoring agents.

Many modern Linux distributions use systemd to manage system services.

Important commands:

• systemctl status service_name – Check service status.
• systemctl start service_name – Start a service.
• systemctl stop service_name – Stop a service.
• systemctl restart service_name – Restart a service.
• systemctl enable service_name – Configure a service to start during boot.
• systemctl disable service_name – Prevent automatic startup during boot.

For example:

sudo systemctl status ssh

The service name can differ between Linux distributions. On some systems, the SSH service is named sshd.

4.9 Package Management

Package managers help install, update, and remove software.

Different Linux distributions use different package management systems.

Ubuntu and Debian

Common commands:

• sudo apt update
• sudo apt upgrade
• sudo apt install package_name
• sudo apt remove package_name

Amazon Linux and RHEL-based distributions

Depending on the distribution and version, common commands include:

• sudo dnf check-update
• sudo dnf install package_name
• sudo dnf update
• sudo dnf remove package_name

Beginners should understand the differences between package managers and avoid blindly executing commands intended for another distribution.

4.10 Disk and Storage Management

Linux administrators should understand how disks and file systems are managed.

Important commands include:

• lsblk – Display block devices.
• blkid – Display block device attributes.
• df -h – Check file system space.
• du -sh directory_name – Check directory size.
• mount – Attach a file system to a directory.
• umount – Detach a mounted file system.

In AWS, these concepts are useful when working with Amazon EBS volumes attached to EC2 instances.

4.11 Linux Networking Commands

Linux servers communicate with other systems through networks.

Important commands include:

• ip addr – Display network interface addresses.
• ip route – Display routing information.
• ping – Test network reachability.
• ss -tulnp – Inspect listening network sockets.
• curl – Transfer data using supported URL protocols.
• wget – Retrieve files from network locations.
• traceroute – Inspect network paths, when installed.
• dig – Perform DNS queries, when installed.
• hostname -I – Display assigned IP addresses.

These commands are useful when troubleshooting DNS resolution, connectivity, and application ports.

4.12 SSH and Remote Server Management

SSH (Secure Shell) is a protocol used to securely access remote systems.

DevOps Engineers frequently use SSH to connect to Linux servers.

For example:

ssh username@server_ip

AWS EC2 instances can be accessed through SSH when the instance, network configuration, security group, credentials, and user account are correctly configured.

SSH authentication can use key pairs instead of passwords.

Protect private keys carefully and never upload them to public repositories.

4.13 Linux Log Management and Troubleshooting

Logs provide information about system activity, application behavior, and errors.

Common locations and tools include:

• /var/log – Common directory for system and application logs.
• journalctl – Query logs collected by systemd's journal.
• dmesg – Display kernel ring buffer messages.
• tail -f – Follow a log file as new entries are written.
• grep – Search log entries for specific error messages.

For example:

sudo journalctl -u nginx -n 50

This displays recent journal entries for the Nginx service, if the service is managed by systemd and its logs are available there.

Log analysis is one of the most important troubleshooting skills in production environments.

4.14 Bash Shell Scripting

Bash is a command-line shell commonly used for Linux administration and automation.

Shell scripts allow engineers to automate repetitive tasks.

Topics to learn include:

• Variables.
• User input.
• Conditional statements.
• Loops.
• Functions.
• Command-line arguments.
• Exit codes.
• Error handling.
• Scheduling tasks with cron.

Example:

#!/bin/bash

echo "Checking disk usage"

df -h

echo "Disk usage check completed"

Save the script as disk_check.sh.

Make it executable:

chmod +x disk_check.sh

Execute it:

./disk_check.sh

Bash scripting is useful for automating server administration, log analysis, backups, and deployment tasks.

4.15 Hands-On Linux Projects

Practice the following activities:

Project 1: Linux User Management

• Create three Linux users.
• Create a group.
• Add users to the group.
• Configure file ownership and permissions.
• Verify access restrictions.

Project 2: Linux Service Management

• Install Nginx.
• Start and enable the service.
• Check service status.
• Stop and restart the service.
• Inspect service logs.

Project 3: Linux System Monitoring

• Check CPU and memory usage.
• Inspect running processes.
• Identify disk usage.
• Find large files.
• Investigate a sample service failure.

Project 4: Bash Automation

• Write a script to check disk usage.
• Write a script to check memory usage.
• Create a basic backup script.
• Schedule a script using cron.

4.16 Learning Resources

• Linux Journey
• Ubuntu Documentation
• Red Hat Documentation
• The Linux Documentation Project

4.17 Phase 2 Completion Checklist

Before moving to the next phase, make sure you can:

• Navigate the Linux file system.
• Create, copy, move, and delete files.
• Understand Linux permissions and ownership.
• Create and manage users and groups.
• Monitor and manage processes.
• Start, stop, and troubleshoot services.
• Install and update packages.
• Inspect disk and memory usage.
• Use basic networking commands.
• Connect to remote servers using SSH.
• Read and analyze Linux logs.
• Write basic Bash scripts.

Expected outcome:

By the end of this phase, you should be comfortable administering a Linux server, performing common troubleshooting tasks, managing users and services, and automating basic operations using Bash.

These skills will prepare you for the next phase: Networking Fundamentals.

5. Phase 3: Networking Fundamentals (Weeks 7–8)

Networking is one of the core foundations of Cloud Computing and DevOps.

Applications, servers, databases, containers, and cloud services communicate with each other through networks.

An AWS DevOps Engineer must understand how data travels between systems, how network communication works, and how to troubleshoot connectivity problems.

For example, imagine an application running on an AWS EC2 instance. Users access the application through a web browser. To make this communication possible, engineers must understand IP addresses, DNS, ports, protocols, routing, firewalls, and load balancing.

Let's explore the important networking concepts step by step.

5.1 What Is Computer Networking?

A computer network is a collection of connected devices that communicate and exchange information.

Examples include:

• Home Wi-Fi networks.
• Office networks.
• Data center networks.
• Cloud networks.
• The internet.

Networking allows computers, servers, and applications to share resources and communicate with each other.

5.2 Understanding IP Addresses

An IP (Internet Protocol) address is a numerical address used to identify a device or network interface in an IP network.

There are two major IP versions:

IPv4

IPv4 uses a 32-bit address.

Example:

192.168.1.10

IPv4 addresses are commonly written as four decimal numbers separated by dots.

IPv6

IPv6 uses a 128-bit address.

Example:

2001:db8::1

IPv6 was developed to provide a much larger address space than IPv4.

Public IP Address

A public IP address is globally routable and can be used to communicate over the public internet, subject to network and security configuration.

Private IP Address

A private IP address is used within private networks and is not directly routable over the public internet.

Common private IPv4 ranges include:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

In AWS, EC2 instances can have private IP addresses within a VPC. Public connectivity depends on the instance's network configuration and associated routing.

5.3 Understanding Subnetting and CIDR

A subnet is a logical subdivision of an IP network.

Subnetting helps organizations divide networks into smaller address ranges.

CIDR stands for Classless Inter-Domain Routing.

CIDR notation represents an IP address range using a prefix length.

Example:

192.168.1.0/24

The /24 indicates that the first 24 bits represent the network portion of the address.

Another example:

10.0.0.0/16

A smaller prefix length generally represents a larger address range, while a larger prefix length represents a smaller address range.

Why is CIDR important in AWS?

When creating an AWS VPC, engineers specify a CIDR block.

For example:

10.0.0.0/16

They can then create smaller subnets within that VPC, such as:

• 10.0.1.0/24
• 10.0.2.0/24
• 10.0.3.0/24

These subnets can be used to organize application servers, databases, and other resources.

5.4 Understanding MAC Addresses

A MAC (Media Access Control) address is a link-layer address associated with a network interface.

It is commonly represented as six groups of hexadecimal digits.

Example:

00:1A:2B:3C:4D:5E

MAC addresses are primarily used for communication within a local network at the data link layer.

An IP address identifies an endpoint at the network layer, while a MAC address is used for local link-layer delivery.

5.5 Understanding DNS

DNS stands for Domain Name System.

It translates human-readable domain names into IP addresses or other DNS records.

For example:

When a user enters:

www.example.com

The DNS resolution process helps the client discover the IP address associated with that domain name.

Important DNS record types include:

• A: Maps a hostname to an IPv4 address.
• AAAA: Maps a hostname to an IPv6 address.
• CNAME: Creates an alias for another domain name.
• MX: Identifies mail servers for a domain.
• TXT: Stores text information, commonly used for domain verification and email authentication.
• NS: Identifies authoritative name servers.

Why is DNS important in AWS?

Amazon Route 53 is an AWS service that provides DNS management, domain registration, and health-check-based routing capabilities.

DevOps Engineers use DNS to connect domain names to applications and cloud infrastructure.

5.6 Understanding Network Ports

A port is a logical communication endpoint used by transport-layer protocols such as TCP and UDP.

Ports help a system direct network traffic to the correct application or service.

Common ports include:

Port	Protocol / Service
20, 21	FTP
22	SSH
25	SMTP
53	DNS
80	HTTP
110	POP3
143	IMAP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
8080	Common alternative HTTP application port

These are common default or conventional ports. Actual application configurations can differ.

Example:

When a user accesses a website using HTTPS, the client typically connects to the web server using TCP port 443.

In AWS, security groups can control which inbound and outbound traffic is allowed to reach an EC2 instance.

5.7 Understanding TCP and UDP

TCP and UDP are transport-layer protocols.

TCP (Transmission Control Protocol)

TCP provides reliable, connection-oriented communication.

Important characteristics include:

• Connection establishment.
• Ordered data delivery.
• Error detection.
• Retransmission of lost data.
• Flow and congestion control.

Examples of applications that commonly use TCP include HTTPS, SSH, and many database connections.

UDP (User Datagram Protocol)

UDP provides connectionless communication with lower protocol overhead.

It does not guarantee delivery, ordering, or retransmission at the transport layer.

Common uses include:

• DNS queries in many configurations.
• Real-time audio and video.
• Online gaming.
• Certain monitoring and streaming protocols.

5.8 Understanding the TCP Three-Way Handshake

TCP establishes a connection using a three-way handshake.

The three steps are:

1. SYN: The client sends a connection request to the server.
2. SYN-ACK: The server acknowledges the request and responds.
3. ACK: The client acknowledges the server's response.

After the handshake, TCP data communication can begin.

Understanding this process helps when troubleshooting connection establishment problems.

5.9 Understanding HTTP and HTTPS

HTTP stands for Hypertext Transfer Protocol.

It is an application-layer protocol used for communication between clients and web servers.

HTTPS is HTTP secured using TLS (Transport Layer Security).

Important HTTP methods include:

• GET – Retrieve a resource.
• POST – Submit data or create a resource.
• PUT – Replace a resource.
• PATCH – Partially update a resource.
• DELETE – Delete a resource.

Common HTTP status codes include:

Status code	Meaning
200	OK
201	Created
301	Moved Permanently
302	Found
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
500	Internal Server Error
502	Bad Gateway
503	Service Unavailable
504	Gateway Timeout

DevOps Engineers frequently investigate HTTP errors during application deployments and production incidents.

5.10 Understanding OSI and TCP/IP Models

Networking communication is commonly explained through layered models.

OSI Model

The OSI model has seven layers:

1. Physical – Transmits raw bits through physical media.
2. Data Link – Handles local link communication and frames.
3. Network – Handles logical addressing and routing.
4. Transport – Provides end-to-end transport using TCP or UDP.
5. Session – Manages communication sessions.
6. Presentation – Handles data representation, encoding, and related transformations.
7. Application – Provides network services used by applications.

TCP/IP Model

The commonly used four-layer TCP/IP model includes:

1. Network Access.
2. Internet.
3. Transport.
4. Application.

Understanding these models helps engineers identify where network communication problems may occur.

5.11 Understanding Routing and Gateways

Routing is the process of determining how network packets travel from a source to a destination.

A router forwards packets between different networks based on routing information.

A default gateway is the next-hop device used when a destination does not match a more specific route.

In AWS, route tables determine where network traffic from a subnet is directed.

For example, a public subnet may have a route to an Internet Gateway for internet connectivity.

A private subnet can use a NAT Gateway for outbound internet connectivity without allowing unsolicited inbound internet connections through that NAT Gateway.

5.12 Understanding Firewalls and Network Security

A firewall controls network traffic based on configured security rules.

Firewalls help protect systems from unauthorized network access.

Common network security concepts include:

• Inbound traffic.
• Outbound traffic.
• Allowed ports.
• Source and destination IP addresses.
• Network protocols.
• Stateful and stateless filtering.

In AWS, two important network security components are:

Security Groups

• Act as virtual firewalls for supported resources such as EC2 network interfaces.
• Are stateful.
• Support inbound and outbound rules.

Network ACLs (NACLs)

• Operate at the subnet level.
• Are stateless.
• Support inbound and outbound rules.
• Use numbered rules evaluated in order.

Understanding these differences is essential when troubleshooting AWS network access.

5.13 Understanding Load Balancing

A load balancer distributes incoming traffic across multiple backend targets.

This helps improve application availability, scalability, and performance.

For example, instead of sending every user request to one EC2 instance, a load balancer can distribute requests across multiple instances.

AWS provides Elastic Load Balancing with different load balancer types, including:

• Application Load Balancer (ALB).
• Network Load Balancer (NLB).
• Gateway Load Balancer (GWLB).

An Application Load Balancer operates at the application layer and supports HTTP and HTTPS routing features.

5.14 Essential Network Troubleshooting Commands

DevOps Engineers regularly use networking tools to diagnose connectivity problems.

Important commands include:

Check network interfaces

ip addr

Check routing information

ip route

Test basic connectivity

ping example.com

Check DNS resolution

nslookup example.com

Perform detailed DNS queries

dig example.com

Test HTTP connectivity

curl -I https://example.com

Check listening ports and sockets

ss -tulnp

Inspect the network path

traceroute example.com

Some commands may need to be installed separately. Network firewalls or cloud security rules may also block diagnostic traffic.

5.15 Hands-On Networking Projects

Practice these activities:

Project 1: IP Address Exploration

• Find your computer's IP address.
• Identify its subnet mask or CIDR prefix.
• Identify its default gateway.
• Understand the difference between private and public IP addresses.

Project 2: DNS Troubleshooting

• Use nslookup to resolve a domain.
• Use dig to inspect DNS records.
• Compare results for different domain names.
• Investigate what happens when DNS resolution fails.

Project 3: Port and Connectivity Testing

• Check which ports are listening on your Linux machine.
• Use curl to test a web server.
• Investigate a connection-refused error.
• Understand the difference between a closed port and a filtered port.

Project 4: AWS Network Fundamentals

• Study the purpose of an AWS VPC.
• Understand public and private subnets.
• Explore route tables.
• Learn the roles of Internet Gateways and NAT Gateways.
• Understand security groups and Network ACLs.

5.16 Learning Resources

• Cloudflare Learning Center
• Cisco Networking Basics
• AWS VPC Documentation
• AWS Elastic Load Balancing Documentation

5.17 Phase 3 Completion Checklist

Before moving to the next phase, make sure you can explain:

• What is computer networking?
• What are IPv4 and IPv6?
• What is the difference between public and private IP addresses?
• What is CIDR notation?
• What is subnetting?
• What is DNS?
• What are common network ports?
• What is the difference between TCP and UDP?
• How does the TCP three-way handshake work?
• What are HTTP and HTTPS?
• What are the OSI and TCP/IP models?
• What is routing?
• What is a default gateway?
• What is the difference between a security group and a Network ACL?
• What is load balancing?

Expected outcome:

By the end of this phase, you should understand the fundamentals of network communication, IP addressing, DNS, ports, protocols, routing, firewalls, and load balancing.

These concepts will prepare you for the next phase: Git and GitHub Version Control.

Phase 4: Learn Git and GitHub (Weeks 9–10)

Before automating infrastructure or building CI/CD pipelines, you must understand how developers and DevOps engineers manage changes to files and collaborate on projects.

Git and GitHub are essential tools in modern software development and DevOps.

4.1 What Is Version Control?

Version control is a system that tracks changes made to files over time.

Imagine working on a project and accidentally deleting an important configuration file. Without version control, recovering the previous version may be difficult.

With version control, you can:

• Track changes made to files.
• Restore previous versions.
• Work with multiple people on the same project.
• Create separate development branches.
• Review changes before merging them.
• Maintain a history of your project.

4.2 What Is Git?

Git is a distributed version control system used to track changes in source code and other files.

Every developer can maintain a local copy of a Git repository and its history.

Important Git concepts:

Concept	Explanation
Repository	A project tracked by Git
Working directory	The folder where you modify files
Staging area	The area where changes are prepared for a commit
Commit	A saved snapshot of changes
Branch	An independent line of development
Merge	Combining changes from different branches
Remote	A repository hosted on another system
Clone	Creating a local copy of a repository
Pull	Fetching and integrating remote changes
Push	Uploading local commits to a remote repository

4.3 Install and Configure Git

Install Git on your operating system and configure your identity.

Check the installed version:

git --version

Configure your username and email:

git config --global user.name "Your Name"
git config --global user.email "[e-mail]"

Verify your configuration:

git config --global --list

4.4 Essential Git Commands

Learn these commands and practise them regularly.

Initialize a repository:

git init

Check repository status:

git status

Add a file to the staging area:

git add README.md

Stage all changes:

git add .

Create a commit:

git commit -m "Initial project setup"

View commit history:

git log

Create a branch:

git branch feature-branch

Switch to a branch:

git switch feature-branch

Create and switch to a new branch:

git switch -c feature-branch

Merge a branch:

git switch main
git merge feature-branch

View configured remote repositories:

git remote -v

Upload commits to a remote repository:

git push origin main

Download and integrate remote changes:

git pull origin main

Clone a remote repository:

git clone <repository-url>

4.5 Understand the Git Workflow

A typical Git workflow follows this sequence:

1. Modify files in your working directory.
2. Review changes using git status and git diff.
3. Stage the required changes using git add.
4. Create a commit using git commit.
5. Push commits to a remote repository.
6. Create a pull request for review when collaborating with a team.
7. Merge approved changes into the main branch.

4.6 Understand Branching and Merging

Branches allow developers and DevOps engineers to work on different tasks without directly modifying the main development branch.

For example:

• main — stable project code.
• develop — ongoing development.
• feature-login — a new feature.
• bugfix-database — a bug fix.

A typical team workflow:

1. A developer creates a feature branch.
2. The developer makes changes and commits them.
3. The branch is pushed to GitHub.
4. A pull request is opened.
5. Team members review the changes.
6. Approved changes are merged into the main branch.

Learn how to resolve merge conflicts when different branches modify the same parts of a file.

4.7 What Is GitHub?

GitHub is a cloud-based platform for hosting Git repositories and collaborating on software projects.

Git and GitHub are not the same:

• Git is the version control system.
• GitHub is a platform that hosts Git repositories and provides collaboration features.

Important GitHub features:

• Repositories
• Pull requests
• Issues
• Branch protection
• Code reviews
• GitHub Actions
• Releases
• Project boards
• README files
• SSH authentication

4.8 Create and Manage GitHub Repositories

Learn how to:

1. Create a GitHub account.
2. Create a public and private repository.
3. Connect a local Git repository to GitHub.
4. Push local projects to GitHub.
5. Clone repositories.
6. Create branches.
7. Open and review pull requests.
8. Manage repository permissions.
9. Configure SSH authentication.
10. Maintain a professional project README.

4.9 Understand .gitignore

The .gitignore file tells Git which files and directories should not be tracked.

For example:

.env
.venv/
venv/
__pycache__/
*.pyc
*.log
.terraform/
*.tfstate
*.tfstate.*

This is especially important in DevOps projects because configuration files may contain sensitive information, and Terraform state files can contain infrastructure details or secrets.

Important: .gitignore does not remove files that Git is already tracking. Also, never commit passwords, access keys, private keys, or other credentials.

4.10 Understand Git Authentication

Learn the difference between:

• HTTPS authentication.
• SSH authentication.
• Personal access tokens.
• SSH key pairs.

Practise configuring SSH authentication to connect your local machine to GitHub securely.

4.11 GitHub Collaboration and Pull Requests

In real-world teams, developers rarely push every change directly into the main branch.

Instead, they use pull requests to propose changes.

Understand:

• Creating a pull request.
• Reviewing code changes.
• Adding review comments.
• Approving or requesting changes.
• Resolving merge conflicts.
• Merging pull requests.
• Protecting important branches.

4.12 Practical Projects

Project 1: Personal Git Repository

• Create a local project directory.
• Initialize Git.
• Add a README file.
• Commit your changes.
• Create a GitHub repository.
• Push the project to GitHub.

Project 2: Branching and Pull Request Workflow

• Create a repository.
• Create a feature branch.
• Modify a file.
• Commit and push your changes.
• Open a pull request.
• Review and merge the pull request.

Project 3: DevOps Documentation Repository

Create a repository with this structure:

devops-learning/
├── README.md
├── linux/
├── networking/
├── aws/
├── docker/
├── kubernetes/
├── terraform/
└── cicd/

Use Git to maintain your notes, configuration examples, and project documentation.

4.13 Learning Resources

• Git documentation: https://git-scm.com/doc
• GitHub documentation: https://docs.github.com/
• Learn Git Branching: https://learngitbranching.js.org/
• GitHub Skills: https://skills.github.com/

4.14 Phase 4 Completion Checklist

By the end of this phase, you should be able to:

• [ ] Explain version control and Git.
• [ ] Differentiate Git and GitHub.
• [ ] Initialize and manage repositories.
• [ ] Use essential Git commands.
• [ ] Understand staging, commits, and branches.
• [ ] Merge branches and resolve conflicts.
• [ ] Create and manage GitHub repositories.
• [ ] Configure SSH authentication.
• [ ] Create and review pull requests.
• [ ] Maintain a professional GitHub repository.
• [ ] Understand .gitignore and credential safety.

Expected outcome: You should be comfortable managing project files using Git and collaborating through GitHub. These skills will become essential when you start working with Terraform, Dockerfiles, Kubernetes manifests, and CI/CD pipelines.

Phase 5: Learn Python and Bash Scripting (Weeks 11–15)

Automation is one of the most important responsibilities of a DevOps engineer.

Instead of performing repetitive tasks manually, DevOps engineers write scripts to automate operations, manage infrastructure, process files, interact with APIs, and simplify deployments.

Two useful scripting languages are:

• Bash: Commonly used for Linux administration and command-line automation.
• Python: Used for automation, API integrations, cloud operations, and more complex scripting tasks.

You do not need to become a software developer before learning DevOps. However, you should be comfortable reading, writing, debugging, and maintaining practical scripts.

5.1 Understand Bash Scripting

Bash (Bourne Again Shell) is a command-line shell commonly used on Linux systems.

A Bash script is a file containing commands that can be executed together.

For example, instead of manually checking disk usage every day, you can write a script that collects disk information automatically.

Create a file named system-info.sh:

#!/bin/bash

echo "System Information"
echo "------------------"

echo "Current user:"
whoami

echo "Current date:"
date

echo "Disk usage:"
df -h

echo "Memory usage:"
free -h

Make the script executable:

chmod +x system-info.sh

Run the script:

./system-info.sh

5.2 Bash Scripting Fundamentals

Learn the following concepts:

Variables

name="DevOps Engineer"
echo "$name"

User input

read -p "Enter your name: " name
echo "Hello, $name"

Conditional statements

if [ -f "/etc/passwd" ]; then
    echo "File exists"
else
    echo "File does not exist"
fi

Loops

for service in nginx docker ssh
do
    echo "Checking $service"
done

Functions

check_disk() {
    df -h
}

check_disk

Also learn:

• Exit codes.
• Command-line arguments.
• Positional parameters.
• Input and output redirection.
• Pipes.
• Environment variables.
• Scheduling scripts with cron.
• Error handling and logging.
• Debugging Bash scripts.

5.3 Practical Bash Automation Tasks

Practise writing scripts to:

1. Check CPU, memory, and disk usage.
2. Monitor whether a Linux service is running.
3. Create daily backups.
4. Find and delete old temporary files safely.
5. Check whether a website or server is reachable.
6. Monitor log files for specific errors.
7. Create Linux users and directories.
8. Generate system health reports.

5.4 Introduction to Python

Python is a high-level programming language widely used in DevOps automation.

It is useful for:

• Automating repetitive tasks.
• Working with AWS services using Boto3.
• Calling REST APIs.
• Processing JSON and YAML.
• Managing files and directories.
• Integrating different tools.
• Building automation utilities.

Start with the fundamentals.

5.5 Python Fundamentals

Learn these topics in order:

1. Variables and data types

• Strings
• Integers
• Floats
• Booleans
• Lists
• Tuples
• Sets
• Dictionaries

2. Operators

• Arithmetic operators.
• Comparison operators.
• Logical operators.
• Assignment operators.

3. Conditional statements

• if
• elif
• else

4. Loops

• for
• while
• break
• continue

5. Functions

• Defining functions.
• Parameters and arguments.
• Return values.
• Default arguments.
• Scope.

6. Data structures

• Lists and list methods.
• Dictionaries and dictionary methods.
• Tuples and sets.
• Nested data structures.

7. File handling

• Reading files.
• Writing files.
• Appending data.
• Working with text and CSV files.

8. Exception handling

• try
• except
• else
• finally
• Raising exceptions.

Example:

try:
    number = int(input("Enter a number: "))
    print(number * 2)
except ValueError:
    print("Please enter a valid integer.")

5.6 Intermediate Python Concepts

After understanding the fundamentals, learn:

• Modules and packages.
• Import statements.
• Object-oriented programming basics.
• Classes and objects.
• Inheritance.
• Working with JSON.
• Working with CSV.
• Regular expressions.
• Virtual environments.
• Installing packages using pip.
• Logging.
• Debugging.
• Working with environment variables.
• Making HTTP requests.
• REST API fundamentals.

5.7 Python for DevOps Automation

Focus on practical automation rather than learning every Python feature.

Understand how to:

1. Execute system commands using Python.
2. Read and process log files.
3. Check server availability.
4. Automate file and directory management.
5. Make HTTP requests to REST APIs.
6. Parse JSON responses.
7. Generate system reports.
8. Automate backup-related tasks.
9. Handle errors and write logs.
10. Build reusable automation scripts.

Useful Python modules and libraries include:

Module or library	Purpose
os	Operating system operations
sys	Python runtime and command-line arguments
subprocess	Execute external commands
pathlib	Work with filesystem paths
shutil	File and directory operations
json	Process JSON data
csv	Read and write CSV files
logging	Application and script logging
requests	Make HTTP requests
boto3	Interact with AWS services

5.8 Introduction to AWS Boto3

Boto3 is the AWS SDK for Python.

It allows Python scripts to interact with AWS services programmatically.

For example, you can use Boto3 to:

• List S3 buckets.
• Upload and download S3 objects.
• Start and stop EC2 instances.
• Retrieve information about AWS resources.
• Automate selected cloud operations.

Example: List S3 buckets.

import boto3

s3_client = boto3.client("s3")

response = s3_client.list_buckets()

for bucket in response["Buckets"]:
    print(bucket["Name"])

Before running AWS scripts, configure credentials securely through an appropriate AWS authentication method. Prefer IAM roles or temporary credentials where possible. Never hardcode access keys in scripts or commit them to GitHub.

You will study Boto3 in greater depth during the AWS automation phase.

5.9 Python and Bash Projects

Project 1: Linux System Health Monitor

Write a Bash script that reports:

• CPU information.
• Memory usage.
• Disk usage.
• Running processes.
• System uptime.

Project 2: Automated Backup Script

Create a Bash script that:

• Selects a directory.
• Creates a timestamped backup.
• Stores the backup in another directory.
• Logs the backup result.

Project 3: Log File Analyzer

Use Python to:

• Read a log file.
• Identify error messages.
• Count occurrences of different error types.
• Generate a summary report.

Project 4: Website Availability Checker

Use Python to send an HTTP request to a website and report whether it responds successfully.

Project 5: AWS S3 Automation

Use Boto3 to:

• List S3 buckets.
• Display bucket names.
• Upload a sample file to an authorized test bucket.
• List objects in the bucket.

5.10 Learning Resources

• Python documentation: https://docs.python.org/3/
• Python tutorial: https://www.learnpython.org/
• Bash reference manual: https://www.gnu.org/software/bash/manual/
• Boto3 documentation: https://boto3.amazonaws.com/v1/documentation/api/latest/index.html
• Python practice: https://www.hackerrank.com/domains/python

5.11 Phase 5 Completion Checklist

By the end of this phase, you should be able to:

• [ ] Write basic Bash scripts.
• [ ] Use variables, conditions, loops, and functions.
• [ ] Automate common Linux administration tasks.
• [ ] Understand Python variables and data types.
• [ ] Work with conditions, loops, and functions.
• [ ] Use lists, dictionaries, and other data structures.
• [ ] Read and write files.
• [ ] Handle exceptions and generate logs.
• [ ] Work with JSON, CSV, and REST APIs.
• [ ] Execute system commands using Python.
• [ ] Understand Python virtual environments and pip.
• [ ] Write basic AWS automation scripts using Boto3.
• [ ] Store credentials securely.

Expected outcome: You should be able to write practical Bash and Python scripts to automate routine system administration and DevOps tasks. You do not need advanced software development skills at this stage; focus on writing reliable, reusable automation.

Phase 6: Learn Amazon Web Services (AWS) Fundamentals (Weeks 16–21)

Amazon Web Services (AWS) is one of the leading cloud computing platforms.

It provides on-demand computing resources such as virtual servers, storage, databases, networking, security, and application deployment services.

Instead of purchasing and maintaining physical servers, organizations can use AWS infrastructure and pay for the resources they consume.

For an AWS DevOps Engineer, understanding AWS services and cloud architecture is essential.

6.1 Understand Cloud Computing

Before learning individual AWS services, understand the fundamentals of cloud computing.

Learn:

• What is cloud computing?
• Traditional infrastructure vs cloud infrastructure.
• On-premises vs cloud environments.
• Public, private, and hybrid cloud.
• Infrastructure as a Service (IaaS).
• Platform as a Service (PaaS).
• Software as a Service (SaaS).
• Scalability and elasticity.
• High availability.
• Fault tolerance.
• Disaster recovery.
• Pay-as-you-go pricing.

Understand the shared responsibility model: AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, with responsibilities varying by service.

6.2 Understand AWS Global Infrastructure

AWS operates a global infrastructure to deliver cloud services.

Learn these concepts:

AWS Regions

A Region is a separate geographical area where AWS operates infrastructure.

For example:

• Mumbai (ap-south-1)
• Singapore (ap-southeast-1)
• US East (N. Virginia) (us-east-1)
• Europe (Ireland) (eu-west-1)

Availability Zones

An Availability Zone (AZ) is an isolated location within an AWS Region, consisting of one or more data centers.

Using multiple Availability Zones can improve application availability and fault tolerance.

Edge Locations

Edge Locations help deliver content with lower latency through services such as Amazon CloudFront.

Understand how Regions, Availability Zones, and Edge Locations fit into AWS architecture.

6.3 Create and Secure an AWS Account

Learn how to:

1. Understand AWS account structure.
2. Sign in to the AWS Management Console.
3. Navigate the AWS Console.
4. Select an AWS Region.
5. Configure account security.
6. Enable multi-factor authentication (MFA).
7. Understand root user security.
8. Create IAM users where appropriate.
9. Create IAM groups and roles.
10. Apply least-privilege permissions.
11. Configure billing alerts and budgets.

Important cost and security precautions:

• Protect the root user credentials.
• Never share AWS access keys.
• Prefer IAM roles and temporary credentials over long-lived access keys.
• Check service pricing before launching resources.
• Configure billing notifications and budgets.
• Delete resources after completing practice exercises.
• Remember that AWS Free Tier eligibility and limits vary by account, service, and usage. Not every resource or activity is free.

6.4 Identity and Access Management (IAM)

IAM controls who can access AWS resources and what actions they can perform.

Learn:

• IAM users.
• IAM groups.
• IAM roles.
• IAM policies.
• Managed policies.
• Inline policies.
• Identity-based policies.
• Resource-based policies.
• Permission boundaries.
• Policy evaluation.
• Least-privilege access.
• IAM role assumption.
• Temporary security credentials.

Understand the difference between an IAM user and an IAM role.

Practical exercises:

• Create an IAM policy.
• Create a test IAM role.
• Attach permissions to a role.
• Understand role assumption.
• Restrict access to a specific S3 bucket.
• Troubleshoot common AccessDenied errors.

6.5 Amazon EC2 — Elastic Compute Cloud

Amazon EC2 provides virtual servers in the AWS cloud.

Learn:

• What is EC2?
• EC2 instance types.
• Instance families.
• AMIs (Amazon Machine Images).
• Instance launch process.
• Key pairs.
• Security groups.
• User data.
• EBS volumes.
• Instance lifecycle.
• Public and private IP addresses.
• Elastic IP addresses.
• Instance metadata.
• Instance purchasing options.
• EC2 monitoring.
• Instance troubleshooting.

Practical exercises:

1. Launch a Linux EC2 instance.
2. Connect using SSH.
3. Install and configure a web server.
4. Host a simple webpage.
5. Configure inbound and outbound security group rules.
6. Attach and mount an EBS volume.
7. Explore instance monitoring.
8. Stop and terminate the instance when finished.

6.6 Amazon S3 — Simple Storage Service

Amazon S3 is an object storage service used to store and retrieve data.

Learn:

• Buckets and objects.
• Object keys.
• Storage classes.
• Versioning.
• Bucket policies.
• Access control.
• Encryption.
• Lifecycle rules.
• Replication.
• Static website hosting.
• Multipart uploads.
• Presigned URLs.
• S3 event notifications.
• S3 security best practices.

Practical exercises:

• Create an S3 bucket.
• Upload and download files.
• Configure bucket versioning.
• Create a lifecycle policy.
• Configure encryption.
• Apply a bucket policy.
• Enable access logging where appropriate.
• Understand cross-region replication and its cost implications.

6.7 AWS Networking — Amazon VPC

Amazon Virtual Private Cloud (VPC) allows you to create an isolated virtual network in AWS.

This is one of the most important AWS topics for a DevOps Engineer.

Learn:

• What is a VPC?
• CIDR blocks.
• Public and private subnets.
• Route tables.
• Internet Gateway (IGW).
• NAT Gateway.
• Security groups.
• Network Access Control Lists (NACLs).
• Elastic Network Interfaces (ENIs).
• VPC peering.
• VPC endpoints.
• DNS resolution in VPC.
• VPC Flow Logs.
• Network connectivity troubleshooting.

Understand how traffic flows between public and private resources.

Practical project:

Design a VPC with:

• One VPC.
• Two public subnets across different Availability Zones.
• Two private subnets across different Availability Zones.
• Internet Gateway.
• Appropriate route tables.
• Security groups.
• NAT Gateway, where required.

Understand that NAT Gateways and data transfer can generate charges. Use cost-conscious alternatives for practice where appropriate.

6.8 Elastic Load Balancing (ELB)

A load balancer distributes incoming traffic across multiple targets.

Learn the different load balancer types:

• Application Load Balancer (ALB).
• Network Load Balancer (NLB).
• Gateway Load Balancer (GWLB).

Understand:

• Listeners.
• Listener rules.
• Target groups.
• Health checks.
• Routing.
• High availability.
• Load balancing algorithms and behavior.

Practical exercise: Deploy a web application on multiple EC2 instances and understand how an Application Load Balancer distributes requests.

6.9 EC2 Auto Scaling

Auto Scaling helps automatically adjust the number of EC2 instances based on configured conditions.

Learn:

• Launch templates.
• Auto Scaling groups.
• Minimum capacity.
• Maximum capacity.
• Desired capacity.
• Scaling policies.
• Dynamic scaling.
• Scheduled scaling.
• Health checks.
• Instance replacement.

Understand how Auto Scaling works with Elastic Load Balancing to improve application availability and scalability.

6.10 Amazon EBS — Elastic Block Store

Amazon EBS provides persistent block storage for EC2 instances.

Learn:

• EBS volumes.
• Volume types.
• Volume attachment.
• Formatting and mounting.
• Snapshots.
• Encryption.
• Volume resizing.
• Backup and recovery.

Understand the difference between object storage in S3 and block storage in EBS.

6.11 AWS Database Services

Understand the purpose of AWS database services.

Amazon RDS

A managed relational database service.

Learn:

• Database engines.
• DB instances.
• Storage.
• Backups.
• Multi-AZ deployments.
• Read replicas.
• Security groups.
• Monitoring.

Amazon Aurora

A relational database engine compatible with MySQL and PostgreSQL.

Amazon DynamoDB

A managed NoSQL database service.

Learn:

• Tables.
• Items.
• Attributes.
• Partition keys.
• Sort keys.
• Read and write capacity concepts.
• On-demand capacity.
• Indexes.

Understand when to use relational databases and when NoSQL databases are appropriate.

6.12 Amazon Route 53

Route 53 is AWS's scalable DNS and domain registration service.

Learn:

• DNS fundamentals.
• Hosted zones.
• Record types.
• A records.
• AAAA records.
• CNAME records.
• Alias records.
• Routing policies.
• Health checks.
• DNS failover.

Understand how a domain name resolves to an application hosted on AWS.

6.13 Amazon CloudWatch

CloudWatch is an AWS monitoring and observability service.

Learn:

• Metrics.
• Logs.
• Log groups.
• Log streams.
• Dashboards.
• Alarms.
• Events and scheduled rules through Amazon EventBridge.
• CloudWatch Agent.
• Custom metrics.
• Monitoring EC2 resources.

Practical exercises:

• Monitor EC2 CPU utilization.
• Create a CloudWatch alarm.
• View application logs.
• Build a monitoring dashboard.
• Understand how alarms can trigger notifications through configured integrations.

6.14 AWS Command Line Interface (AWS CLI)

AWS CLI allows you to interact with AWS services through commands.

Install and configure AWS CLI using the official documentation.

Check the installed version:

aws --version

Check the identity associated with your active credentials:

aws sts get-caller-identity

List S3 buckets:

aws s3 ls

List EC2 instances:

aws ec2 describe-instances

Copy a file to S3:

aws s3 cp sample.txt s3://your-bucket-name/

Learn:

• AWS CLI installation.
• Credential configuration.
• Named profiles.
• Regions.
• Output formats.
• Filters and queries.
• Service-specific commands.
• CLI troubleshooting.

Prefer IAM roles and temporary credentials for workloads instead of embedding long-lived credentials in scripts.

6.15 AWS Hands-On Projects

Project 1: Host a Website on EC2

• Launch an EC2 instance.
• Install a web server.
• Configure a security group.
• Host a sample webpage.
• Test application accessibility.

Project 2: Build a Secure S3 Storage Solution

• Create an S3 bucket.
• Enable versioning.
• Configure encryption.
• Apply least-privilege access.
• Configure lifecycle management.

Project 3: Build a Highly Available Web Architecture

• Create a VPC.
• Configure public and private subnets.
• Deploy EC2 instances in multiple Availability Zones.
• Configure an Application Load Balancer.
• Configure an Auto Scaling group.
• Monitor the architecture.

Project 4: Deploy a Database-Backed Application

• Launch a database using RDS.
• Deploy an application on EC2.
• Configure network access securely.
• Connect the application to the database.
• Enable monitoring and backups.

Project 5: AWS CLI Automation

• Configure AWS CLI.
• Retrieve AWS account information.
• List S3 buckets.
• Inspect EC2 resources.
• Upload and download objects.
• Automate selected tasks using Bash or Python.

6.16 AWS Learning Resources

• AWS documentation: https://docs.aws.amazon.com/
• AWS Skill Builder: https://skillbuilder.aws/
• AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
• AWS Architecture Center: https://aws.amazon.com/architecture/
• AWS CLI documentation: https://docs.aws.amazon.com/cli/latest/userguide/

6.17 Phase 6 Completion Checklist

By the end of this phase, you should be able to:

• [ ] Explain cloud computing and its service models.
• [ ] Understand AWS Regions and Availability Zones.
• [ ] Navigate the AWS Management Console.
• [ ] Secure an AWS account.
• [ ] Create and manage IAM users, roles, and policies.
• [ ] Launch and connect to EC2 instances.
• [ ] Store and manage objects in S3.
• [ ] Design basic VPC architectures.
• [ ] Configure subnets, route tables, and gateways.
• [ ] Understand security groups and NACLs.
• [ ] Configure load balancing and Auto Scaling.
• [ ] Understand EBS and AWS database services.
• [ ] Configure basic DNS using Route 53.
• [ ] Monitor AWS resources using CloudWatch.
• [ ] Perform AWS operations using the CLI.
• [ ] Understand basic AWS security and cost management.

Expected outcome: You should be able to explain core AWS services, deploy basic cloud infrastructure, configure secure network connectivity, and troubleshoot common AWS issues. These skills form the foundation for advanced AWS DevOps engineering.

Phase 7: Advanced AWS Services and Cloud Architecture (Weeks 22–25)

Understanding individual AWS services is only the beginning. A professional AWS DevOps Engineer must also understand how these services work together to build secure, scalable, highly available, and reliable applications.

In this phase, you will explore advanced AWS services, cloud architecture patterns, security, automation, messaging, and infrastructure management.

7.1 Advanced IAM and AWS Security

IAM is not just about creating users and attaching policies. In production environments, access must be controlled carefully across applications, services, teams, and AWS accounts.

Learn:

• Advanced IAM policy structure.
• Policy conditions.
• Resource-based policies.
• Cross-account access.
• IAM role assumption.
• AWS Security Token Service (STS).
• Temporary security credentials.
• IAM Access Analyzer.
• Service control policies (SCPs).
• Permission boundaries.
• IAM Identity Center.
• AWS Organizations.
• Least-privilege access design.

Practical exercises:

• Create a cross-account IAM role.
• Configure an application to assume an IAM role.
• Restrict access using policy conditions.
• Understand explicit deny and allow evaluation.
• Review permissions using IAM Access Analyzer.

7.2 AWS Systems Manager (SSM)

AWS Systems Manager helps manage and operate AWS resources at scale.

Learn these important capabilities:

• Systems Manager Session Manager.
• Run Command.
• Automation.
• Parameter Store.
• Patch Manager.
• State Manager.
• Inventory.
• Maintenance Windows.
• Fleet Manager.

Understand how Systems Manager can help administrators manage EC2 instances without relying on direct SSH access.

Practical exercises:

• Connect to an EC2 instance using Session Manager.
• Execute commands remotely.
• Store configuration values in Parameter Store.
• Understand patch management.
• Automate a simple operational task.

7.3 AWS Key Management Service (KMS)

AWS KMS is a managed service used to create and manage cryptographic keys.

Learn:

• Customer managed keys.
• AWS managed keys.
• Key policies.
• Key rotation.
• Encryption and decryption.
• Envelope encryption.
• Key grants.
• Cross-account key access.
• Integration with S3, EBS, and other AWS services.

Understand the difference between encryption at rest and encryption in transit.

Practical exercise: Configure an encrypted S3 bucket using an appropriate KMS key and understand how access permissions affect encryption operations.

7.4 AWS Secrets Manager

Secrets Manager helps securely store, retrieve, and manage sensitive information.

Learn:

• Secret creation.
• Secret retrieval.
• Secret rotation.
• Resource policies.
• IAM permissions.
• Integration with applications.
• Database credential management.
• Secure access from Lambda and EC2 workloads.

Understand why passwords, database credentials, and API keys should not be stored directly in source code or Git repositories.

Practical exercise: Store a test database credential in Secrets Manager and retrieve it through an authorized application or script.

7.5 AWS CloudTrail

CloudTrail records account activity and API events across AWS.

Learn:

• Management events.
• Data events.
• Event history.
• Trails.
• CloudTrail Lake.
• Log storage in S3.
• Integration with CloudWatch Logs.
• Security auditing.
• Investigating suspicious API activity.

Practical exercise: Identify who performed a particular AWS API action and understand how CloudTrail can help investigate account activity.

7.6 AWS Config

AWS Config helps assess, audit, and evaluate the configurations of AWS resources.

Learn:

• Configuration items.
• Configuration history.
• Configuration snapshots.
• AWS Config rules.
• Managed and custom rules.
• Compliance evaluation.
• Remediation concepts.
• Integration with AWS Organizations.

Practical exercise: Create a rule to evaluate whether selected S3 buckets meet a security requirement.

7.7 AWS Lambda and Serverless Computing

AWS Lambda is a serverless compute service that runs code in response to events without requiring you to manage servers.

Learn:

• Serverless architecture.
• Functions.
• Event sources.
• Triggers.
• Execution roles.
• Environment variables.
• Layers.
• Runtime configuration.
• Timeouts and memory.
• Concurrency.
• Versions and aliases.
• Error handling.
• Dead-letter queues.
• Monitoring with CloudWatch.

Understand integrations with:

• Amazon S3.
• Amazon API Gateway.
• Amazon EventBridge.
• Amazon SQS.
• Amazon SNS.

Practical exercises:

• Create a Lambda function.
• Trigger a function using an S3 event.
• Write a basic Python Lambda function.
• Configure an execution role.
• Monitor execution logs.
• Handle errors and retries.

7.8 AWS Messaging and Event-Driven Services

Modern cloud applications often use messaging and event-driven architectures to communicate between independent services.

Understand these services:

Amazon SQS

A message queuing service used to decouple application components.

Learn:

• Standard queues.
• FIFO queues.
• Visibility timeout.
• Message retention.
• Dead-letter queues.
• Long polling.

Amazon SNS

A notification service used to distribute messages to multiple subscribers.

Learn:

• Topics.
• Subscriptions.
• Publishers and subscribers.
• Message filtering.
• Delivery mechanisms.

Amazon EventBridge

An event bus service used to connect applications and AWS services through event-driven architectures.

Learn:

• Event buses.
• Rules.
• Event patterns.
• Targets.
• Scheduled events.
• Event-driven automation.

Practical project: Build a simple event-driven workflow in which an S3 upload triggers a Lambda function and the result is sent to an SNS notification topic.

7.9 AWS CloudFormation

CloudFormation is an Infrastructure as Code service that allows you to define AWS infrastructure using templates.

Learn:

• Infrastructure as Code concepts.
• YAML and JSON templates.
• Stacks.
• Resources.
• Parameters.
• Outputs.
• Mappings.
• Conditions.
• Intrinsic functions.
• Change sets.
• Stack updates.
• Stack deletion.
• Drift detection.
• Nested stacks.

Understand how CloudFormation differs from manually creating AWS resources through the console.

You will study Terraform in greater depth in a dedicated phase later in this roadmap.

7.10 AWS Backup and Disaster Recovery

Production systems must be prepared for failures, accidental deletion, and infrastructure disruptions.

Learn:

• AWS Backup.
• Backup plans.
• Backup vaults.
• Recovery points.
• Retention policies.
• EBS snapshots.
• RDS backups.
• Cross-region backup considerations.
• Cross-account backup.
• Recovery testing.
• Disaster recovery strategies.

Understand these disaster recovery approaches:

• Backup and restore.
• Pilot light.
• Warm standby.
• Multi-site active/active.

Learn the meaning of:

• Recovery Point Objective (RPO).
• Recovery Time Objective (RTO).

Practical exercise: Create a backup plan for a test resource and understand how to restore it.

7.11 AWS Organizations and Multi-Account Architecture

Large organizations often use multiple AWS accounts to separate environments, teams, workloads, and security boundaries.

Learn:

• AWS Organizations.
• Organizational Units (OUs).
• Service Control Policies.
• Consolidated billing.
• Account management.
• Cross-account roles.
• Centralized logging.
• Shared services accounts.
• Multi-account governance.

Understand the purpose of separating development, testing, production, logging, and security environments.

7.12 AWS Well-Architected Framework

The AWS Well-Architected Framework provides guidance for building and operating cloud workloads effectively.

Study its six pillars:

1. Operational Excellence.
2. Security.
3. Reliability.
4. Performance Efficiency.
5. Cost Optimization.
6. Sustainability.

Understand how these pillars influence architecture and operational decisions.

7.13 Advanced AWS Architecture Concepts

Learn how to design systems that can handle failures, increased traffic, and changing business requirements.

Topics include:

• High availability.
• Fault tolerance.
• Horizontal and vertical scaling.
• Multi-AZ architecture.
• Multi-Region architecture.
• Stateless and stateful applications.
• Decoupled architectures.
• Microservices fundamentals.
• Disaster recovery.
• Network segmentation.
• Centralized logging.
• Cost optimization.
• Resilience and failure handling.

7.14 Practical Projects

Project 1: Secure AWS Workload

• Create an EC2 instance.
• Configure an IAM role.
• Store application secrets securely.
• Enable encryption.
• Monitor API activity using CloudTrail.
• Review resource configurations using AWS Config.

Project 2: Serverless File Processing

• Create an S3 bucket.
• Configure an S3 event notification.
• Trigger a Lambda function.
• Process an uploaded file.
• Store the processing result.
• Monitor execution using CloudWatch.

Project 3: Event-Driven Notification System

• Create an SNS topic.
• Create an SQS queue.
• Configure an EventBridge rule.
• Connect event sources and targets.
• Test message delivery.
• Understand retry and dead-letter queue behavior.

Project 4: Multi-Account AWS Architecture

Design a sample organization containing:

• Development account.
• Testing account.
• Production account.
• Centralized logging account.
• Security account.

Document how IAM roles, AWS Organizations, and centralized monitoring can help manage this environment.

Project 5: AWS Backup and Recovery

• Create a backup plan.
• Configure a backup schedule.
• Understand retention settings.
• Perform a test restore.
• Document the recovery process.

7.15 Learning Resources

• AWS Systems Manager: https://docs.aws.amazon.com/systems-manager/
• AWS IAM: https://docs.aws.amazon.com/IAM/latest/UserGuide/
• AWS KMS: https://docs.aws.amazon.com/kms/
• AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/
• AWS CloudTrail: https://docs.aws.amazon.com/awscloudtrail/
• AWS Config: https://docs.aws.amazon.com/config/
• AWS Lambda: https://docs.aws.amazon.com/lambda/
• Amazon SQS: https://docs.aws.amazon.com/sqs/
• Amazon SNS: https://docs.aws.amazon.com/sns/
• Amazon EventBridge: https://docs.aws.amazon.com/eventbridge/
• AWS CloudFormation: https://docs.aws.amazon.com/cloudformation/
• AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html

7.16 Phase 7 Completion Checklist

By the end of this phase, you should be able to:

• [ ] Understand advanced IAM permissions and cross-account access.
• [ ] Manage EC2 instances using Systems Manager.
• [ ] Understand encryption and key management with KMS.
• [ ] Store application secrets securely.
• [ ] Investigate AWS activity using CloudTrail.
• [ ] Evaluate resource configurations using AWS Config.
• [ ] Build basic serverless applications using Lambda.
• [ ] Understand SQS, SNS, and EventBridge.
• [ ] Create basic infrastructure templates using CloudFormation.
• [ ] Understand AWS Backup and disaster recovery.
• [ ] Explain multi-account AWS architecture.
• [ ] Apply the AWS Well-Architected Framework.
• [ ] Design basic highly available and resilient architectures.

Expected outcome: You should be able to work with advanced AWS services, implement essential security and governance practices, automate cloud operations, and explain how multiple AWS services work together in production-oriented architectures.

Phase 8: Learn Terraform and Infrastructure as Code (Weeks 26–30)

Infrastructure as Code (IaC) is the practice of defining, provisioning, configuring, and managing infrastructure through machine-readable configuration files.

Traditionally, engineers created cloud resources manually through management consoles. This approach becomes difficult to maintain when infrastructure grows or multiple environments are required.

IaC helps solve this problem by allowing infrastructure to be managed like application code.

8.1 Understand Infrastructure as Code

Learn:

• What is Infrastructure as Code?
• Manual infrastructure provisioning vs IaC.
• Declarative vs imperative approaches.
• Idempotency.
• Reusability.
• Version control for infrastructure.
• Infrastructure automation.
• Configuration management vs infrastructure provisioning.

Understand the benefits of IaC:

• Repeatable infrastructure deployments.
• Consistent environments.
• Reduced manual errors.
• Easier collaboration.
• Infrastructure change tracking.
• Faster environment creation.
• Better disaster recovery and reproducibility.

8.2 Introduction to Terraform

Terraform is an Infrastructure as Code tool developed by HashiCorp.

It allows engineers to define infrastructure using HashiCorp Configuration Language (HCL).

Terraform supports multiple cloud providers and infrastructure platforms through providers.

Learn:

• What is Terraform?
• Terraform architecture.
• Terraform workflow.
• Providers.
• Resources.
• Data sources.
• Configuration files.
• HCL syntax.
• Terraform Registry.

Understand the difference between Terraform and AWS CloudFormation.

8.3 Install and Configure Terraform

Learn how to:

1. Install Terraform.
2. Verify the installation.
3. Configure AWS CLI credentials securely.
4. Create a Terraform working directory.
5. Configure the AWS provider.
6. Understand Terraform configuration files.

Check the Terraform version:

terraform version

Example provider configuration:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

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

Use a compatible provider version based on your project requirements and verify the current provider documentation.

8.4 Terraform Core Commands

Understand the purpose of each command.

Initialize the working directory:

terraform init

Validate configuration syntax:

terraform validate

Format configuration files:

terraform fmt

Preview infrastructure changes:

terraform plan

Apply infrastructure changes:

terraform apply

Destroy Terraform-managed infrastructure:

terraform destroy

Understand why reviewing a Terraform plan before applying changes is important.

8.5 Terraform Configuration Language (HCL)

Learn the building blocks of Terraform configuration.

Topics include:

• Blocks.
• Arguments.
• Expressions.
• Attributes.
• Variables.
• Outputs.
• Locals.
• Data types.
• Lists and maps.
• Conditional expressions.
• Functions.
• Dynamic blocks.
• for expressions.
• Dependency references.

Example variable:

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

Example output:

output "instance_id" {
  description = "Created EC2 instance ID"
  value       = aws_instance.web.id
}

8.6 Terraform Resources and Data Sources

Resources define infrastructure objects that Terraform manages.

For example:

• EC2 instances.
• S3 buckets.
• VPCs.
• Subnets.
• Security groups.
• IAM roles.

Data sources allow Terraform to retrieve information about existing infrastructure or external resources.

Learn:

• Resource syntax.
• Resource arguments.
• Resource attributes.
• Resource dependencies.
• Explicit dependencies using depends_on.
• Data source syntax.
• Resource references.
• Implicit dependency creation.

8.7 Terraform State Management

Terraform state is one of the most important concepts to understand.

The state file records the relationship between Terraform configuration and managed infrastructure.

Learn:

• What is Terraform state?
• Local state.
• Remote state.
• State locking.
• State refresh behavior.
• State file structure.
• Resource tracking.
• State drift.
• State backup.
• State security.

Important commands:

terraform state list
terraform state show <resource-address>
terraform state mv <source> <destination>
terraform state rm <resource-address>

Understand that state files can contain sensitive information. Never commit state files containing sensitive data to a public repository.

8.8 Remote Backend and State Locking

In team environments, storing Terraform state only on an engineer's local machine is not a reliable collaboration strategy.

Learn:

• Backend configuration.
• Remote state storage.
• Amazon S3 backend.
• State locking.
• Concurrent Terraform operations.
• State recovery.
• Backend migration.

Understand the current S3 backend locking configuration supported by your Terraform version. For modern Terraform versions, S3-native lock files can be enabled with use_lockfile; older examples may use DynamoDB-based locking.

8.9 Terraform Modules

Modules help organize reusable infrastructure configurations.

Learn:

• Root modules.
• Child modules.
• Module inputs.
• Module outputs.
• Module sources.
• Local modules.
• Remote modules.
• Module versioning.
• Reusable infrastructure patterns.

Example project structure:

terraform-project/
├── main.tf
├── variables.tf
├── outputs.tf
├── providers.tf
├── versions.tf
└── modules/
    ├── vpc/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── ec2/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

8.10 Terraform Workspaces and Multiple Environments

Organizations commonly maintain separate environments such as:

• Development.
• Testing.
• Staging.
• Production.

Learn:

• Terraform workspaces.
• Workspace commands.
• Environment-specific variables.
• Variable files.
• Environment isolation.
• Separate state files.
• Reusable modules.

Understand that workspaces alone are not a complete environment-isolation or security strategy. Separate configurations, accounts, permissions, and state backends may be more appropriate for production systems.

8.11 Advanced Terraform Concepts

After understanding the fundamentals, learn:

• Lifecycle meta-arguments.
• create_before_destroy.
• prevent_destroy.
• ignore_changes.
• Provisioners and their limitations.
• Importing existing resources.
• Resource replacement.
• Tainting and replacement concepts.
• Dependency graphs.
• Terraform functions.
• Dynamic blocks.
• Conditional resource creation.
• for_each and count.
• Provider aliases.
• Multiple AWS accounts and regions.
• Terraform testing fundamentals.

Also understand how to detect and manage infrastructure drift.

8.12 Terraform Security Best Practices

Learn how to:

• Avoid hardcoding credentials.
• Use IAM roles and temporary credentials.
• Protect state files.
• Avoid exposing secrets in outputs.
• Restrict backend access.
• Use encryption for remote state.
• Review infrastructure plans.
• Pin provider and module versions.
• Scan Terraform code for security issues.
• Apply least-privilege IAM permissions.

Explore tools such as Checkov and Trivy for infrastructure configuration scanning.

8.13 Terraform and GitHub Integration

Infrastructure code should be managed using version control.

Learn:

• Store Terraform configurations in Git.
• Use .gitignore correctly.
• Review infrastructure changes through pull requests.
• Protect the main branch.
• Maintain environment-specific configuration.
• Use code reviews before infrastructure deployment.

Never commit sensitive credentials or unprotected state files to GitHub.

8.14 Practical Terraform Projects

Project 1: Create an EC2 Instance Using Terraform

• Configure the AWS provider.
• Define an EC2 resource.
• Configure an instance type and AMI.
• Create a security group.
• Generate an infrastructure plan.
• Apply the configuration.
• Verify the EC2 instance.
• Destroy the resources after testing.

Project 2: Build an AWS VPC Using Terraform

Create:

• One VPC.
• Public and private subnets.
• Route tables.
• Internet Gateway.
• Security groups.
• Required network associations.

Project 3: Build a Reusable Terraform Module

• Create a VPC module.
• Create an EC2 module.
• Define variables and outputs.
• Reuse modules in another configuration.
• Document module inputs and outputs.

Project 4: Configure Remote Terraform State

• Create a dedicated S3 bucket for state storage.
• Enable bucket versioning.
• Configure encryption and restricted access.
• Configure the S3 backend.
• Enable supported state locking.
• Test remote state management.

Project 5: Build Multi-Environment Infrastructure

Create reusable Terraform configurations for:

• Development.
• Testing.
• Production.

Use appropriate environment isolation, configuration, and state management.

8.15 Learning Resources

• Terraform documentation: https://developer.hashicorp.com/terraform/docs
• Terraform tutorials: https://developer.hashicorp.com/terraform/tutorials
• Terraform Registry: https://registry.terraform.io/
• AWS provider documentation: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
• Terraform best practices: https://developer.hashicorp.com/terraform/language

8.16 Phase 8 Completion Checklist

By the end of this phase, you should be able to:

• [ ] Explain Infrastructure as Code.
• [ ] Understand Terraform architecture and workflow.
• [ ] Write basic HCL configurations.
• [ ] Configure Terraform providers.
• [ ] Use resources and data sources.
• [ ] Work with variables, outputs, and locals.
• [ ] Execute Terraform core commands.
• [ ] Understand Terraform state management.
• [ ] Configure remote state and locking.
• [ ] Create and reuse Terraform modules.
• [ ] Manage multiple environments.
• [ ] Understand infrastructure drift.
• [ ] Import existing resources.
• [ ] Apply Terraform security best practices.
• [ ] Manage Terraform code using Git and GitHub.
• [ ] Provision AWS infrastructure using Terraform.

Expected outcome: You should be able to design reusable Terraform configurations, provision AWS infrastructure, manage remote state, and maintain infrastructure code using professional version-control practices.

Phase 9: Learn Docker and Containerization (Weeks 31–35)

Modern applications often contain multiple components, dependencies, libraries, and runtime requirements.

Deploying these applications consistently across development, testing, and production environments can be challenging.

Docker helps solve this problem by packaging applications and their dependencies into portable units called containers.

Containerization is a fundamental skill for AWS DevOps Engineers, particularly when working with microservices, CI/CD pipelines, Kubernetes, and cloud-native applications.

9.1 Understand Containerization

Learn:

• What is containerization?
• What is Docker?
• Why do we need containers?
• Traditional deployment vs container-based deployment.
• Containers vs virtual machines.
• Benefits of containerization.
• Application portability.
• Container isolation.
• Container lifecycle.
• Container orchestration fundamentals.

Understand how containers share the host operating system kernel while maintaining isolated execution environments.

9.2 Understand Docker Architecture

Learn the main components of Docker:

• Docker Client.
• Docker Daemon.
• Docker Engine.
• Docker Images.
• Docker Containers.
• Docker Registries.
• Docker Hub.
• Docker Desktop.

Understand how the Docker client communicates with the Docker daemon to build images and manage containers.

9.3 Install and Configure Docker

Learn how to:

1. Install Docker Desktop on Windows or macOS.
2. Understand Docker Engine on Linux.
3. Configure Docker using WSL 2 on Windows where appropriate.
4. Verify Docker installation.
5. Understand Docker service management.
6. Run your first container.

Check the installed version:

docker --version

Check Docker system information:

docker info

Run a test container:

docker run hello-world

9.4 Understand Docker Images

A Docker image is a packaged template used to create containers.

Learn:

• Image layers.
• Image tags.
• Image IDs.
• Base images.
• Image repositories.
• Image registries.
• Image caching.
• Image size optimization.
• Image lifecycle.

Essential commands:

docker images
docker pull nginx
docker inspect nginx
docker history nginx
docker rmi nginx

Understand the difference between an image and a running container.

9.5 Understand Docker Containers

A container is a running or stopped instance created from a Docker image.

Learn:

• Container creation.
• Container execution.
• Container lifecycle.
• Container isolation.
• Container networking.
• Container storage.
• Container resource limits.
• Container logs.

Essential commands:

docker run -d --name web nginx
docker ps
docker ps -a
docker stop web
docker start web
docker restart web
docker logs web
docker inspect web
docker rm web

Understand foreground and detached execution, interactive containers, and port mapping.

9.6 Learn Dockerfile

A Dockerfile contains instructions used to build a Docker image.

Learn these instructions:

• FROM
• RUN
• COPY
• ADD
• WORKDIR
• ENV
• ARG
• EXPOSE
• CMD
• ENTRYPOINT
• USER
• HEALTHCHECK

Example:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

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

Understand how Dockerfile instructions create image layers and why instruction ordering can affect build caching.

9.7 Build and Manage Docker Images

Learn how to:

• Build an image.
• Tag an image.
• Inspect an image.
• Remove unused images.
• Use build arguments.
• Use environment variables.
• Optimize image size.
• Rebuild images after application changes.

Example:

docker build -t myapp:1.0 .

Tag an image:

docker tag myapp:1.0 myapp:latest

9.8 Docker Volumes and Storage

Containers are designed to be replaceable. Data that must survive container replacement should be stored appropriately.

Learn:

• Container writable layers.
• Volumes.
• Bind mounts.
• Temporary filesystem mounts.
• Volume management.
• Persistent application data.
• Backup considerations.

Useful commands:

docker volume create app-data
docker volume ls
docker volume inspect app-data
docker volume rm app-data

Understand when to use a Docker volume and when a bind mount is more appropriate.

9.9 Docker Networking

Learn how containers communicate with each other and external systems.

Understand:

• Bridge networks.
• Host networking.
• None networking.
• User-defined bridge networks.
• Port publishing.
• Container DNS.
• Network isolation.
• Container-to-container communication.

Useful commands:

docker network ls
docker network create app-network
docker network inspect app-network
docker network connect app-network web
docker network disconnect app-network web

9.10 Docker Compose

Docker Compose allows you to define and manage multi-container applications using a YAML configuration file.

Learn:

• Compose files.
• Services.
• Networks.
• Volumes.
• Environment variables.
• Service dependencies.
• Health checks.
• Container startup order.
• Compose lifecycle.

Example:

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"

  database:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: example-password
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  mysql-data:

This is a learning example. Do not use a simple hardcoded database password in production.

Useful commands:

docker compose up -d
docker compose ps
docker compose logs
docker compose down

Understand why Docker Compose is useful for local development and testing.

9.11 Docker Registry and Image Management

A container registry stores and distributes container images.

Learn:

• Docker Hub.
• Private registries.
• Image repositories.
• Tags.
• Image authentication.
• Image push and pull.
• Registry permissions.
• Image scanning.
• Image retention.

Understand how to publish an image to a registry and retrieve it from another environment.

9.12 Amazon Elastic Container Registry (ECR)

Amazon ECR is a managed container image registry integrated with AWS.

Learn:

• ECR repositories.
• Private and public repositories.
• Image tags.
• Image push and pull.
• IAM permissions.
• Repository policies.
• Image scanning.
• Lifecycle policies.
• Authentication to ECR.

Understand how Docker images are stored in ECR before being deployed to ECS or EKS.

9.13 Multi-Stage Docker Builds

Multi-stage builds help reduce final image size by separating build dependencies from runtime dependencies.

Learn:

• Build stages.
• Build-time dependencies.
• Runtime images.
• Copying artifacts between stages.
• Image optimization.
• Build caching.

Understand why smaller images can improve deployment efficiency and reduce unnecessary attack surface.

9.14 Docker Security Best Practices

Learn:

• Run containers as non-root users where possible.
• Use trusted and maintained base images.
• Avoid embedding secrets in Dockerfiles.
• Scan images for vulnerabilities.
• Keep images updated.
• Apply resource limits.
• Use minimal images.
• Avoid unnecessary container privileges.
• Restrict network access.
• Use read-only filesystems where appropriate.
• Manage image tags carefully.
• Protect registry credentials.

9.15 Docker Troubleshooting

Learn how to troubleshoot:

• Containers that exit immediately.
• Image pull failures.
• Port conflicts.
• Application connectivity problems.
• Permission issues.
• Volume mounting errors.
• Container DNS problems.
• Build failures.
• High container resource usage.
• Application errors inside containers.

Useful commands:

docker logs <container-name>
docker exec -it <container-name> sh
docker inspect <container-name>
docker stats
docker events

9.16 Practical Docker Projects

Project 1: Containerize a Static Website

• Create a simple HTML webpage.
• Write a Dockerfile.
• Build an Nginx image.
• Run the container.
• Publish the application port.
• Access the webpage through a browser.

Project 2: Containerize a Python Application

• Create a Python application.
• Write a requirements file.
• Build a Docker image.
• Run the container.
• Configure environment variables.
• View application logs.

Project 3: Multi-Container Application

Build a sample application using:

• Frontend container.
• Backend container.
• Database container.

Use Docker Compose to manage services, networks, and persistent storage.

Project 4: Publish Images to Amazon ECR

• Create an ECR repository.
• Build a Docker image.
• Authenticate to ECR.
• Tag the image.
• Push the image.
• Verify the uploaded image.
• Pull the image from the repository.

Project 5: Optimize a Docker Image

• Create an initial Docker image.
• Identify unnecessary layers and dependencies.
• Implement a multi-stage build.
• Use a smaller trusted base image.
• Compare image sizes.
• Scan the resulting image.

9.17 Learning Resources

• Docker documentation: https://docs.docker.com/
• Docker Get Started: https://docs.docker.com/get-started/
• Dockerfile reference: https://docs.docker.com/reference/dockerfile/
• Docker Compose documentation: https://docs.docker.com/compose/
• Amazon ECR documentation: https://docs.aws.amazon.com/ecr/

9.18 Phase 9 Completion Checklist

By the end of this phase, you should be able to:

• [ ] Explain containerization and Docker architecture.
• [ ] Differentiate containers and virtual machines.
• [ ] Install and configure Docker.
• [ ] Manage images and containers.
• [ ] Write Dockerfiles.
• [ ] Build and tag images.
• [ ] Work with Docker volumes.
• [ ] Configure Docker networking.
• [ ] Use Docker Compose.
• [ ] Push and pull images from registries.
• [ ] Integrate Docker with Amazon ECR.
• [ ] Build optimized multi-stage images.
• [ ] Apply Docker security best practices.
• [ ] Troubleshoot common Docker issues.
• [ ] Containerize a sample application.

Expected outcome: You should be able to containerize applications, manage their images and runtime environments, publish images to Amazon ECR, and prepare containerized workloads for deployment through orchestration platforms.

Phase 10: CI/CD Pipelines and Automation (Weeks 36–40)

CI/CD is one of the most important skills for an AWS DevOps Engineer. It helps teams automate software building, testing, and deployment instead of performing every step manually.

In this phase, you will learn how to design, build, secure, troubleshoot, and maintain CI/CD pipelines using tools such as GitHub Actions and Jenkins.

10.1 What Is CI/CD?

CI/CD stands for Continuous Integration and Continuous Delivery or Continuous Deployment.

It is a software development practice that automates the process of integrating code changes, validating applications, and delivering software to environments.

Without CI/CD, developers may need to manually:

1. Write application code.
2. Test the application.
3. Build a Docker image.
4. Push the image to a container registry.
5. Connect to a server.
6. Deploy the application.
7. Verify whether the deployment succeeded.

CI/CD pipelines automate many of these activities.

10.2 Continuous Integration (CI)

Continuous Integration is the practice of frequently integrating code changes into a shared repository.

Whenever a developer pushes code or creates a pull request, an automated pipeline can:

• Check out the source code.
• Install dependencies.
• Run code-quality checks.
• Execute unit tests.
• Build the application.
• Build a Docker image.
• Perform security scans.

Example:

A developer pushes a Python application to GitHub. GitHub Actions automatically runs tests and builds the application.

If the tests fail, the pipeline reports the failure so the developer can fix the issue before the code proceeds further.

10.3 Continuous Delivery vs. Continuous Deployment

These terms are related but have an important difference.

Continuous Delivery

Code is automatically built, tested, and prepared for deployment. A human approval may be required before production deployment.

Continuous Deployment

Every change that successfully passes the required automated checks is automatically deployed to production.

Feature	Continuous Delivery	Continuous Deployment
Automated build	Yes	Yes
Automated testing	Yes	Yes
Production deployment	Approval may be required	Automated
Human intervention	Often required	Not normally required

10.4 Understanding a CI/CD Pipeline

A pipeline consists of multiple stages that execute in a defined order.

A typical application pipeline looks like this:

Developer writes code
        |
        v
Push code to GitHub
        |
        v
Source Code Checkout
        |
        v
Install Dependencies
        |
        v
Code Quality Checks
        |
        v
Run Automated Tests
        |
        v
Build Application
        |
        v
Build Docker Image
        |
        v
Security and Image Scanning
        |
        v
Push Image to Amazon ECR
        |
        v
Deploy to AWS Environment
        |
        v
Deployment Verification
        |
        v
Monitoring and Notifications

Not every pipeline needs every stage. The pipeline should reflect the application's architecture, security requirements, and release process.

10.5 Important CI/CD Concepts

Before working with pipeline tools, understand these concepts.

Pipeline: A collection of automated steps that build, test, and deploy software.

Stage: A logical section of a pipeline, such as build, test, or deployment.

Job: A unit of work executed by a pipeline runner or agent.

Step: An individual command or action inside a job.

Runner or Agent: The machine or execution environment that runs pipeline jobs.

Artifact: A file produced during a pipeline, such as a compiled application, test report, or deployment package.

Environment: A deployment target such as development, testing, staging, or production.

Secret: Sensitive information such as passwords, API tokens, and access credentials. Secrets must not be committed to source code.

10.6 GitHub Actions

GitHub Actions is a CI/CD and workflow automation platform integrated with GitHub.

It allows developers to automate tasks whenever specific repository events occur.

Examples include:

• Running tests after every code push.
• Building Docker images.
• Scanning application dependencies.
• Publishing images to Amazon ECR.
• Deploying applications to AWS.
• Sending notifications after a deployment.

Important GitHub Actions Components

Workflow: An automated process defined in a YAML file.

Event: The activity that triggers a workflow, such as push, pull_request, or a scheduled event.

Job: A collection of steps executed on a runner.

Runner: The machine that executes the workflow.

Step: An individual action or shell command.

Action: A reusable unit of automation.

Example GitHub Actions Workflow

Create the following file inside your repository:

.github/workflows/ci.yml

name: Python Application CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Source Code
        uses: actions/checkout@v4

      - name: Set Up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install Dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run Tests
        run: |
          python -m unittest discover

This example checks out the repository, installs Python dependencies, and runs automated tests.

For a production workflow, select supported action versions, pin third-party actions to verified commit SHAs where appropriate, and update them through a controlled process.

10.7 Jenkins

Jenkins is an open-source automation server commonly used to implement CI/CD pipelines.

It can integrate with GitHub, Docker, Kubernetes, AWS, and many other tools.

Important Jenkins Components

• Controller: Manages pipeline execution, configuration, and scheduling.
• Agent: Executes pipeline tasks.
• Job: An individual automation task.
• Pipeline: A sequence of stages and steps.
• Jenkinsfile: A file that defines a pipeline as code.
• Plugin: An extension that adds functionality to Jenkins.

Example Jenkins Pipeline

Create a file named Jenkinsfile in your project repository.

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                echo 'Checking out source code'
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'python3 -m pip install -r requirements.txt'
            }
        }

        stage('Run Tests') {
            steps {
                sh 'python3 -m unittest discover'
            }
        }

        stage('Build') {
            steps {
                echo 'Building application'
            }
        }
    }
}

This is a basic declarative Jenkins pipeline. It demonstrates how to organize automation into stages.

10.8 GitLab CI/CD Fundamentals

GitLab CI/CD is an automation platform integrated into GitLab.

Its pipeline configuration is normally defined in a file called:

.gitlab-ci.yml

Important concepts include:

• Pipelines
• Stages
• Jobs
• Runners
• Artifacts
• Cache
• Environment variables
• Deployment environments

You should understand how GitLab CI/CD works and be able to read and modify basic pipeline configurations, even if you choose GitHub Actions or Jenkins as your primary hands-on tool.

10.9 Connecting CI/CD with Docker and Amazon ECR

In a container-based application, a pipeline can build a Docker image and push it to Amazon Elastic Container Registry (ECR).

A simplified workflow:

GitHub Repository
       |
       v
GitHub Actions
       |
       v
Build Docker Image
       |
       v
Run Security Scan
       |
       v
Authenticate to AWS
       |
       v
Push Image to Amazon ECR
       |
       v
Deploy to ECS or EKS

A production pipeline should use secure authentication, preferably GitHub Actions OpenID Connect (OIDC) with an appropriately restricted AWS IAM role instead of long-lived AWS access keys.

10.10 Deploying Applications Through CI/CD

You should understand how pipelines deploy applications to different AWS services.

Amazon EC2: Deploy an application or container to an EC2 instance using a controlled deployment mechanism.

Amazon ECS: Update an ECS service with a new task definition and container image.

Amazon EKS: Update Kubernetes deployment manifests or Helm releases to use the new image.

AWS Lambda: Package and deploy updated function code or container images.

Learn how to handle:

• Development, testing, staging, and production environments.
• Environment-specific configuration.
• Deployment approvals.
• Health checks.
• Failed deployments.
• Rollbacks.
• Release versioning.

10.11 CI/CD Security Best Practices

A CI/CD pipeline can become a security risk if credentials, permissions, and dependencies are not managed properly.

Follow these practices:

1. Never hardcode AWS access keys or passwords in pipeline files.
2. Use GitHub Secrets or an equivalent secret-management facility.
3. Prefer OIDC-based authentication for GitHub Actions to AWS.
4. Follow the principle of least privilege for IAM roles.
5. Scan dependencies and container images.
6. Protect important branches.
7. Require reviews for sensitive changes.
8. Restrict production deployment permissions.
9. Pin and review third-party pipeline actions.
10. Keep build agents and dependencies updated.

10.12 Pipeline Troubleshooting

A DevOps Engineer should be able to investigate pipeline failures systematically.

Common problems include:

Problem	Possible Cause
Dependency installation fails	Incorrect package version or network issue
Unit tests fail	Application bug or incorrect test configuration
Docker build fails	Invalid Dockerfile or missing build files
ECR push fails	Incorrect IAM permissions or authentication
Deployment fails	Configuration, networking, or permission issue
Pipeline cannot access secrets	Incorrect secret configuration
Production health check fails	Application startup or infrastructure problem

Useful troubleshooting practices:

• Read the complete pipeline logs.
• Identify the first failing step.
• Reproduce the error locally when possible.
• Verify environment variables and secrets.
• Check IAM permissions and AWS service logs.
• Validate the deployment before attempting a rollback.

10.13 Hands-On Projects

Project 1: Python CI Pipeline

Create a simple Python application and build a GitHub Actions workflow that installs dependencies and runs unit tests.

Project 2: Docker Build Pipeline

Create a Dockerfile for a Python application. Configure GitHub Actions to build the image whenever code is pushed to the main branch.

Project 3: Docker Image Publishing to Amazon ECR

Extend the workflow to authenticate to AWS using OIDC, build the image, and push it to an ECR repository.

Project 4: AWS Deployment Pipeline

Create a pipeline that deploys an application to an AWS service such as ECS. Include deployment verification and a rollback strategy.

Project 5: Multi-Environment CI/CD Pipeline

Design a pipeline with separate development, staging, and production environments. Add an approval step before production deployment.

10.14 Recommended Learning Resources

• GitHub Actions Documentation: https://docs.github.com/en/actions
• Jenkins Documentation: https://www.jenkins.io/doc/
• GitLab CI/CD Documentation: https://docs.gitlab.com/ci/
• Amazon ECR Documentation: https://docs.aws.amazon.com/ecr/
• AWS IAM OIDC Documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html

10.15 Phase 10 Completion Checklist

Before moving to Kubernetes, make sure you can:

• [ ] Explain CI, Continuous Delivery, and Continuous Deployment.
• [ ] Describe the stages of a CI/CD pipeline.
• [ ] Understand workflows, jobs, steps, runners, and artifacts.
• [ ] Create a basic GitHub Actions workflow.
• [ ] Understand Jenkins architecture and Jenkinsfiles.
• [ ] Read and understand a basic GitLab CI/CD pipeline.
• [ ] Build Docker images through a pipeline.
• [ ] Push Docker images to Amazon ECR.
• [ ] Explain secure GitHub Actions-to-AWS authentication using OIDC.
• [ ] Understand deployment approvals and environment protection.
• [ ] Troubleshoot common pipeline failures.
• [ ] Build at least one complete CI/CD project.

Expected Outcome: By the end of this phase, you should be able to create an automated CI/CD pipeline that takes application code from a Git repository, runs tests, builds a Docker image, publishes it to Amazon ECR, and prepares it for deployment to AWS.

Phase 11: Kubernetes and Container Orchestration (Weeks 41–47)

Docker helps you package and run applications inside containers. However, managing a large number of containers across multiple servers introduces additional challenges.

Consider an application running across 20 containers. What happens if:

• A container crashes?
• Application traffic suddenly increases?
• A server becomes unavailable?
• You need to deploy a new application version?
• Multiple application services need to communicate?
• You need to scale applications without manually managing every container?

Managing these tasks manually becomes difficult as applications grow.

This is where Kubernetes becomes useful.

11.1 What Is Kubernetes?

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.

It helps manage containers across a cluster of machines.

Kubernetes is commonly abbreviated as K8s.

Important capabilities include:

• Container orchestration.
• Automated application deployment.
• Scaling application workloads.
• Self-healing and container replacement.
• Service discovery and load balancing.
• Configuration and secret management.
• Rolling updates and rollbacks.
• Resource management.

Example:

Suppose an application runs inside three containers.

If one container crashes, Kubernetes can detect the failure and create a replacement to maintain the desired number of application instances.

This is an example of Kubernetes self-healing behavior.

11.2 Why Do We Need Kubernetes?

Docker can run containers, but Docker alone does not provide the complete orchestration capabilities required for managing large containerized applications across a cluster.

Docker	Kubernetes
Builds container images	Manages containerized workloads
Runs individual containers	Coordinates workloads across a cluster
Provides container networking	Provides cluster-level networking and services
Uses Docker Compose for multi-container applications	Uses Kubernetes resources and controllers
Does not provide Kubernetes-style cluster orchestration by itself	Provides scheduling, scaling, and self-healing

Docker and Kubernetes solve related but different problems. Kubernetes can run containers using compatible container runtimes such as containerd.

11.3 Kubernetes Architecture

A Kubernetes cluster consists of two major parts:

1. Control Plane
2. Worker Nodes

Control Plane

The control plane manages the cluster and makes decisions about application workloads.

Important components include:

• API Server
• Scheduler
• Controller Manager
• etcd

Worker Nodes

Worker nodes run application workloads.

Important components include:

• kubelet
• kube-proxy (commonly used, although some networking implementations replace its functionality)
• Container Runtime

Simplified architecture:

                 Kubernetes Cluster
                         |
              +----------------------+
              |     Control Plane    |
              |                      |
              |    API Server        |
              |    Scheduler        |
              |    Controller Mgr   |
              |    etcd             |
              +----------------------+
                         |
              +----------+----------+
              |                     |
        Worker Node 1         Worker Node 2
              |                     |
        +-----------+         +-----------+
        | Pod       |         | Pod       |
        | Container |         | Container |
        +-----------+         +-----------+
        | Pod       |         | Pod       |
        | Container |         | Container |
        +-----------+         +-----------+

11.4 Control Plane Components

API Server

The API Server is the main communication interface of Kubernetes.

When you execute a command such as:

kubectl get pods

kubectl communicates with the Kubernetes API Server to retrieve cluster information.

Scheduler

The Scheduler decides which worker node should run a newly created Pod.

It considers factors such as available resources and scheduling constraints.

Controller Manager

The Controller Manager runs controllers that continuously compare the actual cluster state with the desired state.

For example, if you request three application replicas but only two are running, a controller works to create another replica.

etcd

etcd is a distributed key-value store that maintains Kubernetes cluster state and configuration data.

11.5 Worker Node Components

kubelet

The kubelet runs on each worker node and communicates with the API Server.

It ensures that the Pods assigned to its node are running as expected.

Container Runtime

The container runtime is responsible for running containers.

Examples include containerd and CRI-O.

kube-proxy

kube-proxy traditionally implements Kubernetes Service networking behavior on nodes. Some cluster networking solutions provide equivalent functionality without kube-proxy.

11.6 What Is a Pod?

A Pod is the smallest deployable unit in Kubernetes.

A Pod can contain one or more containers that share certain resources, such as networking and storage.

Most application Pods contain one main application container, although multi-container Pods are useful for tightly coupled supporting processes.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx:stable
      ports:
        - containerPort: 80

Save this configuration as pod.yaml.

Create the Pod:

kubectl apply -f pod.yaml

Check the Pod:

kubectl get pods

View detailed information:

kubectl describe pod nginx-pod

11.7 What Is a ReplicaSet?

A ReplicaSet maintains a specified number of identical Pod replicas.

For example, if you configure three replicas, Kubernetes attempts to maintain three matching Pods.

If one Pod disappears, the ReplicaSet creates another to restore the desired count.

In real-world applications, Deployments are generally used to manage ReplicaSets rather than creating ReplicaSets directly.

11.8 What Is a Deployment?

A Deployment manages application Pods and their ReplicaSets.

It supports:

• Application deployment.
• Replica management.
• Rolling updates.
• Rollbacks.
• Declarative application updates.

Example:

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

Apply the Deployment:

kubectl apply -f deployment.yaml

Check its status:

kubectl get deployments

Check Pods:

kubectl get pods

Scale the Deployment:

kubectl scale deployment nginx-deployment --replicas=5

Update the container image:

kubectl set image deployment/nginx-deployment nginx=nginx:latest

Check rollout status:

kubectl rollout status deployment/nginx-deployment

Undo a deployment update:

kubectl rollout undo deployment/nginx-deployment

11.9 Kubernetes Services

Pods are temporary resources. Their IP addresses can change when they are recreated.

A Kubernetes Service provides a stable network endpoint for accessing a group of Pods.

Important Service types:

ClusterIP

Provides internal access to an application from within the cluster. This is the default Service type.

NodePort

Exposes a Service on a port across the cluster nodes.

LoadBalancer

Requests an external load balancer through the cluster's infrastructure integration, when supported.

Example:

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

Apply the Service:

kubectl apply -f service.yaml

Check Services:

kubectl get services

11.10 Namespaces

Namespaces provide logical separation of resources within a Kubernetes cluster.

They are useful for organizing environments and teams.

For example:

• development
• testing
• staging
• production

Create a namespace:

kubectl create namespace development

List namespaces:

kubectl get namespaces

Deploy an application into a namespace:

kubectl apply -f deployment.yaml -n development

List Pods in a namespace:

kubectl get pods -n development

Namespaces provide logical organization, but they are not a complete security boundary by themselves.

11.11 ConfigMaps and Secrets

Applications often need configuration values such as database endpoints, application modes, and credentials.

Kubernetes provides two important resources for managing configuration.

ConfigMap

Stores non-confidential configuration data.

Example:

kubectl create configmap app-config \
  --from-literal=APP_ENV=development

Secret

Stores sensitive configuration data such as passwords and tokens.

Example:

kubectl create secret generic app-secret \
  --from-literal=DB_PASSWORD=change-this-value

The example value is only a placeholder. Do not use real credentials in public repositories or article examples.

Important security considerations:

• Enable encryption at rest for Kubernetes Secrets.
• Apply restrictive RBAC permissions.
• Avoid exposing secrets in logs.
• Consider external secret-management solutions.
• Use AWS Secrets Manager or another appropriate secret store when integrating with AWS.

Kubernetes Secrets are not automatically secure merely because their values are encoded in Base64.

11.12 Health Checks and Probes

Kubernetes uses probes to understand application health.

Liveness Probe

Checks whether a container is still functioning. Kubernetes can restart a container when its liveness probe repeatedly fails.

Readiness Probe

Checks whether a container is ready to receive traffic.

Startup Probe

Provides time for an application to start before liveness and readiness checks become active.

Example:

livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /
    port: 80
  periodSeconds: 5

These settings must be tuned to the application's actual startup and health-check behavior.

11.13 Resource Requests and Limits

Kubernetes allows you to specify CPU and memory requirements for containers.

Requests

The amount of CPU and memory Kubernetes uses when scheduling a Pod.

Limits

The maximum CPU and memory resources a container can use, subject to Kubernetes resource behavior.

Example:

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Resource management helps prevent applications from consuming excessive cluster resources.

11.14 Kubernetes Storage

Containers are generally designed to be replaceable. Data that must survive container replacement needs appropriate storage.

Important storage concepts include:

• Volumes
• Persistent Volumes (PV)
• Persistent Volume Claims (PVC)
• StorageClasses
• Dynamic provisioning

Persistent Volume

Represents storage available to the cluster.

Persistent Volume Claim

Represents a request for storage by an application.

StorageClass

Defines how storage can be dynamically provisioned.

In AWS, persistent storage can be integrated with services such as Amazon EBS and Amazon EFS through suitable CSI drivers.

11.15 Ingress

Ingress provides HTTP and HTTPS routing to Services inside a Kubernetes cluster.

For example:

                  Internet
                     |
                     v
               Ingress Controller
                     |
              +------+------+
              |             |
              v             v
          Service A     Service B
              |             |
              v             v
          Application   Application

An Ingress resource defines routing rules, while an Ingress Controller implements those rules.

Kubernetes Gateway API is another important approach to managing application traffic and should also be explored.

11.16 RBAC and Kubernetes Security

RBAC stands for Role-Based Access Control.

It controls what users and service accounts are allowed to do in a Kubernetes cluster.

Important resources include:

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding
• ServiceAccount

Security practices:

1. Follow the principle of least privilege.
2. Avoid giving unnecessary cluster-admin permissions.
3. Restrict access to Secrets.
4. Use network policies where supported.
5. Keep Kubernetes and container images updated.
6. Scan images for vulnerabilities.
7. Use secure authentication and authorization.
8. Avoid running containers as root unless required.

11.17 Helm

Helm is a package manager for Kubernetes.

It helps you package, configure, install, and upgrade Kubernetes applications.

Important Helm concepts:

• Chart
• Release
• Values
• Templates
• Repository

Useful commands:

helm version
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx
helm install my-nginx bitnami/nginx
helm list
helm upgrade my-nginx bitnami/nginx
helm uninstall my-nginx

Always review the chart's source, permissions, configuration, and resource requirements before installing it in a production environment.

11.18 Important kubectl Commands

kubectl is the command-line tool used to communicate with Kubernetes clusters.

Command	Purpose
kubectl get nodes	List cluster nodes
kubectl get pods	List Pods
kubectl get deployments	List Deployments
kubectl get services	List Services
kubectl describe pod NAME	Inspect a Pod
kubectl logs POD_NAME	View container logs
kubectl exec -it POD_NAME -- sh	Open a shell in a container
kubectl apply -f file.yaml	Apply a configuration
kubectl delete -f file.yaml	Delete resources defined in a file
kubectl get all	Display common resources in the current namespace
kubectl rollout history deployment/NAME	View Deployment rollout history
kubectl top pods	View Pod resource usage when Metrics Server is available
kubectl config get-contexts	List configured cluster contexts

11.19 Kubernetes Troubleshooting

A DevOps Engineer must understand how to identify and resolve common Kubernetes problems.

Problem	Meaning or Possible Cause
Pending	Pod has not been scheduled or cannot obtain required resources
ImagePullBackOff	Kubernetes cannot successfully pull the container image
CrashLoopBackOff	Container repeatedly starts and crashes
CreateContainerConfigError	Container configuration or referenced resources are invalid
OOMKilled	Container was terminated after exceeding its memory limit
Node NotReady	Node is not reporting healthy status

Useful troubleshooting commands:

kubectl get pods -o wide
kubectl describe pod POD_NAME
kubectl logs POD_NAME
kubectl logs POD_NAME --previous
kubectl get events --sort-by=.metadata.creationTimestamp
kubectl describe node NODE_NAME

Always inspect events, application logs, resource availability, and configuration before making changes.

11.20 Hands-On Projects

Project 1: Deploy an Nginx Application

Create a Kubernetes cluster using Minikube or another suitable local environment. Deploy Nginx using a Pod and then a Deployment.

Project 2: Application Scaling

Create a Deployment with three replicas. Scale it to five replicas and verify the results.

Project 3: Service Networking

Create a ClusterIP Service and access your application from another Pod.

Project 4: Configuration Management

Use ConfigMaps and Secrets to provide configuration values to an application.

Project 5: Application Health Monitoring

Configure liveness, readiness, and startup probes for an application.

Project 6: Persistent Storage

Deploy an application that uses a PersistentVolumeClaim and verify that data survives Pod replacement.

Project 7: Helm Deployment

Install an application using Helm and perform an upgrade and rollback.

11.21 Recommended Learning Resources

• Kubernetes Official Documentation: https://kubernetes.io/docs/
• Kubernetes Tutorials: https://kubernetes.io/docs/tutorials/
• Minikube: https://minikube.sigs.k8s.io/docs/
• Helm Documentation: https://helm.sh/docs/
• Kubernetes Concepts: https://kubernetes.io/docs/concepts/

11.22 Phase 11 Completion Checklist

Before moving to AWS container services, make sure you can:

• [ ] Explain Kubernetes and why container orchestration is needed.
• [ ] Explain Kubernetes cluster architecture.
• [ ] Understand control plane and worker node components.
• [ ] Create and manage Pods.
• [ ] Deploy applications using Deployments.
• [ ] Scale application replicas.
• [ ] Configure Kubernetes Services.
• [ ] Work with Namespaces.
• [ ] Understand ConfigMaps and Secrets.
• [ ] Configure application health probes.
• [ ] Manage CPU and memory requests and limits.
• [ ] Understand Persistent Volumes and Persistent Volume Claims.
• [ ] Configure Ingress and understand Gateway API fundamentals.
• [ ] Understand Kubernetes RBAC.
• [ ] Install applications using Helm.
• [ ] Troubleshoot common Kubernetes errors.
• [ ] Complete at least three practical Kubernetes projects.

Expected Outcome: By the end of this phase, you should be able to deploy, expose, scale, configure, and troubleshoot containerized applications on a Kubernetes cluster and understand the foundations required to work with Amazon EKS.

Phase 12: AWS Container Services — ECR, ECS, Fargate, and EKS (Weeks 48–51)

In the previous phases, you learned Docker and Kubernetes. Now it is time to understand how organizations run containerized applications on AWS.

AWS provides several services for storing, managing, and running containers.

The most important services for an AWS DevOps Engineer are:

• Amazon Elastic Container Registry (ECR)
• Amazon Elastic Container Service (ECS)
• AWS Fargate
• Amazon Elastic Kubernetes Service (EKS)

By the end of this phase, you should understand how to select the appropriate container service, deploy applications, manage infrastructure, and troubleshoot container workloads in AWS.

12.1 Understanding AWS Container Architecture

Consider an organization that develops a web application using Docker.

The organization needs to:

1. Build a Docker image.
2. Store the image securely.
3. Run containers on AWS.
4. Scale the application based on traffic.
5. Expose the application to users.
6. Monitor application health.
7. Secure access to AWS resources.

AWS container services help implement this architecture.

A simplified architecture:

              Developer
                  |
                  v
             GitHub Repo
                  |
                  v
             CI/CD Pipeline
                  |
                  v
             Docker Build
                  |
                  v
              Amazon ECR
                  |
          +-------+-------+
          |               |
          v               v
        Amazon ECS      Amazon EKS
          |               |
          v               v
       Fargate or       Kubernetes
       EC2 capacity      Cluster
          |               |
          +-------+-------+
                  |
                  v
           Application Users

12.2 Amazon Elastic Container Registry (ECR)

Amazon ECR is a fully managed container image registry.

It allows organizations to store, manage, and retrieve container images.

Think of ECR as a private Docker image repository hosted on AWS.

Important capabilities:

• Store Docker and OCI-compatible container images.
• Manage private repositories.
• Integrate with Amazon ECS and EKS.
• Support image tagging.
• Scan images for vulnerabilities using supported scanning features.
• Apply lifecycle policies to manage old images.
• Control repository access using IAM and repository policies.

Important ECR Concepts

Registry: The image registry associated with an AWS account and Region.

Repository: A location where container images are stored.

Image: A packaged application containing its runtime and dependencies.

Tag: A label used to identify a particular image version.

Lifecycle Policy: A policy that can expire or retain images based on configured rules.

Basic ECR Workflow

Developer
   |
   v
Build Docker Image
   |
   v
Authenticate to ECR
   |
   v
Tag Docker Image
   |
   v
Push Image to ECR
   |
   v
Image Stored in Repository

Common ECR Commands

Authenticate Docker to your ECR registry:

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

Create a repository:

aws ecr create-repository \
--repository-name my-application \
--region ap-south-1

Build an image:

docker build -t my-application .

Tag the image:

docker tag my-application:latest \
ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com/my-application:latest

Push the image:

docker push \
ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com/my-application:latest

Replace ACCOUNT_ID with your AWS account ID and use the appropriate Region and repository name.

For production deployments, prefer immutable or uniquely identifiable image tags rather than relying only on latest.

12.3 Amazon Elastic Container Service (ECS)

Amazon ECS is a fully managed container orchestration service provided by AWS.

It allows you to deploy, manage, and scale containerized applications without having to operate your own Kubernetes control plane.

ECS integrates with other AWS services such as:

• Amazon ECR
• Elastic Load Balancing
• AWS IAM
• Amazon CloudWatch
• Amazon VPC
• AWS Auto Scaling

Important ECS Components

Cluster

A logical grouping of infrastructure used to run ECS tasks and services.

Task Definition

A blueprint describing how containers should run.

It includes information such as:

• Container image.
• CPU and memory configuration.
• Port mappings.
• Environment variables.
• Logging configuration.
• IAM roles.
• Storage configuration.

Task

An instantiated workload created from a task definition.

Service

Maintains the desired number of running tasks and manages their lifecycle.

Container Instance

An EC2 instance registered with an ECS cluster when using the EC2 launch type or capacity provider model.

ECS Architecture

                 Amazon ECS
                      |
                ECS Cluster
                      |
          +-----------+-----------+
          |                       |
          v                       v
      ECS Service A          ECS Service B
          |                       |
          v                       v
       Task A                  Task B
          |                       |
      +---+---+               +---+---+
      |       |               |       |
    App     Sidecar          App     Sidecar
  Container Container      Container Container

ECS Launch Options

ECS supports different infrastructure choices.

EC2 Launch Type

You manage the EC2 instances that provide compute capacity for your containers.

You are responsible for aspects such as:

• EC2 instance selection.
• Operating system maintenance.
• Capacity planning.
• Instance-level security.
• Scaling the underlying infrastructure.

Fargate Launch Type

AWS Fargate provides serverless compute for containers.

You do not need to provision or manage the underlying EC2 instances.

You configure the task's resource requirements, and AWS manages the underlying compute infrastructure.

ECS can also use capacity providers to manage and scale infrastructure for workloads.

12.4 AWS Fargate

AWS Fargate is a serverless compute engine for containers.

It works with Amazon ECS and Amazon EKS.

With Fargate, you can run containers without directly managing the underlying servers.

Important benefits:

• No direct EC2 instance management.
• Infrastructure management handled by AWS.
• Resource-based task or Pod configuration.
• Integration with AWS networking and IAM.
• Simplified container operations.

Example:

Suppose an organization needs to run a small API application.

Instead of creating EC2 instances, installing a container runtime, and managing the servers, the organization can use ECS with Fargate.

It defines the required CPU, memory, networking, and container image. Fargate provides the underlying compute capacity.

Remember that serverless does not mean free. Fargate usage, networking, storage, and other associated resources can incur charges.

12.5 Amazon ECS vs. AWS Fargate

These services are related but are not the same.

Amazon ECS	AWS Fargate
Container orchestration service	Serverless container compute engine
Manages container workloads	Provides compute capacity to run containers
Supports EC2 and Fargate capacity	Works with ECS and EKS
Defines clusters, tasks, and services	Runs workloads without direct server management

ECS manages the orchestration of workloads, while Fargate provides the underlying serverless compute for supported workloads.

12.6 Amazon Elastic Kubernetes Service (EKS)

Amazon EKS is a managed Kubernetes service provided by AWS.

It allows organizations to run Kubernetes workloads without managing the Kubernetes control plane themselves.

AWS manages the EKS control plane, while you remain responsible for configuring and operating your workloads and much of the worker infrastructure.

Important EKS features:

• Managed Kubernetes control plane.
• Integration with AWS IAM.
• VPC networking.
• Integration with Amazon ECR.
• Support for Kubernetes workloads.
• Integration with AWS load balancing.
• Support for EC2 and Fargate compute options, subject to workload requirements.

EKS Architecture

                 AWS Cloud
                     |
                     v
             Amazon EKS Cluster
                     |
          +----------+----------+
          |                     |
          v                     v
     EKS Control Plane      Worker Compute
      Managed by AWS        |
          |                 +------+
          |                 |      |
          v                 v      v
       Kubernetes          EC2   Fargate
          API             Nodes  Pods
          |
          v
     Kubernetes Resources
     - Deployments
     - Services
     - Pods
     - ConfigMaps
     - Secrets

EKS worker workloads can run on managed node groups, self-managed nodes, or Fargate profiles, depending on the cluster design.

12.7 EKS Important Concepts

EKS Cluster

The managed Kubernetes environment created through Amazon EKS.

Managed Node Group

A group of EC2 worker nodes managed through EKS.

AWS helps manage node provisioning and lifecycle operations, while you still need to maintain compatible configurations and plan upgrades.

Fargate Profile

Defines which Kubernetes Pods should run using AWS Fargate.

EKS Add-ons

Add-ons provide important cluster capabilities, such as networking, DNS, and storage integration.

EKS Access Entries

Provide a way to configure IAM principal access to an EKS cluster.

12.8 Connecting kubectl to EKS

The AWS CLI can update your local kubeconfig file to connect to an EKS cluster.

Example:

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

Check cluster nodes:

kubectl get nodes

Check running Pods:

kubectl get pods -A

View cluster information:

kubectl cluster-info

The IAM identity used by the AWS CLI must have the necessary EKS access, and the network must allow connectivity to the Kubernetes API endpoint.

12.9 AWS Load Balancing with ECS and EKS

Applications running inside containers often need to receive traffic from external users.

AWS provides Elastic Load Balancing services.

Important load balancers include:

Application Load Balancer (ALB)

Works at the application layer and supports HTTP/HTTPS routing.

Network Load Balancer (NLB)

Works at the transport layer and supports high-performance TCP, UDP, and TLS use cases.

For ECS, you can associate a load balancer with a service.

For EKS, AWS Load Balancer Controller can provision and manage supported AWS load-balancing resources based on Kubernetes resources.

12.10 ECR vs. ECS vs. EKS vs. Fargate

Understanding the differences between these services is important for interviews.

Service	Primary Purpose
ECR	Stores container images
ECS	Orchestrates container workloads
EKS	Provides managed Kubernetes
Fargate	Runs containers without direct server management

Real-world example:

An organization builds a Docker image and pushes it to Amazon ECR.

It then chooses one of two orchestration approaches:

• ECS for AWS-native container orchestration.
• EKS for Kubernetes-based container orchestration.

For compute, it can choose supported EC2-based capacity or Fargate, depending on the service, workload, and architecture.

12.11 ECS vs. EKS

Feature	ECS	EKS
Orchestration	AWS-native	Kubernetes
Learning complexity	Generally simpler	Generally more complex
Kubernetes compatibility	No Kubernetes API	Yes
AWS integration	Native AWS integration	AWS and Kubernetes ecosystem
Control plane management	AWS-managed service	AWS manages Kubernetes control plane
Workload compute	EC2 or Fargate	EC2 or Fargate, depending on workload
Best suited for	AWS-focused container workloads	Kubernetes-based workloads and ecosystems

Neither service is universally better. The right choice depends on team expertise, application requirements, operational complexity, portability needs, and cost.

12.12 AWS Container Security

Container security is an essential responsibility of an AWS DevOps Engineer.

Important practices include:

1. Store images in private ECR repositories when appropriate.
2. Scan images for known vulnerabilities.
3. Use minimal and trusted base images.
4. Avoid running containers with unnecessary privileges.
5. Follow IAM least-privilege principles.
6. Use task roles for ECS applications.
7. Use appropriate workload identity mechanisms for EKS.
8. Store credentials in AWS Secrets Manager or another suitable secret-management system.
9. Restrict network access using security groups and network policies where supported.
10. Keep container images and runtime components updated.

Do not embed AWS credentials inside Docker images.

12.13 Container Monitoring and Troubleshooting

Monitor your containerized applications using AWS monitoring services and platform-level tools.

For ECS, understand:

• ECS service events.
• Task status.
• Container exit codes.
• CloudWatch Logs.
• CPU and memory utilization.
• Load balancer health checks.

For EKS, understand:

• Pod status.
• Kubernetes events.
• Container logs.
• Node health.
• Resource utilization.
• Cluster networking.
• Control plane logs.

Useful commands:

aws ecs list-clusters

aws ecs list-services \
--cluster my-cluster

aws ecs list-tasks \
--cluster my-cluster

aws eks list-clusters \
--region ap-south-1

kubectl get pods -A

kubectl describe pod POD_NAME

kubectl logs POD_NAME

When troubleshooting, start with the service events and logs, then inspect IAM permissions, networking, resource availability, image access, and application health.

12.14 Hands-On Projects

Project 1: Push a Docker Image to ECR

Build a Docker image locally, create an ECR repository, authenticate, and push the image.

Project 2: Deploy an Application Using ECS

Create an ECS cluster, task definition, and service. Run a containerized application and verify its health.

Project 3: Run Containers Using Fargate

Deploy a small application using ECS with Fargate. Configure CPU, memory, networking, logging, and security.

Project 4: Deploy an Application to EKS

Create a Kubernetes cluster using a suitable learning environment. Deploy an application using Kubernetes Deployments and Services.

Project 5: CI/CD to ECS

Build a pipeline that creates a Docker image, pushes it to ECR, and updates an ECS service.

Project 6: CI/CD to EKS

Build a pipeline that publishes an image to ECR and deploys the updated application to EKS.

12.15 Recommended Learning Resources

• Amazon ECR: https://docs.aws.amazon.com/ecr/
• Amazon ECS: https://docs.aws.amazon.com/ecs/
• AWS Fargate: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
• Amazon EKS: https://docs.aws.amazon.com/eks/
• AWS Containers: https://aws.amazon.com/containers/

12.16 Phase 12 Completion Checklist

Before moving to monitoring and observability, make sure you can:

• [ ] Explain the purpose of Amazon ECR.
• [ ] Create an ECR repository and push Docker images.
• [ ] Understand ECS clusters, tasks, task definitions, and services.
• [ ] Explain the EC2 and Fargate compute options.
• [ ] Understand AWS Fargate.
• [ ] Explain Amazon EKS architecture.
• [ ] Connect kubectl to an EKS cluster.
• [ ] Understand EKS managed node groups and Fargate profiles.
• [ ] Configure application access through AWS load balancers.
• [ ] Understand ECS vs. EKS trade-offs.
• [ ] Apply container security best practices.
• [ ] Monitor and troubleshoot container workloads.
• [ ] Complete at least two practical AWS container projects.

Expected Outcome: By the end of this phase, you should be able to store Docker images in ECR, deploy applications using ECS or EKS, understand Fargate, configure application networking, and troubleshoot containerized workloads running on AWS.

Phase 13: Monitoring, Logging, and Observability (Weeks 52–55)

Deploying an application successfully is not the end of a DevOps Engineer's responsibility.

After deployment, you must ensure that the application and infrastructure continue working correctly.

Consider an e-commerce application running on AWS.

One day, customers report that the website is loading slowly. Some users cannot complete payments, and the application occasionally returns errors.

A DevOps Engineer must investigate:

• Is the EC2 instance running out of memory?
• Is CPU utilization unusually high?
• Is the database responding slowly?
• Are application errors increasing?
• Is the load balancer reporting unhealthy targets?
• Are containers restarting repeatedly?
• Did a recent deployment introduce the problem?

Monitoring, logging, and observability help answer these questions.

13.1 What Is Monitoring?

Monitoring is the process of continuously collecting and examining information about systems and applications to understand their health and performance.

It helps identify:

• Infrastructure failures.
• High CPU and memory usage.
• Application errors.
• Network problems.
• Database performance issues.
• Service availability problems.

Example:

Suppose an EC2 instance normally uses 30% CPU. Suddenly, CPU utilization increases to 95%.

A monitoring system can detect this change and trigger an alert.

13.2 What Is Logging?

Logging is the process of recording events that occur inside an application or infrastructure component.

Logs help engineers understand what happened before, during, and after an issue.

Examples:

• Application startup messages.
• Authentication failures.
• Database connection errors.
• API request information.
• Container startup failures.
• Operating system events.

Example application log:

2026-10-12 10:00:00 INFO Application started
2026-10-12 10:01:15 INFO Database connection successful
2026-10-12 10:02:30 ERROR Payment service connection failed
2026-10-12 10:02:35 WARN Retrying payment request

Logs provide detailed event information that helps troubleshoot application behavior.

13.3 What Is Observability?

Observability is the ability to understand the internal state and behavior of a system by examining the information it produces.

The three commonly discussed observability signals are:

1. Metrics
2. Logs
3. Traces

Metrics: Numerical measurements that describe system behavior over time.

Examples: CPU utilization, memory usage, request count, and error rate.

Logs: Records of individual events.

Examples: application errors, authentication events, and database failures.

Traces: Information showing how a request travels across multiple services.

For example, an online shopping request may pass through:

User Request
     |
     v
API Gateway
     |
     v
Authentication Service
     |
     v
Order Service
     |
     v
Payment Service
     |
     v
Database

Distributed tracing helps identify which service is responsible for a delay or failure.

13.4 Monitoring vs. Logging vs. Observability

Concept	Purpose	Example
Monitoring	Detect system health problems	CPU usage reaches 95%
Logging	Understand recorded events	Database connection failure
Observability	Investigate system behavior	Identify which microservice caused request latency

These concepts complement one another. Monitoring identifies symptoms, logs provide event details, and traces help follow requests across distributed systems.

13.5 Important Monitoring Metrics

A DevOps Engineer should understand the following metrics.

CPU Utilization

Measures how much processing capacity is being used.

Memory Utilization

Shows how much system memory is consumed.

Disk Utilization

Measures disk capacity usage.

Disk I/O

Tracks disk read and write activity.

Network Traffic

Measures data transferred into and out of a system.

Request Rate

Measures the number of requests received over a period.

Error Rate

Measures how many requests or operations fail.

Latency

Measures how long an operation takes to complete.

Availability

Measures the proportion of time a service is available.

A useful starting point for application monitoring is to understand the RED method:

• Rate: Requests per second.
• Errors: Failed requests.
• Duration: Request response time.

For infrastructure monitoring, the USE method is also useful:

• Utilization: How busy a resource is.
• Saturation: How much work is waiting.
• Errors: Resource-related errors.

13.6 Amazon CloudWatch

Amazon CloudWatch is an AWS monitoring and observability service.

It helps monitor AWS resources, collect application data, create alarms, and visualize system health.

Important CloudWatch features include:

• Metrics.
• Logs.
• Alarms.
• Dashboards.
• Log Insights.
• Events and integrations with other AWS services.
• Application monitoring capabilities.

CloudWatch Metrics

Metrics are numerical measurements collected over time.

Examples include:

• EC2 CPU utilization.
• EBS volume metrics.
• Application Load Balancer request count.
• RDS database metrics.
• ECS service metrics.

You can use metrics to understand resource utilization and application performance.

CloudWatch Logs

CloudWatch Logs allows you to collect, store, and analyze log data.

Important concepts:

Log Group: A logical collection of log streams.

Log Stream: A sequence of log events from a particular source.

Log Event: A recorded event with a timestamp and message.

Example:

CloudWatch Logs
      |
      v
Log Group
      |
      +----------+
      |          |
      v          v
Log Stream 1  Log Stream 2
      |          |
      v          v
Log Events   Log Events

CloudWatch Alarms

CloudWatch Alarms monitor metrics and perform configured actions when specified conditions are met.

Example:

If EC2 CPU utilization exceeds 80% for a configured evaluation period, an alarm can enter the ALARM state.

You can configure notifications through Amazon SNS and integrate alarms with other operational workflows.

CloudWatch Dashboards

Dashboards provide a visual representation of metrics from AWS resources and applications.

A dashboard can display:

• EC2 CPU utilization.
• Memory metrics collected through an appropriate agent.
• Application request count.
• Error rate.
• Database connections.
• Load balancer response time.

13.7 CloudWatch Agent

The CloudWatch Agent can collect additional information from EC2 instances and on-premises servers.

Examples include:

• Memory utilization.
• Disk utilization.
• Filesystem usage.
• Application log files.
• Additional operating system metrics.

Important: EC2's basic monitoring metrics do not automatically provide every operating system metric. Additional configuration, such as the CloudWatch Agent, may be required.

13.8 CloudWatch Logs Insights

CloudWatch Logs Insights allows you to query and analyze log data.

Example query:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

This query finds recent log events containing the word ERROR.

You should learn how to:

• Search logs.
• Filter events.
• Identify repeated errors.
• Analyze application failures.
• Compare events across time periods.
• Investigate production incidents.

13.9 Prometheus

Prometheus is an open-source monitoring and alerting toolkit.

It is widely used in cloud-native and Kubernetes environments.

Important features:

• Time-series metrics collection.
• PromQL query language.
• Metric storage.
• Alerting integrations.
• Service discovery.
• Integration with Grafana.

Prometheus commonly collects metrics by scraping HTTP endpoints exposed by applications or exporters.

Important concepts:

Metric: A measurement collected from a monitored system.

Time Series: A sequence of metric values identified by metric name and labels.

Exporter: A component that exposes metrics in a format Prometheus can collect.

PromQL: The query language used to retrieve and analyze Prometheus metrics.

Prometheus Server: The main component responsible for collecting and storing metrics.

Example PromQL query:

up

This query shows whether discovered targets are currently reachable.

Another example:

rate(http_requests_total[5m])

This calculates the per-second average increase in the request counter over the previous five minutes.

13.10 Grafana

Grafana is an observability and visualization platform.

It can connect to multiple data sources, including:

• Prometheus.
• Amazon CloudWatch.
• Loki.
• Elasticsearch-compatible data sources.

It helps engineers create dashboards to understand system performance.

Example dashboard panels:

Panel	Metric
CPU Usage	CPU utilization
Memory Usage	Memory consumption
Request Rate	Requests per second
Error Rate	Failed requests
Response Time	Application latency
Pod Status	Kubernetes workload health

Prometheus collects and stores metrics, while Grafana helps visualize them.

13.11 ELK Stack and OpenSearch

Logs from multiple servers and applications can become difficult to manage.

Centralized logging platforms help collect, search, and analyze logs in one place.

The traditional ELK Stack consists of:

Elasticsearch: Search and analytics engine.

Logstash: Data collection and processing pipeline.

Kibana: Visualization and exploration interface.

Be aware that the Elasticsearch and Kibana ecosystem has evolved, including changes in licensing and distribution. Understand the versions and products being used by the organization.

13.12 Amazon OpenSearch Service

Amazon OpenSearch Service is a managed service for search, analytics, and log analysis.

It can be used to:

• Centralize application logs.
• Search log events.
• Analyze operational information.
• Create visualizations.
• Investigate application failures.

A simplified centralized logging architecture:

EC2 Logs --------+
                 |
ECS Logs --------+
                 |
EKS Logs --------+----> Log Collection
                 |            |
Application Logs-+            v
                         Processing
                              |
                              v
                     Amazon OpenSearch
                              |
                              v
                       Dashboards

13.13 SLI, SLO, and SLA

These concepts are important in Site Reliability Engineering (SRE).

SLI — Service Level Indicator

A measurable value that represents service performance.

Example: 99.9% of requests complete successfully.

SLO — Service Level Objective

A target for a service-level indicator.

Example: The application should maintain 99.9% successful requests over a defined measurement window.

SLA — Service Level Agreement

A formal agreement between a service provider and customer that defines expected service levels and may specify consequences when commitments are not met.

Term	Meaning
SLI	What you measure
SLO	What target you aim to achieve
SLA	What you formally commit to

13.14 Alerting and Incident Management

Monitoring is useful only when important problems reach the people responsible for resolving them.

Alerting systems notify engineers when defined conditions occur.

Examples:

• High CPU utilization.
• Application error rate exceeds a threshold.
• Database connections approach capacity.
• Kubernetes Pods repeatedly restart.
• An application endpoint becomes unavailable.

A good alert should be:

• Actionable.
• Relevant.
• Clear.
• Prioritized.
• Linked to useful diagnostic information.

Avoid creating too many noisy alerts. Excessive notifications can cause alert fatigue.

Incident Response Workflow

Problem Detected
       |
       v
Alert Triggered
       |
       v
Incident Assigned
       |
       v
Investigate Logs and Metrics
       |
       v
Identify Root Cause
       |
       v
Apply Fix or Mitigation
       |
       v
Verify Recovery
       |
       v
Document Lessons Learned

A post-incident review should focus on understanding the causes and improving systems rather than assigning blame.

13.15 Hands-On Projects

Project 1: EC2 Monitoring with CloudWatch

Launch a small EC2 instance, monitor CPU utilization, and create a CloudWatch dashboard.

Project 2: Application Log Monitoring

Configure an application to write logs and collect them using the CloudWatch Agent.

Project 3: CloudWatch Alarm and Notification

Create an alarm for a suitable metric and configure an SNS notification.

Project 4: Prometheus and Grafana

Set up Prometheus and Grafana in a local learning environment. Collect system metrics and build dashboards.

Project 5: Kubernetes Monitoring

Monitor Kubernetes node and Pod metrics using a suitable Prometheus and Grafana setup.

Project 6: Centralized Logging

Collect logs from an application and send them to an appropriate centralized logging platform. Explore OpenSearch as one possible destination.

Project 7: Production Incident Simulation

Simulate an application failure, identify it through monitoring, investigate the logs, and document the resolution.

13.16 Recommended Learning Resources

• Amazon CloudWatch: https://docs.aws.amazon.com/cloudwatch/
• Prometheus: https://prometheus.io/docs/
• Grafana: https://grafana.com/docs/
• OpenSearch: https://opensearch.org/docs/
• Google SRE Books: https://sre.google/books/
• Kubernetes Monitoring: https://kubernetes.io/docs/tasks/debug/

13.17 Phase 13 Completion Checklist

Before moving to security and DevSecOps, make sure you can:

• [ ] Explain monitoring, logging, and observability.
• [ ] Understand metrics, logs, and distributed traces.
• [ ] Identify important infrastructure and application metrics.
• [ ] Configure CloudWatch metrics, logs, and alarms.
• [ ] Create CloudWatch dashboards.
• [ ] Use CloudWatch Logs Insights.
• [ ] Understand the purpose of the CloudWatch Agent.
• [ ] Explain Prometheus architecture and PromQL basics.
• [ ] Create Grafana dashboards.
• [ ] Understand centralized logging and OpenSearch.
• [ ] Explain SLI, SLO, and SLA.
• [ ] Configure meaningful alerts.
• [ ] Follow an incident response workflow.
• [ ] Complete at least two monitoring and troubleshooting projects.

Expected Outcome: By the end of this phase, you should be able to monitor AWS infrastructure and containerized applications, analyze logs, build observability dashboards, configure alerts, and investigate operational incidents.

Phase 14: Security and DevSecOps (Weeks 56–58)

Security is a fundamental responsibility of every DevOps Engineer.

Modern applications use cloud infrastructure, containers, APIs, databases, third-party libraries, and automated deployment pipelines. Every component can introduce security risks if it is not configured correctly.

Consider an organization deploying an application to AWS.

Even if the application works correctly, it may still have serious security problems:

• AWS credentials are stored inside source code.
• An S3 bucket is publicly accessible.
• An IAM user has unnecessary administrative permissions.
• A Docker image contains vulnerable software packages.
• A production server exposes unnecessary network ports.
• Application secrets are visible in pipeline logs.
• An attacker exploits an outdated application dependency.

DevSecOps addresses these challenges by integrating security into the entire software development and deployment lifecycle.

14.1 What Is DevSecOps?

DevSecOps stands for Development, Security, and Operations.

It is an approach that integrates security practices into software development, infrastructure management, testing, and deployment.

Traditionally, security checks were often performed near the end of the software development lifecycle.

DevSecOps encourages teams to identify and resolve security issues earlier.

This approach is commonly called Shift Left Security.

Instead of waiting until production deployment, security checks are introduced during development and throughout the CI/CD pipeline.

14.2 DevOps vs. DevSecOps

DevOps	DevSecOps
Integrates development and operations	Integrates development, security, and operations
Focuses on automation and delivery	Includes security automation throughout delivery
May perform security checks separately	Integrates security checks into workflows
Automates build and deployment	Automates build, deployment, and security validation

DevSecOps does not replace DevOps. It extends DevOps practices with continuous security controls.

14.3 Understanding the DevSecOps Lifecycle

A secure software delivery lifecycle can look like this:

Plan
  |
  v
Develop
  |
  v
Source Code Security Checks
  |
  v
Build Application
  |
  v
Dependency Scanning
  |
  v
Build Container Image
  |
  v
Container Image Scanning
  |
  v
Infrastructure Security Checks
  |
  v
Deploy to Environment
  |
  v
Runtime Monitoring
  |
  v
Incident Response

Security is not a single pipeline stage. It is a continuous responsibility throughout the lifecycle.

14.4 IAM Security and Least Privilege

AWS Identity and Access Management (IAM) controls access to AWS resources.

One of the most important security principles is Least Privilege.

It means providing only the permissions required to perform a specific task.

For example:

A CI/CD pipeline that only needs to push Docker images to one ECR repository should not receive full administrator permissions.

Important IAM concepts:

• Users.
• Groups.
• Roles.
• Policies.
• Permission boundaries.
• Trust policies.
• Temporary credentials.
• Multi-factor authentication (MFA).

Security best practices:

1. Avoid using the AWS root account for daily operations.
2. Enable MFA for privileged identities.
3. Prefer IAM roles and temporary credentials.
4. Avoid unnecessary IAM users with long-lived access keys.
5. Restrict access to specific resources.
6. Review unused permissions.
7. Separate development and production permissions.
8. Audit access using AWS CloudTrail.

14.5 AWS Secrets Management

Applications and pipelines often require sensitive information, such as:

• Database passwords.
• API keys.
• Access tokens.
• Third-party service credentials.
• Encryption keys.

Storing these values directly in application source code or configuration files creates security risks.

AWS provides services for managing sensitive information.

AWS Secrets Manager

Stores, retrieves, and manages secrets. It supports integrations for secret rotation in suitable configurations.

AWS Systems Manager Parameter Store

Provides centralized management of configuration data and secrets, with encryption capabilities for secure parameters.

AWS Key Management Service (KMS)

Provides key-management capabilities for cryptographic operations and integration with AWS encryption services.

Important practices:

• Never commit secrets to Git repositories.
• Do not include secrets in Docker images.
• Restrict secret access through IAM.
• Avoid printing secrets in pipeline logs.
• Rotate credentials where appropriate.
• Use encrypted storage for sensitive information.

14.6 Encryption: At Rest and In Transit

Encryption protects information from unauthorized access.

There are two important concepts.

Encryption at Rest

Protects data stored on disks, databases, object storage, and backups.

Examples:

• Amazon S3 server-side encryption.
• EBS volume encryption.
• RDS encryption.
• Encrypted backups.

Encryption in Transit

Protects data while it moves between systems.

Examples:

• HTTPS using TLS.
• Secure API communication.
• Encrypted database connections.
• Secure communication between application components.

A secure AWS architecture should consider both.

14.7 Network Security in AWS

AWS provides several networking and security controls.

Important services and concepts include:

Security Groups

Act as stateful virtual firewalls associated with supported resources and network interfaces.

Network ACLs

Provide stateless network filtering at the subnet level.

AWS WAF

Helps protect supported web applications against common web exploits and unwanted traffic patterns.

AWS Shield

Provides protection against distributed denial-of-service (DDoS) attacks.

AWS Network Firewall

Provides managed network protection and traffic filtering for supported VPC architectures.

Security practices:

1. Expose only required ports.
2. Avoid unrestricted SSH access from the internet.
3. Use private subnets for internal workloads where appropriate.
4. Restrict database access to approved application sources.
5. Use HTTPS for public applications.
6. Review security group rules regularly.
7. Monitor unusual network activity.

14.8 Vulnerability Management

A vulnerability is a weakness in software, infrastructure, or configuration that could be exploited.

Examples include:

• Outdated operating system packages.
• Vulnerable application libraries.
• Insecure container images.
• Misconfigured cloud resources.
• Weak authentication.
• Exposed credentials.

A vulnerability management process includes:

1. Identify assets.
2. Scan for vulnerabilities.
3. Evaluate severity and exploitability.
4. Prioritize findings.
5. Apply patches or mitigations.
6. Verify remediation.
7. Monitor continuously.

14.9 Important DevSecOps Security Testing Types

SAST — Static Application Security Testing

Examines source code or compiled application artifacts for potential security issues without executing the application.

DAST — Dynamic Application Security Testing

Tests a running application to identify potential security weaknesses from the outside.

SCA — Software Composition Analysis

Identifies vulnerable or risky third-party dependencies and open-source components.

Container Image Scanning

Checks container images for known vulnerabilities, misconfigurations, and other security concerns.

Infrastructure as Code Scanning

Examines Terraform and other infrastructure definitions for insecure configurations before deployment.

These methods complement each other. No single scanner can identify every possible security issue.

14.10 Common DevSecOps Tools

Tool	Primary Purpose
SonarQube	Code quality and supported static analysis
Trivy	Vulnerability and misconfiguration scanning
Checkov	Infrastructure as Code security scanning
OWASP ZAP	Dynamic application security testing
Snyk	Developer security and dependency analysis
GitHub Dependabot	Dependency update and vulnerability workflows
Gitleaks	Secret detection in repositories
AWS Security Hub	Centralized security findings and posture management

Learn the purpose of each tool and gain hands-on experience with a few of them.

You do not need to master every tool to become an effective DevOps Engineer.

14.11 Container Security

Docker images and running containers must be secured.

Important practices:

1. Use trusted base images.
2. Prefer minimal images.
3. Scan images before publishing them.
4. Avoid unnecessary packages.
5. Do not run applications as root without a valid requirement.
6. Avoid embedding credentials in images.
7. Use read-only filesystems where practical.
8. Restrict container capabilities.
9. Keep images updated.
10. Use image digests or controlled image tags for reproducibility.

For Kubernetes environments, also learn:

• Pod Security Standards.
• RBAC.
• Network Policies.
• Service Account permissions.
• Secret protection.
• Admission controls.
• Workload security contexts.

14.12 CI/CD Pipeline Security

CI/CD pipelines often have access to source code, cloud credentials, container registries, and production environments.

A compromised pipeline can therefore create serious security risks.

Follow these practices:

• Use short-lived credentials where possible.
• Use OIDC to authenticate GitHub Actions to AWS.
• Restrict IAM permissions.
• Protect important branches.
• Require reviews for sensitive changes.
• Scan dependencies and container images.
• Protect pipeline secrets.
• Avoid executing untrusted code with privileged credentials.
• Pin and review third-party actions.
• Restrict production deployment approvals.
• Maintain audit logs.

14.13 AWS Security Monitoring

AWS provides services that help identify and investigate security risks.

AWS CloudTrail

Records AWS account activity and API events.

Amazon GuardDuty

Provides threat detection using supported AWS data sources.

AWS Security Hub

Aggregates and helps manage security findings and security posture information across supported services and accounts.

AWS Config

Tracks resource configuration changes and evaluates resources against rules.

Amazon Inspector

Assesses supported workloads for vulnerabilities and exposure risks.

Understand what each service does and how its findings can be integrated into an organization's security operations.

14.14 Security Incident Response

A security incident occurs when a security control fails or a threat affects the environment.

Examples:

• Unauthorized access to an AWS account.
• Leaked application credentials.
• Public exposure of confidential data.
• Suspicious API activity.
• Malware detected on a server.
• A vulnerable container deployed to production.

A simplified response process:

Security Alert
      |
      v
Identify Affected Resources
      |
      v
Assess Severity and Impact
      |
      v
Contain the Incident
      |
      v
Investigate Evidence
      |
      v
Remove the Threat
      |
      v
Recover Services
      |
      v
Document and Improve Controls

Incident response must follow the organization's approved procedures. Preserve relevant evidence and involve the appropriate security team.

14.15 Hands-On Projects

Project 1: Secure an AWS IAM Role

Create a role with limited permissions for a specific application task. Verify that unauthorized actions are denied.

Project 2: Manage Application Secrets

Store a test application secret in AWS Secrets Manager or Systems Manager Parameter Store and retrieve it using an appropriately restricted IAM role.

Project 3: Scan Docker Images

Build a Docker image and scan it using Trivy. Review the findings and rebuild the image using updated dependencies or a safer base image.

Project 4: Scan Terraform Configuration

Use Checkov to identify potential security issues in Terraform files. Fix the findings and rerun the scan.

Project 5: Secure a CI/CD Pipeline

Build a GitHub Actions pipeline that runs tests, performs security checks, and uses OIDC for AWS authentication.

Project 6: AWS Security Monitoring

Explore CloudTrail, GuardDuty, AWS Config, and Security Hub. Understand how findings can help identify suspicious activity and configuration risks.

14.16 Recommended Learning Resources

• AWS Security Documentation: https://docs.aws.amazon.com/security/
• AWS IAM: https://docs.aws.amazon.com/iam/
• AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/
• OWASP: https://owasp.org/
• OWASP ZAP: https://www.zaproxy.org/docs/
• Trivy: https://trivy.dev/
• Checkov: https://www.checkov.io/
• SonarQube: https://docs.sonarsource.com/

14.17 Phase 14 Completion Checklist

Before moving to advanced DevOps and SRE practices, make sure you can:

• [ ] Explain DevSecOps and Shift Left Security.
• [ ] Apply IAM least-privilege principles.
• [ ] Understand IAM roles, policies, and temporary credentials.
• [ ] Explain AWS Secrets Manager, Parameter Store, and KMS.
• [ ] Understand encryption at rest and in transit.
• [ ] Configure basic AWS network security controls.
• [ ] Explain SAST, DAST, and SCA.
• [ ] Scan Docker images for vulnerabilities.
• [ ] Scan Terraform configurations.
• [ ] Secure CI/CD pipelines.
• [ ] Understand CloudTrail, GuardDuty, Security Hub, Config, and Inspector.
• [ ] Explain the security incident response process.
• [ ] Complete at least two practical security projects.

Expected Outcome: By the end of this phase, you should be able to apply fundamental security practices across AWS infrastructure, Docker containers, Kubernetes workloads, Terraform configurations, and CI/CD pipelines.

Phase 15: Advanced DevOps, GitOps, and Site Reliability Engineering (SRE) (Weeks 59–62)

By this stage, you have learned the major foundations of AWS DevOps:

• Computer fundamentals.
• Linux administration.
• Networking.
• Git and GitHub.
• Python and Bash scripting.
• AWS services.
• Terraform and Infrastructure as Code.
• Docker.
• CI/CD pipelines.
• Kubernetes.
• AWS container services.
• Monitoring and observability.
• Security and DevSecOps.

The next step is to understand how experienced DevOps Engineers design reliable systems, automate complex infrastructure, manage application releases, and improve operational efficiency.

This phase introduces advanced practices and tools used in modern cloud and product engineering teams.

15.1 What Is Advanced DevOps?

Advanced DevOps goes beyond learning individual tools.

It focuses on combining infrastructure, automation, security, deployment, monitoring, and operational practices to build reliable systems.

An advanced DevOps Engineer should be able to:

• Design production-ready cloud infrastructure.
• Automate infrastructure provisioning.
• Build reusable CI/CD pipelines.
• Manage Kubernetes workloads.
• Implement deployment strategies.
• Monitor application reliability.
• Investigate production incidents.
• Improve infrastructure security.
• Optimize cloud costs.
• Collaborate with development, security, and operations teams.

15.2 Ansible for Configuration Management

Ansible is an open-source automation tool used for configuration management, application deployment, and infrastructure automation.

Terraform and Ansible solve related but different problems.

Terraform

Primarily provisions and manages infrastructure resources.

Examples:

• EC2 instances.
• VPCs.
• Subnets.
• Security groups.
• Load balancers.
• Databases.

Ansible

Primarily configures systems and automates tasks on existing infrastructure.

Examples:

• Installing software packages.
• Configuring Linux servers.
• Creating users.
• Managing services.
• Deploying applications.
• Updating configuration files.

Important Ansible Concepts

Control Node: The machine from which Ansible commands are executed.

Managed Node: A system that Ansible manages.

Inventory: A list of managed hosts.

Playbook: A YAML file defining automation tasks.

Module: A reusable unit of work that performs an operation.

Role: A reusable structure for organizing tasks, variables, handlers, and related files.

Example Ansible Playbook

Create a file named install_nginx.yml.

---
- name: Install and Start Nginx
  hosts: webservers
  become: true

  tasks:
    - name: Install Nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Start Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Execute the playbook:

ansible-playbook -i inventory install_nginx.yml

This example installs Nginx and ensures that its service is running and enabled.

Learn the following topics:

• Ansible installation.
• Inventory management.
• Ad hoc commands.
• Playbooks.
• Variables.
• Facts.
• Conditionals.
• Loops.
• Handlers.
• Roles.
• Templates.
• Ansible Vault.
• AWS integration.
• Configuration management at scale.

15.3 GitOps

GitOps is an operational approach in which Git repositories act as the source of truth for the desired state of infrastructure and applications.

Instead of manually changing production environments, engineers declare the desired configuration in Git.

A GitOps controller continuously compares the desired state with the actual state and reconciles differences.

How GitOps Works

Developer
    |
    v
Changes Kubernetes YAML
    |
    v
Pushes Changes to Git
    |
    v
Git Repository
    |
    v
GitOps Controller
    |
    v
Compares Desired and Actual State
    |
    v
Applies Required Changes
    |
    v
Kubernetes Cluster

Important benefits:

• Version-controlled infrastructure and application configuration.
• Improved deployment consistency.
• Easier auditability.
• Better collaboration.
• Simplified rollback through Git history.
• Continuous reconciliation.

GitOps is particularly useful in Kubernetes environments.

15.4 Argo CD

Argo CD is a declarative GitOps continuous delivery tool for Kubernetes.

It monitors Git repositories and synchronizes Kubernetes applications with the desired configuration.

Important Argo CD concepts:

• Application.
• Project.
• Repository.
• Sync.
• Health status.
• Application source.
• Automated synchronization.
• Self-healing.
• Pruning.

Example Argo CD Workflow

GitHub Repository
       |
       v
Kubernetes YAML Files
       |
       v
Argo CD
       |
       v
Compare Desired State
       |
       v
Synchronize Resources
       |
       v
Kubernetes Cluster

Learn how to:

1. Install Argo CD in a learning Kubernetes cluster.
2. Connect a Git repository.
3. Create an Argo CD application.
4. Synchronize an application.
5. Understand automated synchronization.
6. Configure health checks.
7. Understand pruning and self-healing.
8. Troubleshoot synchronization failures.

Official documentation: https://argo-cd.readthedocs.io/

15.5 Deployment Strategies

Deploying a new application version without disrupting users is an important DevOps responsibility.

Learn these deployment strategies.

Rolling Deployment

Gradually replaces existing application instances with new versions.

Advantages:

• Gradual rollout.
• Reduced deployment disruption.
• Commonly supported by Kubernetes Deployments.

Blue-Green Deployment

Maintains two environments:

• Blue: Current production version.
• Green: New application version.

After validating the green environment, traffic is switched to it.

Advantages:

• Fast traffic switching.
• Easier rollback when the previous environment remains available.

Canary Deployment

Releases a new version to a small percentage of users before expanding the deployment.

For example:

• 5% of traffic receives the new version.
• Engineers monitor errors and performance.
• If successful, the rollout expands.
• If problems occur, the rollout is stopped or reversed.

Recreate Deployment

Stops the existing version before starting the new version.

It is simple but may cause downtime.

Strategy	Main Idea	Common Use
Rolling	Gradually replace instances	Routine application updates
Blue-Green	Switch between two environments	Controlled production releases
Canary	Release to a small percentage first	Risk-sensitive deployments
Recreate	Replace all instances at once	Applications that tolerate downtime

15.6 Site Reliability Engineering (SRE)

Site Reliability Engineering applies engineering practices to operations and service reliability.

It focuses on creating systems that remain available, performant, scalable, and recoverable.

An SRE works to balance:

• Reliability.
• Application performance.
• Deployment speed.
• Operational efficiency.
• Automation.

Important SRE concepts include:

• Service Level Indicators.
• Service Level Objectives.
• Service Level Agreements.
• Error budgets.
• Incident management.
• Toil reduction.
• Capacity planning.
• Reliability testing.

What Is Toil?

Toil refers to repetitive, manual operational work that does not create lasting value.

Examples:

• Manually restarting services every day.
• Repeatedly creating infrastructure by hand.
• Performing routine deployments manually.
• Investigating the same recurring alerts.

SRE teams aim to reduce toil through automation and engineering improvements.

15.7 Error Budgets

An error budget represents the acceptable amount of unreliability within a defined SLO measurement period.

For example, suppose a service has a 99.9% availability target over a 30-day period.

The remaining 0.1% represents its availability error budget.

If reliability decreases and the error budget is consumed too quickly, the organization may prioritize reliability improvements over additional feature releases.

Error budgets help teams make informed decisions about release velocity and reliability.

15.8 High Availability and Fault Tolerance

High availability means designing systems to remain accessible despite certain component failures.

Fault tolerance means designing systems to continue operating despite specific failures.

Important concepts:

Redundancy: Having additional resources available if a component fails.

Failover: Switching operations to a backup component or environment.

Multi-AZ Architecture: Distributing supported resources across multiple Availability Zones.

Auto Scaling: Automatically adjusting capacity based on configured requirements and policies.

Load Balancing: Distributing traffic across multiple targets.

Example AWS architecture:

                  Internet
                     |
                     v
              Application Load
                  Balancer
                     |
          +----------+----------+
          |                     |
          v                     v
      Availability Zone A   Availability Zone B
          |                     |
          v                     v
        EC2 A                 EC2 B
          |                     |
          +----------+----------+
                     |
                     v
                Database
              Multi-AZ Setup

The architecture must use services and configurations that support the intended availability design. Multi-AZ deployment improves resilience but does not eliminate every failure scenario.

15.9 Disaster Recovery and Business Continuity

Disaster Recovery (DR) focuses on restoring systems and data after a major failure.

Business Continuity (BC) focuses on maintaining essential business operations during disruptions.

Important DR concepts:

RTO — Recovery Time Objective

The maximum targeted time required to restore a service after disruption.

RPO — Recovery Point Objective

The maximum targeted amount of data loss measured in time.

Example:

• RTO: 2 hours.
• RPO: 15 minutes.

This means the recovery target is to restore service within two hours and limit data loss to approximately the previous 15 minutes.

Important AWS services and capabilities:

• AWS Backup.
• Amazon S3 versioning.
• Cross-Region replication where appropriate.
• Amazon RDS automated backups.
• EBS snapshots.
• Multi-AZ deployments.
• Infrastructure as Code.
• Route 53 health checks and routing policies.

Learn the major disaster recovery approaches:

• Backup and restore.
• Pilot light.
• Warm standby.
• Multi-site active/active.

15.10 Auto Scaling and Performance Optimization

Applications must handle changing workloads.

For example, an e-commerce application may receive more traffic during a major sale.

Auto Scaling helps increase or decrease capacity based on configured policies.

Learn:

• EC2 Auto Scaling.
• Target tracking scaling policies.
• Scheduled scaling.
• Predictive scaling.
• ECS service auto scaling.
• Kubernetes Horizontal Pod Autoscaler.
• Kubernetes Cluster Autoscaler.
• EKS node scaling approaches.
• Load testing.
• Application performance optimization.

Understand the difference between scaling vertically and scaling horizontally.

Vertical Scaling: Increasing the resources of an existing machine.

Horizontal Scaling: Adding more machines or application instances.

15.11 Cloud Cost Optimization

A DevOps Engineer must understand how infrastructure decisions affect cloud spending.

Important AWS cost optimization practices include:

1. Select appropriately sized EC2 instances.
2. Remove unused resources.
3. Use Auto Scaling where suitable.
4. Review storage usage.
5. Apply S3 lifecycle policies.
6. Monitor data transfer costs.
7. Review NAT Gateway usage.
8. Select appropriate database configurations.
9. Use cost allocation tags.
10. Monitor spending through AWS Budgets and Cost Explorer.

Learn these AWS services:

• AWS Cost Explorer.
• AWS Budgets.
• AWS Compute Optimizer.
• AWS Cost and Usage Reports.

Do not assume that resources are free simply because an account is eligible for Free Tier benefits. Always review current pricing and clean up unused resources.

15.12 Advanced Infrastructure Automation

As infrastructure grows, manual configuration becomes difficult to maintain.

Learn how to combine Terraform, Ansible, GitHub Actions, and AWS services.

A simplified workflow:

Git Repository
      |
      v
CI/CD Pipeline
      |
      v
Terraform
      |
      v
Provision AWS Infrastructure
      |
      v
Ansible
      |
      v
Configure Servers
      |
      v
Docker Deployment
      |
      v
Monitoring and Alerting

Understand how to:

• Create reusable Terraform modules.
• Maintain remote state securely.
• Review infrastructure changes before applying them.
• Automate configuration management.
• Validate infrastructure changes.
• Separate environments.
• Implement infrastructure deployment approvals.
• Monitor automation failures.

15.13 Hands-On Projects

Project 1: Automated Server Configuration

Use Ansible to install and configure Nginx on Linux servers.

Project 2: GitOps Deployment with Argo CD

Deploy a Kubernetes application from a Git repository and configure synchronization.

Project 3: Blue-Green Deployment

Create two application environments and implement controlled traffic switching.

Project 4: Canary Deployment

Release a new application version to a small percentage of traffic and monitor its health.

Project 5: Highly Available AWS Architecture

Design a multi-AZ application architecture using load balancing, Auto Scaling, and a suitable database configuration.

Project 6: Disaster Recovery Simulation

Create a backup and recovery plan. Test restoration and document the actual recovery time and data recovery point.

Project 7: AWS Cost Optimization

Review a sample infrastructure design, identify potential unnecessary costs, and propose improvements.

15.14 Recommended Learning Resources

• Ansible Documentation: https://docs.ansible.com/
• Argo CD Documentation: https://argo-cd.readthedocs.io/
• Google SRE Books: https://sre.google/books/
• AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/
• AWS Disaster Recovery: https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-disaster-recovery/
• AWS Cost Optimization: https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/

15.15 Phase 15 Completion Checklist

Before moving to your final portfolio and job preparation, make sure you can:

• [ ] Explain configuration management using Ansible.
• [ ] Create and execute basic Ansible playbooks.
• [ ] Explain GitOps principles.
• [ ] Deploy applications using Argo CD.
• [ ] Understand rolling, blue-green, canary, and recreate deployments.
• [ ] Explain SRE and toil reduction.
• [ ] Understand SLI, SLO, SLA, and error budgets.
• [ ] Design basic high-availability AWS architectures.
• [ ] Understand disaster recovery strategies.
• [ ] Explain RTO and RPO.
• [ ] Configure and understand application auto scaling.
• [ ] Identify cloud cost optimization opportunities.
• [ ] Automate infrastructure and application configuration.
• [ ] Complete at least three advanced DevOps projects.

Expected Outcome: By the end of this phase, you should understand advanced DevOps practices, GitOps, SRE fundamentals, deployment strategies, high availability, disaster recovery, automation, and cloud cost optimization.

Section 18: Build a Real-World AWS DevOps Project Portfolio (Weeks 63–66)

Learning DevOps tools is important, but employers also want to understand how you apply those tools to solve real-world problems.

A strong project portfolio demonstrates your ability to design infrastructure, automate deployments, manage containers, monitor applications, and troubleshoot failures.

You do not need dozens of projects. Focus on building a few well-documented projects that demonstrate your understanding of the complete DevOps lifecycle.

18.1 What Should Your DevOps Portfolio Demonstrate?

Your portfolio should demonstrate that you can:

• Provision cloud infrastructure using Infrastructure as Code.
• Configure and manage Linux servers.
• Build and manage Docker images and containers.
• Create automated CI/CD pipelines.
• Deploy applications to AWS.
• Work with Kubernetes and container orchestration.
• Implement monitoring, logging, and alerting.
• Apply security best practices.
• Troubleshoot application and infrastructure issues.
• Document technical decisions and deployment procedures.

18.2 Recommended Projects for Your Portfolio

Start with smaller projects and gradually move toward more complex implementations.

Project 1: AWS Infrastructure Provisioning Using Terraform

Objective: Automate the creation of AWS infrastructure using Terraform.

Technologies:

• AWS
• Terraform
• Linux
• Git and GitHub

Implementation:

1. Create a custom VPC.
2. Configure public and private subnets.
3. Create appropriate route tables.
4. Configure Internet Gateway and NAT Gateway where required.
5. Provision EC2 instances.
6. Configure security groups with least-privilege access.
7. Organize infrastructure using reusable Terraform modules.
8. Configure a remote Terraform state backend.
9. Document the infrastructure architecture.

Expected outcome: A reusable infrastructure project that demonstrates Infrastructure as Code and AWS networking knowledge.

Project 2: Automated CI/CD Pipeline for a Web Application

Objective: Automate application building, testing, and deployment.

Technologies:

• Git and GitHub
• GitHub Actions or Jenkins
• Docker
• AWS ECR
• AWS ECS or EC2

Implementation:

1. Create a simple application.
2. Store the application source code in GitHub.
3. Write a Dockerfile.
4. Build the Docker image.
5. Run automated tests.
6. Scan the image for vulnerabilities.
7. Push the image to Amazon ECR.
8. Deploy the application to an AWS compute environment.
9. Configure deployment notifications and failure handling.
10. Document the pipeline.

Expected outcome: An automated pipeline that demonstrates how code moves from a repository to a running application.

Project 3: Kubernetes Application Deployment

Objective: Deploy and manage a containerized application using Kubernetes.

Technologies:

• Docker
• Kubernetes
• kubectl
• Helm
• Minikube or another suitable Kubernetes environment

Implementation:

1. Build a Docker image.
2. Create Kubernetes Deployment manifests.
3. Configure Services.
4. Create ConfigMaps and Secrets.
5. Configure readiness and liveness probes.
6. Set CPU and memory requests and limits.
7. Configure persistent storage where required.
8. Deploy the application using Helm.
9. Perform scaling and rolling updates.
10. Troubleshoot common Pod and Service issues.

Expected outcome: A Kubernetes project demonstrating application deployment, configuration, scaling, and troubleshooting.

Project 4: Monitoring and Observability

Objective: Monitor application and infrastructure health.

Technologies:

• Prometheus
• Grafana
• AWS CloudWatch
• Linux

Implementation:

1. Deploy a sample application.
2. Collect infrastructure or application metrics.
3. Configure Prometheus scraping.
4. Create Grafana dashboards.
5. Configure CloudWatch metrics and alarms where appropriate.
6. Create alerts for selected conditions.
7. Simulate an application failure.
8. Investigate the failure using metrics and logs.
9. Document the incident and resolution.

Expected outcome: A monitoring project demonstrating how to detect, investigate, and respond to operational issues.

Project 5: DevSecOps Pipeline

Objective: Integrate security checks into the software delivery process.

Technologies:

• GitHub Actions or Jenkins
• SonarQube
• Trivy
• Checkov
• Gitleaks

Implementation:

1. Create an application repository.
2. Configure source-code quality analysis.
3. Add dependency vulnerability checks.
4. Scan Docker images using Trivy.
5. Scan Terraform configurations using Checkov.
6. Detect accidentally committed secrets.
7. Configure pipeline failure conditions for selected security findings.
8. Document security checks and their results.

Expected outcome: A CI/CD pipeline that incorporates automated security checks.

18.3 Flagship Capstone: End-to-End AWS DevOps Platform

After completing the smaller projects, combine your knowledge into one comprehensive project.

Project objective: Design and implement an automated platform for deploying, operating, monitoring, and securing a containerized application on AWS.

Suggested architecture:

                 Developer
                     |
                     v
                GitHub Repo
                     |
                     v
              CI/CD Pipeline
              (GitHub Actions)
                     |
          +----------+----------+
          |          |          |
          v          v          v
        Tests     Security    Build
                  Scanning
                     |
                     v
                 Docker Image
                     |
                     v
                  AWS ECR
                     |
                     v
             AWS ECS or Amazon EKS
                     |
                     v
               Load Balancer
                     |
                     v
               Web Application
                     |
          +----------+----------+
          |                     |
          v                     v
      Monitoring             Logging
   CloudWatch/Grafana       CloudWatch
          |                     |
          +----------+----------+
                     |
                     v
               Alerts

Use Terraform to provision the infrastructure. Store application code and deployment configuration in GitHub. Integrate security checks into the pipeline and implement monitoring and logging.

Core implementation requirements:

1. Provision AWS networking and compute infrastructure using Terraform.
2. Build and containerize an application using Docker.
3. Store container images in Amazon ECR.
4. Create a CI/CD pipeline using GitHub Actions or Jenkins.
5. Deploy the application using ECS or EKS.
6. Configure a load balancer and appropriate network access.
7. Implement application and infrastructure monitoring.
8. Centralize relevant logs.
9. Configure security controls and automated vulnerability scanning.
10. Document deployment, rollback, and troubleshooting procedures.

You do not need to implement every advanced feature in your first version. Build a working foundation first, then improve it incrementally.

18.4 How to Document Projects on GitHub

A project is more convincing when another engineer can understand and reproduce it.

Use a structure similar to this:

aws-devops-capstone/
│
├── application/
│
├── docker/
│   └── Dockerfile
│
├── terraform/
│   ├── modules/
│   ├── environments/
│   └── README.md
│
├── kubernetes/
│
├── helm/
│
├── .github/
│   └── workflows/
│
├── monitoring/
│
├── security/
│
├── docs/
│   ├── architecture/
│   ├── deployment/
│   └── troubleshooting/
│
└── README.md

Your README.md should explain:

• Project objective and problem statement.
• Technologies used.
• Architecture diagram.
• Prerequisites.
• Setup and deployment instructions.
• Infrastructure and application configuration.
• Security considerations.
• Monitoring and logging.
• Troubleshooting examples.
• Screenshots or demonstration links, where appropriate.
• Known limitations and future improvements.

Never publish AWS access keys, passwords, private certificates, Terraform state files, or other sensitive information in a public repository.

18.5 Four-Week Portfolio Plan

Week	Focus	Expected result
Week 63	Review and improve Terraform and CI/CD projects	Two documented projects
Week 64	Improve Docker and Kubernetes projects	Working container and orchestration demonstrations
Week 65	Add monitoring and security	Observability and DevSecOps demonstrations
Week 66	Complete and document capstone	One integrated flagship project

You can adapt this schedule based on the complexity of your projects and the time available.

18.6 Important Portfolio Principles

• Prefer working projects over copied configurations.
• Understand every command and configuration you use.
• Explain why you selected a particular AWS service or deployment strategy.
• Include meaningful commit history.
• Document errors you encountered and how you resolved them.
• Use architecture diagrams to explain complex systems.
• Never claim that a project is production-ready unless it has actually been designed, tested, and operated to that standard.
• Keep repositories clean, organized, and reproducible.

18.7 Free and Low-Cost Practice Strategy

You can build a strong portfolio without continuously running expensive cloud infrastructure.

• Use local Linux virtual machines for Linux practice.
• Use Minikube or another local Kubernetes environment.
• Use local Docker containers for containerization practice.
• Use Terraform validation and planning to practice infrastructure configuration without necessarily creating resources.
• Use GitHub for source control and eligible CI/CD usage within its current plan limits.
• Use AWS only when necessary for cloud-specific demonstrations.
• Review current AWS pricing and Free Tier eligibility before creating resources.
• Delete resources after completing practical exercises and verify that chargeable resources have been removed.

Important: Local practice does not replace real AWS experience, but it can reduce unnecessary cloud expenses while you learn.

Section 19: Become Job-Ready — Resume, GitHub, Interviews, and Job Search

Completing a learning roadmap is only one part of becoming an AWS DevOps Engineer. You must also be able to demonstrate your knowledge, explain your projects, solve technical problems, and communicate effectively during interviews.

This section explains how to prepare for entry-level and junior AWS DevOps opportunities.

19.1 Build an ATS-Friendly DevOps Resume

Your resume should clearly communicate your technical skills, practical projects, and ability to work with cloud infrastructure and automation.

Recommended resume structure:

1. Name and contact information
2. Professional summary
3. Technical skills
4. Projects
5. Work experience, if applicable
6. Education
7. Certifications, if earned

Example professional summary:

"Entry-level AWS DevOps Engineer with hands-on project experience in AWS cloud services, Linux administration, Terraform, Docker, Kubernetes, and CI/CD automation. Familiar with infrastructure provisioning, containerized application deployments, monitoring, logging, and DevSecOps practices. Passionate about building reliable, secure, and automated cloud infrastructure."

Customize this summary to reflect your actual knowledge and completed projects.

19.2 Organize Your Technical Skills

Group related skills so recruiters can quickly understand your technical background.

Category	Skills
Cloud	AWS, IAM, EC2, S3, VPC, ELB, Auto Scaling
Operating Systems	Linux, Ubuntu, shell administration
Programming and Scripting	Python, Bash
Version Control	Git, GitHub
Infrastructure as Code	Terraform, CloudFormation
Containers	Docker, Kubernetes
CI/CD	GitHub Actions, Jenkins, GitLab CI/CD
AWS Containers	ECR, ECS, EKS, Fargate
Configuration Management	Ansible
Monitoring	CloudWatch, Prometheus, Grafana
Logging	ELK Stack, OpenSearch
Security	IAM, KMS, Secrets Manager, Trivy, Checkov
GitOps	Argo CD
SRE	SLI, SLO, SLA, incident management

Only include technologies you can explain and demonstrate. Separate tools you have used in practical projects from those you have only studied.

19.3 Create a Professional GitHub Profile

Your GitHub profile should serve as a portfolio of your technical work.

Recommended steps:

1. Add a professional profile photo or avatar.
2. Write a clear technical bio.
3. Add your major technical skills.
4. Pin your best repositories.
5. Write meaningful README files.
6. Include architecture diagrams.
7. Maintain clean commit history.
8. Remove credentials and sensitive configuration from repositories.
9. Keep project documentation updated.

Suggested pinned repositories:

• AWS Infrastructure Automation with Terraform
• Automated CI/CD Pipeline
• Docker Application Deployment
• Kubernetes Application Deployment
• DevSecOps Pipeline
• AWS DevOps Capstone Project

Quality and clarity matter more than the number of repositories.

19.4 Prepare for AWS DevOps Technical Interviews

Interview preparation should cover both theoretical understanding and practical troubleshooting.

Organize your preparation into these categories.

Linux and Operating Systems

• Explain Linux architecture.
• What is the difference between a process and a thread?
• Explain file permissions.
• How do you troubleshoot high CPU utilization?
• How do you investigate disk-space issues?
• What is systemd?
• How do you troubleshoot SSH connection failures?

Networking

• Explain TCP and UDP.
• What happens when you open a website?
• What is DNS?
• Explain public and private IP addresses.
• What is a subnet?
• What is the difference between a security group and a network ACL?
• How do you troubleshoot connectivity issues?

AWS

• Explain IAM users, groups, roles, and policies.
• What is the difference between EC2 and Lambda?
• Explain VPC components.
• What is the difference between S3 and EBS?
• Explain Application Load Balancer and Network Load Balancer.
• What is Auto Scaling?
• How do CloudWatch and CloudTrail differ?
• How would you secure an AWS environment?

Terraform

• What is Infrastructure as Code?
• Explain Terraform state.
• What is the difference between a resource and a data source?
• What are Terraform modules?
• Explain remote state.
• What is the purpose of terraform plan?
• How do you manage sensitive variables?

Docker

• What is a container?
• What is the difference between an image and a container?
• Explain Dockerfile instructions.
• What are Docker volumes?
• Explain Docker networking.
• What is a multistage build?
• How do you troubleshoot a container that exits unexpectedly?

Kubernetes

• Explain Kubernetes architecture.
• What is a Pod?
• What is the difference between a Deployment and a StatefulSet?
• Explain Kubernetes Services.
• What are ConfigMaps and Secrets?
• What are readiness and liveness probes?
• How do you troubleshoot a Pod stuck in Pending or CrashLoopBackOff?

CI/CD and DevSecOps

• Explain a CI/CD pipeline.
• What is the difference between continuous delivery and continuous deployment?
• How do you securely manage pipeline credentials?
• What is a deployment rollback?
• What are blue-green and canary deployments?
• How do you integrate security scanning into a pipeline?

Monitoring and SRE

• Explain metrics, logs, and traces.
• What is Prometheus?
• What is Grafana?
• What are SLIs, SLOs, and SLAs?
• How do you design an alerting strategy?
• What is incident management?

Do not simply memorize answers. Practise explaining concepts in your own words and demonstrate them using your projects.

19.5 Practise Real-World Troubleshooting Scenarios

Employers often evaluate how candidates investigate and solve problems.

Practise scenarios such as:

1. An EC2 instance is unreachable through SSH.
2. An application is running locally but not accessible from the internet.
3. A Docker container exits immediately after starting.
4. A CI/CD pipeline fails during the deployment stage.
5. A Kubernetes Pod enters CrashLoopBackOff.
6. A Kubernetes Service cannot communicate with its Pods.
7. A Terraform deployment fails because of an IAM permission error.
8. An application experiences high CPU utilization.
9. An AWS application unexpectedly incurs high costs.
10. A deployment introduces an application failure.

For each scenario, practise the following troubleshooting method:

1. Understand the reported problem.
2. Identify the affected component.
3. Collect relevant logs and metrics.
4. Form a possible cause.
5. Test your hypothesis.
6. Apply a safe corrective action.
7. Verify that the issue is resolved.
8. Document the root cause and prevention steps.

19.6 Consider Relevant AWS Certifications

Certifications can help demonstrate structured knowledge, but they do not replace practical experience.

Potential certifications include:

• AWS Certified Cloud Practitioner — foundational cloud knowledge.
• AWS Certified Solutions Architect – Associate — AWS architecture fundamentals.
• AWS Certified Developer – Associate — application development on AWS.
• AWS Certified CloudOps Engineer – Associate — operational management of AWS workloads.
• AWS Certified DevOps Engineer – Professional — advanced AWS DevOps practices.

You do not need to earn every certification.

Start with the certification that best matches your current knowledge and career goals. Review the latest official exam guides before preparing because certification names, objectives, and exam requirements can change.

Official certification information: https://aws.amazon.com/certification/

19.7 Create a Consistent Job Search Strategy

Once you have a credible technical foundation and demonstrable projects, begin applying for relevant opportunities.

Search for roles such as:

• Junior DevOps Engineer
• Associate DevOps Engineer
• AWS Cloud Engineer
• Cloud Operations Engineer
• Infrastructure Engineer
• Junior Site Reliability Engineer
• Build and Release Engineer
• Platform Engineering Associate

Recommended job-search activities:

Activity	Suggested frequency
Technical learning	Daily
Hands-on practice	Daily
Interview questions	5 days per week
GitHub improvements	Weekly
Resume improvements	As needed
Job applications	Consistently
Mock interviews	Weekly
Technical revision	Weekly

Tailor your resume to the actual requirements of each role. Do not claim professional experience with tools or production systems that you have not worked with.

19.8 Develop Communication and Documentation Skills

DevOps engineers work with developers, testers, security engineers, infrastructure teams, and business stakeholders.

Develop the ability to:

• Explain technical concepts clearly.
• Document deployment procedures.
• Write incident reports.
• Communicate infrastructure changes.
• Explain technical trade-offs.
• Collaborate through GitHub pull requests.
• Describe project challenges and solutions.
• Ask clear questions when troubleshooting.

Strong communication is an important part of engineering effectiveness.

19.9 Final Job-Readiness Checklist

Before considering yourself ready to apply for junior AWS DevOps roles, review this checklist.

Fundamentals

• [ ] Understand computer and operating-system fundamentals.
• [ ] Work comfortably with Linux.
• [ ] Understand networking fundamentals.
• [ ] Use Git and GitHub confidently.
• [ ] Write basic Python and Bash scripts.

AWS and Infrastructure

• [ ] Understand core AWS services.
• [ ] Configure IAM permissions securely.
• [ ] Understand VPC networking.
• [ ] Provision infrastructure using Terraform.
• [ ] Understand AWS architecture and cost management.

Containers and Automation

• [ ] Build and manage Docker images.
• [ ] Write Dockerfiles.
• [ ] Deploy applications using Kubernetes.
• [ ] Build CI/CD pipelines.
• [ ] Understand ECS and EKS fundamentals.

Operations and Security

• [ ] Configure monitoring and logging.
• [ ] Understand alerting and incident response.
• [ ] Apply DevSecOps principles.
• [ ] Troubleshoot common infrastructure issues.
• [ ] Understand backup and disaster recovery fundamentals.

Portfolio and Career

• [ ] Complete multiple practical projects.
• [ ] Build one documented end-to-end capstone.
• [ ] Maintain a professional GitHub portfolio.
• [ ] Prepare an ATS-friendly resume.
• [ ] Practise technical and scenario-based interviews.
• [ ] Understand and explain every project listed on your resume.

19.10 Final Advice: Focus on Engineering Skills, Not Just Tools

Becoming an AWS DevOps Engineer is not about memorizing hundreds of commands or collecting certificates.

It is about understanding how applications are developed, deployed, secured, monitored, and maintained.

Build your foundation first. Practise consistently. Create projects that solve meaningful problems. Learn to troubleshoot failures rather than simply following tutorials.

A strong engineer understands not only how to use a tool, but also why it is used, when it is appropriate, and what trade-offs it introduces.

Your learning journey does not end when you get your first job. Continue learning, experimenting, documenting, and improving.

Start with fundamentals. Build with purpose. Automate with confidence. Operate with reliability.