AWS Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps

An AWS interview cheatsheet in 2026 should help you sound like someone who can operate in the cloud, not someone who memorized a service catalog. Interviewers rarely care whether you can list every database or analytics product. They care whether you can choose sane defaults, explain tradeoffs, debug production symptoms, secure access, control cost, and design systems that fail gracefully. This guide gives you the patterns, examples, practice plan, and common traps that matter for backend, DevOps, SRE, data, security, and platform interviews.

AWS interview cheatsheet in 2026: the evaluation map

Most AWS interview questions fall into six buckets:

| Area | What interviewers want | Good answer signal | |---|---|---| | Compute | EC2, ECS, EKS, Lambda, Batch, autoscaling | Picks based on runtime, ops burden, latency, and control needs | | Networking | VPC, subnets, routing, security groups, load balancers, private access | Explains traffic path and blast radius | | Data | RDS, DynamoDB, S3, ElastiCache, OpenSearch, Redshift | Chooses based on access pattern, consistency, scale, and cost | | Security | IAM, KMS, Secrets Manager, least privilege, audit logs | Starts with identity and boundary design, not just encryption | | Reliability | Multi-AZ, backups, retries, queues, health checks, DR | Designs for known failure modes | | Cost | right-sizing, storage lifecycle, reserved capacity, egress | Treats cost as architecture, not a finance afterthought |

The strongest candidates narrate the constraints first: traffic pattern, latency requirement, compliance needs, team maturity, operational tolerance, and expected growth. Then they select services.

Core patterns you should be able to design

A public web API

A common answer: Route 53 to CloudFront if global caching or TLS edge behavior matters, then Application Load Balancer to ECS/Fargate, EKS, or EC2 Auto Scaling. Put services in private subnets, ALB in public subnets, NAT or private endpoints for outbound dependencies, RDS in private subnets, ElastiCache if needed, S3 for object storage, CloudWatch/OpenTelemetry for logs and metrics, and IAM roles for workload access.

If the team wants low operations and containers, ECS Fargate is a strong default. If the organization already has Kubernetes expertise or needs portability and ecosystem control, EKS can fit. If request volume is spiky and workloads are short-running, Lambda plus API Gateway may be cheaper and simpler, but watch cold starts, timeouts, payload limits, and local debugging complexity.

Event-driven processing

For async workflows, mention SQS for queue buffering, SNS or EventBridge for fanout/events, Lambda or ECS workers for processing, dead-letter queues, idempotency keys, retries with backoff, and visibility timeouts. The key phrase is: "At-least-once delivery means my handler must be idempotent." That alone separates practical candidates from catalog memorizers.

Example: image processing after upload. User uploads to S3 with pre-signed URL. S3 event goes to EventBridge or SQS. Worker processes image, writes derived files to S3, updates DynamoDB or RDS, and emits status. Use DLQ for poison messages. Limit concurrency to protect downstream systems. Track processing latency and failure rate.

Data store selection

AWS data questions are usually access-pattern questions. RDS is the default for relational data, transactions, joins, mature SQL, and predictable operational model. Aurora is useful when you want managed relational scale and replicas. DynamoDB is strong for high-scale key-value or document access with well-known partition keys and predictable access patterns. S3 is object storage, not a database, but it is often the source of truth for files, exports, logs, and data lake patterns. ElastiCache helps with hot reads, sessions, locks only with care, and rate limiting. Redshift is for analytics warehouses, not transactional app paths.

A strong answer includes what you would not choose. "I would not put relational, ad hoc reporting workloads into DynamoDB unless the access patterns were stable. I would not use RDS as a queue. I would not use S3 for low-latency row-level updates."

IAM: the area that makes or breaks senior interviews

IAM is where many candidates sound vague. You need a crisp model: principals make requests to resources; policies allow or deny actions; explicit deny wins; identity policies attach to users/roles/groups; resource policies attach to resources; trust policies define who can assume a role; permission boundaries and SCPs can cap permissions.

For workloads, prefer IAM roles, not long-lived access keys. EC2 uses instance profiles. ECS tasks and EKS service accounts can assume roles. Lambda execution roles define what the function can access. Human access should go through SSO/federation where possible, with MFA, short sessions, and least privilege.

Interview example: "An app needs to read one S3 bucket and write to one SQS queue." Good answer: create a role for that workload with s3:GetObject limited to the bucket/prefix and sqs:SendMessage limited to the queue ARN; attach it to the task/function/instance; avoid static keys; log access with CloudTrail; consider KMS permissions if the bucket or queue is encrypted with a customer-managed key.

Common trap: saying "I gave the service admin so it works, then locked it down later." In production, that can become permanent. Better: start with narrowly scoped managed or custom policies, validate with IAM Access Analyzer or logs, and expand only when a specific denied action is justified.

Networking: explain the packet path

AWS networking interviews often test whether you can draw the path. A VPC spans Availability Zones. Subnets live in one AZ. Public subnets have a route to an Internet Gateway and resources with public IPs can be reached from the internet if security allows. Private subnets do not route directly to the internet; outbound internet usually goes through NAT Gateway, or better, private VPC endpoints for AWS services like S3, DynamoDB, ECR, Secrets Manager, and CloudWatch.

Security groups are stateful virtual firewalls attached to resources. Network ACLs are stateless subnet-level controls and are less commonly the main application boundary. Route tables determine where traffic goes. Load balancers sit across subnets and distribute traffic to targets. VPC peering and Transit Gateway connect networks; PrivateLink exposes services privately without broad network routing.

A strong debugging answer for "The app cannot connect to RDS" goes like this: verify DNS/endpoint and port, check RDS status, confirm the app and DB are in routable subnets, inspect security group inbound on RDS and outbound on the app, validate NACLs if present, check route tables, confirm credentials and TLS requirements, and review CloudWatch/RDS logs. Do not start by rebooting the database.

Reliability and resilience patterns

For most production workloads, multi-AZ is the baseline. Put load balancers in multiple AZs, run compute across multiple AZs, use managed databases with Multi-AZ or replicas when needed, back up data, and test restore. Autoscaling is not a substitute for failure design; it helps with capacity, not all outages.

Know the difference between high availability and disaster recovery. HA handles component or AZ-level failure with minimal interruption. DR handles regional or catastrophic failure. DR has RPO and RTO. A warm standby is faster and more expensive than backup-and-restore. Active-active multi-region is complex and rarely the default unless the business truly needs it.

Retries need backoff and jitter. Timeouts should be shorter than user patience and shorter than upstream load balancer timeouts. Circuit breakers and bulkheads matter when dependencies fail. Queues smooth spikes and isolate downstream failures. Idempotency prevents duplicate side effects when messages or HTTP requests retry.

For senior roles, talk about failure modes: AZ outage, database failover, IAM misconfiguration, expired certificates, runaway autoscaling, bad deploy, regional service degradation, account limits, and third-party dependency failure.

Cost signals interviewers like

Cost awareness is now a strong hiring signal. You do not need exact AWS pricing memorized, but you should know the big levers:

• NAT Gateway data processing can surprise teams; use VPC endpoints for heavy AWS-service traffic.
• Cross-AZ and cross-region data transfer can dominate chatty architectures.
• Overprovisioned RDS and OpenSearch clusters are expensive and often under-reviewed.
• S3 lifecycle policies can move old objects to cheaper storage classes, but retrieval patterns matter.
• Compute Savings Plans or Reserved Instances can help steady workloads; spot can help fault-tolerant batch jobs.
• CloudWatch high-cardinality metrics, verbose logs, and long retention can become a real bill.
• Lambda is cheap for spiky low-volume workloads but not automatically cheaper at sustained high throughput.

Good framing: "I would set budgets and anomaly alerts, tag resources by service/team/environment, review unit cost like dollars per thousand requests, and treat cost regressions as part of production health."

Common AWS interview traps

• Choosing Lambda for everything. Lambda is excellent for event-driven and spiky workloads, but long-running, high-throughput, low-latency, or heavy local-dependency systems may fit containers better.
• Ignoring IAM boundaries. Security is not complete because traffic is private; identities still need least privilege.
• Confusing security groups and NACLs. Security groups are stateful and resource-attached; NACLs are stateless and subnet-level.
• Forgetting AZ scope. Subnets are AZ-specific; many resources need explicit multi-AZ design.
• Using RDS as a queue. It can work at small scale, but SQS or a streaming system is usually cleaner for buffering.
• No idempotency. Retries and queues create duplicates. Design for them.
• No restore test. Backups that have never been restored are a hope, not a recovery plan.
• Treating encryption as the whole security story. Access control, audit, network boundaries, rotation, and operational discipline matter just as much.

Practice answers for common prompts

Prompt: Design a URL shortener on AWS. Use API Gateway or ALB plus a container/Lambda service, DynamoDB keyed by short code, optional ElastiCache for hot redirects, Route 53, CloudFront if global edge caching is useful, CloudWatch metrics, WAF for abuse, rate limits, and idempotent create endpoint. Talk about collision handling, custom aliases, TTLs, analytics pipeline, and hot-key mitigation.

Prompt: Design a file upload system. Prefer direct-to-S3 uploads with pre-signed URLs so app servers do not proxy large files. Store metadata in RDS or DynamoDB. Use S3 events to trigger scanning or processing through SQS. Apply bucket policies, KMS encryption, lifecycle rules, object size limits, content-type validation, and DLQs for failed processing.

Prompt: Migrate a monolith to AWS. Start with discovery: dependencies, database size, latency, compliance, release process, and failure tolerance. Lift-and-shift only if speed matters. Otherwise containerize, externalize config/secrets, move static assets to S3/CloudFront, introduce managed DB, add observability, then split services only where the domain boundary and team ownership justify it.

Seven-day AWS interview practice plan

Day 1: Draw a VPC with public/private subnets across two AZs, ALB, ECS or EC2, RDS, NAT, VPC endpoints, and security groups. Explain every traffic path.

Day 2: IAM drills. Write least-privilege access for S3 read and SQS write. Explain role assumption, trust policies, explicit deny, and KMS permissions.

Day 3: Compute choices. Compare Lambda, ECS Fargate, EKS, and EC2 for three workloads: API, queue worker, and batch job.

Day 4: Data choices. Pick between RDS, DynamoDB, S3, ElastiCache, and Redshift for five access patterns. State what would change your mind.

Day 5: Reliability. Add health checks, autoscaling, multi-AZ, backups, retries, DLQ, and deploy rollback to a sample architecture.

Day 6: Cost. Identify the top five cost risks in your design and how you would measure them.

Day 7: Full mock. Design a production system, debug a connectivity issue, and respond to a bad deploy. Keep answers structured: requirements, architecture, tradeoffs, failure modes, and operations.

How to sound senior without pretending

If you have limited AWS production experience, be precise about it. "I have deployed side projects on ECS and used S3/Lambda, but I have not owned a multi-account enterprise platform. In an interview, I would start with simple managed services, least-privilege IAM, private networking, logs/metrics, backups, and cost alerts. For decisions beyond my experience, I would validate with a small load test and a security review."

That is credible. AWS interviews reward judgment, not bravado. The best answers choose boring managed services when they fit, call out where complexity starts, and explain how the system will be secured, observed, recovered, and paid for.

Related guides

• API Design Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical API design interview cheatsheet for 2026: how to scope the problem, choose REST/GraphQL/gRPC patterns, model resources, handle auth, versioning, rate limits, and avoid the traps that cost senior candidates offers.
• Backend System Design Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A backend System Design interview cheatsheet for 2026 with the core flow, architecture patterns, capacity heuristics, reliability tradeoffs, and traps that separate senior answers from vague box drawing.
• Data Modeling Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical Data Modeling interview cheatsheet for 2026 covering entities, relationships, relational and NoSQL patterns, analytics models, index choices, examples, and the traps that make otherwise strong candidates look shallow.
• Distributed Systems Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical distributed systems interview cheatsheet for 2026: the patterns interviewers expect, how to reason through tradeoffs, and the traps that cost strong candidates offers.
• Execution Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A practical execution interview cheatsheet for 2026 with answer patterns, launch and operating examples, a one-week practice plan, and the traps that make otherwise strong candidates sound vague.