The interviewer at a Series B fintech wasn’t impressed when a candidate listed every AWS service they’d touched. “That’s a resume,” she said. “I want to know what breaks first when your S3 bucket hits 10,000 writes per second.” He froze. He knew the services. He hadn’t thought about failure modes.<\/p>\n
That gap is what AWS interviews test. The 2024 Stack Overflow Developer Survey<\/a> found 52% of professional developers use AWS – more than Azure and Google Cloud combined. That market share means AWS questions show up at companies that aren’t even primarily cloud shops. Knowing the services is table stakes. Knowing how they fail and what they cost is the actual bar.<\/p>\n Below are 14 questions that trip up candidates who’ve spent months studying. Organized around three areas with the most freeze-ups: networking, IAM, and cost.<\/p>\n Most candidates can name instance families. Fewer can say when not to use EC2.<\/p>\n Security Groups are stateful, instance-level, and allowlist-only. NACLs are stateless, subnet-level, and support explicit deny rules. To block a specific IP from an entire subnet, a NACL deny rule is correct. Security Groups can’t do it. The interviewer is checking whether you know that Security Groups have no deny rules.<\/p>\n Strong candidates use scheduled scaling for the predictable 9am spike, combined with target tracking as a safety net for unexpected ones. If you skip the scheduled part, you’re still reacting rather than anticipating – and your users feel those first few minutes of degraded performance every morning.<\/p>\n Instance Store data disappears when the instance stops or terminates. That sounds strictly worse than EBS. It isn’t for one case: you need the highest possible IOPS for truly ephemeral data – think shuffle data in a distributed sort, or a Kafka broker’s local log where replication handles durability. The interviewer wants to know you understand the trade-off, not just the safer default.<\/p>\n Concurrency limits. Lambda has a default regional limit of 1,000 concurrent executions. If timeouts only appear at scale, you’ve likely hit that ceiling. Reserve concurrency for critical functions if you can’t get a limit increase right away. The secondary check is S3 event batching configuration. This question filters candidates who debug Lambda as a code problem rather than a distributed-systems problem.<\/p>\n Public subnets for load balancers and NAT Gateways. Private subnets for application servers. Isolated subnets (no internet route, not even via NAT) for databases. Spread each tier across at least two Availability Zones. The trap is candidates who put app servers in public subnets “for simplicity.” The interviewer is watching whether you apply least privilege to network exposure, not just to IAM.<\/p>\n In order: Does the subnet route table point to a NAT Gateway? Does the NAT Gateway sit in a public subnet with an Internet Gateway route? Does the Security Group allow outbound? Is the NACL blocking the needed port? Most candidates jump straight to Security Groups. The routing table is usually the actual culprit.<\/p>\n VPC Peering is point-to-point and doesn’t support transitive routing. If you peer A to B and B to C, A can’t talk to C. That’s fine for a handful of VPCs. Once you’re managing 15+ across multiple accounts, the peering mesh becomes unmanageable (n(n-1)\/2 connections). Transit Gateway is a hub-and-spoke model that scales cleanly. I don’t have a clean data point on exactly where Transit Gateway’s per-attachment pricing makes it cost-negative versus peering, but architecturally the crossover is usually around 10 VPCs.<\/p>\n A Policy is a document defining permissions. A Role is an identity that gets assumed – by an EC2 instance, a Lambda, a user in another account, or a federated identity. Attach policies to roles. The common mistake is confusing “least privilege” with “fewest policies.” One overly broad policy is worse than five specific narrow ones.<\/p>\n Attach an IAM Role to the EC2 instance or Lambda. The AWS SDK picks up temporary credentials automatically from the instance metadata service (IMDS). No hardcoded keys. The follow-up is almost always about IMDS v2, which requires a PUT request to get a session token first – this prevents SSRF attacks from harvesting credentials. If you don’t mention IMDS v2 unprompted, a security-focused interviewer will notice.<\/p>\n Two things must both be true: the caller’s IAM policy must allow the action on the target bucket’s ARN, and the bucket’s resource-based policy must allow the caller’s principal. One without the other doesn’t work. Candidates get this half right constantly. The interviewer is checking whether you know S3 uses resource-based policies in addition to identity-based policies.<\/p>\n Cost Explorer, filtered by service then usage type. Data transfer is almost always the culprit nobody modeled – cross-region transfers and NAT Gateway traffic add up fast. EC2 left running after a load test is a close second. Good candidates also mention enabling Cost Anomaly Detection proactively, so you’re not learning about overages from a monthly invoice.<\/p>\n Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability – per the AWS Well-Architected Framework<\/a>. The neglected one is almost always Operational Excellence: runbooks, post-mortems, change management. Security and reliability get attention because their failures are visible. Operational Excellence failures are invisible until an incident happens and nobody knows what to do.<\/p>\n Multi-AZ behind an Application Load Balancer with Auto Scaling. Route 53 health checks on the ALB, failover record to a static S3-hosted degraded page if everything goes down. 99.99% is roughly 52 minutes of downtime per year – achievable with multi-AZ alone for most workloads. I’d only go multi-region active\/active if the SLA literally requires it. The operational complexity is real and most teams underestimate it.<\/p>\n Hot partitions happen when your partition key has low cardinality or access patterns skew toward a few values. Two real options: add a random suffix to spread writes across N partitions and scatter-gather the reads (adds latency), or put DAX in front to cache repeated reads on the same keys. The partition key redesign is the correct fix. DAX is what you ship at 2am while you’re planning the redesign.<\/p>\n What we see on LastRound AI<\/p>\n Candidates using LastRound AI’s mock interview platform<\/a> struggle most with questions 14 (DynamoDB hot partitions) and 10 (cross-account S3 authorization) – not because they don’t know the answers, but because they’ve never explained the reasoning out loud. Saying “add a random suffix” and walking an interviewer through the scatter-gather tradeoff are different skills. Practicing out loud is what closes that gap.<\/p>\n<\/div>\n<\/div>\n The BLS projects roughly 317,700 new computer and IT job openings per year through 2034<\/a>, and cloud skills sit near the top of requirements in most of those postings. The competition is real. But memorizing 60 services isn’t the gap for most candidates. The gap is explaining trade-offs under pressure.<\/p>\n Work through these questions out loud. “S3 uses resource-based policies” reads fine on a page. Saying it coherently while an interviewer asks follow-ups about cross-account trust is a different skill. If you want reps on the architectural scenarios specifically, LastRound AI’s interview copilot<\/a> can prompt you and flag when your answer glosses over failure modes.<\/p>\n The candidates who do well in AWS panels aren’t the ones who’ve memorized the most. They’re the ones who’ve thought about what breaks.<\/p>\nEC2 and Compute: the questions everyone thinks they can answer<\/h2>\n
1. What’s the difference between a Security Group and a NACL, and which blocks a single bad IP?<\/h3>\n
2. You have a CPU-bound workload that spikes 4x every weekday at 9am. Walk through your Auto Scaling setup.<\/h3>\n
3. EBS vs. Instance Store. When would you ever choose Instance Store?<\/h3>\n
4. You’re running a Lambda that processes S3 events. It starts timing out at high volume. What do you check first?<\/h3>\n
VPC and Networking: where architectural thinking shows<\/h2>\n
5. Design a VPC for a three-tier web application. What subnets do you create and why?<\/h3>\n
6. Your EC2 instance in a private subnet can’t reach the internet. What’s your checklist?<\/h3>\n
7. VPC Peering vs. Transit Gateway. When does one stop being the right choice?<\/h3>\n
IAM and Security: the questions that expose shortcuts<\/h2>\n
8. What’s the difference between an IAM Role and an IAM Policy?<\/h3>\n
9. Your application needs to read from S3 and write to DynamoDB. How do you grant it those permissions without hardcoding credentials?<\/h3>\n
10. Walk me through what happens when you call s3:GetObject on a bucket in another account.<\/h3>\n
Cost and architecture: the questions seniors fail<\/h2>\n
11. You get a $40,000 AWS bill that’s 3x budget. What do you check first?<\/h3>\n
12. Name the six pillars of the Well-Architected Framework. Which one do most startups neglect?<\/h3>\n
13. You need 99.99% availability for a stateless API. What does the architecture look like?<\/h3>\n
14. Your DynamoDB table has one hot partition handling 80% of reads. Fix it.<\/h3>\n
How to prepare without memorizing service lists<\/h2>\n