1.

Practical Exam (Hands-On Tasks)

Objective: Demonstrate your ability to set up essential infrastructure components on AWS and
automate the deployment process for a Laravel application.

1. Flowchart Overview

Below is a high-level flowchart of the infrastructure setup and deployment process:

+----------------+ +----------------+ +----------------+

+-----------------+
| VPC | --> | Subnets | --> | Security Groups| --> | RDS
Setup |
+----------------+ +----------------+ +----------------+
+-----------------+
|
v
+----------------+ +----------------+ +----------------+
+-----------------+
| ECS Cluster | --> | ALB Setup | --> | Task Def. | --> | CI/CD
Pipeline |
+----------------+ +----------------+ +----------------+
+-----------------+
|
v
+----------------+
| Deploy |
| Application |
+----------------+

2. File Structure
terraform-laravel-ecs/
├── main.tf # Main Terraform configuration file
├── variables.tf # Defines input variables
├── outputs.tf # Outputs for key values
├── vpc.tf # VPC, subnets, and route tables setup
├── security_groups.tf # Security groups for ALB, ECS, and RDS
├── ecs_cluster.tf # ECS cluster and task definition
├── rds.tf # RDS instance configuration
├── alb.tf # ALB and target group configuration
├── ci_cd_pipeline.tf # CodePipeline, CodeBuild, CodeDeploy setup
├── Dockerfile # Docker configuration for Laravel + Nginx
├── nginx.conf # Nginx configuration file for Laravel
├── buildspec.yml # CodeBuild build specification
├── scripts/
│ └── deploy.sh # Script to automate deployment
└── README.md # Documentation for setup and configuration
3. Step-by-Step Guide
1. main.tf

The main.tf file is the entry point for Terraform. It includes provider configuration, modules (if any), and
calls other .tf files for managing individual resources.

# main.tf

# Define the provider

provider "aws" {

region = var.aws_region

# Call each component's configuration

module "vpc" {

source = "./vpc" # This points to vpc.tf and related files in a subdirectory

module "ecs_cluster" {

source = "./ecs_cluster" # This points to ecs_cluster.tf and related files in a subdirectory

module "rds" {

source = "./rds" # This points to rds.tf and related files in a subdirectory

module "alb" {

source = "./alb" # This points to alb.tf and related files in a subdirectory

module "security_groups" {

source = "./security_groups" # This points to security_groups.tf and related files in a subdirectory

}
module "ci_cd_pipeline" {

source = "./ci_cd_pipeline" # This points to ci_cd_pipeline.tf and related files in a subdirectory

# Configure outputs (e.g., ECS ALB URL, RDS Endpoint)

output "application_url" {

value = module.alb.alb_dns_name

output "database_endpoint" {

value = module.rds.db_endpoint

output "ecs_cluster_name" {

value = module.ecs_cluster.cluster_name

This file calls modules that will be defined in the respective .tf files (e.g., vpc.tf, ecs_cluster.tf).

2. variables.tf

The variables.tf file defines the input variables used throughout the Terraform configuration. This keeps
configurations flexible and allows you to change values without modifying the core .tf files.

# variables.tf

# AWS region

variable "aws_region" {

description = "The AWS region to deploy resources in"

type = string

default = "us-west-2"

# VPC and Subnet configurations

variable "vpc_cidr" {
 description = "CIDR block for the VPC"

type = string

default = "10.0.0.0/16"

variable "public_subnet_cidrs" {

description = "CIDR blocks for public subnets"

type = list(string)

default = ["10.0.1.0/24", "10.0.2.0/24"]

variable "private_subnet_cidrs" {

description = "CIDR blocks for private subnets"

type = list(string)

default = ["10.0.3.0/24", "10.0.4.0/24"]

# ECS and Application

variable "ecs_cluster_name" {

description = "The name of the ECS Cluster"

type = string

default = "laravel-ecs-cluster"

variable "task_cpu" {

description = "CPU units to allocate for the ECS task"

type = number

default = 256

variable "task_memory" {

description = "Memory (in MiB) to allocate for the ECS task"

 type = number

default = 512

# RDS Database

variable "db_instance_class" {

description = "The instance type of the RDS instance"

type = string

default = "db.t3.micro"

variable "db_engine" {

description = "The database engine to use"

type = string

default = "mysql"

variable "db_username" {

description = "Master username for the database"

type = string

default = "admin"

variable "db_password" {

description = "Master password for the database"

type = string

default = "securepassword123" # For security, use a more secure method in production

sensitive = true

The above variables allow for flexibility in specifying VPC settings, ECS task sizes, and RDS database
configurations.
3. outputs.tf

The outputs.tf file is used to display key outputs after the infrastructure is created, such as URLs,
endpoints, and names for important components.

# outputs.tf

# ALB DNS name

output "alb_dns_name" {

description = "The DNS name of the Application Load Balancer"

value = module.alb.alb_dns_name

# ECS Cluster Name

output "ecs_cluster_name" {

description = "The name of the ECS cluster"

value = module.ecs_cluster.cluster_name

# Database Endpoint

output "db_endpoint" {

description = "The endpoint of the RDS database instance"

value = module.rds.db_endpoint

# Database Username

output "db_username" {

description = "The username for the RDS database"

value = var.db_username

sensitive = true

# Public Subnet IDs (for reference)

output "public_subnet_ids" {
 description = "List of public subnet IDs"

value = module.vpc.public_subnet_ids

Step 1: VPC and Networking

vpc.tf

 Create a VPC with a specified CIDR block:

resource "aws_vpc" "app_vpc" {

cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
}

 Define public and private subnets for the VPC across multiple Availability Zones.
 Configure a NAT gateway in the public subnet to allow private instances to access the
internet.
 Create route tables to direct internet traffic from the public subnets to the internet
gateway.

Step 2: Security Groups

security_groups.tf

 Define security groups:

o ALB Security Group: Allows inbound HTTP/HTTPS traffic.
o ECS Security Group: Allows inbound traffic from the ALB and access to RDS.
o RDS Security Group: Restricts access to the ECS security group on the database
port.

resource "aws_security_group" "alb_sg" {

vpc_id = aws_vpc.app_vpc.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}

Step 3: ECS Cluster and Task Definition

ecs_cluster.tf

1. Create an ECS cluster.

2. Define a task definition with containers for Laravel and Nginx:
 resource "aws_ecs_task_definition" "laravel_task" {
family = "laravel-app"
container_definitions = <<DEFINITION
[
{
"name": "nginx",
"image": "nginx",
"essential": true,
"portMappings": [
{ "containerPort": 80, "hostPort": 80 }
]
}
]
DEFINITION
}

3. Set up ECS service with the ALB as the load balancer.

Step 4: Database Setup (RDS)

rds.tf

1. Create an RDS MySQL or PostgreSQL instance.

2. Set database parameters and configure security.

resource "aws_db_instance" "laravel_db" {

allocated_storage = 20
engine = "mysql"
instance_class = "db.t3.micro"
name = "laravel_db"
username = var.db_username
password = var.db_password
vpc_security_group_ids = [aws_security_group.rds_sg.id]
}

3. Output the database connection endpoint.

Step 5: Load Balancer Setup

alb.tf

1. Set up an Application Load Balancer in the public subnets with a target group for the
ECS service.
2. Define health checks to monitor the Laravel application.

resource "aws_lb" "app_alb" {

name = "app-alb"
load_balancer_type = "application"
security_groups = [aws_security_group.alb_sg.id]
subnets = [aws_subnet.public1.id, aws_subnet.public2.id]

}
Step 6: CI/CD Pipeline

ci_cd_pipeline.tf

1. Source: Set up CodePipeline to pull from GitHub.

2. Build: Use CodeBuild to build the Docker image and push to ECR.
o Define buildspec.yml:

version: 0.2
phases:
install:
commands:
- echo "Installing dependencies"
- composer install --no-dev
pre_build:
commands:
- echo "Logging into Amazon ECR"
- $(aws ecr get-login-password --region $AWS_DEFAULT_REGION)
build:
commands:
- docker build -t $REPOSITORY_URI:latest .
- docker push $REPOSITORY_URI:latest

3. Deploy: Use CodeDeploy to update ECS with the new container image.

Sample Configuration Files

Dockerfile

FROM php:7.4-fpm
WORKDIR /var/www
COPY . .
RUN apt-get update && apt-get install -y nginx supervisor
COPY nginx.conf /etc/nginx/nginx.conf

nginx.conf

server {
listen 80;
server_name localhost;
root /var/www/public;

index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
fastcgi_pass php-fpm:9000;
fastcgi_index index.php;
 include fastcgi_params;
}
}

buildspec.yml

version: 0.2
phases:
install:
commands:
- echo "Installing dependencies"
- composer install --no-dev
pre_build:
commands:
- echo "Logging into Amazon ECR"
- $(aws ecr get-login-password --region $AWS_DEFAULT_REGION)
build:
commands:
- docker build -t $REPOSITORY_URI:latest .
- docker push $REPOSITORY_URI:latest
artifacts:
files:
- nginx.conf
- Dockerfile

Summary

1. Challenges:
o Configuring complex networking with subnets and NAT gateways.
o Ensuring secure connectivity between ECS and RDS.
2. Takeaways:
o Terraform simplifies infrastructure as code, making it easier to manage and scale.
o CodePipeline and CodeDeploy allow smooth deployment processes by
automating CI/CD for ECS applications.

2.Theoretical Exam (Written Questions)

 Objective: Answer the following questions to demonstrate your understanding of
architecture, troubleshooting, and security best practices on AWS.

Architecture Design

Scenario: Designing a scalable and highly available architecture for a high-traffic web
application on AWS.

Solution: To build a highly available, scalable, and secure architecture, I would design a multi-
tier architecture that leverages Amazon Web Services (AWS) such as Elastic Load Balancing
(ELB), Auto Scaling Groups, Amazon EC2, Amazon RDS, Amazon S3, and Amazon
CloudFront.

1. Load Balancing:
o Service: Elastic Load Balancer (ELB) to distribute incoming traffic across
multiple EC2 instances.
o Role: ELB ensures high availability by routing traffic to healthy instances in
different Availability Zones (AZs), preventing any single point of failure. It can
detect unhealthy instances and route traffic only to healthy instances, maintaining
consistent availability.
2. Compute and Scaling:
o Service: Amazon EC2 Auto Scaling with an Auto Scaling Group (ASG) to
dynamically adjust the number of EC2 instances based on demand.
o Role: Auto Scaling allows the architecture to scale out under high traffic and
scale in when demand is lower, ensuring the system remains cost-effective.
Deploying EC2 instances across multiple Availability Zones increases fault
tolerance.
3. Database and Storage:
o Service: Amazon RDS (Relational Database Service) for a managed, scalable
database.
o Role: Amazon RDS with Multi-AZ deployment provides high availability by
maintaining a standby replica in another Availability Zone. In case of a failure,
the system can failover to the standby, maintaining service continuity.
4. Content Delivery and Caching:
o Service: Amazon CloudFront (for global content delivery) and Amazon
ElastiCache (for caching).
o Role: CloudFront caches content at edge locations to reduce latency for end-users,
while ElastiCache (using Redis or Memcached) caches frequently accessed data
to reduce database load, thereby improving performance.
5. Security:
o Service: AWS Web Application Firewall (WAF), AWS Identity and Access
Management (IAM), and Amazon Virtual Private Cloud (VPC).
o Role: WAF helps prevent malicious traffic by filtering requests based on custom
rules, IAM ensures least-privilege access policies for resources, and VPC enables
network segmentation and control over inbound and outbound traffic, enhancing
security.
Troubleshooting and Optimization

Scenario: Application on EC2 instances is experiencing performance issues under high traffic.

Steps to Troubleshoot and Optimize:

1. Monitor and Analyze:

o Service: Amazon CloudWatch to monitor metrics such as CPU utilization,
memory, disk I/O, and network performance on EC2 instances.
o Approach: Analyze CloudWatch logs and metrics for any spikes or patterns
indicating bottlenecks. Also, look at the AWS X-Ray to trace requests across the
architecture and identify latency sources.
2. Identify Bottlenecks:
o Compute and Scaling: Check if the EC2 instances are undersized (e.g., CPU and
memory limitations). Adjust the instance type or enable EC2 Auto Scaling to
handle increased demand.
o Database Optimization: Monitor Amazon RDS metrics like query execution
time, connection count, and disk I/O. Consider adding Read Replicas for read-
heavy applications or implementing caching layers like Amazon ElastiCache to
offload database reads.
3. Optimize Network and Application Layers:
o Content Caching: Use Amazon CloudFront to cache static content closer to
users. This reduces load on the EC2 instances and improves response times.
o Code Optimization: Review application code for inefficiencies, such as
unoptimized database queries or synchronous processing that could be offloaded
to asynchronous or batch processing.
4. Auto Scaling and Load Balancing:
o Tuning Auto Scaling Policies: Ensure Auto Scaling policies are set to react
quickly to traffic spikes and can provision instances in multiple AZs.
o Load Balancer Configuration: Check ELB for healthy instance statuses.
Increase ELB capacity if needed and configure it to route traffic evenly.
5. Enable Alarms and Notifications:
o Set up CloudWatch Alarms to trigger notifications for unusual activity, such as
high latency or CPU usage, allowing proactive response to traffic surges.

Security & Compliance

Scenario: Ensuring data security for an application handling sensitive user information.

Solution:

1. Data Encryption:
o At Rest: Use AWS Key Management Service (KMS) to manage and store
encryption keys securely. Encrypt data at rest using Amazon RDS encryption for
databases, S3 encryption for storage, and EBS encryption for instance volumes.
 o In Transit: Use TLS/SSL certificates (via AWS Certificate Manager) for
HTTPS to encrypt data in transit.
2. Access Control:
o IAM Roles and Policies: Implement fine-grained access control using AWS
Identity and Access Management (IAM), ensuring that only authorized users
and services can access sensitive data. Use multi-factor authentication (MFA) for
all accounts and enforce least privilege for all roles and policies.
o Database Access Control: Use Amazon RDS IAM Authentication and security
groups to restrict database access to authorized applications and block direct
public access.
3. Network Security:
o Amazon VPC: Create a private subnet for sensitive resources (e.g., databases)
and restrict access using security groups and network access control lists
(ACLs). Implement VPC peering or VPN if cross-network access is required.
o Web Application Firewall (WAF): Protect the application from common threats,
such as SQL injection and cross-site scripting (XSS), by configuring AWS WAF
rules.
4. Monitoring and Auditing:
o AWS CloudTrail: Enable CloudTrail to log all account activity and API calls for
auditing. Regularly review logs for suspicious activities.
o Amazon GuardDuty: Enable GuardDuty to monitor for malicious or
unauthorized activities. GuardDuty uses machine learning to detect anomalous
behavior and provide alerts.
o Config Compliance: Use AWS Config to track configuration changes and
compliance with industry standards, such as PCI-DSS or HIPAA.
5. Data Backup and Recovery:
o Configure automated backups for RDS, EBS snapshots, and S3 versioning to
support disaster recovery and data integrity. Ensure that backups are encrypted
and stored in separate regions if needed for compliance.