AWS Interview Questions and Answers
32 hand-picked AWS interview questions with
detailed answers. Open the interactive version above to search, filter
by difficulty, run code, bookmark questions and track your progress.
What is cloud computing, and what's the difference between IaaS, PaaS, and SaaS?
Cloud computing = on-demand delivery of compute, storage, databases and other IT resources over the internet, billed pay-as-you-go, with no hardware to own or manage.
- IaaS (Infrastructure) — you rent raw building blocks and manage the OS upward (e.g. EC2, VPC).
- PaaS (Platform) — you just deploy code; the provider runs the platform (e.g. Elastic Beanstalk, RDS).
- SaaS (Software) — ready-to-use applications (e.g. Gmail, Salesforce).
AWS spans mostly IaaS and PaaS. Benefits: elasticity, no upfront capex, global reach, pay for what you use.
IaaS: EC2, VPC (you manage OS, runtime, app)
PaaS: Beanstalk, RDS (you manage app + data)
SaaS: Gmail, Slack (you just use it)
What is AWS, and what are its main service categories?
AWS (Amazon Web Services) is Amazon's cloud platform — 200+ services delivered on a global, pay-as-you-go basis. The categories you'll actually name in an interview:
- Compute — EC2, Lambda, ECS/EKS, Elastic Beanstalk.
- Storage — S3, EBS, EFS.
- Database — RDS, Aurora, DynamoDB.
- Networking & Content Delivery — VPC, Route 53, CloudFront, ELB.
- Security & Identity — IAM, KMS.
- Management & Monitoring — CloudWatch, CloudTrail, CloudFormation.
Compute : EC2, Lambda, ECS/EKS
Storage : S3, EBS, EFS
Database: RDS, DynamoDB
Network : VPC, Route 53, CloudFront, ELB
Security: IAM, KMS
Ops : CloudWatch, CloudFormation
What are Regions, Availability Zones, and Edge Locations?
Region — a geographic area (e.g. ap-south-1 = Mumbai) containing multiple isolated Availability Zones. You pick a region for latency, cost, and data-residency/compliance.
Availability Zone (AZ) — one or more physically separate data centers within a region, with independent power/network. Spreading resources across AZs gives high availability — one AZ can fail and your app stays up.
Edge Location — a CloudFront CDN point-of-presence, far more numerous than regions, used to cache content close to users for low latency.
Region (Mumbai ap-south-1)
|- AZ ap-south-1a (data center)
|- AZ ap-south-1b
'- AZ ap-south-1c
Edge locations = 100s of CDN PoPs worldwide
Explain the AWS Shared Responsibility Model.
Security is split between AWS and you:
- AWS — security OF the cloud: physical data centers, hardware, the global network, and the software of managed services.
- You — security IN the cloud: your data, IAM users/permissions, OS patching on EC2, security-group rules, and encryption configuration.
The line shifts with the service: on EC2 you patch the OS; on managed/serverless services like S3, RDS, Lambda AWS handles more, but data and access control are always yours.
AWS : hardware, facilities, managed-service software
YOU : data, IAM, OS patching (EC2), SG rules, encryption
Managed (S3/Lambda) -> AWS owns more; data/access still yours
What is IAM (users, groups, roles, policies)?
IAM (Identity and Access Management) controls who can do what in your account.
- Users — identities for people or apps (long-term credentials).
- Groups — a collection of users that share the same policies.
- Roles — identities that are assumed temporarily and hand out short-lived credentials (no stored keys) — used by EC2/Lambda and for cross-account access.
- Policies — JSON documents that allow/deny specific actions on specific resources.
Best practices: least privilege, don't use the root account for daily work, enable MFA.
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}
IAM role vs user — and why do EC2/Lambda use roles instead of keys?
A user is a permanent identity with long-lived access keys. Embedding those keys in application code or on an instance is a security risk (leaks, rotation pain).
A role is an assumable identity that vends temporary, auto-rotated credentials. You attach a role to an EC2 instance or Lambda function, and the service automatically receives credentials (via the instance metadata endpoint / execution role) — no hardcoded keys anywhere. Roles are also how you grant cross-account and federated access.
# BAD: access keys in code / on the box
# GOOD: attach an IAM role to EC2/Lambda
# -> SDK picks up temp creds automatically, no keys stored
What is EC2, and what do you need to launch an instance?
EC2 (Elastic Compute Cloud) gives you resizable virtual servers in the cloud. To launch one you choose:
- AMI — the machine image (OS + preinstalled software).
- Instance type — family + size (e.g.
t3.micro) balancing CPU / memory / network. - Storage — EBS volumes (virtual disks).
- Security group — the instance firewall.
- Key pair — for SSH/RDP access.
A user-data script can run at first boot to install/configure software. You pay per second/hour the instance runs.
aws ec2 run-instances \
--image-id ami-xxxx --instance-type t3.micro \
--key-name my-key --security-group-ids sg-xxxx
What are the EC2 pricing models?
- On-Demand — pay per use, no commitment. Best for short/spiky/unpredictable workloads and dev.
- Reserved Instances / Savings Plans — commit to 1 or 3 years for a big discount (up to ~72%). Best for steady, always-on workloads.
- Spot Instances — AWS spare capacity at up to ~90% off, but can be reclaimed with 2 minutes' notice. Best for fault-tolerant, interruptible batch/CI work.
- Dedicated Hosts — physical servers for licensing/compliance needs.
On-Demand : no commit, spiky/dev
Reserved/SP : 1-3yr commit, steady, big discount
Spot : ~90% off, reclaimable, batch/CI
Dedicated : compliance/licensing
What is Amazon S3?
S3 (Simple Storage Service) is object storage: you store files (— "objects") inside "buckets", each identified by a key. It's virtually unlimited, highly available, and offers 11 nines (99.999999999%) durability by replicating across devices/AZs.
Access is over an HTTP API/URL — it is not a mountable filesystem; the key namespace is flat (folders are just key prefixes). Common uses: static assets, backups, data lakes, log storage, and static website hosting.
aws s3 cp report.pdf s3://my-bucket/reports/report.pdf
aws s3 ls s3://my-bucket/reports/
What are the S3 storage classes?
- S3 Standard — hot, frequently accessed data.
- Intelligent-Tiering — auto-moves objects between tiers based on access; best when the pattern is unknown.
- Standard-IA / One Zone-IA — infrequent access, cheaper storage but a retrieval fee (One Zone = single AZ, less durable).
- Glacier Instant / Flexible Retrieval / Deep Archive — archival, cheapest storage, with retrieval times from ms to hours.
Lifecycle policies transition objects automatically (e.g. Standard → IA → Glacier) as they age.
Standard -> frequent
Intelligent-Tier -> unknown pattern (auto)
Standard-IA -> infrequent (retrieval fee)
Glacier/Deep Arch -> archive (cheapest, slow retrieval)
EBS vs EFS vs S3 (block vs file vs object)?
- EBS (block) — a virtual hard disk attached to a single EC2 instance (in one AZ). Use for OS disks and databases.
- EFS (file) — a managed NFS filesystem that many Linux EC2s can mount at once; elastic, POSIX. Use for shared file access.
- S3 (object) — unlimited storage accessed over HTTP; not mounted as a normal disk. Use for assets, backups, data lakes.
EBS -> disk for ONE EC2 (OS, DB)
EFS -> shared NFS for MANY EC2 (Linux)
S3 -> object storage over HTTP (assets, backups)
What is a VPC, and its core building blocks?
A VPC (Virtual Private Cloud) is your own isolated virtual network in AWS. Building blocks:
- Subnets — IP ranges within an AZ; public (route to the internet) or private (no direct inbound).
- Route tables — decide where traffic goes.
- Internet Gateway (IGW) — gives public subnets internet access.
- NAT Gateway — lets private-subnet resources reach the internet outbound without being reachable inbound.
- Security Groups & NACLs — instance- and subnet-level firewalls.
VPC
|- Public subnet -> Internet Gateway (web tier)
'- Private subnet -> NAT Gateway (app/DB tier, outbound only)
Security Group vs Network ACL (NACL)?
| Security Group | NACL |
|---|
| Level | Instance / ENI | Subnet |
| State | Stateful (return traffic auto-allowed) | Stateless (must allow return explicitly) |
| Rules | Allow only | Allow and Deny |
| Evaluation | All rules | In order by rule number |
Security Groups are your primary, everyday control; NACLs are a coarse subnet-level backstop (e.g. block a bad IP range).
SG : instance, stateful, ALLOW only
NACL : subnet, stateless, ALLOW + DENY (numbered)
What is Amazon RDS?
RDS (Relational Database Service) is managed SQL databases — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Aurora (AWS's high-performance MySQL/Postgres-compatible engine). AWS handles the undifferentiated heavy lifting: provisioning, patching, automated backups, replication, and failover.
You choose the engine and instance size and connect your app — you don't SSH into the box or manage the OS. Contrast with running a database yourself on EC2, where all of that is your job.
Engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora
AWS manages: patching, backups, replication, failover
RDS Multi-AZ vs Read Replica?
Multi-AZ = a synchronous standby copy in another AZ purely for high availability. On failure, RDS automatically fails over to the standby. It is not used to serve reads.
Read Replica = an asynchronous copy used to offload read traffic (read scaling); can be in another region. It lags slightly and isn't an automatic failover target (though it can be promoted).
They solve different problems and are often combined: Multi-AZ for resilience, Read Replicas for read throughput.
Multi-AZ : sync standby, auto-failover -> AVAILABILITY
Read Replica : async copy, serves reads -> READ SCALING
What is DynamoDB, and when do you use it?
DynamoDB is a fully managed, serverless NoSQL key-value / document database with single-digit-millisecond latency at any scale. Data lives in tables of items; a partition key (optionally plus a sort key) determines where each item is stored.
Use it for high-throughput, predictable-access-pattern workloads: sessions, shopping carts, user profiles, IoT, leaderboards. It has no joins or ad-hoc queries — you design the table around your access patterns. For rich relational querying, use RDS instead.
Table: Orders
PartitionKey = userId (where the item lives)
SortKey = orderId (ordering within a user)
-> query 'all orders for user X' is fast & cheap
What are the Elastic Load Balancer types?
- ALB (Application, Layer 7) — HTTP/HTTPS, path- and host-based routing, ideal for microservices and containers.
- NLB (Network, Layer 4) — TCP/UDP, ultra-low latency, static IP, handles millions of requests/sec.
- GWLB (Gateway) — fronts third-party virtual appliances (firewalls/IDS).
- CLB (Classic) — legacy, avoid for new work.
An ELB spreads incoming traffic across healthy targets in multiple AZs, doing health checks and enabling zero-downtime scaling.
ALB -> Layer 7 HTTP/HTTPS, path/host routing (microservices)
NLB -> Layer 4 TCP/UDP, ultra-low latency, static IP
GWLB -> appliances; CLB -> legacy
What is an Auto Scaling Group (ASG)?
An Auto Scaling Group automatically adds or removes EC2 instances to match demand. You define min / desired / max capacity and scaling triggers — a target metric (e.g. CPU 60%), a schedule, or health checks.
Benefits: elasticity (scale out on load, in when idle → cost savings) and self-healing (an unhealthy instance is terminated and replaced). Paired with an ELB, the group keeps healthy capacity matched to traffic automatically.
ASG: min=2, desired=2, max=10
CPU > 60% for 5m -> add instances
CPU < 30% -> remove
unhealthy -> terminate + replace
What is AWS Lambda / serverless?
Lambda runs your code without provisioning servers. You upload a function; it executes in response to events (API Gateway request, S3 upload, SQS message, schedule), scales automatically with load, and you pay only per invocation and execution time.
Traits to mention: stateless, short-lived (max 15 min), possible cold starts. Ideal for event-driven glue, lightweight APIs, and scheduled jobs. "Serverless" means no servers for you to manage — not literally no servers.
S3 upload / API call / SQS msg / cron
|
v (event triggers)
Lambda function -> scales automatically, pay per run
What is API Gateway?
Amazon API Gateway is a managed service to create, publish, secure, and monitor REST, HTTP, and WebSocket APIs. It acts as the front door to your backend (commonly Lambda, but also EC2/HTTP services), handling routing, throttling / rate limiting, authentication (IAM, Cognito, JWT/authorizers), request/response mapping, and caching.
The classic serverless pattern is API Gateway → Lambda → DynamoDB: no servers, scales automatically.
Client -> API Gateway (auth, throttle, route)
-> Lambda -> DynamoDB
SQS vs SNS?
SQS (Simple Queue Service) is a queue: point-to-point, pull-based. Producers put messages on the queue; consumers poll and process them. It decouples components and buffers load so a spike doesn't overwhelm downstream.
SNS (Simple Notification Service) is pub/sub: push-based fan-out. One published message is delivered to many subscribers (Lambda, SQS, email, HTTP).
A common pattern is SNS → multiple SQS queues (fan-out): one event, several independent consumers.
SQS: Producer -> [queue] -> Consumer (pull, buffer)
SNS: Publisher -> [topic] -> many subscribers (push, fan-out)
What is CloudFront?
CloudFront is AWS's Content Delivery Network (CDN). It caches content at edge locations close to users for low latency, offloads your origin (S3, ALB, or EC2), and terminates HTTPS. It integrates with Shield/WAF for DDoS and application-layer protection, supports signed URLs for private content, and can run lightweight logic at the edge (CloudFront Functions / Lambda@Edge).
User -> nearest Edge Location (cached?)
hit -> serve instantly
miss -> fetch from Origin (S3/ALB) + cache
What is Route 53?
Route 53 is AWS's managed DNS and domain-registration service (named after DNS port 53). It resolves domain names to your resources and supports routing policies — simple, weighted, latency-based, failover, and geolocation — combined with health checks.
That makes it the tool for domain routing, blue/green and weighted rollouts, and multi-region failover / disaster recovery.
Policies: simple | weighted | latency | failover | geolocation
+ health checks -> route away from unhealthy endpoints
CloudWatch vs CloudTrail?
CloudWatch = monitoring/observability: metrics, logs, alarms, and dashboards. It answers "is my system healthy / performing?" — CPU, latency, error rates, custom metrics, and alarms that trigger actions.
CloudTrail = auditing: it records API calls — who did what, when, from where — for governance, compliance, and security forensics. It answers "who did this?"
CloudWatch: metrics, logs, alarms -> 'is it healthy?'
CloudTrail: API call history -> 'who did this?'
EC2 vs Elastic Beanstalk vs ECS/EKS vs Lambda — how do you choose?
A spectrum from most control/most ops to least:
- EC2 — raw virtual machines; full control, you manage everything.
- Elastic Beanstalk — PaaS; you push code, AWS provisions and scales the EC2 under it.
- ECS / EKS — run containers; ECS is AWS-native orchestration, EKS is managed Kubernetes (often on Fargate = serverless containers).
- Lambda — serverless functions; no servers, event-driven, auto-scaling.
Rule of thumb: the less infrastructure you want to manage, the further right you go.
EC2 : full control, manage all
Beanstalk : push code, AWS runs EC2
ECS/EKS : containers (ECS native / EKS k8s, Fargate=serverless)
Lambda : functions, no servers
What is CloudFormation / Infrastructure as Code?
Infrastructure as Code (IaC) means defining your AWS resources declaratively in a template instead of clicking in the console. CloudFormation reads a YAML/JSON template and provisions and manages those resources together as a stack — repeatably and version-controlled.
Benefits: reproducible environments (dev/stage/prod identical), easy teardown, change tracking, and drift detection. Alternatives: Terraform (multi-cloud) and AWS CDK (define infra in a real programming language).
template.yaml (YAML/JSON)
-> CloudFormation -> Stack (all resources, managed together)
Benefits: reproducible, versioned, easy teardown, drift detection
A voting site expects millions of hits right after a show. How do you architect it to absorb the write spike?
Decouple the write spike with a queue. Front the site with CloudFront + an Elastic Load Balancer over an auto-scaled fleet of web servers. Instead of writing each vote straight to the database, the web servers drop votes onto an SQS queue (using IAM roles on the EC2 instances). A separate pool of application servers drains the queue at a steady rate and writes into DynamoDB.
Why the queue: it buffers a massive, bursty write load so the datastore isn't overwhelmed, and it smooths spikes into a sustainable throughput. Writing votes directly to an RDS/DynamoDB instance under a flash crowd risks throttling and lost votes.
Users -> CloudFront -> ELB -> Auto-Scaled Web Servers
| (enqueue vote, IAM role)
v
SQS queue
| (drain steadily)
v
App Servers -> DynamoDB
A Lambda + API Gateway API has intermittent failures. What's the first thing to improve reliability?
Enable detailed logging and monitoring with CloudWatch (logs, metrics, alarms) — and ideally X-Ray tracing. You can't fix intermittent failures you can't see; observability tells you whether it's Lambda timeouts, cold starts, throttling, downstream errors, or 5xx from the integration.
The distractors treat symptoms without diagnosis: client-side retries can mask (or amplify) the issue, ElastiCache addresses latency not reliability, and Step Functions is orchestration, not a fix for an unknown fault. Observe first, then target the real cause (add retries/DLQ, raise timeout/memory, fix the downstream).
# Enable Lambda tracing + structured logs, alarm on errors
aws lambda update-function-configuration \
--function-name api --tracing-config Mode=Active
# CloudWatch alarm on Errors metric, DLQ for async failures
A DynamoDB table with fixed capacity throttles during peak load. How do you fix it?
Enable Auto Scaling on the DynamoDB table (or switch it to on-demand capacity). Auto Scaling raises provisioned read/write capacity units as traffic climbs and lowers them when it falls, so bursts stop hitting the throttling ceiling.
The wrong options misunderstand DynamoDB: you don't put an ELB in front of it (it's a managed API, not EC2), it can't join an EC2 Auto Scaling Group, and dropping an SQS queue in front only defers writes without raising table throughput. Scaling the table's capacity is the direct fix.
# Auto Scaling on write capacity, or just use on-demand:
aws dynamodb update-table --table-name votes \
--billing-mode PAY_PER_REQUEST # on-demand, no capacity planning
How should you structure CloudFormation templates when requirements come from many teams (networking, security, app)?
Create separate logical templates per concern — networking, security, application, etc. — and compose them as nested stacks (a parent stack referencing child templates), or share values via cross-stack Exports/ImportValue.
This lets each team own and iterate on its template independently, keeps stacks under CloudFormation's resource limits, and maximises reuse. One giant monolithic template becomes unmaintainable and couples unrelated changes; Elastic Beanstalk / OpsWorks are different provisioning tools, not the way to organise CloudFormation.
# parent.yaml
Resources:
NetworkStack:
Type: AWS::CloudFormation::Stack
Properties: { TemplateURL: https://s3/.../network.yaml }
SecurityStack:
Type: AWS::CloudFormation::Stack
Properties: { TemplateURL: https://s3/.../security.yaml }
Windows EC2 instances joined to AWS Managed Active Directory need shared storage controlled by that AD. Which service?
Amazon FSx for Windows File Server. It provides fully managed SMB file shares with native Windows/NTFS semantics and integrates directly with AWS Managed Microsoft AD, so you control access with AD users/groups and ACLs.
Why not the others: FSx for Lustre targets high-performance computing, not Windows file shares; EFS is NFS for Linux; S3 is object storage (not a mounted file share, and 'AD Connector' doesn't turn it into one). For AD-controlled Windows shared storage, FSx for Windows File Server is the fit.
# FSx for Windows File Server: managed SMB, joined to AWS Managed Microsoft AD
# -> AD users/groups + NTFS ACLs control access to the shares
On-prem storage is full; you want a quick AWS extension with LOW latency for frequently accessed data. What do you use?
AWS Storage Gateway — Cached Volumes. Your primary data lives in S3, while the gateway keeps a local cache of frequently accessed data on-prem, giving low-latency reads for hot data while effectively extending capacity to the cloud.
Contrast Stored Volumes (the common wrong pick): those keep all data on-premises with async backups to S3 — that doesn't extend capacity, it just backs up. Glacier / DEEP_ARCHIVE are cold archival tiers with retrieval delays — the opposite of low-latency frequent access.
# Cached Volumes: primary dataset in S3, hot subset cached on-prem
# -> low-latency reads for frequently accessed data + capacity extension
# Stored Volumes: all data local, async snapshot to S3 (backup, not extension)
