AWS Interview Questions – Core Concepts to Advanced Cloud Architecture
Reviewed by Mark Dickie · Last updated
AWS (Amazon Web Services) is a cloud platform offering on-demand compute, storage, networking, databases, machine learning, and dozens of other managed services, all billed by consumption. For an AWS interview at any level, you need a firm grip on the shared responsibility model, the core service families (compute, storage, networking, database), and how those pieces fit together into fault-tolerant, cost-aware architectures. Mid-level and senior roles typically go further: expect questions on IAM policy evaluation, VPC routing, data durability trade-offs, and when to pick one service over a near-identical alternative. The quiz below covers the full difficulty range, so candidates preparing for a cloud-associate screen and those aiming at a solutions-architect panel will both find useful material.
What does an AWS interview actually test?
Interviews almost never stop at "name an AWS service." Recruiters want to see that you can reason about why you'd choose a service, not just that you know it exists. A question about S3, for example, might really be testing whether you understand eventual consistency, lifecycle policies, or the cost difference between storage classes.
The broad skill areas an interviewer covers tend to map like this:
| Skill area | What the question really probes | |---|---| | IAM & security | Policy evaluation order, least-privilege design, cross-account access | | Compute (EC2, Lambda, ECS/EKS) | When to use each, scaling behaviour, cold-start trade-offs | | Storage (S3, EBS, EFS, Glacier) | Durability vs. availability, storage class selection, pricing model | | Networking (VPC, subnets, Route 53) | Routing, security groups vs. NACLs, private vs. public connectivity | | Databases (RDS, Aurora, DynamoDB) | Read replicas, partition keys, consistency models, failover | | Architecture patterns | High availability, multi-region, event-driven design, decoupling | | Cost & billing | Reserved vs. On-Demand vs. Spot, tagging strategy, Cost Explorer |
How should I structure my AWS interview prep?
Work through the layers from the ground up. Skipping to advanced architecture questions before you can explain a subnet CIDR block or an S3 bucket policy tends to produce answers that sound right but fall apart under follow-up.
- Start with the global infrastructure model: regions, Availability Zones, and edge locations — these concepts underpin almost every availability question.
- Get the shared responsibility model solid. Know exactly where AWS's responsibility ends and yours begins for compute, managed databases, and serverless functions; this comes up at every seniority level.
- Practise IAM from scratch: users, groups, roles, and policies. Walk through policy evaluation (explicit deny beats everything, then explicit allow, then implicit deny) until it is automatic.
- Work through the main compute options side by side. Know the cases where Lambda beats EC2, where ECS Fargate beats both, and where a bare EC2 instance is still the right call.
- For storage, memorise the S3 storage classes and their retrieval-time guarantees. Interviewers use these to test whether you understand cost vs. latency trade-offs under real constraints.
- Revisit networking last, because VPC concepts (route tables, NAT gateways, Transit Gateway, PrivateLink) click faster once you already have a mental model of how traffic flows between services.
One practical note: AWS certifications (Cloud Practitioner, Solutions Architect Associate, Developer Associate) are not required for most roles, but their exam objectives are a reliable map of what interviewers consider in-scope knowledge at each level.
At a glance
| Questions | 15 |
|---|---|
| Difficulty | 2–5 of 5 |
| Formats | Multiple choice, Multiple answer, True / false, Short answer, Flashcard, Ordering, Fill in the blank, Find the bug, Design exercise |
What you'll review
- s3
- security groups
- iam policies
- multi az
- instance profiles
- dynamodb
- sqs
- s3 storage classes
- lambda
- vpc
- load balancers
- ebs
Practice questions
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
- Strong read-after-write: the GET is guaranteed to return the just-written object
- Eventual consistency: the GET may return a 404 until replication settles
- Strong consistency only if you enable Versioning on the bucket
- Strong consistency only within a single Availability Zone
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
- Security groups are stateful — return traffic for an allowed inbound connection is permitted automatically, regardless of outbound rules
- The default outbound rule that allows all traffic is what lets the response out
- Response traffic on ephemeral ports is exempt from all security-group evaluation
- Security groups only filter inbound traffic; outbound is never evaluated
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-iam-security/iam-policies
A user has an identity policy that Allows s3:DeleteObject, but a separate attached policy explicitly Denies s3:DeleteObject on the same bucket. What is the result of a delete request?
Options
- Denied — an explicit Deny in any applicable policy always overrides any Allow
- Allowed — the explicit Allow and explicit Deny cancel out, defaulting to Allow
- Allowed — the more specific (last-attached) policy wins
- Denied only if the two policies are in the same JSON document
Show answer
The request is denied. IAM is deny-by-default, and an explicit Deny in any applicable policy always overrides every Allow — there is no 'Allow wins' and no cancelling-out. Policies are unordered, so 'last attached wins' is false, and it is irrelevant whether the Allow and Deny live in the same document. This is exactly how guardrails such as Service Control Policies and permission boundaries cap permissions that no downstream Allow can re-grant.
IAM evaluation is deny-by-default with one absolute rule: an explicit Deny anywhere in any applicable policy short-circuits the decision to Deny, regardless of how many Allows exist. There is no 'Allow overrides Deny' and no cancelling-out. Policies are not ordered, so 'last attached wins' is fiction, and it makes no difference whether the statements share a document. This is the mechanism behind guardrails like SCPs and permission boundaries — you Deny broadly to cap permissions no downstream Allow can re-grant.
AWS/aws-reliability/multi-az
Your RDS instance is read-bound and you enable Multi-AZ to 'spread the read load.' Read latency doesn't improve. Why?
Options
- A Multi-AZ standby is for failover only — it is synchronously replicated but not readable; read scaling needs read replicas
- Multi-AZ only helps reads once you also enable Performance Insights
- The standby is readable, but only after a manual promotion
- Multi-AZ load-balances reads only for Aurora, not for standard RDS engines
Show answer
A Multi-AZ standby is a failover target, not a read endpoint. Its data is replicated synchronously to another Availability Zone, and on primary failure RDS automatically fails over to it (usually under a minute), but you cannot connect to or read from it. To scale read throughput you add read replicas, which replicate asynchronously and serve traffic on their own endpoints with some lag. Multi-AZ buys availability and durability; read replicas buy read capacity.
A Multi-AZ standby exists purely for high availability: data is synchronously replicated to it in another AZ, and on primary failure RDS fails over to it (DNS repoint, typically under a minute). You cannot connect to or read from the standby. To scale reads you create read replicas, which use asynchronous replication and serve read traffic at their own endpoints (accepting some replication lag). Conflating 'two copies' with 'read scaling' is one of the most common RDS interview misconceptions — Multi-AZ is durability/availability, read replicas are throughput.
AWS/aws-iam-security/instance-profiles
You created an IAM role with the right S3 permissions and a trust policy for EC2, but your application on the instance still can't get credentials. What is the most likely missing piece?
Options
- The role isn't attached to the instance via an instance profile — EC2 consumes a role only through an instance profile container
- You need to hardcode the role's access key and secret in the app's config
- The instance must be rebooted before any IAM role takes effect
- EC2 instances can only assume roles in the same Availability Zone as the role
Show answer
EC2 consumes an IAM role only through an instance profile — a container that holds one role and is what actually attaches to the instance. Creating the role isn't enough; it must be wrapped in an instance profile and that profile attached (the console does this automatically, but the CLI/SDK/CloudFormation do not). Once attached, the SDK pulls temporary, auto-rotated credentials from the Instance Metadata Service. Roles have no static keys to hardcode and are not Availability-Zone scoped.
An EC2 instance cannot reference an IAM role directly — it references an instance profile, which is a container that holds exactly one role. The console creates the profile transparently when you attach a role, but with the CLI/SDK/CloudFormation you can create the role and forget to wrap it in a profile (or attach the profile). Once attached, the SDK/CLI on the box transparently pulls temporary, auto-rotated credentials from the Instance Metadata Service (IMDSv2). Roles have no long-lived access keys to hardcode (b is the anti-pattern this design exists to kill), no reboot is required, and roles are global, not AZ-scoped.
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
GetItemon a base table withConsistentRead: true- A
Queryon a local secondary index (LSI) withConsistentRead: true - A
Queryon a global secondary index (GSI) - A read from a DynamoDB Stream
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.
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.
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/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-compute/lambda
What is a Lambda cold start, and name at least two ways to reduce its impact on latency-sensitive requests.
Show answer
A cold start is the extra latency incurred when Lambda has to create a fresh execution environment for an invocation — downloading/unpacking the code, starting the runtime, and running your initialization (init phase) — because no warm environment is available to reuse. Subsequent invocations reuse the warm environment and skip that cost. Ways to reduce the impact: configure Provisioned Concurrency to keep N environments pre-initialized and warm; use SnapStart (e.g. for Java) to restore from a snapshot; trim the deployment package and dependencies so init is faster; move heavy setup (SDK clients, DB connections) into the init phase so it's reused and out of the request path; right-size memory (more memory = more CPU = faster init); and avoid unnecessary VPC attachment. The init phase is also billed, so cold starts cost money as well as latency.
Cold start = the one-time cost of spinning up a new execution environment (init phase) when none is warm to reuse. The signal is whether the candidate knows the real levers: Provisioned Concurrency / SnapStart to pre-warm, slimmer packages and right-sized memory to shorten init, and moving reusable setup into the init phase. Naming Provisioned Concurrency as the only answer is shallow — it costs money around the clock, so the better engineers weigh it against optimizing the function itself.
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-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
- Route 53 resolves app.example.com to the ALB's DNS name / IP
- The request hits the ALB's HTTPS listener, which terminates TLS
- A listener rule matches the request and selects a target group
- The ALB picks a healthy target from that group (only instances passing health checks)
- The ALB forwards the request to the chosen instance in its private subnet
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/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
Resource: "*"grants the actions on every object in every bucket, not justreports-prod— it should bearn:aws:s3:::reports-prod/*Versionis wrong; an S3 policy must use"Version": "2025-01-01"s3:GetObjectands3:PutObjectcannot appear in the same statement- The policy is missing an explicit
Allowfors3:*, so nothing is permitted
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-networking/security-groups
A teammate's Terraform for a production bastion host includes this security-group ingress rule. The security scanner fails the build. What is the issue?
ingress {
description = "SSH"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}Options
- It opens SSH (port 22) to the entire internet (
0.0.0.0/0); it should be restricted to known admin CIDRs or fronted by SSM Session Manager from_portandto_portmust differ; a single-port rule is invalidprotocol = "tcp"is wrong for SSH; SSH requiresprotocol = "ssh"- Security groups cannot use CIDR blocks; ingress must reference another security group
Show answer
It opens SSH (port 22) to the entire internet (0.0.0.0/0); it should be restricted to known admin CIDRs or fronted by SSM Session Manager
cidr_blocks = ["0.0.0.0/0"] on port 22 exposes SSH to every IP on the internet, inviting brute-force and credential-stuffing attacks — a textbook misconfiguration scanners flag. Restrict it to specific admin/VPN CIDRs, or better, drop public SSH entirely and use AWS Systems Manager Session Manager (no open inbound port at all). The other options are wrong: a single-port rule with equal from_port/to_port is valid, the protocol field takes tcp/udp/etc. (not ssh), and security groups absolutely can use CIDR blocks as well as referencing other groups. Wide-open management ports are among the most common cloud breaches.
AWS/aws-storage/s3
Design a serverless image-upload and processing pipeline on AWS. Requirements Web/mobile clients upload original images directly; the backend must not proxy the bytes. Each upload is processed asynchronously into several resized/optimized variants (thumbnail, web, full). Processed images are served fast and globally; the system must absorb spiky upload bursts without dropping work. Assume Roughly 1M uploads/day with large, unpredictable spikes; images up to ~20 MB. A small team that wants minimal servers to operate. Walk through how clients upload, how processing is triggered and scaled, how you make it resilient to failures and bursts, how you serve the results, and the IAM/security posture. Call out the main failure modes and how the design absorbs them.
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.
Related interview questions
Job market
See aws salaries and hiring demand from live job postings.
Practice this for real
CodePrep turns your target job description into an adaptive quiz from a bank of tagged questions, scores your answers, and resurfaces the topics you miss.