28 Jul, 2026
0 Comments
34 Mins Read

AWS DevOps Interview Questions

How do you perform infrastructure changes in a production environment while ensuring minimal downtime?

Infrastructure changes in production should always follow a controlled, automated, and rollback-ready approach.

Step 1: Understand the Change

Before making any modification, I identify:
- Scope of the change
- Systems affected
- Dependencies
- Potential risks
- Expected downtime (if any)
Example:
- Updating EC2 instances
- Modifying VPC routes
- Upgrading Kubernetes cluster
- Updating RDS parameter group
Step 2: Create a Backup

Always create backups before touching production.

Examples:
- EBS Snapshots
- RDS Snapshot
- AMI of EC2
- Kubernetes etcd backup
- Terraform State Backup
This ensures quick recovery if anything goes wrong.

Step 3: Test in Lower Environments

Never deploy directly to Production.

Deployment flow:
Development ↓ Testing ↓ Staging ↓ Production
Verify:
- Application functionality
- Infrastructure
- Database migrations
- Performance
- Security
Step 4: Infrastructure as Code

Never make manual production changes.

Use:
- Terraform
- CloudFormation
- Ansible
Benefits:
- Version control
- Rollback
- Audit history
- Repeatability
Example:
terraform plan terraform apply
Always review the plan before applying.

Step 5: Blue-Green Deployment

Maintain two environments.
Blue → Current Production Green → New Version
Steps:

Deploy application to Green.

Run tests.

Switch Load Balancer.

If issue occurs:
Rollback → Blue
Users experience almost zero downtime.

Step 6: Rolling Deployment

Instead of replacing every server simultaneously,

Update servers one at a time.

Example:
Server1 → Updated Server2 → Updated Server3 → Updated
Load Balancer keeps routing traffic.

No outage occurs.

Step 7: Canary Deployment

Release application to a small percentage of users.

Example:
5% ↓ 20% ↓ 50% ↓ 100%
Monitor:
- Errors
- CPU
- Memory
- User experience
If problems appear,

Rollback immediately.

Step 8: Enable Monitoring

Monitor throughout deployment.

AWS CloudWatch

Monitor:
- CPU
- Memory
- Latency
- Error Rate
- Disk
- Network
Kubernetes:
- Prometheus
- Grafana
Application:
- Datadog
- New Relic
Step 9: Validate

Verify:
- Health checks
- API
- Logs
- Metrics
- Database
- User Login
- Payment Flow
Step 10: Rollback Plan

Every production deployment must have a rollback strategy.

Examples:
- Previous AMI
- Previous Docker Image
- Previous Terraform State
- Previous Helm Chart
Rollback should take only a few minutes.
An application deployed on AWS suddenly becomes unavailable. How would you troubleshoot the issue step by step?

Production troubleshooting should follow a structured approach.

Step 1: Verify the Issue

Determine whether:
- Entire application is down
- API only
- Frontend only
- Database issue
- Network issue
Check:
Website API Health Endpoint
Step 2: Check Route53

Verify:
- DNS Resolution
Use:
nslookup dig
Step 3: Check Load Balancer

AWS ALB/NLB

Verify:
- Target Health
If targets unhealthy,

Investigate EC2 or Kubernetes.

Step 4: Check EC2 Status

Verify:
Running CPU Memory Disk
Check:
CloudWatch EC2 Console
Step 5: Verify Security Groups

Ensure:
- Port 80
- Port 443
- Port 22
Not accidentally removed.

Step 6: Check Auto Scaling

Verify:
- Desired Capacity
- Running Instances
Instances may have terminated unexpectedly.

Step 7: Review Application Logs

Locations:
/var/log CloudWatch Logs Docker Logs Kubernetes Logs
Look for:
- Exceptions
- Connection refused
- OutOfMemory
- Timeout
Step 8: Database

Check:

RDS Status

Connections

CPU

Storage

Slow Queries

Step 9: Network

Verify:
- VPC
- Route Tables
- Internet Gateway
- NAT Gateway
Step 10: Recent Changes

Check:
- Terraform
- Jenkins
- Git Commit
- Deployment History
Often the latest deployment introduces the issue.

Step 11: Rollback

If deployment caused failure,

Rollback immediately.

Step 12: RCA

Prepare Root Cause Analysis.

Include:
- Timeline
- Cause
- Resolution
- Prevention
How do you monitor AWS applications? Which tools, metrics, and alerts do you consider essential?

Monitoring is proactive, not reactive.

AWS Monitoring Tools

CloudWatch

Used for:
- Metrics
- Logs
- Alarms
- Dashboards
CloudTrail

Tracks:
- AWS API Calls
- IAM Activities
AWS X-Ray

Monitors:
- Request Flow
- Latency
- Microservices
Prometheus

Collects Kubernetes metrics.

Grafana

Visualization Dashboard.

ELK Stack
- Elasticsearch
- Logstash
- Kibana
Centralized logging.

Important Metrics

EC2
- CPU Utilization
- Memory
- Disk Usage
- Network In/Out
ALB
- Request Count
- HTTP 5xx
- Latency
RDS
- CPU
- Connections
- Storage
- Replica Lag
Kubernetes
- Pod Restart Count
- CPU
- Memory
- Node Status
Application
- Response Time
- Error Rate
- Throughput
Essential Alerts
- CPU >80%
- Disk >85%
- Memory >90%
- Pod CrashLoopBackOff
- HTTP 5xx increase
- High latency
- Failed deployments
- SSL certificate expiration
- Database storage threshold
- Instance termination
Describe your experience designing and maintaining CI/CD pipelines. How do you handle deployment failures?

I have designed CI/CD pipelines using Jenkins, Git, Docker, Terraform, Kubernetes, and AWS.

Typical pipeline:
Developer Pushes Code ↓ GitHub ↓ Jenkins ↓ Build ↓ Unit Test ↓ SonarQube ↓ Docker Build ↓ Docker Push ↓ Deploy Kubernetes ↓ Smoke Test
Deployment Failure Handling
1. Read Jenkins logs
2. Verify Git changes
3. Check Docker image
4. Validate Kubernetes deployment
5. Inspect application logs
6. Roll back to the previous stable version
7. Fix the issue in a lower environment
8. Redeploy after validation
I also configure notifications via Slack or email so failures are reported immediately.
Explain your experience with Kubernetes or Amazon EKS. What challenges have you faced while managing workloads?

I have worked with Kubernetes/EKS for deploying and managing containerized applications.

Responsibilities included:
- Creating Deployments and Services
- Configuring Ingress
- Managing ConfigMaps and Secrets
- Autoscaling with HPA
- Rolling Updates
- Monitoring with Prometheus and Grafana
Challenges Faced

1. Pod Scheduling Issues
- Cause: Insufficient CPU/Memory
- Solution: Scale nodes or optimize resource requests.
2. CrashLoopBackOff
- Cause: Application startup failure or incorrect configuration.
- Solution: Review logs, events, and configuration.
3. ImagePullBackOff
- Cause: Incorrect image tag or registry authentication.
- Solution: Verify image exists and configure imagePullSecrets.
4. Resource Limits
- Cause: Pods killed due to OOM.
- Solution: Tune requests/limits and optimize the application.
5. Networking
- Cause: Services unable to communicate.
- Solution: Check Services, Endpoints, Network Policies, and CoreDNS.
How do you securely manage secrets, credentials, and sensitive configuration in AWS and Kubernetes?

Secrets should never be hardcoded in source code or Docker images.

AWS

I use:
- AWS Secrets Manager
- AWS Systems Manager Parameter Store
- IAM Roles for EC2/EKS instead of static access keys
- KMS for encryption
Examples include storing:
- Database passwords
- API keys
- OAuth tokens
- Third-party credentials
Kubernetes

I use:
- Kubernetes Secrets
- RBAC to restrict access
- Encryption at rest for secrets
- External Secrets Operator or CSI Secrets Store to integrate AWS Secrets Manager
Best Practices
- Rotate credentials regularly.
- Grant least-privilege IAM permissions.
- Audit access with CloudTrail.
- Avoid storing secrets in Git repositories.
- Mask secrets in CI/CD pipeline logs.
Terraform reports infrastructure drift during terraform plan. How would you investigate and resolve it?

Infrastructure drift means the actual infrastructure differs from the Terraform state.

Investigation
1. Run:
terraform plan
1. Identify which resources have changed.
2. Review Terraform state:
terraform state list terraform state show <resource>
1. Compare with the AWS Console or CLI.
2. Check CloudTrail to determine who or what modified the resource.
Resolution
- If the manual change was intentional, update the Terraform code and apply it.
- If the manual change was accidental, run terraform apply to restore the desired state.
- If Terraform state is incorrect, use:
terraform import
or
terraform state mv
as appropriate.

Prevention
- Restrict manual production changes.
- Use Infrastructure as Code for all modifications.
- Store Terraform state remotely (for example, in S3 with DynamoDB state locking).
- Perform regular drift detection.
Your Jenkins pipeline has suddenly started failing after months of successful deployments, even though no application code has changed. What would you investigate first?

Since the application code hasn’t changed, I would first investigate the environment and pipeline dependencies.

Step-by-step
1. Review Jenkins console logs.
2. Identify the exact failing stage.
3. Check whether Jenkins plugins were updated.
4. Verify agent/node availability and disk space.
5. Validate credentials (expired passwords, tokens, certificates).
6. Check external services:
  - GitHub/GitLab
  - Docker Registry
  - SonarQube
  - Artifact Repository
7. Confirm AWS credentials or IAM permissions haven’t changed.
8. Verify network connectivity and DNS.
9. Check whether base Docker images or package repositories have changed.
10. Review recent infrastructure or configuration changes.
If the root cause is identified, I fix it, rerun the pipeline, and document the incident to prevent recurrence.
A Kubernetes Pod is stuck in CrashLoopBackOff. Walk me through your troubleshooting approach from start to finish.

Step 1: Check Pod Status
kubectl get pods
Step 2: Describe the Pod
kubectl describe pod <pod-name>
Look for:
- Events
- Failed mounts
- OOMKilled
- Probe failures
Step 3: View Logs
kubectl logs <pod-name>
If the container restarts quickly:
kubectl logs <pod-name> --previous
Step 4: Verify Configuration

Check:
- ConfigMaps
- Secrets
- Environment variables
- Mounted volumes
Step 5: Check Image

Confirm:
- Correct image name
- Correct tag
- Image availability
- Registry access
Step 6: Review Resource Usage

Check whether the pod was terminated due to insufficient memory or CPU.
kubectl top pod

Step 7: Validate Liveness and Readiness Probes
Incorrect probe settings can continuously restart a healthy application.

Step 8: Check Node Health
kubectl describe node
Verify:
- Disk pressure
- Memory pressure
- CPU pressure
Step 9: Apply the Fix

Depending on the root cause:
- Correct configuration
- Increase resources
- Fix the application bug
- Update the image
- Resolve secret or ConfigMap issues
Step 10: Verify

Ensure:
- Pod status is Running
- Logs are clean
- Readiness checks pass
- Application is accessible
Describe a production incident you handled. What was the root cause, how did you resolve it, and what did you learn from the experience?

Example Answer:

One production incident I handled involved a web application hosted on Amazon EKS becoming intermittently unavailable during peak traffic.

Situation

Users reported slow responses and occasional HTTP 503 errors. CloudWatch and Prometheus showed a sharp increase in CPU utilization, and several application pods were repeatedly restarting.

Investigation

I followed a structured troubleshooting process:
- Verified the Load Balancer and confirmed it was routing traffic correctly.
- Checked Kubernetes pod status and found multiple pods in CrashLoopBackOff.
- Reviewed pod logs and discovered OutOfMemoryError exceptions.
- Examined resource requests and limits and found that the application had been deployed with memory limits that were too low for the production workload.
- Confirmed there were no database or networking issues.
Resolution
- Increased the container memory limits and requests.
- Performed a rolling update to deploy the corrected configuration.
- Configured the Horizontal Pod Autoscaler (HPA) to scale based on CPU utilization.
- Monitored the deployment until CPU, memory, and response times returned to normal.
Root Cause

The application’s memory allocation was insufficient for peak production traffic, causing repeated container crashes and service disruption.

Lessons Learned
- Validate resource sizing through load testing before production deployments.
- Configure autoscaling to handle traffic spikes.
- Set proactive CloudWatch and Prometheus alerts for high memory usage, pod restarts, and HTTP 5xx errors.
- Include performance and capacity validation as part of the CI/CD pipeline before every production release.
This incident reinforced the importance of proactive monitoring, automated scaling, and thorough pre-production testing to maintain high application availability.
Which CI/CD tool are you using?

Answer:

I have primarily worked with Jenkins as the CI/CD tool for automating application build, testing, and deployment. In addition to Jenkins, I have experience integrating it with GitHub/GitLab, Maven, SonarQube, Docker, Amazon ECR, Terraform, Ansible, Kubernetes (EKS), and various AWS services.

CI/CD Workflow
Developer │ ▼ GitHub Repository │ Webhook Trigger ▼ Jenkins Pipeline │ Build (Maven) ▼ Unit Testing ▼ SonarQube Code Analysis ▼ Build Docker Image ▼ Push Image to Amazon ECR ▼ Deploy to Amazon EKS / EC2 ▼ Smoke Testing ▼ Production Deployment
Jenkins Pipeline Stages
1. Pull source code from Git.
2. Build the application using Maven.
3. Execute unit tests.
4. Perform static code analysis with SonarQube.
5. Build a Docker image.
6. Push the image to Amazon ECR.
7. Deploy the application to EKS or EC2.
8. Run smoke tests.
9. Send deployment notifications through Slack or email.
  
  Benefits
  - Fully automated deployments
  - Faster releases
  - Consistent deployments
  - Easy rollback
  - Reduced human errors
  - Continuous monitoring
Tell me step by step, from basic to end level, how you deploy your Java application on an EC2 server?

Answer:

Suppose we have a Spring Boot Java application.

Step 1: Developer Writes Code

The developer develops the application locally.

Example:
Spring Boot Application
Step 2: Push Code to GitHub
git add . git commit -m "Added new feature" git push origin main
Step 3: Jenkins Trigger

A GitHub webhook automatically triggers Jenkins.

Step 4: Build the Application

Jenkins executes:
mvn clean package
This generates:
target/app.jar
Step 5: Run Unit Tests
mvn test
If tests fail, deployment stops.

Step 6: SonarQube Analysis

Jenkins performs code quality analysis.

Checks include:
- Bugs
- Code smells
- Security vulnerabilities
- Code coverage
Step 7: Build Docker Image (Optional)
docker build -t springboot-app .
Step 8: Push to Amazon ECR (if containerized)
docker push <account>.dkr.ecr.<region>.amazonaws.com/app
Step 9: Launch EC2 Instance

Create an EC2 instance with:
- Amazon Linux or Ubuntu
- Java installed
- Security Group allowing ports 22, 80, and 8080
- IAM Role (if needed)
Step 10: Connect to EC2
ssh -i key.pem ubuntu@Public-IP
Step 11: Install Java

Ubuntu:
sudo apt update sudo apt install openjdk-17-jdk
Verify:
java -version
Step 12: Copy Application

Using SCP:
scp -i key.pem app.jar ubuntu@Public-IP:/home/ubuntu
Or automate with Jenkins.

Step 13: Start Application
java -jar app.jar
Background execution:
nohup java -jar app.jar &
Step 14: Configure Nginx (Optional)

Nginx forwards traffic from port 80 to 8080.

Step 15: Verify Application
http://Public-IP:8080
or
http://domain-name
Step 16: Monitor Logs
tail -f application.log
or
journalctl
Step 17: Configure CloudWatch

Monitor:
- CPU
- Memory
- Disk
- Logs
Step 18: Rollback

If deployment fails:
- Restore previous JAR.
- Redeploy previous version.
- Restart the application.
How do you connect to an EC2 instance?

Answer:

The most common way is using SSH.

Linux / macOS
ssh -i mykey.pem [email protected]
Amazon Linux:
ssh -i mykey.pem ec2-user@Public-IP
Ubuntu:
ssh -i mykey.pem ubuntu@Public-IP
Windows

Use:
- PuTTY
- MobaXterm
- Windows Terminal with OpenSSH
Prerequisites
- Running EC2 instance
- Public IP or Elastic IP
- Security Group allowing port 22
- Correct private key (.pem)
- Proper file permissions
Example:
chmod 400 mykey.pem
Troubleshooting

If SSH fails:
- Check Security Group
- Verify Network ACL
- Ensure EC2 is running
- Verify key pair
- Confirm public IP
- Check SSH service:
sudo systemctl status ssh

In Terraform, how do you connect to ECR?

Answer:

Terraform itself doesn’t log in to ECR. It provisions ECR resources, while Docker authenticates using the AWS CLI.

Step 1: Create ECR Repository

resource "aws_ecr_repository" "app" {
  name = "java-app"
}

Step 2: Authenticate Docker

aws ecr get-login-password \
| docker login \
--username AWS \
--password-stdin \
<account-id>.dkr.ecr.ap-south-1.amazonaws.com

Step 3: Build Image

docker build -t java-app .

Step 4: Tag Image

docker tag java-app:latest \
<account>.dkr.ecr.ap-south-1.amazonaws.com/java-app:latest

Step 5: Push Image

docker push <account>.dkr.ecr.ap-south-1.amazonaws.com/java-app:latest

Terraform Authentication

Terraform authenticates with AWS using:

IAM User credentials
IAM Role
Environment variables
AWS CLI profile

Example:

export AWS_ACCESS_KEY_ID=xxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxx

or preferably an IAM Role for EC2/EKS.

In Kubernetes, what is RBAC?

Answer:

RBAC (Role-Based Access Control) is the Kubernetes authorization mechanism used to control who can perform which actions on which resources.

It follows the principle of least privilege, ensuring users and applications only receive the permissions they require.

RBAC Components

Role

Defines permissions within a namespace.

Example:
- Read Pods
- Create Services
ClusterRole

Provides cluster-wide permissions.

Examples:
- Manage Nodes
- Access all namespaces
RoleBinding

Assigns a Role to a user, group, or ServiceAccount within a namespace.

ClusterRoleBinding

Assigns a ClusterRole across the entire cluster.

Example

Developer:

Can:
- View Pods
- View Deployments
Cannot:
- Delete Nodes
- Modify Secrets
Benefits
- Improved security
- Least privilege access
- Separation of responsibilities
- Compliance and auditing
Suppose you are working on a Terraform script for EC2 infrastructure creation. A team member makes changes in the AWS Console, but your Terraform template is different. How do you fetch those changes into your Terraform template?

This situation is called Infrastructure Drift. Terraform’s state file and actual AWS infrastructure are no longer in sync.

Step 1: Detect the Drift

Run:

terraform plan

Terraform will compare:
- Terraform code
- Terraform state
- Actual AWS infrastructure
Example output:

~ instance_type = "t2.micro" -> "t3.micro"

This means someone changed the EC2 instance type manually in AWS.

Step 2: Investigate What Changed

Check the resource:

terraform state show aws_instance.web

Also verify in the AWS Console or AWS CLI:

aws ec2 describe-instances --instance-ids i-xxxx

Step 3: Decide the Desired State

Ask:
- Should AWS remain as modified?
- Or should Terraform revert it?
Step 4A: Keep the AWS Changes

Update the Terraform code to match AWS.

Example:

instance_type = "t3.micro"

Run:

terraform plan

It should show No changes.

Step 4B: Revert the AWS Changes

If the console change was accidental:

terraform apply

Terraform will restore the infrastructure to the code-defined state.

Step 5: If the Resource Was Created Manually

Import it:

terraform import aws_instance.web i-1234567890abcdef0

Then generate or update the Terraform configuration for that resource.

Step 6: Best Practices
- Restrict manual console changes.
- Use Terraform for all infrastructure modifications.
- Store state remotely (S3 + DynamoDB locking).
- Enable CloudTrail for auditing.
- Run periodic drift detection.
Interview Tip: “I first run terraform plan to detect drift, verify the actual AWS changes, then either update the Terraform code to adopt the change or run terraform apply to restore the desired state.”
How do you monitor the logs for pods running in an EKS cluster?

Answer:

There are multiple methods.

Method 1: kubectl logs

Single pod:
kubectl logs pod-name
Multiple containers:
kubectl logs pod-name -c container-name
Previous logs:
kubectl logs pod-name --previous
Real-time logs:
kubectl logs -f pod-name
Method 2: Describe Pod
kubectl describe pod pod-name
Shows events such as scheduling failures and probe issues.

Method 3: CloudWatch Container Insights

Integrate EKS with CloudWatch.

Monitor:
- Application logs
- Node logs
- Container logs
- Performance metrics
Method 4: Fluent Bit

Collect logs and send them to:
- CloudWatch
- Elasticsearch
- OpenSearch
Method 5: ELK Stack
- Elasticsearch
- Logstash
- Kibana
Provides centralized logging and visualization.
Are you using volume mounts? Using volume mount services or without volume mounts?

Answer:

Yes, I have used volume mounts in Kubernetes whenever applications require persistent storage or need to share configuration or data.

When I use volume mounts
- Database storage
- Log storage
- Shared files
- Configuration files
- SSL certificates
- Application uploads
Common Volume Types
- emptyDir – Temporary storage that exists while the Pod runs.
- hostPath – Mounts a directory from the node (mainly for testing or special use cases).
- PersistentVolume (PV) with PersistentVolumeClaim (PVC) – Persistent storage backed by EBS, EFS, or other storage providers.
- ConfigMap – Mount configuration files.
- Secret – Mount sensitive data like passwords or certificates.
Example

For a MySQL application on EKS, I would use an Amazon EBS-backed PersistentVolume with a PersistentVolumeClaim to ensure data persists even if the Pod is recreated.

For stateless applications, such as many Spring Boot microservices, persistent storage may not be required, and I deploy them without volume mounts unless they need logs, uploads, or external configuration.
What is PVC?

Answer:

PVC stands for PersistentVolumeClaim.

It is a request for storage made by a Pod.

Think of it as follows:
- PersistentVolume (PV) = The actual storage resource.
- PersistentVolumeClaim (PVC) = The request for that storage.
- Pod = Uses the PVC to access the storage.
Workflow
Pod │ ▼ PersistentVolumeClaim (PVC) │ ▼ PersistentVolume (PV) │ ▼ Amazon EBS / Amazon EFS / NFS / Azure Disk
Why PVC?

Without persistent storage:
- Pod deleted → Data lost.
With PVC:
- Pod deleted → Data remains.
Common Use Cases
- MySQL
- PostgreSQL
- MongoDB
- Jenkins
- Elasticsearch
- File uploads

What is ADD in a Dockerfile? What is the difference between CMD and ENTRYPOINT?

What is ADD?

ADD copies files or directories from the local machine into the Docker image.

It also has additional capabilities:

Extracts local .tar archives automatically.
Can download files from a URL (though COPY is generally preferred for local files).

Example:

ADD app.jar /app/

Difference Between COPY and ADD

COPY	ADD
Copies local files	Copies local files and supports additional features
Preferred for most use cases	Can extract archives and fetch URLs
Simpler and more predictable	More powerful but less commonly needed

CMD

CMD specifies the default command to run when the container starts.

Example:

CMD ["java","-jar","app.jar"]

It can be overridden when running the container:

docker run image-name ls

ENTRYPOINT

ENTRYPOINT defines the main executable for the container.

Example:

ENTRYPOINT ["java","-jar","app.jar"]

Arguments passed with docker run are appended to the command instead of replacing it.

CMD vs ENTRYPOINT

CMD	ENTRYPOINT
Default command	Main executable
Easy to override	Normally remains fixed
Suitable for flexible containers	Suitable for dedicated applications

Interview Tip: A common pattern is to use both together:

ENTRYPOINT ["java","-jar"]
CMD ["app.jar"]

This allows changing only the JAR name or additional arguments without replacing the main executable.

Tell the command in Ubuntu: if a process is running, how do you kill that process?

Answer:

There are several ways to stop a running process.

Step 1: Find the Process

Using ps:
ps -ef
Search for a specific process:
ps -ef | grep java

or
ps -ef | grep nginx
Using top:
top
Using htop (if installed):
htop
Using pgrep:
pgrep java
Step 2: Kill the Process

Graceful termination:
kill <PID>
Example:
kill 12345
This sends the SIGTERM (15) signal, allowing the application to shut down cleanly.

Step 3: Force Kill (if needed)
kill -9 <PID>
Example:
kill -9 12345
This sends the SIGKILL (9) signal, immediately terminating the process without allowing cleanup.

Step 4: Kill by Process Name
pkill java
or
killall java
Step 5: Verify the Process Has Stopped
ps -ef | grep java

or
pgrep java
If no process ID is returned, the process has been successfully terminated.

Interview Best Practice

In production, always try a graceful shutdown (kill) before using kill -9, because forcefully killing a process can interrupt transactions, leave temporary files behind, or cause data corruption in applications such as databases.
What is your application technology stack?

A typical Java microservices stack I have worked with is:

Frontend

React / Angular

Backend

Java 17 + Spring Boot

Build

Maven

Container

Docker

Registry

Amazon ECR

Orchestration

Amazon EKS (Kubernetes)

Database

PostgreSQL / MySQL / Amazon RDS

CI/CD

Jenkins + GitHub

Monitoring

CloudWatch + Prometheus + Grafana

IaC

Terraform

OS

Ubuntu / Amazon Linux 2

Architecture

React UI

ALB / Ingress

Spring Boot Microservices on EKS

RDS PostgreSQL

Why this stack?
- Scalable
- Cloud-native
- Easy CI/CD
- Containerized
- High availability
- Easier monitoring and rollback
Which CI/CD tool are you using?

I primarily use Jenkins.

Integrated Tools
- GitHub
- Maven
- SonarQube
- Docker
- Amazon ECR
- Terraform
- Kubernetes/EKS
- Slack
Pipeline Flow

GitHub Push → Jenkins Trigger → Maven Build + Test → SonarQube Scan → Docker Build → Push to ECR → Deploy to EKS → Smoke Test & Notify

Benefits
- Automated deployments
- Faster releases
- Consistent builds
- Easy rollback
- Audit trail
Tell me step by step, from basic to end level, how you deploy your Java application on an EC2 server?

Step 1: Developer pushes code

git push origin main

Step 2: Jenkins triggers

GitHub webhook starts the pipeline.

Step 3: Build

mvn clean package

Produces:

target/app.jar

Step 4: Run tests

mvn test

Step 5: Launch EC2
- Ubuntu 22.04
- Security Group: 22, 80, 8080
- IAM Role attached
Step 6: Connect

ssh -i key.pem ubuntu@PUBLIC_IP

Step 7: Install Java

sudo apt update sudo apt install openjdk-17-jdk -y

Verify:

java -version

Step 8: Copy JAR

scp -i key.pem target/app.jar ubuntu@PUBLIC_IP:/home/ubuntu

Step 9: Start application

nohup java -jar app.jar > app.log 2>&1 &

Step 10: Verify

curl http://localhost:8080/health

Step 11: Configure Nginx (optional)

Nginx → 80 → 8080.

Step 12: Monitor

tail -f app.log

CloudWatch for metrics and logs.

Step 13: Rollback

Keep previous JAR:

mv app.jar app-old.jar

Restart previous version if needed.
How do you connect to an EC2 instance?

Linux / macOS

ssh -i mykey.pem [email protected]

Amazon Linux:

ssh -i mykey.pem [email protected]

Windows
- PuTTY
- MobaXterm
- Windows Terminal
Prerequisites
- Running instance
- Public IP
- Port 22 open
- Correct key pair
Set permissions:

chmod 400 mykey.pem

Troubleshooting
- Check Security Group
- Verify public IP
- Check SSH service
- Verify key pair
In Terraform, how do you connect to ECR?

Terraform provisions ECR; Docker authenticates to it.

Create repository

resource "aws_ecr_repository" "app" { name = "java-app" }

Login

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

Build

docker build -t java-app .

Tag

docker tag java-app:latest ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com/java-app:latest

Push

docker push ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com/java-app:latest

Terraform authentication
- IAM Role (preferred)
- AWS profile
- Environment variables
In Kubernetes, what is RBAC?

RBAC = Role-Based Access Control

Controls who can do what on which resource.

Components

Component

Purpose

Role

Namespace permissions

ClusterRole

Cluster-wide permissions

RoleBinding

Assign Role

ClusterRoleBinding

Assign ClusterRole

Example

Developer can:
- Get Pods
- List Deployments
Cannot:
- Delete Nodes
- Read Secrets
Benefits
- Least privilege
- Better security
- Separation of duties
- Auditing
How do you monitor the logs for pods running in an EKS cluster?View logs

kubectl logs pod-name

Follow logs

kubectl logs -f pod-name

Previous container logs

kubectl logs pod-name --previous

Multi-container pod

kubectl logs pod-name -c container-name

Describe pod

kubectl describe pod pod-name

Shows events, probe failures, scheduling issues.

Centralized logging

I usually use:
- Fluent Bit
- CloudWatch Container Insights
- Prometheus + Grafana (metrics)
- ELK/OpenSearch for search and dashboards
Are you using volume mounts? Using volume mount services or without volume mounts?

Yes. It depends on whether the application is stateful or stateless.

Stateless apps
- Spring Boot APIs
- No persistent storage
- Usually without volume mounts
Stateful apps
- MySQL
- PostgreSQL
- Jenkins
- Elasticsearch
Use Persistent Volumes.

Common mounts

Type

Use

emptyDir

Temporary data

ConfigMap

Configuration files

Secret

Passwords/certs

PVC

Persistent storage

In EKS
- EBS for single-node persistence
- EFS for shared storage
What is PVC?

PVC = PersistentVolumeClaim

A request for storage by a Pod.

Flow

Pod → PVC → PV → EBS / EFS / NFS

Why use PVC?

Without PVC:
- Pod deleted → data lost
With PVC:
- Pod deleted → data persists
Example use cases
- Databases
- Jenkins home
- File uploads
- Shared application data
What is ADD in a Dockerfile? What is the difference between CMD and ENTRYPOINT?

ADD

Copies files into the image and can also extract local tar archives.

ADD app.jar /app/

Prefer COPY

For normal file copying:

COPY app.jar /app/

CMD

Default command.

CMD ["java","-jar","app.jar"]

Can be overridden.

ENTRYPOINT

Main executable.

ENTRYPOINT ["java","-jar","app.jar"]

Arguments are appended.

Difference

CMD

ENTRYPOINT

Default command

Main executable

Easily overridden

Usually fixed

Flexible containers

Dedicated containers

Best practice

ENTRYPOINT ["java","-jar"] CMD ["app.jar"]
Tell the command in Ubuntu: if a process is running, how do you kill that process?

Find the process

ps -ef | grep java

or

pgrep java

Graceful kill

kill PID

Example:

kill 12345

Sends SIGTERM (15).

Force kill

kill -9 PID

Example:

kill -9 12345

Sends SIGKILL (9).

Kill by name

pkill java

or

killall java

Verify

pgrep java

If nothing is returned, the process has stopped.

Production Best Practice

Always try:

kill PID (graceful)

If it does not stop

kill -9 PID (force)
Difference between Application Load Balancer (ALB) and Network Load Balancer (NLB)

Both ALB and NLB are AWS Elastic Load Balancers, but they work at different OSI layers and are used for different types of traffic.

Application Load Balancer (ALB)
- Works at Layer 7 (Application Layer).
- Handles HTTP, HTTPS, and WebSocket traffic.
- Can route requests based on:
  - URL path (/api, /admin)
  - Hostname (app.example.com)
  - Headers or query strings.
- Supports SSL termination.
- Commonly used for:
  - Web applications
  - REST APIs
  - Microservices
  - Kubernetes Ingress.
Example: Requests to /api go to API servers, and /admin goes to admin servers.

Network Load Balancer (NLB)
- Works at Layer 4 (Transport Layer).
- Handles TCP, UDP, and TLS traffic.
- Provides very high performance and ultra-low latency.
- Preserves the original client IP address.
- Commonly used for:
  - Gaming servers
  - IoT applications
  - Real-time applications
  - Databases
  - High-throughput services.
Key Difference
- ALB = intelligent application-level routing.
- NLB = high-performance transport-level routing.
Explain how Auto Scaling works in AWS

Auto Scaling automatically adds or removes EC2 instances based on traffic or resource usage.

Main Components
- Launch Template: Defines AMI, instance type, security groups, etc.
- Auto Scaling Group (ASG): Manages the EC2 instances.
- CloudWatch: Monitors metrics.
- Scaling Policies: Decide when to scale.
Example
- Minimum: 2 instances
- Desired: 2 instances
- Maximum: 10 instances
Scale Out

If CPU > 70% for 5 minutes:
- ASG launches 2 more instances.
- Load Balancer starts sending traffic to them.
Scale In

If CPU < 30% for 10 minutes:
- ASG terminates 1 instance.
Types of Scaling
- Target Tracking: Maintain a target metric (e.g., 50% CPU).
- Step Scaling: Add/remove instances in steps.
- Scheduled Scaling: Scale at fixed times.
- Predictive Scaling: Forecast future demand.
Benefits
- High availability
- Cost optimization
- Automatic recovery from failures
- Better performance during traffic spikes
Security Groups and Network ACLs – How do they differ?

Both control network traffic in a VPC.

Security Groups
- Attached to EC2 instances (ENI).
- Stateful: return traffic is automatically allowed.
- Supports allow rules only.
Example: Allow SSH (22) from office IP.

Network ACLs (NACLs)
- Attached to subnets.
- Stateless: must allow both inbound and outbound traffic.
- Supports allow and deny rules.
- Rules are processed in number order.
Difference
- Security Group = instance-level firewall.
- NACL = subnet-level firewall.
How do you secure an S3 bucket?

1. Block Public Access

Enable Block all public access unless the bucket must be public.

2. Use Bucket Policies

Grant only required permissions.

3. Enable Encryption
- SSE-S3
- SSE-KMS (preferred for production)
4. Enable Versioning

Protects against accidental deletion or overwrite.

5. Use IAM Roles

Avoid embedding access keys in applications.

6. Restrict Access

Use conditions such as:
- Source IP
- VPC Endpoint
- MFA
7. Enable Logging and Auditing
- S3 Access Logs
- CloudTrail Data Events
8. Use Least Privilege

Avoid permissions such as s3:* or wildcard access.
Difference between NAT Gateway and Internet Gateway

Internet Gateway (IGW)

Provides internet access for resources in public subnets.

Requirements:
- Public IP or Elastic IP
- Route to IGW
Traffic can flow inbound and outbound.

NAT Gateway

Allows resources in private subnets to access the internet outbound only.

Used for:
- Software updates
- Pulling Docker images
- Accessing AWS APIs
The internet cannot initiate connections back to private instances.

Difference
- IGW: public internet access.
- NAT Gateway: private instances can access the internet securely.
How does Route 53 perform failover routing?

Route 53 can automatically redirect traffic when a primary endpoint becomes unhealthy.

Components
- Primary record
- Secondary record
- Health check
Workflow
- User queries Route 53.
- Route 53 checks the health of the primary endpoint.
- If healthy → returns primary endpoint.
- If unhealthy → returns secondary endpoint.
Use Cases
- Multi-region disaster recovery
- Active-passive architecture
- Website failover
- API failover
Health Check Types
- HTTP
- HTTPS
- TCP
- CloudWatch-based
Benefit

Automatic failover without manual DNS changes.
EBS volume types and their use cases

gp3 (General Purpose SSD)
- Default choice
- Balanced price and performance
Use: Web servers, app servers, development, small databases.

gp2

Older generation of general-purpose SSD.

io2 (Provisioned IOPS SSD)
- Very high IOPS
- High durability
Use: Oracle, PostgreSQL, SAP, high-transaction databases.

io1

Older provisioned IOPS volume.

st1 (Throughput Optimized HDD)
- High throughput
- Lower IOPS
Use: Big data, log processing, streaming.

sc1 (Cold HDD)
- Lowest cost
- Infrequent access
Use: Backups and archives.

Interview Tip
- gp3 for most workloads
- io2 for mission-critical databases
- st1 for throughput-heavy workloads
- sc1 for archival storage
Purpose of IAM Roles compared to IAM Users

IAM User

Represents a person or application needing long-term access.

Includes:
- Username
- Password
- Access keys
Use: Administrators and developers.

IAM Role

Represents a set of permissions that can be assumed temporarily.

No permanent credentials are stored.

Use:
- EC2 accessing S3
- Lambda accessing DynamoDB
- EKS pods accessing AWS services
- Cross-account access
Example

Instead of storing AWS access keys on an EC2 instance, attach an IAM Role. AWS automatically provides temporary credentials.

Key Difference
- User: permanent identity.
- Role: temporary permissions.
Best Practice
- Humans → IAM Users (with MFA).
- Applications and AWS services → IAM Roles.
- Follow least privilege.
- Avoid long-term access keys whenever possible.
How do you copy data from one S3 bucket to another?

You can copy objects between S3 buckets using the AWS CLI, S3 Replication, or the AWS Console.

Using AWS CLI (most common)

Copy a single file:

aws s3 cp s3://source-bucket/file.txt s3://destination-bucket/

Copy an entire bucket recursively:

aws s3 cp s3://source-bucket s3://destination-bucket --recursive

Sync buckets (recommended for large migrations):

aws s3 sync s3://source-bucket s3://destination-bucket

Cross-account copy
- Grant read access on the source bucket.
- Grant write access on the destination bucket.
- Use an IAM role or profile with permissions to both buckets.
Production Best Practice

For continuous replication, use S3 Replication (CRR/SRR) instead of manual copy.
How do you securely provide external/public access to an S3 bucket?

Public access should be restricted and controlled.

Recommended Approach
- Keep the bucket private: Enable Block Public Access.
- Use CloudFront: Serve content through Amazon CloudFront.
- Use Origin Access Control (OAC): Allow only CloudFront to access the bucket.
- Use signed URLs/cookies: For temporary external access.
- Use least-privilege bucket policies: Avoid wildcard permissions.
Example: Temporary access

Generate a pre-signed URL:

aws s3 presign s3://my-bucket/report.pdf --expires-in 3600

This gives access for 1 hour.

Avoid
- Public bucket with Principal: "*"
- Public write access
- Long-lived access keys
How do you enable HTTPS/SSL for S3-hosted content?

S3 supports HTTPS automatically for object access.

For direct S3 access

Use:

https://my-bucket.s3.ap-south-1.amazonaws.com/index.html

For a custom domain (recommended)
- Create a CloudFront distribution.
- Set the S3 bucket as the origin.
- Request an SSL certificate in ACM.
- Attach the certificate to CloudFront.
- Create a Route 53 record (e.g., www.example.com).
Why CloudFront?
- HTTPS with custom domain
- Better performance (CDN)
- DDoS protection
- Access control
- Caching
How do you troubleshoot an inaccessible EC2 instance end-to-end?

I follow a structured approach from network to OS level.

Step 1: Verify Instance State
- Running?
- Status checks passed?
Step 2: Check Security Group

Ensure required ports are open:
- 22 (SSH)
- 80/443 (Web)
Step 3: Check Network ACL

Allow inbound and outbound traffic.

Step 4: Verify Route Table
- Public subnet → Internet Gateway
- Private subnet → NAT Gateway (for outbound)
Step 5: Check Public IP
- Public IP or Elastic IP attached?
Step 6: Test Connectivity

ping <ip> nc -zv <ip> 22

Step 7: Use EC2 Serial Console

If SSH is not working.

Step 8: Check SSH Service

sudo systemctl status ssh

Step 9: Check Disk Space

df -h

Step 10: Check Logs
- /var/log/auth.log
- /var/log/syslog
- journalctl -xe
Step 11: Recover if Needed
- Stop instance
- Detach root volume
- Attach to another instance
- Fix configuration
- Reattach
Common Root Causes
- Wrong security group
- Full disk
- SSH service stopped
- Corrupted network config
- Deleted route
- High CPU/memory
How can an EKS pod securely access an S3 bucket (IRSA)?

IRSA = IAM Roles for Service Accounts

This is the recommended secure method.

Architecture

EKS Pod

Kubernetes ServiceAccount

IAM Role (IRSA)

S3 Bucket

Steps

1. Enable OIDC provider

eksctl utils associate-iam-oidc-provider --cluster my-cluster --approve

2. Create IAM policy

Allow only required S3 actions.

3. Create IAM role with trust policy

Trust the EKS OIDC provider.

4. Create ServiceAccount

Annotate with IAM role ARN.

5. Use the ServiceAccount in the Pod

The pod receives temporary credentials automatically.

Benefits
- No access keys in pods
- Least privilege
- Automatic credential rotation
- Auditable via CloudTrail
What is a Pod Disruption Budget (PDB), and why is it important?

A PDB limits how many pods can be voluntarily disrupted at the same time.

Example

You have 5 replicas.

PDB:

minAvailable: 4

This means at least 4 pods must remain available.

Protects Against
- Node drain
- Cluster upgrades
- Autoscaler scale-down
- Maintenance operations
Why Important?

Without PDB:
- All pods could be evicted.
- Application outage may occur.
With PDB:
- Kubernetes evicts pods gradually.
- Availability is maintained.
Best Practice
- Stateless apps: minAvailable: 1 or percentage.
- Critical services: minAvailable: 80-90%.
How do you upgrade an EKS/Kubernetes cluster with minimal downtime?

I use a rolling, controlled upgrade strategy.

Step 1: Check Compatibility
- EKS version
- Kubernetes version
- Add-ons
- Ingress controller
- CSI drivers
Step 2: Upgrade Control Plane

AWS upgrades it with no worker node downtime.

Step 3: Upgrade Add-ons
- CoreDNS
- kube-proxy
- VPC CNI
Step 4: Create New Node Group

Use the newer AMI/version.

Step 5: Cordon Old Nodes

kubectl cordon <node>

Step 6: Drain Nodes

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

PDBs protect availability.

Step 7: Verify
- Pods running
- Readiness probes passing
- Application healthy
Step 8: Delete Old Node Group

After successful migration.

Zero-Downtime Requirements
- Multiple replicas
- Readiness probes
- PDBs
- Rolling updates
- Load balancer health checks
Which Dockerfile instructions do you use most often?

For Java/Spring Boot applications:

Frequently Used Instructions

FROM

Base image.

FROM eclipse-temurin:17-jre

WORKDIR

WORKDIR /app

COPY

COPY target/app.jar app.jar

EXPOSE

EXPOSE 8080

ENTRYPOINT

ENTRYPOINT ["java","-jar","app.jar"]

ENV

ENV SPRING_PROFILES_ACTIVE=prod

RUN

Install packages or create users.

RUN adduser --disabled-password appuser

USER

Run as non-root.

USER appuser

Best Practices
- Use small base images
- Use COPY instead of ADD
- Run as non-root
- Use multi-stage builds
- Keep layers minimal
What are Terraform Workspaces, and when should you use them?

Terraform Workspaces allow multiple state files from the same configuration.

Example
- dev
- test
- prod
Create

terraform workspace new dev

Switch

terraform workspace select prod

List

terraform workspace list

Use Cases
- Small environment differences
- Isolated state files
- Quick testing
Not Ideal For
- Large production differences
- Different architectures
- Different modules
Production Recommendation

Use:
- Separate directories/repos
- Separate backends
- Separate pipelines
Use workspaces mainly for simple environment isolation.
What does null mean in Terraform?

null means no value.

Example

variable "instance_type" { default = null }

Behavior
- Terraform treats it as unset.
- Optional arguments may be omitted.
Common Uses

Conditional arguments

key_name = var.create_key ? aws_key_pair.main.key_name : null

Optional variables

Dynamic blocks

Important

null is not the same as:
- Empty string ""
- Empty list []
- Empty map {}

How do you deploy applications on Amazon EKS? What are the advantages over Amazon ECS?

Answer

Amazon EKS (Elastic Kubernetes Service) is AWS’s managed Kubernetes service. AWS manages the Kubernetes control plane, while we manage worker nodes or use managed node groups/Fargate.

A typical EKS deployment looks like:

Developer → Git → CI/CD → Docker Image → ECR → EKS → Pods → Service → ALB/NLB

Step 1: Create the Docker image

For example:

docker build -t myapp:1.0 .

Tag it:

docker tag myapp:1.0 <account-id>.dkr.ecr.ap-south-1.amazonaws.com/myapp:1.0

Push it to ECR:

docker push <account-id>.dkr.ecr.ap-south-1.amazonaws.com/myapp:1.0

Step 2: Create Kubernetes deployment

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: <account-id>.dkr.ecr.ap-south-1.amazonaws.com/myapp:1.0
          ports:
            - containerPort: 8080

Apply it:

kubectl apply -f deployment.yaml

Step 3: Expose the application

For example, using a Kubernetes Service:

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

For external access, I would typically use the AWS Load Balancer Controller with an ALB for HTTP/HTTPS traffic.

Step 4: Verify

kubectl get pods
kubectl get svc
kubectl get deployment
kubectl describe pod <pod-name>

Advantages of EKS over ECS

EKS	ECS
Kubernetes-based	AWS-native container orchestrator
Kubernetes ecosystem	AWS ecosystem
Highly portable	More AWS-specific
Supports Helm, Operators, CRDs	Simpler orchestration
Large Kubernetes community	Easier learning curve
Can run multi-cloud/hybrid Kubernetes	Primarily AWS
Advanced scheduling capabilities	Simpler
More complex	Easier to operate

When would I choose EKS?

I would choose EKS when:

Organization already uses Kubernetes.
We need Helm and Kubernetes Operators.
We need portability between cloud providers.
We have complex microservices.
Teams already have Kubernetes expertise.

I would choose ECS when:

The application is AWS-specific.
We want simpler container orchestration.
The team doesn’t need Kubernetes features.
We want lower operational complexity.

What is the difference between Launch Templates and Launch Configurations?

Answer

Both are used by Auto Scaling Groups (ASGs) to define how EC2 instances should be launched.

However, Launch Templates are the modern and recommended option.

Launch Configuration

Launch Configuration is an older EC2 Auto Scaling configuration.

It defines things like:

AMI
Instance type
Security groups
Key pair
User data
IAM instance profile
EBS configuration

But it has limitations.

For example, Launch Configurations are immutable. If I need to change something, I generally create a new Launch Configuration.

Launch Template

Launch Templates provide more flexibility.

They support:

Versioning
Multiple instance types
Spot instances
On-Demand instances
T2/T3 Unlimited
Dedicated Hosts
Network interfaces
Capacity reservations
More advanced configuration options

Example:

aws ec2 create-launch-template \
  --launch-template-name my-template \
  --version-description "v1" \
  --launch-template-data file://template.json

Key difference

Feature	Launch Configuration	Launch Template
Versioning	❌	✅
Multiple versions	❌	✅
Mixed instance types	Limited	✅
Spot support	Limited	✅
Modern AWS features	Limited	✅
Recommended	❌ Legacy	✅

Interview answer

“I prefer Launch Templates because they support versioning and modern EC2 capabilities. For production Auto Scaling Groups, I can create a new template version, test it, and then update the ASG to use that version.”

ALB vs NLB – when would you use each?

Application Load Balancer — ALB

ALB operates at Layer 7 — Application Layer.

It understands protocols such as:

HTTP
HTTPS
WebSocket

It supports advanced routing.

For example:

example.com/api → API service

example.com/orders → Order service

example.com/users → User service

It can route based on:

Host
Path
HTTP headers
Query parameters

Network Load Balancer — NLB

NLB operates primarily at Layer 4 — Transport Layer.

It supports:

It is designed for:

Very high throughput
Low latency
Static IP requirements
Non-HTTP applications

Comparison

Feature	ALB	NLB
OSI layer	L7	L4
HTTP routing	✅	❌
Path-based routing	✅	❌
Host-based routing	✅	❌
TCP	Limited use	✅
UDP	❌	✅
Static IP	Not traditionally	✅
Web applications	Excellent	Possible
Ultra-low latency	Good	Excellent

Example

For an e-commerce website:

Internet
   ↓
ALB
   ↓
Frontend
Backend
API

For a TCP-based application:

Client
  ↓
NLB
  ↓
TCP Application

Interview answer

“I use ALB when I need HTTP/HTTPS-aware routing such as host-based or path-based routing. I use NLB when I need Layer 4 performance, TCP/UDP support, static IPs, or extremely high throughput and low latency.”

Explain Blue-Green and Canary Deployment

Blue-Green Deployment

There are two environments:

BLUE = Current Production
GREEN = New Version

Example:

              Load Balancer
                    |
             100% BLUE
                    |
             Application v1

Deploy v2 to Green:

              Load Balancer
               /          \
           BLUE          GREEN
            v1             v2

After testing:

              Load Balancer
                    |
             100% GREEN
                    |
             Application v2

If something goes wrong, switch traffic back to Blue.

Advantages

Fast rollback
Minimal downtime
Easy testing
Production-like validation

Canary Deployment

Instead of sending 100% traffic to the new version, we send a small percentage first.

For example:

95% → v1
5%  → v2

Monitor:

Error rate
Latency
CPU
Application metrics
Business metrics

If everything is good:

75% → v1
25% → v2

Then:

0% → v1
100% → v2

Difference

Blue-Green	Canary
Two complete environments	Gradual traffic
Fast traffic switch	Gradual rollout
Higher infrastructure cost	Lower additional capacity
Easy rollback	Gradual rollback
Good for major releases	Good for risk reduction

Interview implementation example

In Kubernetes I can implement rolling/canary strategies using tools such as:

AWS Load Balancer
Kubernetes
Argo Rollouts
Istio
Service mesh
CI/CD pipelines

How do you securely manage application secrets in AWS?

I never store secrets directly in Git repositories or Docker images.

For AWS applications, I would use:

AWS Secrets Manager

Suitable for:
- Database passwords
- API keys
- OAuth secrets
- Credentials
Example:
Application ↓ Secrets Manager ↓ Database password
Secrets Manager also supports secret rotation.

AWS Systems Manager Parameter Store

Useful for:
- Configuration
- Environment variables
- Secure strings
Example:
/db/username /db/password /app/api-url
Sensitive parameters can use:
SecureString
Encryption

Secrets should be encrypted using AWS KMS.

IAM

The application should have only the required permission.

For example:
{ "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:..." }
Not:
"Action": "*"
Kubernetes

For EKS, I can integrate Secrets Manager with Kubernetes using mechanisms such as the AWS Secrets and Configuration Provider (ASCP) and IAM Roles for Service Accounts / EKS Pod Identity.

Best practices
- Never commit secrets to Git.
- Don’t put secrets in Dockerfiles.
- Use least-privilege IAM.
- Encrypt secrets.
- Rotate credentials.
- Audit access using CloudTrail.
- Separate production and non-production secrets.

Component	Purpose
Role	Namespace permissions
ClusterRole	Cluster-wide permissions
RoleBinding	Assign Role
ClusterRoleBinding	Assign ClusterRole

Type	Use
emptyDir	Temporary data
ConfigMap	Configuration files
Secret	Passwords/certs
PVC	Persistent storage

AWS DevOps Interview Questions

AWS DevOps Interview Questions

How do you perform infrastructure changes in a production environment while ensuring minimal downtime?

Step 1: Understand the Change

Step 2: Create a Backup

Step 3: Test in Lower Environments

Step 4: Infrastructure as Code

Step 5: Blue-Green Deployment

Step 6: Rolling Deployment

Step 7: Canary Deployment

Step 8: Enable Monitoring

Step 9: Validate

Step 10: Rollback Plan

An application deployed on AWS suddenly becomes unavailable. How would you troubleshoot the issue step by step?

Step 1: Verify the Issue

Step 2: Check Route53

Step 3: Check Load Balancer

Step 4: Check EC2 Status

Step 5: Verify Security Groups

Step 6: Check Auto Scaling

Step 7: Review Application Logs

Step 8: Database

Step 9: Network

Step 10: Recent Changes

Step 11: Rollback

Step 12: RCA

How do you monitor AWS applications? Which tools, metrics, and alerts do you consider essential?

AWS Monitoring Tools

CloudWatch

CloudTrail

AWS X-Ray

Prometheus

Grafana

ELK Stack

Important Metrics

EC2

ALB

RDS

Kubernetes

Application

Essential Alerts

Describe your experience designing and maintaining CI/CD pipelines. How do you handle deployment failures?

Deployment Failure Handling

Explain your experience with Kubernetes or Amazon EKS. What challenges have you faced while managing workloads?

Challenges Faced

How do you securely manage secrets, credentials, and sensitive configuration in AWS and Kubernetes?

AWS

Kubernetes

Best Practices

Terraform reports infrastructure drift during terraform plan. How would you investigate and resolve it?

Investigation

Resolution

Prevention

Your Jenkins pipeline has suddenly started failing after months of successful deployments, even though no application code has changed. What would you investigate first?

Step-by-step

A Kubernetes Pod is stuck in CrashLoopBackOff. Walk me through your troubleshooting approach from start to finish.

Step 1: Check Pod Status

Step 2: Describe the Pod

Step 3: View Logs

Step 4: Verify Configuration

Step 5: Check Image

Step 6: Review Resource Usage

Step 8: Check Node Health

Step 9: Apply the Fix

Step 10: Verify

Describe a production incident you handled. What was the root cause, how did you resolve it, and what did you learn from the experience?

Situation

Investigation

Resolution

Root Cause

Lessons Learned

Which CI/CD tool are you using?

CI/CD Workflow

Jenkins Pipeline Stages

Benefits

Tell me step by step, from basic to end level, how you deploy your Java application on an EC2 server?

Step 1: Developer Writes Code

Step 2: Push Code to GitHub

Step 3: Jenkins Trigger

Step 4: Build the Application

Terraform reports infrastructure drift during `terraform plan`. How would you investigate and resolve it?

A Kubernetes Pod is stuck in `CrashLoopBackOff`. Walk me through your troubleshooting approach from start to finish.