AWS Interview Questions for Cloud, DevOps and Backend Engineers

The interviewer shares a blank whiteboard and says, “Our app runs on one EC2 instance. It went down last Tuesday. Fix it.” You know the answer involves an Auto Scaling group and a load balancer. You’ve clicked through that setup a dozen times. But now you have to explain it out loud, in order, and justify every box, and suddenly you’re saying “and then, um, Route 53 does… DNS things.”

That’s what AWS interview questions really test. Nobody expects you to know the whole service catalog. They want to hear you reason about the pieces you use every week and say why you’d pick one over another.

Below are the questions that come up most for cloud, DevOps and backend roles, with short spoken-style answers and two STAR stories.

Service behavior here follows the official AWS documentation as of October 2026, and AWS changes often, so double-check anything you plan to quote. The sample answers are illustrative, with made-up details.

What AWS interviews actually test

Most AWS questions fall into three buckets, and the mix depends on the role.

A cloud or solutions architect interview leans on design: multi-AZ setups, picking a database, migration plans, trade-offs between managed and self-run. A DevOps or platform interview adds infrastructure as code, CI/CD, monitoring and incident handling. A backend interview asks fewer AWS questions, but sharper ones: SQS retries, Lambda timeouts, S3 under load.

In all three, they listen for one thing: can you explain a choice in terms of failure, cost and security, not features? “I’d use DynamoDB because it’s serverless” is a feature. “I’d use DynamoDB because the access pattern is always lookup by user ID, and I don’t want to manage connection pools during traffic spikes” is a reason.

If you want the wider shape of a cloud or platform loop, our guide on how to prepare for cloud and platform engineering interviews covers the rounds beyond AWS itself.

Core service questions: EC2, S3, RDS and DynamoDB

These are warm-ups, which is exactly why a vague answer here costs you.

• What’s the difference between an EC2 instance store and an EBS volume?
• When would you pick Spot Instances, and what has to be true about the workload?
• How does S3 consistency work today?
• What’s the difference between RDS Multi-AZ and a read replica?
• When would you choose DynamoDB over RDS?
• Lambda or containers on ECS/Fargate? How do you decide?

“Multi-AZ or read replica?” This one trips people up because both involve a second copy of the database. Here’s roughly how I’d say it: “Multi-AZ is for availability. RDS keeps a standby in another Availability Zone, replicates to it synchronously, and fails over to it if the primary dies. You don’t read from that standby in the classic setup. A read replica is for scale. Replication is asynchronous, so it can lag a little, and you point read-heavy traffic at it. If they asked for both availability and read scaling, I’d use both.”

“How does S3 consistency work?” Older prep material says S3 is eventually consistent for overwrites. That’s out of date. Since December 2020, S3 gives strong read-after-write consistency for PUTs and DELETEs of objects, at no extra cost. If you say “eventually consistent” here, the interviewer will wonder what else in your head is from 2019.

“DynamoDB partition key?” Talk about access patterns before you talk about keys. A good key spreads traffic evenly, so something like a user ID usually beats a status field with three possible values. The classic bad answer is a date as the partition key, which sends every write for today to one partition. Mention that and you’ve basically answered it.

On Spot, say yes for batch jobs, CI runners and anything that can be interrupted, and mention the two-minute interruption notice. That detail tells them you’ve run it.

IAM, VPC and networking questions

Security and networking questions separate people who’ve deployed things from people who’ve only read about deploying things.

• Explain the shared responsibility model.
• How does IAM evaluate a request when one policy allows and another denies?
• How would you give an EC2 instance access to an S3 bucket?
• What’s the difference between a security group and a network ACL?
• Public subnet vs private subnet. How does a private instance reach the internet?

“How does IAM decide?” “By default everything is denied. An explicit allow in a relevant policy lets the request through, unless there’s an explicit deny anywhere, because an explicit deny always wins. Then there are guardrails that cap what any allow can do, like service control policies in AWS Organizations and permissions boundaries.” That’s the core of the evaluation logic in the IAM docs, and it fits in thirty seconds.

“EC2 to S3?” If you say “put access keys on the instance,” the interview is in trouble. Attach an IAM role through an instance profile, scope the policy to the bucket and the actions the app really needs, and let the SDK pick up temporary credentials automatically. Mention a VPC gateway endpoint for S3 and you’ve covered the networking side too.

Security groups vs NACLs comes up constantly. Security groups attach to network interfaces, they’re stateful (return traffic is allowed automatically) and they only have allow rules. Network ACLs sit at the subnet level, they’re stateless (you have to allow return traffic yourself, which usually means ephemeral ports) and they support deny rules, evaluated in number order. If you want one line: “Security groups are my main tool; I reach for NACLs when I need to block something at the subnet edge.”

The subnet question is easier with a picture, so here’s the standard layout most interviewers have in their head.

The layout behind most “public vs private subnet” questions. Say where traffic enters, where it can’t, and how private instances get updates.

Narrate it: users come in through the internet gateway to the load balancer in the public subnets. App servers sit in private subnets with no public IPs and reach out for patches through a NAT gateway, but nothing outside can start a connection to them. The database is reachable only from the app tier’s security group.

The Well-Architected Framework questions

Some interviewers ask about it by name: “What are the pillars of the Well-Architected Framework?” There are six, per AWS’s own framework docs: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Sustainability is the one people forget, since it was added later than the rest.

Reciting the list won’t impress anyone. Use the pillars as a checklist instead: if you’re handed an architecture and asked what you’d improve, go pillar by pillar out loud. No backups or failover? Reliability. Everyone has admin? Security. Fifty m5.4xlarge instances at 6% CPU? Cost, and arguably sustainability too.

Scenario design questions

This is where most AWS interviews get decided. Expect something like these:

• Our app runs on a single EC2 instance. Make it highly available.
• Design a backend for a photo-upload feature that handles big spikes.
• How would you migrate a 2 TB on-prem PostgreSQL database to AWS with minimal downtime?
• Design disaster recovery for a service whose recovery time objective is 15 minutes.

Take the first one. I’d start with questions, not boxes: what’s the traffic, is there state on the instance, what’s an acceptable outage? Then the answer builds in layers. Put the app behind an Application Load Balancer. Run it in an Auto Scaling group across at least two Availability Zones, with health checks that replace bad instances. Move session state off the box into ElastiCache or DynamoDB. Move the database to RDS Multi-AZ. Put static files in S3 behind CloudFront. Then say what you’d monitor.

Multi-AZ in one image: one zone goes dark, the other two keep the ships coming in.

For the photo-upload design, the trick most strong candidates use is presigned URLs. The client uploads straight to S3 instead of streaming megabytes through your servers. An S3 event notification then puts a message on SQS (or triggers EventBridge), and workers process thumbnails at their own pace. The spike lands on S3 and the queue instead of your API fleet.

For DR, know the menu (backup and restore, pilot light, warm standby, multi-site active/active), which gets faster and pricier in that order, and pick from the stated recovery objectives. Our system design interview template gives you a structure for pacing these answers inside 45 minutes.

DevOps and operations questions

For DevOps and SRE roles, the AWS questions shift toward how things get built and watched.

• CloudFormation, CDK or Terraform? What would you choose for a new team?
• How do you handle secrets in a pipeline? Secrets Manager or Parameter Store?
• Walk me through a blue/green or canary deployment on AWS.
• An ECS service keeps restarting tasks. How do you debug it?

On infrastructure as code there’s no single right answer. Say what you’ve used, what hurt, and what you’d pick. “Terraform if we’re multi-cloud or already have modules; CDK if the team is mostly TypeScript developers who’d rather write code than YAML” is a perfectly good answer.

For restarting ECS tasks, read the stopped reason, then the CloudWatch logs, then check the usual suspects: a health check grace period that’s too short, out-of-memory kills, or a missing task role permission. There’s more on the operations side in our guide to preparing for DevOps and SRE interviews, and if the team runs EKS, see the Kubernetes interview questions post too.

Security and cost questions

• A developer accidentally made an S3 bucket public. What do you do now, and what do you change so it can’t happen again?
• How would you find out who deleted a resource last night?
• The AWS bill jumped 40% this month. Where do you look first?

For “who deleted it,” the answer is CloudTrail, which records API calls with the identity that made them. For the public bucket, contain first (turn on S3 Block Public Access for the bucket, then at the account level), then check access logs to see whether anything was read, then prevent it with an organization-level guardrail. AWS has blocked public access by default on new buckets since April 2023, so it’s fair to ask how this one got opened in the first place.

The long-term fix for most security questions is least privilege: hand out the one key the job needs, not the whole ring.

Cost questions reward a method. Open Cost Explorer, group by service, then by usage type, and look for the thing that changed. In my experience the usual culprits are boring: NAT gateway data processing, cross-AZ traffic, idle instances someone forgot, EBS snapshots nobody pruned, log retention set to forever. Saying “I’d check NAT gateway data charges” sounds like experience in a way “I’d optimize costs” never will.

Behavioral AWS questions, with STAR answers

Cloud roles still get behavioral rounds, and the best stories are usually incidents or cleanups. Two made-up examples in two voices; build yours from things you actually did. Our STAR method guide covers timing in more detail.

“Tell me about a time you reduced cloud costs.” (A DevOps engineer, fairly formal.)

Situation: “Our team ran about forty microservices on ECS, and the monthly AWS bill had grown much faster than traffic for two quarters in a row.”

Task: “My manager asked me to find out why and bring it down without hurting reliability.”

Action: “I broke the bill down in Cost Explorer by service and usage type. The surprise was NAT gateway data processing. Our services were pulling container images and writing to S3 through the NAT gateway. I added VPC endpoints for S3, ECR and CloudWatch Logs, which moved that traffic off the NAT. Then I tagged everything by team and set up a weekly cost report, because half the waste was test environments nobody owned.”

Result: “The NAT line on the bill dropped to a fraction of what it was, and three teams deleted environments once they saw their names next to the cost. The bigger change was that cost became something people looked at every week instead of every quarter.”

Most surprise bills are a lot of small taps left running, not one big pipe.

“Describe an outage you handled.” (A backend developer, more conversational.)

“So we had an image service on Lambda that started timing out one Friday afternoon. I was on call. First thing I did was check whether it was everything or some requests, and it was only big uploads. Turned out a client had started sending 30 MB images, and our function was downloading them, resizing in memory and hitting the timeout. Short term, I raised the memory setting, which on Lambda also gives you more CPU, and that got us through the weekend. On Monday I moved the heavy resizing to a queue with workers on Fargate and put a size limit on the upload. What I learned is to ask about the worst-case input before you pick the compute, not after.”

Notice the second one never says “Situation” or “Task.” It doesn’t need to. The shape is still there.

Practicing with OfferBull

Most AWS prep is reading docs. That builds knowledge, not the habit of explaining a design out loud while someone pokes holes in it. Saying “explicit deny always wins” smoothly, then handling “okay, what if the SCP doesn’t allow it?”, takes reps.

That’s what OfferBull is for. It’s an AI mock interview app for iOS and Android where an interviewer voice asks you questions out loud and you answer by speaking. Paste in the job description, or upload your resume, and the questions follow the stack you’ll be asked about, so a DevOps role heavy on EKS and Terraform gets different questions than a backend role built on Lambda and DynamoDB. It asks follow-ups based on what you say. Mention a NAT gateway and it may ask why you didn’t use VPC endpoints. If you get stuck while practicing, it can show answer suggestions and a STAR structure. You can practice in English or Chinese.

It’s built for the prep weeks. On interview day, it’s all you.

Start an AI mock interview

FAQ

Do I need an AWS certification to pass these interviews? No. A certification can help you get past a resume screen, but interviewers care much more about how you explain real design decisions. A project you built and can defend beats a badge you can’t back up.

Which AWS services should I know best? For most roles: EC2, S3, IAM, VPC, RDS, DynamoDB, Lambda, SQS, CloudWatch and CloudTrail. Then go deeper on whatever the job description names. If it says EKS, Terraform or Kinesis, those just moved to the top of your list.

Should I mention other clouds if I’ve mostly used Azure or GCP? Yes, honestly. Map what you know: “I’ve done this with GCP’s Cloud Run; on AWS I’d reach for Fargate.” Interviewers respect clear thinking in a neighboring cloud more than bluffing in theirs.

---

Practice This Out Loud

Tonight, take the single-EC2-instance question and answer it out loud in under five minutes, with a sketch. Then answer “the bill jumped this month, where do you look?” in two. If both feel smooth, try them in a voice mock interview that asks follow-ups. → Practice Now