Question 1

How do you approach an open-ended AWS design question?

Accepted Answer

Clarify requirements before designing: expected scale, latency targets, availability and recovery objectives, data residency and compliance, budget, team skills, and what already exists. Then state assumptions, sketch a high-level design, and go deeper where probed, naming trade-offs at each decision rather than presenting one answer as obviously correct. The most common failure is naming services in the first thirty seconds. Asking two or three sharp questions — "what is the read to write ratio?", "is that 99.99% a hard requirement or an aspiration?" — is worth more than any specific architecture.

Question 2

What are the Well-Architected pillars and how do you use them in a design answer?

Accepted Answer

Operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. Use them as axes for evaluating a design, and name explicitly which pillar you are trading away in a given decision — because improving one usually costs something on another. Using the framework as a structure prevents presenting a technically elegant design that is operationally unmaintainable. Naming the trade-off rather than claiming a design is optimal on every axis is what a senior interviewer wants to hear.

Question 3

Design a URL shortener handling a billion redirects a month.

Accepted Answer

Reads dominate, so optimise the read path. Generate short codes from a counter in base62 or a hash with collision check. Store the mapping in DynamoDB keyed by short code. Serve redirects from Lambda or Fargate behind CloudFront, cached at the edge because the mapping is immutable, with DynamoDB DAX or ElastiCache for hot codes. Publish click events to Kinesis and land them in S3 for analytics rather than counting synchronously. The two decisions being tested are separating the read path from analytics — never increment a counter in the redirect request — and recognising that an immutable mapping is CDN-cacheable, which removes almost all traffic from compute.

Question 4

Design a video streaming platform on AWS.

Accepted Answer

Upload directly to S3 with presigned URLs so bytes never traverse your servers. An S3 event triggers transcoding with MediaConvert or Fargate jobs, producing multiple bitrates and HLS or DASH segments in an output bucket. Serve through CloudFront with signed cookies for entitlement. Metadata in DynamoDB or Aurora, recommendations from Personalize, and playback events through Kinesis and Firehose into S3 and Redshift for analytics. The decisions that matter are direct-to-storage upload, asynchronous transcoding rather than blocking a request, signed cookies rather than signed URLs because a player fetches hundreds of segments, and a separate output bucket to avoid recursive triggers.

Question 5

Design a multi-tenant SaaS platform on AWS.

Accepted Answer

Choose the isolation model first: pooled with a tenant identifier and row-level or IAM-condition isolation for many small tenants; silo with a database or account per tenant for the strongest isolation; or a bridge model between them. Then design tenant-aware identity with Cognito, per-tenant throttling to prevent noisy neighbours, per-tenant cost attribution, and a data model allowing a single tenant to be restored. Per-tenant restore is the requirement that most often forces stronger isolation than a team initially wants, and noisy-neighbour control is the second. Naming both as design drivers, rather than defaulting to pooled, is what shows real multi-tenant experience.

Question 6

Design a system to process 10 million IoT readings per minute.

Accepted Answer

Devices publish through IoT Core or directly to Kinesis Data Streams with a partition key that distributes evenly. Managed Flink or Lambda consumers validate and aggregate; Firehose lands raw records as partitioned Parquet in S3. Recent per-device state goes to DynamoDB or Timestream for low-latency lookup, aggregates to Redshift or Athena for analytics. Alerting rules run in the stream, with S3 lifecycle tiering for long retention. The partition key choice is the specific technical decision being probed — a low-cardinality key creates a hot shard. Separating the serving store from the analytics store, rather than querying the warehouse from the device path, is the other differentiator.

Question 7

Design a globally available e-commerce checkout.

Accepted Answer

CloudFront and Global Accelerator in front of regional stacks. Orders and inventory in DynamoDB global tables or Aurora Global Database depending on the consistency requirement, with writes homed to one region if strong consistency across regions is needed. ElastiCache for cart and session, SQS and EventBridge for order events consumed idempotently, Step Functions for the fulfilment saga with compensation, and a transactional outbox or DynamoDB Streams so events cannot diverge from the database. The consistency question is the crux: DynamoDB global tables resolve conflicts last-writer-wins, which is unacceptable for inventory decrement. Recognising that and homing writes, or using conditional writes with a single-region authority, is the senior answer.

Question 8

How do you design for 99.99% availability?

Accepted Answer

That allows about 52 minutes of downtime a year, so every layer needs redundancy: multi-AZ compute behind a load balancer sized to survive an AZ loss, a database with automatic failover, health checks and automated replacement, progressive delivery with fast rollback, and rehearsed recovery. Operational maturity matters as much as architecture. The insight that scores is that availability is limited by your deployment process as much as by infrastructure, because most downtime comes from change. A perfectly redundant system that ships a bad change without a canary will not reach four nines.

Question 9

Design a real-time analytics dashboard for millions of events an hour.

Accepted Answer

Events into Kinesis, Managed Flink for windowed aggregation with event-time processing and late-data handling, writing pre-aggregated results to DynamoDB or Timestream for sub-second dashboard reads and to S3 for the warehouse. The dashboard queries aggregates, never raw events. A daily batch job recomputes aggregates to correct for late or duplicated data. The two things being tested are never querying raw data from a dashboard, and having a batch path that reconciles the streaming path. Streaming aggregates drift over time, and a design without reconciliation silently produces wrong numbers.

Question 10

Design a data platform serving both operational and analytical needs.

Accepted Answer

Keep them separate. Operational stores — Aurora, DynamoDB — serve the application. Change data capture through DMS, DynamoDB Streams or zero-ETL integrations, plus event streams through Kinesis, feed an S3 and Redshift warehouse with raw, curated and aggregate layers. Governance through Lake Formation. Analysts and dashboards query the warehouse, never the operational database. The rule to state plainly is that analytical queries must never hit the production database, because an unconstrained query can take down the application. Naming CDC rather than nightly extracts is the modern part, reducing both latency and source load.

Question 11

How do you decide between a monolith and microservices?

Accepted Answer

Start with a well-structured monolith unless there is a specific reason not to — it is simpler to develop, test, deploy and debug. Split when independent scaling, independent deployment cadence, team autonomy or technology diversity genuinely require it. Each service adds network calls, failure modes, observability burden and operational surface. The honest position — that microservices are an organisational solution to a team-scaling problem more than a technical one — is what senior interviewers respect. Recommending microservices for a five-person team is a red flag rather than ambition.

Question 12

How do you apply the CAP theorem in an AWS design?

Accepted Answer

Under a network partition you must choose availability or consistency. Aurora and RDS choose consistency — they refuse rather than serve divergent data. DynamoDB global tables choose availability with last-writer-wins. Choose per data type: money and inventory need consistency, a recommendation panel does not. Applying the choice per data path rather than per system is the mature framing. Naming that DynamoDB global tables silently discard a concurrent write is what shows you understand the consequence rather than the theorem.

Question 13

Design an API platform for external developers.

Accepted Answer

API Gateway with Cognito or a Lambda authoriser, usage plans with per-key throttling and quotas, request validation, WAF and CloudFront in front. Backends on Lambda or Fargate behind an internal load balancer. Secrets in Secrets Manager, per-consumer metrics for usage analytics and billing, a developer portal, versioned endpoints and a published deprecation policy. The elements external developers actually care about are versioning and deprecation policy, which are governance decisions rather than infrastructure. Naming them alongside the technical stack shows you have run a platform rather than only built an API.

Question 14

How would you architect for data residency across multiple countries?

Accepted Answer

Regional deployments with SCPs restricting permitted regions and the aws:RequestedRegion condition. Partition data by jurisdiction — separate accounts and regional stacks, or a partitioned model with enforced routing. Ensure backups, replicas and logs also stay in region, and consider Outposts or Local Zones where no region satisfies the requirement. Backups and replicas are the part designs forget: a cross-region backup copy silently moves data out of jurisdiction. Enforcing residency with an SCP rather than convention is the control that actually holds.

Question 15

Design a chat or messaging backend on AWS.

Accepted Answer

API Gateway WebSocket API with connection IDs stored in DynamoDB, or AppSync subscriptions for a managed real-time layer. Messages in DynamoDB with a conversation partition key and timestamp sort key. Lambda or Fargate for the message handler, SNS or EventBridge for fan-out to push notifications via Pinpoint, S3 with presigned URLs for media, and Kinesis into the warehouse for analytics. The state you must manage is the connection registry, because API Gateway does not track which user owns which connection. Cleaning up stale connections on disconnect and on send failure is the operational detail that shows implementation experience.

Question 16

Design a batch processing system running nightly over terabytes.

Accepted Answer

Land raw data in S3 partitioned by date in a columnar format. Orchestrate with Step Functions or MWAA expressing dependencies, retries and backfills. Process with Glue, EMR Serverless or Batch on Spot capacity since the work is delay-tolerant. Write outputs idempotently keyed by partition so a rerun replaces rather than duplicates, and alert on data freshness and record-count reconciliation. Idempotent partition-keyed writes are what make reruns safe, which is what you need at 3am when a job fails halfway. Choosing Spot because the workload tolerates interruption is the cost decision that follows from the workload shape.

Question 17

How would you handle a 100x traffic spike during a sale?

Accepted Answer

Pre-scale rather than relying on reactive autoscaling — warm capacity, pre-provisioned concurrency, capacity reservations for the peak window. Put as much as possible behind CloudFront so the origin sees a fraction of traffic. Protect downstream systems with queues, rate limits and circuit breakers. Load test at the target, and have a degradation plan naming which features you disable to protect checkout. The graceful-degradation plan is the senior element — deciding in advance that recommendations and reviews are switched off before checkout is affected. Reactive autoscaling alone cannot absorb an instantaneous 100x, which is why pre-scaling and load testing are non-negotiable.

Question 18

How do you design a system to be observable from the start?

Accepted Answer

Instrument with OpenTelemetry so metrics, traces and logs share context. Define SLIs and SLOs per user-facing operation before launch. Emit structured logs with request, tenant and version identifiers. Add deployment markers to dashboards. Write the runbook alongside the service, and make the first alert a symptom-based SLO burn-rate alert rather than a CPU threshold. Defining the SLO before launch changes design decisions, because you have to decide what "working" means. Teams that add observability after the first outage always find they cannot answer the question they most need to.

Question 19

How do you decide where to put a cache and what are the risks?

Accepted Answer

Cache as close to the consumer as possible — CloudFront at the edge for cacheable responses, ElastiCache for computed results and sessions, DAX for DynamoDB, database query cache last. The risks are stale data, cache stampedes when a hot key expires, and the origin being unable to cope if the cache empties. The cache-failure scenario is the one to raise: a system running at a 95% hit rate may receive twenty times the load if the cache empties. Sizing the origin for a cold cache, or warming it, is the mitigation people forget.

Question 20

How do you design when one dependency is much less reliable than the rest?

Accepted Answer

Isolate it: put a queue in front so its slowness does not propagate, add a circuit breaker so repeated failures fail fast, set aggressive timeouts, use bulkheads so its connection pool cannot starve others, and design a degraded mode where the rest of the system works without it. The failure being prevented is cascading collapse, where one slow dependency consumes all threads and takes down the whole service. Naming bulkheads and timeouts specifically matters — retries alone make a slow dependency worse.

Question 21

How do you design an idempotent API?

Accepted Answer

Accept an idempotency key from the client, store it with the result of the first successful execution, and return that stored result on retry rather than re-executing. Make the underlying operation naturally idempotent where possible, and ensure the key store and the business change commit together — a conditional write in DynamoDB, or the same transaction in a relational store. The transactional coupling is the subtle part: recording the key outside the transaction that does the work leaves a window where a crash produces a duplicate or a lost operation. Naming that requirement is the mark of someone who has implemented it correctly.

Question 22

What is the strangler fig pattern and how would you apply it on AWS?

Accepted Answer

Incrementally replace a legacy system by routing specific functionality to new services while the rest continues on the old one, growing the new system until the old can be removed. On AWS, put an ALB or API Gateway in front routing by path to either the legacy backend — reachable over Direct Connect or as an IP target — or to new services. The routing layer in front of both is the concrete mechanism that makes it practical rather than theoretical. The organisational requirement is choosing the slice order by business value and risk, not by what is technically easiest.

Question 23

How do you handle schema evolution across services?

Accepted Answer

Use a schema registry — Glue Schema Registry or EventBridge schemas — to enforce compatibility; make changes additive since new optional fields are safe while removals and type changes are not; version the contract explicitly; have consumers ignore unknown fields; and use expand-and-contract for anything breaking, deploying producers and consumers in a compatible order. The ordering rule is what people get wrong: for an additive change, deploy consumers first so they tolerate the new field, then producers. Being able to state the deploy order is the applied version of the answer.

Question 24

Design a notification system supporting email, SMS and push at scale.

Accepted Answer

Producers publish notification events to EventBridge. A router applies user preferences, quiet hours and deduplication, then enqueues per-channel work in SQS so each provider is rate-limited independently. Channel workers on Lambda call SES, SNS or Pinpoint with retries and circuit breakers, writing delivery status to DynamoDB. Templates in a versioned store, dead-letter queues with alarms, and delivery events into the warehouse. Per-channel queues are the key decision because each provider has different rate limits and failure behaviour, and a shared queue lets one slow provider block the others. Deduplication and quiet hours are the product requirements most technical answers omit.

Question 25

How would you architect to minimise vendor lock-in?

Accepted Answer

Prefer portable abstractions where the cost is low — containers, Kubernetes, PostgreSQL-compatible databases, open formats like Parquet and Iceberg, OpenTelemetry — and isolate provider-specific services behind interfaces. But accept lock-in deliberately where a managed service delivers disproportionate value, and document that decision with its exit cost. The honest position is that avoiding all lock-in means rejecting the managed services that make cloud worth using, so the goal is deliberate, documented lock-in. Presenting portability as a free good is the weaker answer.

Question 26

How do you design for a hard latency requirement of 50 milliseconds at p99?

Accepted Answer

Put compute close to users with CloudFront, Global Accelerator and multi-region deployment; cache aggressively at the edge; keep the request path short with few sequential hops; use a low-latency data store such as DynamoDB or ElastiCache rather than a query engine; avoid cold starts with provisioned concurrency; and measure end to end from the client, not server-side. Measuring from the client is what changes designs, because server-side p99 excludes DNS, TLS handshake and network time that dominate for distant users. A design meeting the target on the server and missing it for real users has failed.

Question 27

How do you evaluate build versus buy?

Accepted Answer

Compare total cost of ownership including engineering time to build and maintain, opportunity cost of not building something differentiating, time to market, and vendor risk. Build what differentiates the business; use managed services for everything else. Reassess when scale changes the economics. The framing is differentiation: nobody wins by building their own message queue, and the maintenance cost is invisible until it breaks. Being willing to say "we should not build this" is a senior contribution.

Question 28

Design a system for financial transactions with exactly-once semantics.

Accepted Answer

Accept the request with an idempotency key, persist it transactionally with the transaction record — a conditional write in DynamoDB or the same database transaction in Aurora — and return the stored result on retry. Publish downstream events from a transactional outbox or DynamoDB Streams so they cannot diverge from committed state. Make consumers idempotent, use Step Functions with compensation for multi-step flows, and reconcile against the ledger in batch daily. The core point is that exactly-once end to end comes from idempotency plus transactional state, not from a messaging guarantee. Daily reconciliation is the control that catches whatever the design missed, and financial systems always have one.

Question 29

How do you approach capacity planning on AWS?

Accepted Answer

Measure current utilisation and growth, model demand including seasonal peaks, identify the binding constraint per component, then check service quotas — EC2 vCPU, Lambda concurrency, Elastic IPs, API rate limits — well before you need them, because increases take days. Use capacity reservations for known peaks and autoscaling for the variable portion, and load test at the target. Quotas are the constraint people forget, and they fail at exactly the wrong moment — during the spike you planned for. Naming quota review as part of capacity planning, rather than only instance sizing, is a practical differentiator.

Question 30

How would you design a system with strict data deletion requirements?

Accepted Answer

Know where every copy lives — primary store, replicas, backups, caches, logs, warehouse, exports — and design deletion to reach all of them. Use crypto-shredding where physical deletion from immutable backups is impractical: encrypt per subject with a key you can destroy. Set lifecycle policies so data expires by default, and log deletion actions for proof. Crypto-shredding solves the backup problem, since you cannot selectively delete one record from an immutable snapshot. Naming logs and analytics copies as places data hides is what makes the answer complete rather than aspirational.

Question 31

How do you design a system that degrades gracefully?

Accepted Answer

Identify the critical path that must work and the non-essential features. Put timeouts and circuit breakers on non-critical dependencies, serve stale cached data when a dependency is down, use feature flags to disable expensive features under load, and shed load with rate limiting rather than letting everything slow down equally. Load shedding is the counter-intuitive part: refusing some requests quickly is better than serving all of them slowly, because slow requests hold resources and cause cascading failure. Deciding what to shed in advance is a design decision, not an incident-time one.

Question 32

What questions would you ask before choosing a database on AWS?

Accepted Answer

What is the data shape and are the query patterns known in advance; what is the read and write volume and ratio; is strong consistency required and at what scope; what are the latency requirements; does it need to scale writes horizontally; what are the availability and recovery objectives; what residency constraints apply; and what does the team already know how to operate. The last question is the one candidates omit and interviewers value, because a technically optimal database the team cannot operate is a worse choice than a familiar one. Whether query patterns are known in advance is the specific question separating DynamoDB from a relational store.

Question 33

How would you review someone else's AWS architecture?

Accepted Answer

Check against the pillars: is there a single point of failure; is identity least-privilege with no long-lived keys; is data encrypted and access-controlled at the right granularity; what is the cost shape and are there enforcement points; can it be deployed and rolled back safely; is it observable with defined SLOs; and does it match the team's operational capability. The last check is what most reviews miss: a design requiring operational maturity the team does not have will fail regardless of technical merit. Framing review as fit-for-team as well as fit-for-purpose is a senior perspective.

Question 34

How do you handle a requirement you believe is wrong?

Accepted Answer

Ask what problem it is meant to solve and what happens if it is not met, quantify the cost of meeting it, and propose an alternative that solves the underlying problem more cheaply. If it is confirmed after that discussion, implement it and document the trade-off rather than quietly building something else. Interviewers ask this to see whether you push back constructively and then commit. A stated 99.99% requirement that turns out to be aspirational is the example that works well — quantifying what the fourth nine costs usually changes the conversation productively.

Question 35

What is static stability and why does it matter for architecture?

Accepted Answer

Static stability means the system continues operating with its existing resources when a dependency fails, without needing to make changes — pre-provisioning capacity in every AZ so no scaling action is required when one fails. It matters because the control plane is more likely to be impaired during a large event, which is exactly when a dynamic recovery would need it. This is one of the most valuable AWS resilience concepts and few candidates know it. A design that requires launching new instances to survive an AZ failure may fail precisely when needed, which is why pre-provisioned capacity is the resilient choice.

Question 36

Design a search feature over millions of documents.

Accepted Answer

OpenSearch Service for keyword and relevance search, populated from the system of record via a stream so the index is derived rather than authoritative. Add a vector index for semantic search if required. Front it with an API layer applying tenant filtering, cache common queries, and reindex from the source when the mapping changes rather than mutating in place. Treating the search index as derived rather than authoritative is the key design decision, because it means a corrupted or lost index is rebuilt rather than restored. Naming reindex-from-source as the schema-change strategy is the operational detail.

Question 37

How do you design an event-driven system that stays debuggable?

Accepted Answer

Use orchestration with Step Functions for processes with compensation and a business meaning, and choreography only for genuinely independent reactions. Archive every event so you can replay. Propagate a correlation identifier through all events and logs. Alarm on dead-letter queues, and maintain a documented event catalogue so the flow is discoverable. The failure of pure choreography is that no one place shows what happened, so a partial failure requires reconstructing the flow from logs across many services. Naming archive-and-replay and correlation identifiers is what makes an event-driven design operable.

Question 38

How would you migrate a monolith to a serverless architecture?

Accepted Answer

Containerise and lift onto Fargate first if it is stateless, then externalise session state, local file writes and configuration. Peel off boundaries incrementally with the strangler pattern, routing specific paths to new Lambda or Fargate services behind the same load balancer. Only decompose where independent scaling or deployment justifies it. Separating "move it" from "decompose it" is the mature answer, because teams attempting both simultaneously usually fail. Naming the routing layer as the mechanism that makes incremental replacement possible is the concrete part.

Question 39

How do you design for cost as a first-class requirement?

Accepted Answer

Choose an architecture with a low cost floor — serverless that scales to zero rather than always-on capacity; set quotas rather than relying on budget alerts; cap autoscaling maxima; apply lifecycle and retention policies; commit only to the measured baseline; and build a cost dashboard with anomaly alerting so drift is caught in days rather than at month end. The distinction to make explicit is that quotas enforce and budgets only notify. A design meeting a hard budget needs enforcement points, and naming the specific quotas — regional vCPU, Lambda concurrency, max instances — is the concrete answer.

Question 40

How do you decide between synchronous and asynchronous communication?

Accepted Answer

Synchronous when the caller genuinely needs the result to proceed and the operation is fast and reliable. Asynchronous when the work is slow, the caller does not need the result immediately, the downstream may be unavailable, or you need buffering and independent scaling. Asynchronous adds eventual consistency and complexity, so it is not a default. The failure of over-using synchronous calls is that availability multiplies down the chain — five services each at 99.9% give 99.5% end to end. Naming that arithmetic is what makes the argument for decoupling concrete.

Question 41

What is a cell-based architecture and when is it worth it?

Accepted Answer

Partitioning the system into independent cells, each a complete stack serving a subset of customers, with a thin routing layer, so a failure or bad deployment affects only one cell. It is worth it for large multi-tenant systems where blast radius matters more than the operational overhead of running many identical stacks. Combined with shuffle sharding it bounds both failure and noisy-neighbour impact. The cost — many stacks to manage and deploy — is why it suits large systems rather than small ones, and acknowledging that is what makes the recommendation credible.

Question 42

How do you handle a system that must integrate with a slow legacy partner API?

Accepted Answer

Queue the work with SQS so bursts are absorbed, control the outbound rate with reserved concurrency or a fixed worker count, set aggressive timeouts, retry with exponential backoff and jitter, add a circuit breaker, and return 202 to your own callers with a status mechanism rather than blocking on the partner. Reserved concurrency as a rate limiter is the AWS-specific mechanism worth naming. The architectural point is that your availability should not be bounded by theirs, which is what the queue and the asynchronous contract achieve.

Question 43

Design a system for scheduled per-entity actions — for example a reminder per order.

Accepted Answer

EventBridge Scheduler creating a one-time schedule per entity scales to millions of schedules and invokes a target directly, which removes polling entirely. The alternative patterns are a DynamoDB table with a sweep query on a time index, or SQS delay queues for horizons under fifteen minutes. EventBridge Scheduler's one-time schedules are the modern answer and many candidates still describe a minute-by-minute sweep. Naming the fifteen-minute limit on SQS delay is the detail that rules out the naive option.

Question 44

Design the complete architecture for a fintech application in India handling payments and KYC.

Accepted Answer

Organizations with Control Tower, OUs per environment, SCPs restricting regions to India, forbidding public IPs and IAM key creation. IAM Identity Center federated with the corporate IdP and MFA enforced. Private subnets with centralised egress inspection, VPC endpoints with restrictive policies and a data perimeter. Compute on Fargate or EKS behind CloudFront with WAF and Shield as the only ingress. Aurora for the transaction ledger with Multi-AZ and a global secondary for DR, DynamoDB for high-throughput lookups, ElastiCache for sessions and rate limits, S3 with Object Lock and CMEK for KYC documents accessed only through presigned URLs. Macie for PII discovery, Lake Formation column-level controls for analytics fed by CDC. CloudTrail with data events, Config, GuardDuty and Security Hub to a locked logging account with Vault-Locked cross-account backups. IaC-managed, attested container supply chain, per-environment CI identities via OIDC, SLO-based alerting, and rehearsed DR and incident response. The closing scenario. What marks it senior is enforcing residency and configuration with SCPs rather than convention, solving the dual-write problem with CDC, protecting KYC documents against both accident and attacker with Object Lock, and treating rehearsed DR and incident response as part of the architecture.

AWS Architecture & System Design Interview Questions and Answers

How to use this set