A candidate at a Series B fintech I was interviewing last year hit a wall on a question I didn't think was hard: "Walk me through what happens differently when a Multi-AZ RDS instance fails over versus promoting a read replica." He'd used both. He'd never had to explain the difference out loud, under pressure, to someone deciding whether to hire him. That's the gap this list is about — not whether you've clicked around the AWS console, but whether you can reason about it when someone's watching.
I've been on both sides of this table for about seven years now, first as the person sweating through EC2 questions with no real production experience, later as the person asking them. These are the nine that come up constantly, roughly in the order they tend to get asked.
1. How do you choose between EC2 instance families?
Interviewers aren't looking for a spec sheet recitation. They want to know you think about workload shape before you think about price. Compute-optimized (C-family) for CPU-bound work like batch processing or gaming servers. Memory-optimized (R-family, X1) for in-memory caches and large databases. General purpose (M/T-family) as the default until you have a reason not to. Storage-optimized (I/D-family) for workloads doing heavy local I/O, like a self-managed Cassandra cluster.
The wrong answer is "I just pick T3.medium for everything." The right answer names a workload and a bottleneck. A weak candidate says "M5 is a good general instance." A strong one says "if I'm seeing sustained CPU above 80% with memory sitting at 30%, I'm moving to compute-optimized, not just bumping the instance size" — because bumping size without diagnosing the bottleneck is how teams end up overpaying for headroom they don't need.
2. What's the actual difference between S3 storage classes, and when does a lifecycle policy save real money?
Standard for anything accessed regularly. Standard-IA (Infrequent Access) for things you touch less than once a month but need fast when you do. Glacier and Glacier Deep Archive for compliance data you may never touch again but legally can't delete.
Here's what actually happens if you get this wrong in a live interview: candidates often forget the retrieval cost and latency tradeoff. Glacier is cheap to store, expensive and slow to retrieve — minutes to hours depending on the retrieval tier. I've seen a team set up "smart" lifecycle rules that moved logs to Glacier after 30 days, then got hit with a five-figure retrieval bill during an incident investigation because nobody accounted for needing that data fast, under pressure, all at once.
3. ALB vs NLB — what's the real distinction, not just "one is Layer 7 and one is Layer 4"?
Everyone can recite the OSI layer answer. Fewer can explain why it matters. ALB (Application Load Balancer) operates on HTTP/HTTPS, so it can route based on path, host header, or query string — useful for microservices behind one load balancer. NLB (Network Load Balancer) handles TCP/UDP at extreme scale with static IPs and sub-millisecond latency, which matters for things like gaming backends or when a client needs to whitelist a fixed IP.
My honest opinion, which goes against what a lot of "AWS certification" content pushes: don't reach for NLB by default just because it's "faster." Most web applications never come close to needing NLB's throughput ceiling, and you lose ALB's content-based routing, which usually saves more architectural complexity than the latency gain is worth.
4. How do Auto Scaling Groups actually decide to scale, and what's a cooldown period doing?
An ASG scales based on a scaling policy tied to a CloudWatch metric — target tracking (keep CPU at 50%), step scaling, or simple scaling. The cooldown period is the part people forget to mention: it's a pause after a scaling action during which the ASG won't trigger another one, specifically to stop it from overreacting to a metric spike before the last scale-out has had time to actually reduce load.
A weak answer stops at "it adds instances when CPU is high." A strong answer explains why an ASG without a sensible cooldown can thrash — scaling out, watching the metric dip as new instances register, scaling back in too soon, then scaling out again ten minutes later.
5. EBS vs instance store — why does persistence actually matter here?
EBS is network-attached, persists independently of the instance lifecycle, and can be snapshotted. Instance store is physically attached to the host, is faster, and is gone the moment the instance stops (not just terminates — stops). I've watched someone lose a day of processed data because they stored intermediate results on instance store and then had a routine instance stop for maintenance.
6. Multi-AZ RDS vs read replicas — the question that started this whole post
Multi-AZ is for availability: a synchronous standby in a different AZ that RDS automatically fails over to if the primary dies, usually in under two minutes, and you don't manage it — RDS handles the DNS switch. A read replica is for scaling read traffic: an asynchronous copy you query directly, that you promote manually if you want it to become a new primary, and promotion isn't instant or transparent to your application.
The distinction that trips people up: Multi-AZ doesn't help with read scaling (you can't query the standby), and a read replica isn't a high-availability solution by itself (replication lag means it can be behind, and promotion requires action). You often want both, for different reasons.
7. Public vs private subnets — what makes a subnet "public," really?
It's not the subnet itself, it's the route table. A subnet is public because its route table has a route to an Internet Gateway. Nothing else makes it public — not IP ranges, not naming conventions. A private subnet with no such route, reaching the internet only through a NAT Gateway in a public subnet, can still send outbound traffic (for package updates, API calls) without being reachable from outside.
8. Reserved Instances vs Savings Plans vs Spot — what would you actually recommend to a team trying to cut their AWS bill?
RIs commit to a specific instance family/region for 1-3 years for a discount, and they're inflexible if your architecture changes. Savings Plans are similar in discount depth but flexible across instance families and even compute types (EC2, Fargate, Lambda), which is why most teams moving off RIs prefer them now. Spot Instances are steeply discounted spare capacity that AWS can reclaim with two minutes' notice — great for stateless, interruption-tolerant work like batch jobs or CI runners, a genuinely bad idea for anything holding session state without an external store.
9. What actually gets monitored via CloudWatch in a production system, beyond CPU and memory?
This is where junior and senior answers diverge hardest. Junior answers stop at CPU, memory, disk. Senior answers mention custom application metrics (queue depth, error rate by endpoint, p99 latency), composite alarms that reduce alert fatigue by requiring multiple conditions before paging someone, and the discipline of alerting on symptoms users feel (latency, error rate) rather than every resource metric that moves.
None of these questions are exotic. That's the point — the bar in a real interview isn't obscure trivia, it's whether you can explain the "why" behind something you've used, calmly, to someone who's going to make a hiring decision based on how that explanation lands. I've started running through questions like these out loud before interviews rather than just re-reading docs, since the muscle you actually need is talking it through under mild pressure, not recognition. LastRound AI's mock interview practice is what I've been using to do that — it pushes back with follow-up questions the way a real interviewer would, which flat re-reading never does.
Top comments (1)
Solid list, and #6 is the one I'd double down on because the subtlety goes a layer deeper than most candidates (or interviewers) take it.
On Multi-AZ failover: the "under two minutes" number hides the thing that actually bites you in prod, the failover is a DNS change. If your app or connection pooler caches DNS (many JVM setups do by default) or holds long-lived connections, you'll keep hammering the dead primary past those two minutes until connections time out and re-resolve. The senior answer names that: set a sane DNS TTL and make sure your driver/pool reconnects on failover instead of clinging to the stale endpoint.
On read replicas: the trap beyond replication lag is that promoting one breaks replication for the others. Primary + 3 replicas, promote one, and the other two don't auto-repoint at the new primary, you rebuild that topology by hand. So "just promote a replica" mid-incident can leave you with a new primary and no HA until you reattach everything.
One to add to #8: the cleanest Spot pattern people miss is mixing Spot + On-Demand in a single ASG with a capacity-optimized allocation strategy, so you get the discount on the interruptible bulk while a baseline of On-Demand keeps the service alive when a Spot pool gets reclaimed. "Spot for everything" and "never Spot" are both junior answers; the blend is the senior move.