AWS Interview Questions and Answers

Elastic Load Balancing has four types: Application (ALB), Network (NLB), Gateway (GWLB) and the legacy Classic (CLB). ALB and NLB are the two you use most.

• Use ALB for web apps and microservices that need path-based routing, redirects, or authentication.
• Use NLB for non-HTTP protocols, extreme throughput, or when clients must whitelist fixed IPs.
• GWLB fronts third-party firewalls and inspection appliances.

What they are checking: Whether you can pick the right load balancer for a workload instead of reciting definitions

Answer with the services you have really used, grouped by purpose, and say what problem each solved. Do not list everything on the console.

Structure that works:

• Compute: EC2 for long-running servers, Lambda for event-driven jobs, ECS/Fargate for containers.
• Storage: S3 for objects and backups, EBS for instance disks, EFS for shared files.
• Network: VPC with public and private subnets, ALB, Route 53, CloudFront.
• Data: RDS or DynamoDB for application data.
• Security and ops: IAM for access, CloudWatch for logs, metrics and alarms, Secrets Manager or SSM Parameter Store.
• Delivery: CloudFormation or Terraform, CodePipeline or GitHub Actions.

Sample line: "I ran a web app on EC2 behind an ALB in private subnets. I stored uploads in S3 and watched it with CloudWatch alarms. I used IAM roles instead of keys for access." Be ready for follow-up questions on any service you name.

What they are checking: Whether your hands-on experience is real and you can explain why you chose each service

Configure an S3 event notification on the bucket that targets the Lambda function. Two permissions must exist: S3 must be allowed to invoke the function, and the function must be allowed to read the bucket.

Steps:

• Add a resource-based policy on the function so s3.amazonaws.com can call lambda:InvokeFunction. Set SourceArn to the bucket ARN and SourceAccount to your account ID. This stops the confused deputy problem (another account tricking S3 into calling your function).
• In the bucket, add an event notification that points to the function (for example s3:ObjectCreated:*, with optional prefix and suffix filters).
• Give the function's execution role s3:GetObject on the bucket, plus the basic logging permissions.

aws lambda add-permission --function-name my-fn --statement-id s3-invoke \
  --action lambda:InvokeFunction --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::my-bucket --source-account 123456789012

Do not write output back to the same prefix that triggers the function, or it will loop. For size, start with 256 to 512 MB and check real use in CloudWatch. Then tune the memory, because CPU grows with it.

What they are checking: Whether you know both sides of the permission: S3 invoking Lambda and Lambda reading S3

Lambda runs code in response to events without managing servers, and you pay only for execution time. Use it for event-driven, short, spiky workloads; use EC2 for long-running or highly customized ones.

Key limits:

• Maximum run time: 15 minutes.
• Memory: 128 MB to 10,240 MB, with CPU scaling with memory.
• Package size: 50 MB zipped, 250 MB unzipped; container images up to 10 GB.
• Temporary storage /tmp: 512 MB by default, up to 10 GB.
• Concurrency: default 1,000 per region (can be increased).
• Cold starts add latency on first invocations.

Triggers: API Gateway, S3, SQS, SNS, EventBridge schedules, DynamoDB Streams, Kinesis and more.

Choose Lambda for APIs, file processing, cron jobs and glue logic. Choose EC2 (or containers) for constant heavy load, long jobs, special software or GPUs. Per-hour pricing is cheaper there.

What they are checking: Whether you know the main limits and can choose serverless versus servers sensibly

Use Amazon EFS. It is a managed NFS file system that many Linux EC2 instances can mount at the same time, across Availability Zones.

• EBS volumes attach to one instance at a time in one AZ (io2 Multi-Attach is a small exception). So they are not for sharing.
• EFS grows and shrinks automatically, and you mount it with the NFS client or the amazon-efs-utils helper.
• For Windows servers use Amazon FSx for Windows File Server.
• For objects shared through an API instead of a mounted path, use S3.

sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

Control access with security groups on the mount targets (allow TCP 2049) and IAM or POSIX permissions.

What they are checking: Whether you can tell block, file and object storage apart

SQS has two queue types: Standard and FIFO.

An IAM user is a long-term identity for one person or application, with a password and/or access keys. An IAM role is an identity with no long-term credentials that anyone allowed can assume to get temporary credentials. A trust policy is the resource policy on a role that says who may assume it.

EC2 instance types are grouped into families by the resource they favour. The name encodes it, for example m7g.large: family m, generation 7, g = Graviton, size large.

EC2 has four main ways to pay, and a good setup mixes them.

S3 classes trade storage price against retrieval cost, speed and minimum storage time. All of them offer 11 nines of durability.

CloudWatch is AWS's monitoring service. It collects metrics, stores logs, raises alarms and drives dashboards.

Choose RDS when the data is relational and needs joins, transactions and SQL. Choose DynamoDB when you need huge scale with simple key-based access and little operations work.

SQS is a queue where consumers pull messages, and SNS is a topic that pushes each message to all its subscribers.

EC2 (Elastic Compute Cloud) provides resizable virtual servers. You choose an AMI, an instance type, storage, a VPC subnet and a security group. You pay for what you run.

Identity-based policies attach to an IAM user, group or role and say what that identity can do. Resource-based policies attach to a resource (S3 bucket, SQS queue, KMS key, Lambda function, role trust policy). They say who can access that resource.

An Amazon Machine Image (AMI) is a template used to launch EC2 instances. It contains the root volume snapshot (operating system, installed software, configuration), launch permissions, and block device mappings.

User data is a script or cloud-init setting passed to an instance when it starts. It sets up the instance automatically, for example installing packages, pulling code, or joining a cluster.

An EBS snapshot is a point-in-time, incremental backup of an EBS volume stored in S3-managed storage. After the first full copy, only changed blocks are saved. A snapshot can create a new volume in any AZ of the region.

An S3 bucket policy is a JSON resource-based policy attached to a bucket. It controls who can do what on the bucket and its objects.

Elements: Effect, Principal, Action, Resource (bucket ARN and bucket/* for objects), and optional Condition.

In Route 53 you create a hosted zone for your domain. Then you add records that map names to resources.

Use S3 Object Lock, which enforces write-once-read-many (WORM) retention. It needs versioning, and it is best turned on when you create the bucket.

Vertical scaling (scale up) means giving one server more resources, such as a bigger EC2 instance type. Horizontal scaling (scale out) means adding more servers and spreading the load across them.

Elastic Beanstalk is a platform-as-a-service on AWS: you upload your application code (Java, .NET, Node.js, Python, PHP, Ruby, Go, or Docker). It sets up and manages the infrastructure for you.

CloudFront is AWS's content delivery network (CDN). It caches content at edge locations close to users. Responses are faster, and the origin has less load.

A routing policy decides which answer Route 53 returns for a name.

The load balancer spreads requests across healthy instances. The Auto Scaling Group (ASG) changes how many instances run, based on metrics.

Flow when the system slows:

• Load rises, a CloudWatch metric such as average CPU or RequestCountPerTarget crosses the target.
• A scaling policy (target tracking or step) raises desired capacity.
• The ASG launches instances from the launch template in several AZs.
• Once an instance passes the target group health check, the ALB starts sending it traffic.
• When load falls, the ASG scales in; connection draining (deregistration delay) lets in-flight requests finish.

Points interviewers like:

• Turn on ELB health checks on the ASG, so unhealthy instances are replaced. EC2 status checks alone are not enough.
• Set a health check grace period longer than app start time.
• Keep instances stateless (sessions in Redis or DynamoDB, files in S3 or EFS).
• If the database is the bottleneck, scaling the web tier will not help; use read replicas, caching or connection pooling.

What they are checking: Whether you understand the scale-out loop end to end, including health checks and statelessness

Use an S3 Lifecycle configuration with an expiration rule on the bucket or on a prefix. S3 deletes eligible objects in the background, free of charge.

• Filter by prefix or tag, for example logs/.
• Set Expiration to the number of days after creation.
• For versioned buckets, also expire old versions and clean up expired delete markers. Otherwise old versions keep costing money.
• Add AbortIncompleteMultipartUpload to remove stuck uploads.
• To control growth rather than delete, transition to cheaper classes first (Standard-IA, Glacier) and expire later; use Intelligent-Tiering when access is unpredictable.

{"Rules":[{"ID":"expire-logs","Status":"Enabled",
 "Filter":{"Prefix":"logs/"},
 "Expiration":{"Days":10},
 "NoncurrentVersionExpiration":{"NoncurrentDays":1},
 "AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}]}

aws s3api put-bucket-lifecycle-configuration --bucket my-logs --lifecycle-configuration file://lifecycle.json

Monitor size with S3 Storage Lens or CloudWatch BucketSizeBytes, and set a budget alert.

What they are checking: Whether you know lifecycle rules, including versioning and multipart cleanup

Run a Transfer Family SFTP server with service-managed users. Script user creation with a Terraform module or the CLI. Each client then gets its own separate home directory.

A cold start is the extra delay when Lambda must create a new execution environment. It downloads the code, starts the runtime, and runs your initialization code before handling the request. Warm invocations reuse an existing environment and skip this.

Set the timeouts based on how long your consumer needs. Send messages that keep failing to a dead-letter queue.

Use an ALB for the public entry point. Use service discovery inside the VPC for private traffic between services.

Use AWS Organizations to group accounts into organizational units (OUs). Apply guardrails in one place, and use IAM Identity Center for sign-in. Common accounts are management, security or log archive, shared services, and separate dev, staging and production accounts.

Use VPC endpoints so resources in private subnets reach AWS services over the AWS network. You need no NAT gateway and no public internet.

Choose ECS when you want simple container management that fits AWS well. Choose EKS when you need Kubernetes itself.

ECS:

• No control plane fee, easy to learn, task definitions and services.
• Deep integration with IAM task roles, ALB, CloudWatch and Fargate.
• AWS-specific, so less portable.

Amplify Hosting supports Next.js SSR natively: it builds the app and runs server-rendered routes on managed compute. It serves static files (_next/static, public files) through its own CloudFront distribution backed by S3. So you usually do not connect these yourself.

Use the ECS service's rolling update deployment controller together with the deployment circuit breaker and health checks.

A dead-letter queue (DLQ) is a separate queue for messages that the main queue could not process after a set number of tries. They then do not block the queue or loop forever.

Graviton instances (such as m7g, c7g, t4g) usually give better value for money. But the software must run on the arm64 architecture.

Layer controls so only intended traffic reaches the load balancer and the targets behind it.

Combine controls that stop bad settings before they happen with controls that find and fix them later.

Start by measuring (Cost Explorer, tags, Budgets), then act on the biggest items.

No. A React single-page app compiles to static files, so EKS is heavy overkill. You pay about $0.10 per hour for the control plane plus worker nodes. You must also run the cluster.

With Fargate, AWS runs the compute for you (serverless containers); with the EC2 launch type you manage the instances in the cluster.

Keep secrets out of images and task definitions as plain text. Use IAM roles so no keys are stored.

Place an ALB in public subnets, tasks in private subnets, and register tasks through IP-type target groups.

Run them across Availability Zones, keep them private, encrypt them, and monitor failover.

They go through a NAT gateway placed in a public subnet. The private subnet route table sends 0.0.0.0/0 to the NAT gateway. The NAT gateway has an Elastic IP. It sits in a subnet whose route table points to the internet gateway.

Security groups are stateful firewalls attached to network interfaces (instances, load balancers); network ACLs (NACLs) are stateless firewalls attached to subnets.

Each service invokes Lambda in a different way, which affects retries and scaling.

Lambda behavior depends on how it is invoked, so plan timeouts, retries and idempotency together.

Recursive loop detection is a Lambda safeguard. It stops a function from calling itself again and again through AWS services. An example is a function triggered by an SQS queue or SNS topic that writes back to the same queue or topic. After about 16 recursive calls in a chain, Lambda blocks the next one. It sends a notice through the Health Dashboard and email.

Cognito provides authentication, authorization and user management for web and mobile apps.

Amazon ECS (Elastic Container Service) is the AWS service that manages containers. It runs Docker containers as tasks and services on Fargate or EC2.

EBS has SSD volumes for most workloads and HDD volumes for throughput-heavy, infrequent access.

It is AWS's set of best practices for reviewing a workload, organised into six pillars:

Keep the bucket private and put CloudFront in front of it. Use Origin Access Control (OAC) so only CloudFront can read the objects.

Steps:

• Create the bucket with Block Public Access on. Do not turn on S3 static website hosting, since that endpoint is public only.
• Create a CloudFront distribution with the bucket as origin and attach an OAC.
• Add a bucket policy that allows cloudfront.amazonaws.com to s3:GetObject, and limit it with AWS:SourceArn to your distribution.
• Attach an ACM certificate (issued in us-east-1) and redirect HTTP to HTTPS.
• Point Route 53 at the distribution with an alias record.
• You can also add AWS WAF and security headers (through a response headers policy). Use CloudFront signed URLs or cookies for private content.

If one site has public and private content, serve public paths openly. Protect the private path pattern with a trusted key group, so only signed requests work.

Deploy with aws s3 sync ./dist s3://my-site-bucket --delete and invalidate the cache with aws cloudfront create-invalidation --distribution-id <id> --paths "/*".

What they are checking: Whether you know the private bucket plus OAC pattern rather than a public bucket

CPU-threshold target tracking reacts only after the load has arrived. New instances need minutes to start and warm up. So a sharp spike can overload the fleet first.

Ways to cope:

• Scheduled scaling: raise min and desired capacity before known peaks (sale, campaign, office hours).
• Predictive scaling: learns daily and weekly patterns and scales ahead.
• Better metrics: scale on ALB RequestCountPerTarget, queue depth, or latency rather than CPU alone.
• Lower the target (for example 50 percent CPU) to keep spare room. Use shorter cooldowns or instance warm-up settings.
• Warm pools or pre-baked AMIs so new instances join quickly.
• Absorb bursts: CloudFront caching, a queue between tiers, and rate limiting at the edge.
• Keep min capacity across at least two AZs so one AZ failure is also covered.

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg --scheduled-action-name morning \
  --recurrence "0 8 * * *" --min-size 4 --desired-capacity 6

What they are checking: Whether you know scaling is reactive and can combine scheduled, predictive and metric choices

Pick the simplest service that meets the need, and add pieces only as complexity grows.

Simple static site:

• Files in S3, served through CloudFront, DNS in Route 53, HTTPS from ACM. No servers to manage and very cheap.

Simple dynamic site:

• One EC2 instance (or Elastic Beanstalk / Lightsail) with a security group, an Elastic IP, and backups.

Complex application:

• VPC with public and private subnets across two AZs.
• ALB in public subnets, application on EC2 Auto Scaling or ECS/Fargate in private subnets.
• RDS or DynamoDB for data, ElastiCache for caching, S3 for uploads.
• CloudWatch for monitoring, IAM roles, Secrets Manager, and CI/CD with CodePipeline or GitHub Actions.
• Infrastructure defined in Terraform or CloudFormation.

You pay for it in cost and work, and you gain availability, scale and security.

What they are checking: Whether you scale the architecture to the problem rather than over-engineering

Use S3 as the landing zone. Send an event to SQS for each new file, and let Lambda process the queue.

Control how fast the queue drives the function. This stops it from using up account concurrency or overloading other systems.

Keep the web, application and data tiers in different subnets across at least two AZs. Expose only the front door.

Put API Gateway in front, one or a few Lambda functions behind it, and DynamoDB for storage. There are no servers to patch, and cost follows usage.

Scale on the backlog per worker, not on raw CPU, so capacity follows the work waiting.

Plan the rollback before the change, because RDS cannot undo a bad write in place.

Build the new version into an AMI. Create a new launch template version that points to it. Then replace instances slowly.

Connect the two VPCs privately, then allow the traffic with routes and security groups.

Start with the address plan, then subnets, routing and connectivity.

Use Route 53 routing policies, or AWS Global Accelerator, in front of identical stacks in each region.

Define the configuration as an image plus a template, and copy or rebuild both in each region.

Staging should look like production in design, but not in size or uptime. This cuts cost without losing test value.

An S3 access decision combines the caller's IAM policy, the bucket policy, and several guardrails. Work through each.

Find what changed with Cost Explorer, fix it, then add guardrails.