Answer: AWS CloudFormation is an AWS-native Infrastructure as Code (IaC) service. It allows you to model, provision, and manage AWS and third-party resources in a safe, repeatable, and automated manner using declarative template files written in JSON or YAML format.

• Declarative: You define what resources you want (e.g., an S3 bucket, an EC2 instance) and their properties, and CloudFormation determines the correct order of operations to provision them.

Answer:

• Automated Provisioning: Creates complex multi-service architectures consistently without manual console clicks.
• Version Control: Infrastructure templates can be stored in Git repositories, enabling code review, audit histories, and rollback tracking.
• Drift Detection: Identifies if resources created via CloudFormation templates have been modified manually outside of CloudFormation.
• Safety & Rollbacks: If resource creation fails during a stack update, CloudFormation automatically rolls back the entire stack to the last known stable state.

Answer:

Answer: The AWS Shared Responsibility Model outlines the division of security duties between AWS and the customer:

• AWS is responsible for Security OF the Cloud: This includes the global infrastructure (Regions, Availability Zones, Edge Locations) and the physical security of data centers, hypervisors, hardware, and core managed service software layers.
• The Customer is responsible for Security IN the Cloud: This includes customer data, IAM access controls, operating system patching (on EC2), network firewall settings (Security Groups/NACLs), application configuration, and data encryption.

Answer:

• AWS Responsibilities:
  • Physical security of data centers (guards, cameras, biometrics).
  • Maintenance of physical host servers, storage arrays, and network routers.
  • Patching the hypervisor (e.g., virtualization layer).
  • Durability and availability of managed services (e.g., RDS, S3, DynamoDB).
• Customer Responsibilities:
  • Configuring network routing, subnets, Security Groups, and NACLs.
  • Patching guest operating systems on EC2 instances.
  • Setting up IAM user accounts, passwords, and permissions (Least Privilege).
  • Encrypting data at rest (via KMS) and in transit (via SSL/TLS certificates).
  • Application-level security, logs, and business data backups.

Answer:

Answer:

• Stateful Firewalls (e.g., Security Groups): Track active connection states. When an inbound rule permits traffic to reach a port, the firewall remembers the connection and automatically allows the return response traffic to leave the instance, regardless of outbound rules.
• Stateless Firewalls (e.g., NACLs): Do not keep track of active connections. They evaluate inbound and outbound packets as entirely separate events. To permit a web server to respond, you must configure both an inbound rule (allowing traffic to port 80/443) and an outbound rule (allowing response traffic to return to the client's ephemeral ports, e.g., 1024-65535).

Answer: Use Security Groups for instance-specific, fine-grained access control:

• Restricting access to an application server to only accept traffic originating from a specific Load Balancer's security group.
• Allowing SSH access (port 22) only from a specific corporate VPN IP or Bastion host.
• Restricting database instances to accept connections only on port 3306/5432 from web servers.

Answer: Use NACLs as a broad subnet-level firewall/guardrail:

• Blacklisting specific known malicious IP addresses or entire CIDR blocks.
• Creating isolated subnet partitions (e.g., ensuring a database subnet cannot communicate under any circumstance with the public internet subnet).
• Enforcing basic compliance rules across an entire subnet layer.

Answer: Security Groups automatically allow return traffic because they are stateful firewalls.

Answer:

1. Create a subnet inside a VPC.
2. Associate the subnet with a Route Table.
3. Add a default route to the Route Table directing all destination traffic 0.0.0.0/0 to an Internet Gateway (IGW) attached to the VPC.
4. Enable the setting "Auto-assign public IPv4 address" for instances launched within that subnet.

Answer:

1. Create a subnet inside a VPC.
2. Associate the subnet with a Route Table.
3. Configure the Route Table to either:
   • Have no route to 0.0.0.0/0 (isolated private subnet).
   • Have a route to 0.0.0.0/0 targeting a NAT Gateway placed in a public subnet (private subnet with outbound internet access).
4. Ensure the setting "Auto-assign public IPv4 address" is disabled.

Answer: An Internet Gateway (IGW) is a horizontally scaled, redundant, and highly available VPC component that enables communication between resources in your VPC and the public internet. It provides a target in VPC route tables for internet-routable traffic and performs Network Address Translation (NAT) for instances assigned public IPv4 addresses.

Answer: A NAT Gateway (Network Address Translation) allows instances in a private subnet to connect outbound to the internet or other AWS services (e.g., for security updates, patch downloads, or API integrations) but prevents the internet from initiating inbound connections to those instances.

Answer:

1. Provision a NAT Gateway in a public subnet of the same VPC.
2. Attach an Elastic IP (EIP) to the NAT Gateway.
3. Update the Route Table associated with the private subnet containing the EC2 instance.
4. Add a route: Destination 0.0.0.0/0 -> Target nat-xxxxxxxx (the NAT Gateway ID).
5. The EC2 instance will now route all outbound internet traffic through the NAT Gateway, while remaining protected from direct inbound connection attempts.

Answer:

• Security & Isolation: Databases contain sensitive, critical data. Keeping them in private subnets ensures they do not have public IP addresses and cannot be reached directly from the public internet.
• Minimized Attack Surface: Limits database access strictly to internal application servers or Bastion hosts, neutralizing brute-force connection attacks and direct exploitation of database software bugs.

Answer:

1. Create an IAM Role with a trust policy allowing the EC2 service (ec2.amazonaws.com) to assume the role.
2. Attach an IAM Policy to this role granting permission to access the S3 bucket (e.g., s3:GetObject, s3:PutObject on the target bucket ARN).
3. Attach the IAM Role to the EC2 instance as an Instance Profile.
4. Inside the EC2 instance, the AWS SDK or CLI will query the Instance Metadata Service (IMDSv2) automatically to obtain temporary security credentials to authenticate S3 requests. Never hardcode access keys on the instance!

Answer:

• Temporary Credentials: IAM Roles issue short-lived security tokens via the AWS Security Token Service (STS) that expire automatically (usually within 1–12 hours).
• No Hardcoding/Leakage Risks: Access keys are static and permanent. If they are hardcoded in code and pushed to public repositories (like GitHub), attackers can scan and compromise the AWS account within minutes. Roles remove the need to store static credentials on disk.
• Automatic Rotation: AWS rotates the temporary credentials of IAM Roles automatically under the hood.

Answer: The Principle of Least Privilege (PoLP) is a security standard where users, service accounts, and applications are granted only the minimum level of access and permissions required to perform their designated tasks, and absolutely nothing more.

Answer:

• Limits Blast Radius: If a developer's access keys or a server is compromised, the attacker can only access the limited set of resources allowed by that specific policy, preventing a full account take-over.
• Reduces Human Error: Prevents developers or automation scripts from accidentally modifying or deleting production databases or resources they shouldn't be touch in the first place.

Answer:

• Amazon CloudWatch: Monitors system performance (CPU, network, disk) and application logs.
• AWS CloudTrail: Tracks API calls for auditing, compliance, and user actions.
• VPC Flow Logs: Monitors IP traffic entering and leaving network interfaces inside the VPC.
• AWS Config: Tracks resource configuration history and compliance rules.
• AWS Trusted Advisor: Identifies cost savings, security gaps, and performance optimizations.

Answer: Amazon CloudWatch is a monitoring and management service designed for developers, system administrators, and DevOps engineers. It collects system-level performance metrics, gathers application log files, tracks events, and allows you to set alarms to automate responses to resource utilization spikes.

Answer:

• CloudWatch Logs Live Tail: A feature in the CloudWatch console that lets you stream and view log events in real-time as they are ingested.
• AWS CLI: Run aws logs tail <log-group-name> --follow in the command terminal.
• Streaming agent: Stream logs to third-party tools (Elasticsearch, Datadog) using Kinesis Data Firehose.

Answer: AWS CloudTrail is an auditing and compliance service that records all API actions taken within an AWS account. It logs the caller identity, the time of the call, the source IP address, the request parameters, and the response. It answers the question: "Who did what, when, and from where in my AWS account?"

Answer:

1. Select a metric in the CloudWatch dashboard (e.g., CPUUtilization for an EC2 instance).
2. Define threshold parameters:
   • Metric threshold: (e.g., Greater than 80%).
   • Evaluation period: (e.g., for 3 consecutive periods of 5 minutes).
3. Configure target actions:
   • Send notification to an Amazon SNS Topic.
   • Trigger an Auto Scaling Policy (e.g., scale out instances).
   • Perform EC2 actions (e.g., Reboot, Terminate, Recover).

Answer: When a monitored metric breaches the defined threshold, the CloudWatch Alarm transitions to the ALARM state. CloudWatch automatically publishes an alert payload to the associated SNS (Simple Notification Service) Topic. SNS then broadcasts that alert to all registered subscribers (e.g., sending emails to developers, triggers a PagerDuty web hook, or executing an AWS Lambda script to auto-remediate the issue).

Answer: Deploy a multi-AZ scalable web application:

1. Route 53: Resolves DNS and routes user traffic to an Application Load Balancer (ALB).
2. ALB: Distributes incoming web traffic across healthy EC2 instances spread across multiple Availability Zones.
3. Auto Scaling Group (ASG): Manages the fleet of EC2 instances residing in private subnets.
4. Dynamic Scaling: Configure the ASG with target-tracking scaling policies (e.g., keep average CPU at 70% or target request count per instance). When traffic surges, CloudWatch alarms trigger the ASG to launch more instances.
5. Database Layer: Deploy an RDS Multi-AZ instance for high availability, with Read Replicas to offload read operations.

Answer:

• Layer 7 Routing: Operates at the application layer, routing traffic based on URL paths (e.g., /api vs /static), host headers, or query parameters.
• High Availability: Automatically runs across multiple AZs and distributes traffic to prevent single-instance bottlenecks.
• Health Checks: Monitors target health and stops routing traffic to failed or degraded instances.
• SSL Termination: Offloads SSL encryption/decryption processing from EC2 servers, saving instance CPU power.

Answer: An Auto Scaling Group (ASG) is a collection of EC2 instances managed as a logical unit. It maintains a defined number of instances by monitoring instances' health and automatically replacing terminated ones. It scales the number of instances up or down dynamically based on user traffic and performance metrics.

Answer:

1. Metric Collection: EC2 instances send CPU/network metrics to CloudWatch.
2. Alarm Trigger: A CloudWatch Alarm evaluates metrics against thresholds (e.g. CPU > 75% for 5 mins).
3. ASG Action: The alarm triggers the ASG's scaling policy, instructing it to spin up more instances to handle the traffic.

Answer:

• Single Point of Failure (SPOF): If the instance crashes, or the underlying hardware fails, or it undergoes OS updates, the application goes offline.
• No Scalability: A single instance is restricted to vertical scaling (resizing CPU/RAM), which requires downtime and has a hard physical ceiling.

Answer:

• Faster Deployment: Containers spin up in seconds, whereas EC2 virtual machines take minutes to boot.
• Resource Efficiency: Run multiple isolated container instances on a single host, maximizing CPU and RAM utilization.
• Consistency: Eliminates the "works on my machine" problem by bundling code, configuration, and dependencies into a single immutable image.
• Serverless Containers: Allows running containers via AWS Fargate without managing underlying EC2 hosts.

Answer:

• Kubernetes Ecosystem: Native compatibility with Helm, ArgoCD, Prometheus, Istio, and other open-source K8s tools.
• Multi-Cloud Portability: Avoids AWS vendor lock-in. Applications designed for Kubernetes run on Azure (AKS), Google Cloud (GKE), or on-premises with minimal configuration changes.
• Advanced Scheduling: More granular control over complex container workloads, scheduling, and pod affinity rules.

Answer:

• EC2: Best for legacy monoliths requiring deep operating system access, custom kernel modifications, or non-containerized software packages.
• ECS: Best for small-to-medium teams looking for a simple, low-overhead container orchestrator that integrates natively with AWS IAM and ALB.
• EKS: Best for complex enterprise microservice architectures, teams already standardizing on Kubernetes, or projects requiring multi-cloud compatibility.

Answer:

1. Directory-Based Separation (Recommended for Production): Write reusable modules and instantiate them in distinct directories for each environment (e.g., environments/dev/main.tf and environments/prod/main.tf). This isolates state files entirely.
2. Terraform Workspaces: Use the same code configuration file but manage different state outputs inside distinct workspaces (e.g., terraform workspace select dev). Not recommended for prod isolation because variables and configs are shared, increasing human error risks.

Answer: A Terraform Module is a container for multiple resources that are used together. It is simply a directory containing .tf files. Modules allow you to package, parameterize, and reuse infrastructure blocks (e.g., a standardized VPC setup or autoscaling group configuration) across different projects and environments, enforcing DRY (Don't Repeat Yourself) principles.

Answer: .tfvars files are configuration files used to pass values to variables defined in your Terraform code. They allow you to separate logic from configuration parameters. For example, you can have a single variables.tf file, but use dev.tfvars (containing instance_type = "t3.micro") and prod.tfvars (containing instance_type = "c5.large") to deploy different sizes of servers.

Answer:

• Isolates Environments: A corrupted state or an accidental command run in a dev environment will not affect the production backend or delete production resources.
• Improves Speed: Smaller state files process faster during terraform plan and terraform apply.
• Access Control: Restricts developer access to critical environments (e.g., dev/QA can run configs, but only CI/CD pipelines can write to the production state file).

Answer: By default, Terraform writes state data to a local file (terraform.tfstate). Remote state storage writes the state file to a shared, remote location (such as Amazon S3, Google Cloud Storage, or Terraform Cloud). This enables teams to collaborate, secure state from local leakage, and leverage automated locking.

Answer:

• Amazon S3 (Storage): Provides highly durable, secure object storage for the .tfstate file. It supports encryption at rest and versioning, allowing you to roll back to a previous state file if the current one is corrupted.
• Amazon DynamoDB (Locking): Provides a distributed locking mechanism. When terraform apply is executed, Terraform locks the state file using a DynamoDB table entry, preventing other engineers from executing concurrent plans that could corrupt the state file.

Answer: Terraform Workspaces allow you to manage multiple distinct state files (representing different environments) using the exact same configuration directory. When in a workspace, Terraform appends the workspace name to the state path. While useful for creating transient, short-lived test environments, they are generally avoided for separating production and development stacks due to overlapping configuration risk.

Answer: Bash scripts are used in pipelines to automate sequential, repetitive, or CLI-based tasks:

• Installing dependencies and environment utilities (e.g., downloading kubectl).
• Running code linters, unit tests, and security scans.
• Running build commands (e.g., docker build and pushing to Amazon ECR).
• Formatting variables or templating config files before applying changes.
• Executing deployment commands (e.g., applying Terraform or running database migrations).

Answer:

• Exit Codes: Every pipeline command executes and returns an exit code. CI runner agents monitor this value automatically.
• Error Flags: Use shell parameters like set -e inside custom Bash steps to terminate scripts immediately upon command failure.
• Log Inspection: Parse command standard error streams (stderr) for failure key phrases using regex.

Answer: set -e (commonly referred to as "exit immediately") instructs the Bash interpreter to exit the script execution immediately if any command, pipeline, or subshell returns a non-zero exit status (failure). This stops the script from executing subsequent lines with incorrect variables, preventing cascading errors.

Answer: An exit code (or return status) is an integer value between 0 and 255 returned by a system process to its parent process upon termination:

• 0 represents a successful execution.
• 1 to 255 represents a specific error or failure type (e.g., 1 for general errors, 127 for command not found).

Answer:

1. Ensure your script steps run with set -e enabled so they terminate on failure.
2. If manually catching errors, explicitly call exit 1 (or another non-zero code) within conditionals.
3. CI/CD runners (like GitHub Actions, GitLab CI, or Jenkins) check the exit code of shell executions. If the exit code is non-zero, the runner marks the build step as failed and stops execution of subsequent jobs.

Answer: Here is a production-grade Bash script script that handles errors automatically using set -e and trap handlers:

#!/bin/bash

# Exit immediately if any command returns a non-zero exit code
set -e

# Treat unset variables as errors when executing
set -u

# Ensure pipelines return the exit status of the last command that failed
set -o pipefail

# Error handler function
cleanup_error() {
    local exit_code=$?
    echo "❌ ERROR: Script failed at line $1 with exit code $exit_code"
    # Perform cleanups (e.g., remove temp files) here
    exit "$exit_code"
}

# Trap any ERR signal and call cleanup_error with the line number
trap 'cleanup_error $LINENO' ERR

echo "🚀 Starting deployment pipeline steps..."

# Simulate a successful command
mkdir -p /tmp/build_dir
echo "Standard compile successful."

# Simulate checking a requirement (this will fail if database is offline)
# If this command returns a non-zero status, the script exits immediately
# rather than proceeding to publish a broken build.
curl -s --fail http://localhost:8080/health || false

echo "✅ Pipeline completed successfully!"

Answer:

Answer: Use Cron for simple, legacy tasks that do not require complex system integrations or granular scheduling:

• Running a database backup script every midnight.
• Clearing system temporary directories on a legacy server every Saturday.
• Sending a simple daily activity email report.

Answer: Use Systemd Timers for modern system automation tasks:

• Tasks that need to run relative to system startup or container boot times (e.g., start scanning files 10 minutes after boot).
• Tasks that should only run if specific dependencies are active (e.g., run backup only if database system service is running).
• Tasks requiring resource limitations (e.g., throttling CPU/RAM usage of a batch script via cgroups).
• Tasks requiring centralized, searchable logs in journalctl.

Answer:

• Using systemd:

  systemctl status nginx
  

• Checking processes:

  ps aux | grep nginx
  # or
  pgrep -x nginx
  

• Testing network response:

  curl -I http://localhost
  

Answer:

• Start Nginx:

  sudo systemctl start nginx
  

• Stop Nginx:

  sudo systemctl stop nginx
  

• Restart Nginx (Hard restart - kills active connections):

  sudo systemctl restart nginx
  

• Reload Nginx (Soft reload - reloads config gracefully without downtime):

  sudo systemctl reload nginx
  

Answer:

• Viewing Access Logs (requests):

  tail -f /var/log/nginx/access.log
  

• Viewing Error Logs (failures):

  tail -f /var/log/nginx/error.log
  

• Using systemd journal logs:

  journalctl -u nginx --tail 50 -f
  

Answer: Use one of the following tools:

• ss command:

  sudo ss -tulnp
  

• netstat command:

  sudo netstat -tulnp
  

• lsof command:

  sudo lsof -i -P -n
  

(Options: -t = TCP, -u = UDP, -l = Listening sockets only, -n = Numeric IPs, -p = Show process IDs)

Answer:

• ss (Socket Statistics): A modern command that queries socket statistics directly from kernel space (using netlink interface). It is much faster and more efficient than netstat under high load.
• netstat (Network Statistics): A legacy tool that reads /proc/net/ files. Deprecated on most modern Linux distributions because it is slow and resource-heavy.
• lsof (List Open Files): Lists all open files on the system. Because "everything is a file" in Unix-like systems, running lsof -i displays network connections associated with running processes.

Answer:

• Using ss:

  sudo ss -tulnp | grep :80
  

• Using nc (netcat):

  nc -zv localhost 80
  

• Using lsof:

  sudo lsof -i :80
  

Answer:

• ALB (Application Load Balancer): Layer 7 (HTTP/HTTPS) load balancer. Best for web apps, supports path/host-based routing.
• NLB (Network Load Balancer): Layer 4 (TCP/UDP/TLS) load balancer. Best for ultra-low latency, high-throughput traffic, and provides static/Elastic IP addresses.
• CLB (Classic Load Balancer): Legacy load balancer. Operates at Layer 4/7. Deprecated; avoid using in new architectures.

Answer:

• Route 53 (DNS): Directs the client to an IP address or load balancer endpoint based on their host lookup query (e.g., matches example.com to 1.2.3.4).
• Load Balancer: Once the client gets the IP, they connect to the Load Balancer. The Load Balancer receives the actual payload data and distributes requests to backend servers.

Answer:

• EBS (Elastic Block Store): High-performance block storage volume attached to a single EC2 instance. It is AZ-locked (cannot be attached to instances in another AZ).
• EFS (Elastic File System): Shared file storage (NFS) that can be mounted simultaneously by thousands of EC2 instances across multiple Availability Zones.

Answer:

• S3: Object storage accessed via HTTP APIs. Infinite scale, global namespace, best for static files and backups.
• EBS: Block storage attached to one server. Acts like a local SSD, lowest latency, best for operating systems and database storage.
• EFS: Networked file storage (NFS) shareable across multiple servers, scales automatically.

Answer:

• RDS: Relational SQL database engine. Great for structured data, complex transactional queries, joins, and ACID compliance.
• DynamoDB: Serverless NoSQL database. Stores key-value documents, offers single-digit millisecond latency at any scale, but has limited support for complex queries/joins.

Answer: A Virtual Private Cloud (VPC) is a logically isolated virtual network dedicated to your AWS account. You need it to define your own IP space, secure resources, create public/private boundaries, and control network routing to prevent unauthorized external access to your infrastructure.

Answer: CIDR (Classless Inter-Domain Routing) is a format used to represent IP addresses and their associated routing masks (e.g., 10.0.0.0/24 means the first 24 bits represent the network address, leaving 8 bits for hosts, resulting in $2^8 = 256$ IP addresses).

Answer: A Bastion Host (or Jump Box) is a highly secured EC2 instance placed in a public subnet. Administrators connect to the Bastion host first (e.g., via SSH or Systems Manager Session Manager) and then use it as a proxy tunnel to connect to servers residing in private subnets, ensuring private instances never expose ports to the internet directly.

Answer: A deployment strategy that uses two identical production environments:

• Blue (Active): Serving current live production traffic.
• Green (Idle): Running the new code release.
• Switch: Traffic is shifted instantly from Blue to Green. If an error is detected, traffic shifts back to Blue immediately with zero downtime.

Answer: A deployment strategy where the new application version is rolled out to a tiny fraction of servers or users (e.g., 5% of traffic) first. Once verified as stable (no error spikes), the new version is incrementally rolled out to the remaining 95% of users.

Answer: Docker is a containerization platform. We use containers to package an application along with its OS filesystem, libraries, and configurations into a single standardized image. This ensures the application runs identically on a developer's laptop, a QA server, and in production.

Answer: Kubernetes (K8s) is an open-source container orchestration system that automates the deployment, scaling, clustering, scheduling, health-monitoring, and networking of containerized applications across fleets of host nodes.

Answer:

1. The associated Application Load Balancer health check detects the instance is unhealthy.
2. The ALB stops routing client traffic to that instance.
3. The Auto Scaling Group health check notices the instance state is terminated/degraded.
4. The ASG terminates the failed instance and launches a new healthy instance in its place to restore target capacity automatically.

Answer: Follow a systematic diagnostic flow:

1. Check DNS: Test resolution using nslookup or dig to confirm Route 53 points to the correct endpoint.
2. Check ALB: Test the Load Balancer DNS endpoint directly. Look for HTTP 502/503/504 errors.
3. Verify Security Groups/NACLs: Confirm port 80/443 traffic is allowed inbound on the ALB and instances, and outbound response traffic is not blocked.
4. Inspect EC2 Status: Verify instance status checks are passing in the console. Check CPU, RAM, and Disk space limits.
5. Verify Listening Sockets: Connect via SSH/Systems Manager and confirm the web server (Nginx/Apache) is running and listening on the expected ports (sudo ss -tulnp).
6. Check Logs: Check Nginx logs (/var/log/nginx/error.log) and application runtime logs for crash errors.
7. Verify Database: Verify the app can establish connections with the database (check db subnets, credentials, and connection limits).