AWS Interview Questions — Real Practice Quiz
Reviewed by Mark Dickie · Last updated
AWS (Amazon Web Services) is the cloud computing platform from Amazon that offers over 200 services covering compute, storage, networking, databases, analytics, machine learning, and security. For an AWS interview, you should know the core service families: EC2 for compute, S3 for object storage, VPC for networking, IAM for identity and access control, and Lambda for serverless execution. Interviewers also expect you to reason through architecture trade-offs—cost versus performance, availability versus consistency, and managed versus self-operated services.
| Domain | Key Services | What Interviewers Ask |
|---|---|---|
| Compute | EC2, Lambda, ECS, EKS | Instance types, auto scaling, spot vs on-demand |
| Storage | S3, EBS, EFS, Glacier | Storage classes, lifecycle policies, durability vs availability |
| Networking | VPC, Route 53, CloudFront, Direct Connect | Subnets, NAT gateways, route tables, CIDR math |
| Security | IAM, KMS, Secrets Manager, GuardDuty | Least-privilege policies, roles vs users, encryption at rest |
| Databases | RDS, DynamoDB, Aurora, Redshift | When to use managed SQL vs NoSQL, read replicas, partition keys |
What does an AWS interview actually test?
Most AWS interviews break into three layers: factual recall of service features, hands-on architecture design, and troubleshooting scenarios. The factual portion checks whether you can name the right service for a given requirement. The architecture portion asks you to draw or describe a system that meets specific constraints. The troubleshooting portion gives you a broken setup and expects you to diagnose it.
How should you prepare for an AWS interview?
- Map each service family to its primary use case and its limits—knowing when not to use a service is as important as knowing when to use it.
- Practice VPC design from scratch: subnets, route tables, internet and NAT gateways, and security groups versus NACLs.
- Study IAM policy JSON by hand. Be able to read a policy and predict what it allows or denies.
- Work through shared-responsibility model questions—the division between AWS and the customer changes per service.
- Build mental cost models: know roughly how EC2, S3, and data transfer are priced, because interviewers love asking you to optimize a bill.
The quiz below pulls from real interview questions across these domains. Work through them, check your answers, and revisit anything you miss.
Key facts
- Tarmac has 99 AWS interview questions on this topic, 10 of them on this page, at difficulty 2–5 of 5.
- Tarmac last reviewed these AWS interview questions on 23 August 2026.
At a glance
| Questions | 10 shown · 99 in the bank |
|---|---|
| Difficulty | 2–5 of 5 |
| Formats | Flashcard, Multiple choice, True / false, Fill in the blank, Find the bug, Short answer, Ordering, Design exercise, Multiple answer |
What you'll review
- vpc
- s3
- security groups
- sqs
- ebs
- iam policies
- s3 storage classes
- load balancers
- dynamodb
Practice questions
AWS/aws-networking/vpc
What is an Amazon VPC, and what are its main building blocks?#
Show answer
A Virtual Private Cloud is a logically isolated virtual network you define inside a Region, with an IP address range you choose (a CIDR block). You carve it into subnets, each living in a single Availability Zone; a public subnet routes to the internet via an Internet Gateway, a private subnet reaches the internet only outbound through a NAT Gateway. Route tables control where traffic goes, and security groups (stateful, instance-level) plus network ACLs (stateless, subnet-level) control what traffic is allowed. It's the network boundary your EC2 instances, RDS databases, and other resources run inside.
A VPC is the foundational networking layer almost every other AWS resource sits in. The pieces that matter in interviews: it's Region-scoped with subnets pinned to one AZ each, public vs private subnets are defined by their route to an Internet Gateway vs a NAT Gateway, and security groups (stateful) vs NACLs (stateless) are the two filtering layers. Being fuzzy on subnets-are-AZ-scoped or on the IGW-vs-NAT distinction is a common tell of someone who hasn't actually built a network.
AWS/aws-storage/s3
Your service writes a brand-new object to S3 and, a millisecond later, issues a GET for that same key from another instance. What consistency does S3 guarantee for that read today?#
Options
Show answer
S3 guarantees strong read-after-write consistency: a GET issued after a successful PUT always returns the latest object. Since December 2020 this applies automatically to all GET, PUT, LIST, and tag/ACL/metadata operations, in every Region, with no extra cost or configuration. The earlier eventual-consistency model — and the read-your-own-write workarounds built around it — no longer applies. It does not require Versioning and is not limited to one Availability Zone.
Since December 2020, S3 provides strong read-after-write consistency automatically for all GET, PUT, LIST, and tag/ACL/metadata operations, in every Region, at no extra cost. A read issued after a successful write always sees the latest data. The old eventual-consistency model (and the read-your-own-write workarounds people built around it) is gone — but a lot of legacy advice and interview prep still teaches it, which is the trap here. Versioning and AZ scope are unrelated to this guarantee.
AWS/aws-networking/security-groups
An EC2 instance's security group has an inbound rule allowing TCP 443 from anywhere, and no outbound rules referencing the client's ephemeral ports. A client opens an HTTPS connection. Why does the response traffic still reach the client?#
Options
Show answer
Security groups are stateful: they track connections, so the return traffic for an allowed inbound flow is permitted automatically — no matching outbound rule is required. This is the defining contrast with network ACLs, which are stateless and need an explicit outbound rule covering the client's ephemeral port range for responses to pass. Outbound is still evaluated for new connections the instance initiates; it is simply bypassed for replies to already-allowed inbound connections.
Security groups are stateful: they use connection tracking, so once an inbound flow is allowed, the corresponding return packets are allowed back automatically even if no outbound rule would match them. This is the key contrast with network ACLs, which are stateless and require an explicit outbound rule covering the client's ephemeral port range. Option (b) is a plausible trap — the default allow-all egress would also let it out, but the question removes reliance on it; statefulness is the actual reason. Misunderstanding this leads people to add unnecessary egress rules or to mis-debug NACLs that genuinely do need them.
AWS/aws-integration/sqs
A standard SQS queue can deliver the same message more than once, so consumers of a standard queue should be written to handle duplicate processing idempotently.#
Options
Show answer
True. Standard SQS queues provide at-least-once delivery — because messages are stored redundantly across servers, a transient failure during a delete can cause the same message to be received again, so consumers must process messages idempotently. FIFO queues are the option that suppresses duplicates and preserves order (exactly-once processing) at the cost of throughput. Treating a standard queue as exactly-once is a common cause of double-applied side effects like duplicate charges.
True. Standard queues guarantee at-least-once delivery: because SQS stores messages redundantly across servers, a server being briefly unavailable during a delete can cause the same message to be received again. So consumers must be idempotent. If you need duplicates suppressed and strict ordering, you use a FIFO queue, which provides exactly-once processing and ordered delivery (at lower throughput). Assuming a standard queue delivers exactly once is a frequent source of double-charged payments and duplicated side effects in production.
AWS/aws-storage/ebs
An EBS volume can only be attached to an instance in the same _____ as the volume. To move its data to a different one, you take a _____ (which is stored in S3 and is Region-scoped) and create a new volume from it there.#
Show answer
An EBS volume can only be attached to an instance in the same availability zone as the volume. To move its data to a different one, you take a snapshot (which is stored in S3 and is Region-scoped) and create a new volume from it there.
EBS volumes are Availability-Zone scoped: a volume lives in one AZ and can only attach to an instance in that same AZ. Snapshots are the portability mechanism — they're stored in S3, backed up across the Region, so you can create a fresh volume from a snapshot in any AZ in the Region (or copy the snapshot to another Region). This is why disaster-recovery and AZ-rebalancing plans are built on snapshots, and why you can't just 'detach and reattach across AZs.'
AWS/aws-iam-security/iam-policies
This identity policy is meant to let a service read and write objects in only the reports-prod bucket. A security review flags it. What is the real problem?#
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "*"
}
]
}Options
Show answer
Resource: "*" grants the actions on every object in every bucket, not just reports-prod — it should be arn:aws:s3:::reports-prod/*
The actions are scoped correctly, but Resource: "*" applies them to every object in every bucket in the account — a massive over-grant that violates least privilege. The fix is the bucket's object ARN, arn:aws:s3:::reports-prod/* (and arn:aws:s3:::reports-prod for bucket-level actions if needed). The Version date 2012-10-17 is the current, correct policy-language version — it is not a year you bump. Multiple actions in one statement is normal, and you would never broaden to s3:* to fix an over-permissive policy. Over-broad Resource is one of the most common and dangerous real-world IAM mistakes.
AWS/aws-storage/s3-storage-classes
When would you choose S3 One Zone-IA over S3 Standard-IA, and what is the risk you accept by doing so?#
Show answer
S3 One Zone-IA stores data in a single Availability Zone, so it's cheaper than Standard-IA (which, like Standard, replicates across at least three AZs). Both are 'infrequent access' tiers with a per-GB retrieval fee and a 30-day minimum storage charge, suited to data accessed rarely. You pick One Zone-IA only for data you can afford to lose or easily re-create — secondary backups, thumbnails, intermediate/derived data, replicas of data held elsewhere — because if that single AZ is destroyed, the data is gone. You accept lower availability and the loss of AZ-level fault tolerance in exchange for roughly 20% lower storage cost. For primary or irreplaceable data, use Standard-IA or Standard.
The whole point of One Zone-IA is trading durability-against-AZ-loss for cost: it lives in one AZ, so an AZ failure loses it. It still has the same 11-nines object durability within that AZ and the same IA economics (retrieval fee, 30-day minimum), so it only makes sense for data that is re-creatable or already replicated elsewhere. A strong answer names the single-AZ risk and a fitting use case rather than just calling it 'the cheap one' — that distinction is exactly what the interviewer is probing.
AWS/aws-networking/load-balancers
A user requests https://app.example.com, served by EC2 instances in private subnets behind an internet-facing Application Load Balancer. Order the steps the request takes to reach a healthy instance.#
Put these in order
Show answer
A request through an internet-facing Application Load Balancer follows a fixed path. The correct order is: first Route 53 resolves the hostname to the ALB's address, then the request hits the ALB's HTTPS listener which terminates TLS, then a listener rule matches the request and selects a target group, then the ALB picks a healthy target passing its health checks, and finally it forwards the request to that instance in its private subnet. This ordering localizes failures: resolution issues are DNS, no-healthy-target 503s are the target group.
The flow is DNS first (Route 53 hands back the ALB endpoint), then the connection reaches the ALB's listener which terminates TLS, then a listener rule routes by host/path to a target group, then the ALB selects among only the targets currently passing health checks, and finally forwards to that instance — which can live in a private subnet because the ALB (in public subnets) is what's internet-facing. Knowing this order is what lets you localize failures: a name that won't resolve is Route 53; a 503 with no healthy targets is the health-check/target-group stage; a 504 is usually the instance itself.
AWS/aws-storage/s3
Design a serverless image-upload and processing pipeline on AWS.#
Show answer
Upload. Clients call a small authenticated endpoint (API Gateway + Lambda) that returns a presigned S3 PUT/POST URL scoped to a per-user key prefix, a max size, an allowed content-type, and a short expiry. The client uploads the original straight to an uploads bucket — the backend never touches the bytes, sidestepping API Gateway/Lambda payload limits and cost.
Trigger & buffer. The uploads bucket emits an ObjectCreated event to SQS (directly or via EventBridge). A processing Lambda consumes the queue. The buffer is deliberate: SQS absorbs spikes and gives us retries and a DLQ, which a direct S3->Lambda wiring wouldn't.
Processing. The Lambda reads the original, generates thumbnail/web/full variants, and writes them to a separate processed bucket (separate bucket avoids recursive event loops). Memory is tuned for 20 MB images; if work outgrew Lambda's 15-minute/resource envelope I'd move to Fargate or AWS Batch pulling the same queue.
Scaling. Lambda scales with queue depth; I set a max/reserved concurrency so a burst can't overwhelm downstream, and set the SQS visibility timeout above the worst-case processing time so messages aren't redelivered mid-flight. 50k uploads in a minute simply queue and drain — nothing is dropped.
Resilience & idempotency. S3 events and SQS are at-least-once, so processing is idempotent: variant keys are deterministic (derived from the source key/hash), so a duplicate event just overwrites identical output. A redrive policy sends repeatedly-failing messages to a DLQ after N attempts; a CloudWatch alarm on DLQ depth pages us, and we can fix and redrive. Poison message: it retries, becomes visible again each time the timeout lapses, and after the threshold lands in the DLQ — without blocking the rest of the queue.
Serving. The processed bucket sits behind CloudFront with Origin Access Control, so the bucket stays private and images are cached at the edge for low global latency. Private images use signed URLs/cookies.
Security. The Lambda role is least-privilege — read on uploads, write on processed, consume on the queue, nothing wildcarded. Both buckets enforce encryption at rest (SSE-S3 or KMS) and block public access; clients get scoped presigned URLs rather than any AWS credentials.
Failure modes. Burst -> SQS buffers. Processor bug -> retries then DLQ + alarm, rest of queue unaffected. Duplicate event -> idempotent keys. AZ issue -> S3/SQS/Lambda/CloudFront are all multi-AZ regional services. Hot serving -> CloudFront cache offloads origin.
The make-or-break instincts: upload directly to S3 via presigned URLs (never proxy big files through Lambda/API Gateway), put a queue between S3 events and the processor so bursts buffer and failures land in a DLQ, make processing idempotent because S3 events and SQS are at-least-once, and serve via CloudFront with OAC instead of a public bucket. Candidates who wire S3 straight to Lambda with no buffer, ignore duplicate delivery, or make buckets public reveal they haven't run an event-driven pipeline in production. The senior signal is naming at-least-once delivery and the DLQ/idempotency response to it.
AWS/aws-databases/dynamodb
You need a strongly consistent read in DynamoDB (read the latest committed write). Select all access patterns where a strongly consistent read is actually available.#
Options
Pick every one that applies.
Show answer
Strongly consistent reads are available only on a base table and on local secondary indexes, opted into per request with ConsistentRead: true (reads are eventually consistent by default). Global secondary indexes keep their own asynchronously-replicated copy and are eventually consistent only — requesting a strong read on a GSI is rejected. DynamoDB Streams deliver change records eventually, not as consistent point reads. Routing a read path through a GSI when you need the latest write is the common design mistake.
Strongly consistent reads are supported only on base tables and local secondary indexes, because an LSI shares the partition's storage with the table. Reads default to eventually consistent; you opt into strong consistency per-request with ConsistentRead: true. Global secondary indexes (c) maintain their own asynchronously-updated copy of the data, so they are eventually consistent only — passing ConsistentRead: true to a GSI query is an error. DynamoDB Streams (d) deliver change records eventually, not as consistent point reads. The GSI limitation is the classic gotcha: people design a read path through a GSI and then discover they can't get a strong read there.
Related interview questions
The other 89 questions
This page shows 10. A free account opens the rest and marks your answers, which a page of answers can't do. Miss one and it returns a few days later, then a week after that, until you stop missing it.
Free · the whole bank · 100 graded answers per 30 days · written feedback and job-ad quizzes on the paid plan