AWS Interview-Level Questions cheat sheet · AWS

1.Foundations and Identity — Four Questions Every Interview Opens With

The first four questions test whether you understand the failure boundary and the identity model. Region versus Availability Zone is really a question about what multi-AZ does and does not protect against. The three identity questions test whether you know that a role has no password, that an explicit deny always wins, and that a credential which expires cannot be leaked permanently.

Key features

An Availability Zone is one or more discrete data centres with independent power, cooling and networking, physically separated inside one Region
Multi-AZ protects against the loss of a zone — it does not protect against a bad deploy, a corrupted row, a deleted bucket or a Region-wide event
A user is a long-lived identity with credentials; a role is an identity anything can assume to receive temporary credentials, and has no password
Identity-based policies attach to a principal and say what it may do; resource-based policies attach to a resource and name who may reach it
Evaluation order: an explicit deny always wins, then an organization SCP or permission boundary must allow, then an explicit allow is required — anything not allowed is denied
Temporary credentials expire on their own, which removes the rotation task and caps the useful life of a leaked credential to the session length

The four questions, the answer in one breath, and the follow-up that separates people

The four questions, the answer in one breath, and the follow-up that separates people
Question	Answer in one breath	The follow-up	What a weak answer sounds like
Region vs AZ. What does multi-AZ protect against?	A Region is a geographic area holding multiple Availability Zones; a zone is one or more discrete data centres with independent power and networking. Multi-AZ survives losing a zone.	"And what does it not protect against?"	"It makes you highly available" — with no failure it fails to contain
IAM user vs role vs policy vs resource policy	A user is a long-lived identity; a role is assumed for temporary credentials; an identity policy says what a principal may do; a resource policy says who may reach a resource.	"Which one lets an account you do not control read your bucket?"	Describing all four as "permissions" without the principal-versus-resource split
How does IAM policy evaluation work?	Explicit deny wins outright. Otherwise an SCP or boundary must allow, an explicit allow must exist, and anything unmatched is an implicit deny.	"You added an allow and access still fails — where do you look?"	"The most specific policy wins" — which is not how it works
Why should workloads use temporary credentials?	They expire without anyone rotating them, so a leak has a bounded lifetime and there is no long-lived secret to store on the instance at all.	"How does a task on ECS get them without any secret?"	"They are more secure" with no mechanism behind it

What each blast radius contains, and what it does not

Multi-AZ contains the middle ring. The two failures on the right cross every ring, which is why they need a different control entirely.

Signature

Region ⊃ AZ · user vs role · identity vs resource policy · deny > allow > implicit deny

Multi-AZ contains a zone failure and nothing else — not a bad deploy, not a corrupted row, not a deleted bucket. A role is permissions plus a trust policy and has no credentials until assumed. Explicit deny always wins, an allow is always required, and an unexplained AccessDenied on an encrypted object is usually the KMS key policy.

2.Networking and Traffic — Four Questions With One Precise Answer Each

These four have exact answers, which is why they are asked. A subnet is public because its route table sends 0.0.0.0/0 to an internet gateway — nothing else makes it public. A security group is stateful and a NACL is not. A NAT gateway reaches the internet and a VPC endpoint avoids it. And ALB, NLB and API Gateway differ by the layer they work at and what they can do with a request.

Key features

A subnet is public when its route table has a 0.0.0.0/0 route to an internet gateway — the name, the tags and the diagram are irrelevant
An instance in a public subnet still needs a public or Elastic IP to be reachable from the internet
Security groups are stateful and allow-only, attached to an interface; NACLs are stateless, allow and deny, evaluated in rule-number order at the subnet edge
A stateless NACL needs an explicit outbound rule for the ephemeral port range, which is the cause of most "the security group looks right" failures
A NAT gateway gives private subnets outbound internet access and costs per hour plus per gigabyte processed; gateway endpoints for S3 and DynamoDB carry that traffic without leaving the AWS network and without a data processing charge
ALB routes on HTTP content, NLB forwards TCP, UDP and TLS at layer 4 with a static IP per zone, and API Gateway adds authorization, throttling and usage plans in front of an API

The four questions, the precise answer, and the trap in each

The four questions, the precise answer, and the trap in each
Question	The precise answer	The follow-up	The trap
What makes a subnet public?	Its route table has a 0.0.0.0/0 route to an internet gateway. Nothing else does.	"It has that route and the instance is still unreachable — why?"	Answering "it has a public IP" — that is required as well, and it is not what makes the subnet public
Security group vs NACL	Security group: stateful, allow-only, attached to an interface. NACL: stateless, allow and deny, evaluated in rule-number order at the subnet edge.	"Outbound works and the reply never arrives. Which one is it?"	Saying NACLs are "a second layer of security groups" — the statelessness is the whole difference
NAT gateway vs VPC endpoint	NAT gives private subnets a route out to the internet. An endpoint reaches an AWS service without the traffic leaving the AWS network.	"Your workload pulls 4 TB a month from S3. Which do you use?"	Treating them as alternatives for the same job — they solve different problems and one of them is often free
ALB vs NLB vs API Gateway	ALB reads HTTP and routes on host, path and header. NLB forwards TCP, UDP and TLS at layer 4, with a static IP per zone. API Gateway is an API front door with authorization, throttling and usage plans.	"Your backend needs 60 seconds to respond. Which one is out?"	Picking API Gateway by default — the REST API integration timeout caps at 29 seconds

One packet, four decisions

Each of the four questions is a different point on the same path. Answering by property rather than by service name is what makes each answer precise.

Signature

route table → public · stateful vs stateless · NAT out vs endpoint inside · L7 / L4 / API front door

A subnet is public because of its route table. A security group is stateful and a NACL is not, which is why NACLs need ephemeral-port return rules. NAT reaches the internet; an endpoint avoids it, and the S3 gateway endpoint is free. ALB reads HTTP, NLB forwards TCP with a static IP, API Gateway adds authorization and stops at 29 seconds.

3.Compute — Choosing a Model, and the Two Lambda Questions

The compute questions test two different things. The first two ask what you give up and what you get back at each level of abstraction — an instance, a scheduled container, an invoked function. The last two are specific: concurrency is invocations in flight rather than requests per second, and throttling happens when that number hits a limit you or AWS set.

Key features

Lambda concurrency is the number of executions running at the same time, not a request rate — 100 requests per second each taking 200 ms is about 20 concurrent executions
The account default is 1,000 concurrent executions per Region, and it is adjustable through a quota increase
Reserved concurrency both guarantees capacity to a function and caps it; setting it to zero stops the function from running at all
Provisioned concurrency pre-initialises execution environments, which is the only setting that removes cold starts
Throttling returns a 429: a synchronous caller sees the error, an asynchronous invocation is retried by Lambda, and an event source mapping backs off and retries
Fargate removes instance management; ECS on EC2 keeps it in exchange for instance choice, GPU or specialised hardware, daemon workloads and higher density at sustained scale

The four compute questions, the answer, and the follow-up

The four compute questions, the answer, and the follow-up
Question	Answer in one breath	The follow-up	The trap
EC2 vs ECS vs Lambda	Decreasing control and decreasing operational surface. EC2 for full machine control, ECS for containerised services you still shape, Lambda for event-driven work that fits its execution model.	"Your service holds WebSocket connections for hours. Which is out?"	Answering by cost — the execution model rules options out long before price does
Fargate vs ECS on EC2	Fargate removes instance management and charges per task. EC2 capacity keeps instance choice, GPUs, daemon tasks and higher density, in exchange for patching and capacity planning.	"When is EC2 capacity clearly right?"	"Fargate is always simpler" — true, and not an argument on its own
How does Lambda concurrency work?	Concurrency is executions in flight — requests per second times average duration. The account default is 1,000 per Region; reserved concurrency caps and guarantees; provisioned concurrency pre-warms.	"Your function got slower. What happens to concurrency?"	Describing it as a request rate, which makes the duration term disappear
What causes Lambda throttling?	Demand above the available concurrency: the account limit, a reserved limit on the function, or burst capacity. The response is a 429, and what happens next depends on the invocation type.	"Who sees the 429, and who does not?"	Forgetting that async and event-source invocations retry, so throttling can be invisible in the caller

What you hand over at each level, and what Lambda concurrency counts

The top half is the trade you make. The bottom half is the arithmetic behind every Lambda concurrency question.

Signature

concurrency = rps × duration · default 1,000/Region · reserved caps · provisioned pre-warms

Rule options out by execution model before comparing cost. Lambda concurrency is requests per second times duration, not a rate — the account default is 1,000 per Region, and duration is what moves during an incident. Reserved concurrency caps as well as guarantees; only provisioned concurrency removes cold starts.

4.Data Stores — Four Comparisons, Four Different Axes

Each of these four pairs is compared on a different axis, and naming the axis is most of the answer. Multi-AZ versus read replica is availability versus read capacity. RDS versus Aurora is the storage layer. RDS versus DynamoDB is whether your access patterns are known in advance. Redis versus DynamoDB is whether the data is allowed to disappear.

Key features

A Multi-AZ instance deployment keeps a synchronous standby in another zone for automatic failover, and that standby serves no read traffic
A read replica is asynchronous, is readable, can lag, and can be promoted to a standalone instance — which makes it a scaling tool, not a high-availability one
Aurora replaces the storage layer: data is kept as six copies across three Availability Zones, and up to fifteen replicas read the same storage rather than replaying a log
Standard RDS runs the community engines on ordinary volumes, which is the right choice when you need exact engine behaviour, an extension Aurora lacks, or a smaller footprint
DynamoDB needs the access patterns before the table exists; a relational database lets you write the query later, and that flexibility is what you are trading away
ElastiCache is memory and may lose data on failover, so it accelerates a system of record and can never be one

The four pairs, the axis, and the follow-up that catches a memorised answer

The four pairs, the axis, and the follow-up that catches a memorised answer
Question	The axis	Answer in one breath	The follow-up
RDS Multi-AZ vs read replica	Availability vs read capacity	Multi-AZ is a synchronous standby for failover and serves no reads. A read replica is an asynchronous readable copy for scaling reads, and it can lag.	"Can a read replica be your high-availability story?"
RDS vs Aurora	The storage layer	Aurora replaces the storage engine — six copies across three zones, replicas reading shared storage, faster failover. RDS runs the community engine as it is.	"When would you deliberately not use Aurora?"
RDS vs DynamoDB	Are the access patterns known in advance?	Relational lets you write the query later. DynamoDB wants the patterns before the table and gives predictable latency at any size in return.	"Product asks for a new report next week. What changes?"
Redis vs DynamoDB	May the data disappear?	Redis is memory: sub-millisecond, rich structures, and may lose data on failover. DynamoDB is durable storage with single-digit millisecond reads.	"Where do you keep a shopping cart, and why?"

Four pairs, four axes

Each row names the axis first. Once the axis is named, the answer is a statement of what the workload needs rather than a preference between products.

Signature

standby (unreadable, automatic) vs replica (readable, lagging) · storage layer · patterns up front · may it vanish

Name the axis first. Multi-AZ is availability and its standby is unreadable; a replica is read capacity and it lags. Aurora is a different storage layer. DynamoDB wants the access patterns up front. Redis may lose data on failover, so it accelerates a system of record and never is one.

5.Messaging — Three Services, Two Queue Types, One Idempotent Consumer

SQS holds work until one consumer takes it. SNS pushes one message to every subscriber at once. EventBridge routes events to targets by matching their content. Standard queues trade ordering for throughput, FIFO trades throughput for ordering, and either way the consumer has to survive receiving the same message twice.

Key features

SQS is pull-based and point-to-point: a message is delivered to one consumer, which deletes it after processing
SNS is push-based fan-out: every subscription receives its own copy, and a failed HTTP subscriber does not stop the others
EventBridge routes on event content, supports many AWS and third-party sources, and can archive and replay events — which SNS cannot
The default composition is SNS to several SQS queues: fan-out from the topic, and a durable buffer with its own retry behaviour per consumer
Standard queues offer effectively unlimited throughput with best-effort ordering and at-least-once delivery; FIFO queues order per MessageGroupId and default to 300 requests per second per API action, or 3,000 messages per second with batching
Idempotency belongs in the consumer regardless of queue type, because a visibility timeout that expires mid-processing redelivers a message that is already being handled

The three messaging questions, the answer, and the follow-up

The three messaging questions, the answer, and the follow-up
Question	Answer in one breath	The follow-up	The trap
SQS vs SNS vs EventBridge	Queue: one consumer pulls work. Topic: every subscriber is pushed a copy. Bus: rules route on event content, with archive and replay.	"Two teams need the same event. Which do you reach for?"	Comparing them on throughput instead of on coupling
Standard vs FIFO SQS	Standard is effectively unlimited throughput with best-effort ordering. FIFO orders strictly within a MessageGroupId and defaults to 300 requests per second per action, or 3,000 messages per second with batching.	"Your FIFO queue is throttling. What is the first thing to check?"	Choosing FIFO for "safety" when nothing in the workload needs ordering
How do you make an SQS consumer idempotent?	Derive a stable key from the message body, record it with a conditional write before the side effect, and treat a duplicate as a successful no-op.	"Where does the key come from, and how long do you keep it?"	Using the message id, which changes when a producer resends the same logical event

Who is waiting, and who knows about whom

The bottom row is the composition used most often in production: the topic fans out, and each queue gives its consumer an independent buffer and retry story.

Command

text

queue = one consumer, work buffered · topic = every subscriber, pushed · bus = content-matched routing + replay · consumer = idempotent either way

Queue for work one consumer takes, topic for a fact several consumers need, bus for routing you do not want the producer to know about — and SNS into SQS when you want both fan-out and per-consumer buffering. FIFO costs throughput for ordering. The consumer is idempotent either way, keyed on the business event rather than the message id.

6.The Seven "How Would You…" Questions

The scenario questions are open on purpose. They are not testing whether you know the services — they are testing whether you answer in a defensible order, name the constraint that shapes the design, and say what you would check first. A structured answer to any of these beats a longer answer to all of them.

Key features

Securing a bucket starts with Block Public Access at the account level, then a bucket policy requiring TLS, then default encryption, then access logging
A React SPA on CloudFront and S3 needs a private bucket reached through origin access control, a certificate in us-east-1, and 403 and 404 mapped to index.html for client-side routing
Django on ECS runs migrations as a separate one-off task before the new service revision rolls, never in the container entrypoint of every task
Zero-downtime schema change means expand, deploy code that tolerates both shapes, backfill in batches, then contract in a later release
A multi-Region DR answer starts with the agreed RPO and RTO numbers, because those select the strategy rather than the other way round
A 5xx investigation moves in one direction — edge, load balancer, targets, dependencies — and the first branch is whether one target is failing or all of them

The seven scenarios, in the order the answer should come out

The seven scenarios, in the order the answer should come out
Scenario	The answer, in order	The detail that marks experience
Secure an S3 bucket	Block Public Access at the account and the bucket → Object Ownership set to bucket-owner-enforced so ACLs stop mattering → a bucket policy denying `aws:SecureTransport` false → default encryption, KMS if the data warrants it → versioning → server access or CloudTrail data events → a VPC endpoint policy if access should only come from your network	Mentioning that `kms:Decrypt` on the key is a separate grant, so an `s3:GetObject` allow alone still fails
Serve React with CloudFront and S3	Build to static output → private bucket, no website hosting → CloudFront with origin access control → ACM certificate in us-east-1 → 403 and 404 mapped to `/index.html` with a 200 so client-side routes resolve → long cache on hashed assets, no-store on `index.html` → invalidate `/index.html` on deploy	The certificate Region and the SPA error mapping — both are the things that fail on a first attempt
Deploy Django on ECS	Image to ECR → task definition with the web command, a second one for workers → Fargate behind an ALB in private subnets → RDS and ElastiCache in data subnets → secrets injected from Secrets Manager by ARN → static and media on S3 behind CloudFront → migrations as a one-off task before the new revision rolls → deep health check → task role for the app, execution role for the pull	Running migrations once as their own task rather than in every container's entrypoint
Zero-downtime database migrations	Expand: add the new column or table, nullable, no destructive change → deploy code that writes both and reads the old → backfill in batches with a bounded rate → switch reads to the new shape → contract in a later release once nothing references the old one	Saying that expand and contract must be separate deploys, because a rollback in between has to still work
Multi-Region disaster recovery	Get the agreed RPO and RTO first → pick the strategy those numbers allow: backup and restore, pilot light, warm standby, or active/active → replicate the data accordingly → same infrastructure code in both Regions → Route 53 health checks for the switch → decide the failback path → drill it on a schedule	Naming the data as the hard part — global tables and cross-Region replication have their own consistency behaviour
Investigate a sudden 5xx spike	Is it the edge or the origin → one target or all targets → did anything deploy or change in the window → dependency health: database connections, cache, downstream APIs → quotas and throttling → pick one failing request and follow its correlation id end to end	Checking whether the error rate is a rate or a count — a traffic drop can raise the percentage with no new failures
Reduce the bill without blind downsizing	Group by usage type, not by service → separate capacity you chose from architecture that accumulated → remove the accumulated first: gateway endpoints, log retention, storage class, orphaned volumes and snapshots → then rightsize on peak, not average → then commit to what is left with Savings Plans → leave a budget alert behind	Naming NAT data processing and log ingestion unprompted, and saying that removal beats shrinking

The opening move for each of the seven

The opening move is the whole difference between a structured answer and a list of services. Each one narrows the problem before any component is named.

Signature

BPA first · what is dynamic · migrations as their own task · expand/contract · RPO first · edge→inward · group by usage type

Open with the move that narrows the problem: Block Public Access, what is actually dynamic, where migrations run, expand-then-contract, the agreed RPO and RTO, edge-to-inward, group by usage type. Then name the constraint that decides between options. A structured answer to one scenario beats a service list for all seven.