AWS interview questions

You have read the service list and still cannot tell what the interview will be like. That gap is normal, and this section closes it: AWS rounds are built to find out whether you have operated something, not whether you can name it.

The pattern shows up in the follow-up. An interviewer asks which service you would use, you answer correctly, and the next question is why not the other one. Someone who has run the workload answers from a bill, an outage, or a migration. Someone who has read the documentation stalls. That second question, not the first, is where AWS interviews are decided.

Three round types recur: a fundamentals round on networking, identity, storage, and compute; a scenario or design round where you architect something under constraints; and a troubleshooting round where you are handed a symptom and asked what you would check. Depth expectations rise with seniority, but the shape holds. Other role and topic banks live on the interview questions hub.

These are the fundamentals questions that recur across AWS interviews, grouped the way rounds tend to be organized.

Networking and VPC

• What is a VPC, and how do public and private subnets differ?
• When do you need a NAT gateway, and what does it cost you?
• How do security groups differ from network ACLs?
• How would you connect two VPCs, and when is peering the wrong choice?

Identity and security

• Explain IAM roles, policies, and users, and when you would use each.
• How does an EC2 instance get credentials without storing a key?
• What does the principle of least privilege look like in a real policy?
• How do you rotate and audit secrets in AWS?

Storage and databases

• Compare S3 storage classes and explain when you would use each.
• What is the difference between EBS and instance store?
• When do you pick DynamoDB over RDS, and what do you give up?
• How do read replicas differ from a multi-AZ deployment?

Compute and availability

• Explain auto scaling groups and the metrics you would scale on.
• When is Lambda the wrong answer?
• What is the difference between an availability zone and a region?
• How would you design for the loss of an entire availability zone?

Scenario questions are the ones that separate candidates, because there is no memorizable answer. Typical prompts:

• Our monthly bill doubled and traffic did not. How do you find out why?
• Design a file upload pipeline that handles files too large for one request.
• A service is slow only in one availability zone. What do you check first?
• Move an on-premise database to AWS with minimal downtime. Walk me through it.
• How would you make this architecture survive a regional outage, and what would that cost?

Answer in the same order every time: restate the constraint you think matters, state your assumption out loud, choose a service, then name the trade-off you accepted. The trade-off sentence is what interviewers listen for, because it proves you know what the choice cost.

A backend engineer interviewing for a platform role at a mid-size company is asked to design an upload pipeline. Instead of naming S3 immediately, she asks whether uploads are user-facing and how large the files get, then chooses presigned URLs with a multipart upload and explains that she rejected routing through the application servers because it would have made throughput a scaling problem. The service choice was ordinary; the reasoning is what got remembered.

Reading a question list is not practice. The failure mode in AWS interviews is knowing the answer and delivering it as an unstructured monologue, and that only surfaces when you speak.

Work through the lists above out loud, one question at a time, and hold yourself to the four-part order: constraint, assumption, choice, trade-off. Record a few and listen back for the moment your answer stops having a shape. Running the same set as a mock interview adds the follow-up question, which is the part you cannot rehearse alone and the part AWS interviewers lean on hardest.

One limit worth stating plainly: some AWS screens are automated, recorded, or proctored assessments rather than live conversations. Those are out of scope for any live assistant, SubcueAI included. Preparation is the only thing that helps there, and the interview types hub explains which formats behave which way.