Question 1

What is high availability and how is it achieved on AWS?

Accepted Answer

High availability is designing so the system keeps working when a component fails — no single points of failure, redundant instances across Availability Zones behind a load balancer, health checks and automatic replacement, and managed services with built-in redundancy such as Multi-AZ RDS and S3. The capacity point is what candidates miss: with three AZs you should be able to serve peak on two, which means running at roughly 150% of single-AZ need. Otherwise an AZ failure produces a capacity outage rather than a graceful degradation.

Question 2

What is the difference between RTO and RPO?

Accepted Answer

Recovery time objective is how long you can be down; recovery point objective is how much data you can afford to lose. A near-zero RPO requires synchronous or continuous replication, which constrains geography and adds write latency. A short RTO requires standby capacity and rehearsed procedures. Both cost money, so the business sets them rather than engineering. Mapping them to AWS options — Multi-AZ RDS for near-zero in-region RPO, cross-region replicas for a non-zero RPO with regional protection — turns definitions into a design.

Question 3

What are the four disaster recovery strategies?

Accepted Answer

Backup and restore is cheapest with the longest RTO, restoring from backups after a failure. Pilot light keeps a minimal core — usually the database replicating — running in the second region and scales up on failover. Warm standby runs a reduced-capacity copy continuously. Multi-site active-active runs full capacity in both, giving the shortest RTO at the highest cost. The line that matters is that an untested DR plan has an unknown RTO, which is functionally the same as not having one. Naming a rehearsal cadence, and that you would actually fail over rather than simulate, is what distinguishes a plan from a document.

Question 4

How do you design a multi-AZ architecture?

Accepted Answer

Subnets in at least two, preferably three AZs; an Auto Scaling group or ECS service spanning them behind a load balancer with cross-zone balancing; Multi-AZ RDS or Aurora with replicas in each AZ; NAT gateways per AZ with route tables pointing to the local one; and stateless compute with state in managed multi-AZ services. The NAT gateway per AZ is the detail most often missed: a single NAT gateway is cheaper and works fine until its AZ fails, at which point two-thirds of the fleet loses outbound access. The cost trade-off is real, so the answer should acknowledge it.

Question 5

When do you need multi-region rather than multi-AZ?

Accepted Answer

When the availability target exceeds what a single region can offer, when regulation requires a geographically distant recovery site, when you need low latency for users in another geography, or when a regional service impairment would be an unacceptable business risk. Multi-AZ handles the vast majority of real failures. The honest framing is that multi-region roughly doubles cost and substantially increases complexity, particularly for the data tier, so it needs a real requirement. Most outages are caused by change, not by regional failure, which is worth saying.

Question 6

What is the hardest part of a multi-region architecture?

Accepted Answer

The data tier. Compute is easy to duplicate; keeping data consistent across regions is not. Options are Aurora Global Database with roughly a second of lag and managed failover, DynamoDB global tables with last-writer-wins conflict resolution, or an active-passive design where only one region accepts writes. Last-writer-wins in DynamoDB global tables is the specific caveat: concurrent writes to the same item in different regions silently discard one. Any design with genuinely concurrent cross-region writes needs application-level conflict handling.

Question 7

How do you route traffic in a multi-region deployment?

Accepted Answer

Route 53 with latency-based or failover routing and health checks, or AWS Global Accelerator with anycast IPs that fail over in the network rather than waiting for a DNS TTL. CloudFront with multiple origins and origin failover is the option for cached content. The DNS caching limitation is the reason to prefer Global Accelerator for fast failover: clients and resolvers honour TTL, so DNS failover can take minutes even with a short TTL, whereas anycast failover is near-instant.

Question 8

What is Route 53 health checking and how does failover routing work?

Accepted Answer

Route 53 health checks probe an endpoint from multiple global locations, or evaluate a CloudWatch alarm, or check other health checks in a calculated hierarchy. Failover routing returns the primary record while it is healthy and the secondary when it is not. Calculated health checks are the useful feature: you can combine several signals so a region is only considered healthy when its load balancer, database and a synthetic transaction all pass. A shallow health check that only pings a load balancer will fail over too late or not at all.

Question 9

What is a bulkhead and how would you apply it?

Accepted Answer

A bulkhead isolates resources so failure in one part cannot exhaust capacity needed by another — separate thread pools or connection pools per dependency, separate queues per consumer, reserved Lambda concurrency per function, or shuffle sharding so one noisy tenant affects only a subset. Shuffle sharding is the AWS-flavoured version worth naming: assigning each customer a random subset of workers means a single abusive tenant degrades only the small overlap rather than everyone. It is a very effective, cheap isolation technique.

Question 10

What is a circuit breaker and why does it matter?

Accepted Answer

A circuit breaker tracks failures to a dependency and, past a threshold, stops sending requests for a cooling period, failing fast instead of exhausting threads or connections waiting on a broken service, then allows a trial request to test recovery. It prevents cascading failure, where retries against a slow dependency consume all capacity and take down healthy components too. The insight to state is that retries alone make a slow dependency worse, which is why timeouts and circuit breakers must accompany them.

Question 11

What is exponential backoff with jitter and why is jitter necessary?

Accepted Answer

Exponential backoff increases the wait between retries. Jitter randomises that wait so clients that failed simultaneously do not all retry at the same moment. Without jitter, synchronised retries produce a thundering herd that prevents the dependency recovering. Full jitter, where the delay is a random value between zero and the exponential cap, is the AWS-recommended variant. Being able to say why jitter matters — recovery, not politeness — is what shows understanding rather than recitation.

Question 12

What is load shedding and why is it better than queueing everything?

Accepted Answer

Load shedding rejects some requests quickly when the system is overloaded, so the remaining requests are served well. Queueing everything makes every request slow, holds resources, and eventually times out anyway — so the system does more work and satisfies fewer users. Deciding in advance what to shed — non-essential features, low-priority tenants, expensive endpoints — is a design decision rather than an incident-time one. Returning 429 with a Retry-After header is the correct protocol behaviour.

Question 13

How do you design for graceful degradation?

Accepted Answer

Identify the critical path that must work and the non-essential features. Put timeouts and circuit breakers on non-critical dependencies so they fail fast, serve stale cached data when a dependency is down, and use feature flags to disable expensive features under load rather than letting everything slow down equally. The concrete example that lands is an e-commerce site disabling recommendations and reviews to protect checkout. Deciding that ordering in advance, and being able to enact it with a flag rather than a deployment, is what makes it real.

Question 14

What is the difference between static stability and dynamic recovery?

Accepted Answer

Static stability means the system continues operating with its existing resources when a dependency fails, without needing to make changes — for example pre-provisioning capacity in every AZ so no scaling action is required when one fails. Dynamic recovery depends on the control plane working during the failure, which is exactly when it may be degraded. This is one of the most valuable AWS resilience concepts: the control plane is more likely to be impaired during a large event, so a design that requires launching new instances to survive an AZ failure may fail precisely when needed. Pre-provisioned capacity is the static answer.

Question 15

What is the difference between the data plane and the control plane, and why does it matter for resilience?

Accepted Answer

The control plane creates and modifies resources — launching instances, updating DNS records, changing route tables. The data plane serves the actual traffic. Data planes are generally simpler and more available than control planes, so a resilient design depends on data-plane operations during a failure. The practical rule is to avoid recovery paths that require control-plane calls: pre-created standby resources, pre-configured DNS records with health checks, and pre-provisioned capacity all continue to work when the control plane is impaired.

Question 16

How do you achieve 99.99% availability?

Accepted Answer

That allows about 52 minutes of downtime per year, so every layer needs redundancy: multi-AZ compute behind a load balancer, a database with automatic failover, no single points of failure, 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 rather than hardware. A perfectly redundant system that ships a bad change without a canary will not reach four nines.

Question 17

What is a single point of failure and how do you find them?

Accepted Answer

Any component whose failure takes down the system — a single NAT gateway, a single-AZ database, a single instance, a shared cache with no replica, or a dependency on one region. Find them by walking each component and asking what happens if it disappears, and by testing with fault injection. The non-obvious ones are usually operational rather than architectural: one person who knows the deployment process, one credential nobody else has, or a build system whose failure prevents fixing anything. Naming those shows breadth.

Question 18

How do you test a disaster recovery plan?

Accepted Answer

Execute it: fail over to the secondary region in a scheduled exercise, restore backups into an isolated environment and validate the data, and measure the actual recovery time against the objective. Use AWS Fault Injection Service for controlled failure experiments and Elastic Disaster Recovery for non-disruptive drills. Restoring backups regularly is the minimum, since an unverified backup is a hope rather than a control. Measuring rather than estimating recovery time is what turns an RTO from an aspiration into a commitment.

Question 19

What is AWS Resilience Hub?

Accepted Answer

Resilience Hub assesses an application against defined RTO and RPO targets, analysing its infrastructure to identify gaps — a single-AZ database, missing backups, insufficient replication — and recommends remediation, with resilience scoring and integration with Fault Injection Service for validation. It turns resilience from an architectural opinion into an assessed score against stated objectives. The valuable part is that it evaluates the actual deployed configuration rather than the design document, which is where the gap usually is.

Question 20

What is AWS Fault Injection Service?

Accepted Answer

FIS runs controlled chaos experiments — terminating instances, injecting CPU or memory pressure, adding network latency, failing an AZ, throttling API calls — with stop conditions tied to CloudWatch alarms so the experiment aborts automatically if a guardrail fires. The stop condition is what makes it an experiment rather than an outage. Starting with a written hypothesis in a non-production environment, then graduating to production during business hours with the team watching, is the responsible progression.

Question 21

How does Auto Scaling contribute to availability?

Accepted Answer

An Auto Scaling group replaces instances that fail health checks, maintains capacity across AZs, rebalances when a zone recovers, and scales to meet demand. Using ELB health checks rather than only EC2 status checks means an instance that is running but not serving is also replaced. The caveat is that scaling depends on the control plane and on capacity being available, so a design that requires launching instances to survive an AZ failure is dynamically rather than statically stable. Pre-provisioning across AZs is the more resilient choice.

Question 22

What is cell-based architecture?

Accepted Answer

Cell-based architecture partitions the system into independent cells, each a complete stack serving a subset of customers, with a thin routing layer. A failure or bad deployment affects only one cell, so blast radius is bounded and deployments can be rolled cell by cell. It is how AWS itself builds many services, and combined with shuffle sharding it bounds both failure and noisy-neighbour impact. The cost is operational complexity — many identical stacks to manage — which is why it suits large multi-tenant systems rather than small ones.

Question 23

What is the difference between availability and durability?

Accepted Answer

Availability is whether you can access the data or service now. Durability is whether the data still exists and is intact over time. S3 offers extremely high durability separately from its availability SLA — data can be temporarily unreachable while remaining perfectly safe. The distinction matters because they are addressed differently: availability by redundancy and failover, durability by replication and backups. Conflating them leads to designs with excellent uptime and no real protection against data loss.

Question 24

How do you handle a stateful service in a highly available design?

Accepted Answer

Externalise state to a managed multi-AZ service — RDS Multi-AZ or Aurora, DynamoDB, ElastiCache with replication, EFS or S3 — so compute becomes replaceable. Where state must be local, use a StatefulSet or equivalent with replication and a tested failover, and accept the added operational burden. The recommendation to prefer a managed data service over self-managed replication is the mature answer, because failover, backup and upgrade are exactly the hard parts. Naming that a zonal EBS volume pins a workload to an AZ is the specific trap.

Question 25

What is a warm standby and how does failover work?

Accepted Answer

A warm standby runs a reduced-capacity but functional copy of the system in a second region, with data continuously replicated. On failover you scale the standby to full capacity and shift traffic with Route 53 or Global Accelerator. RTO is minutes, and RPO depends on replication lag. The scaling step is where warm standby fails in practice: if the region is under general load or you lack capacity reservations, scaling may not succeed. Pre-provisioning more capacity, or holding reservations, is what makes the RTO credible.

Question 26

What is a pilot light architecture?

Accepted Answer

Pilot light keeps only the core — typically a replicating database and the infrastructure definitions — running in the recovery region, with compute switched off. On failover you launch compute from IaC or AMIs and shift traffic. It is cheaper than warm standby with a longer RTO. The risk is that the recovery path depends on the control plane and on IaC that may have drifted from production. Regularly deploying to the pilot-light region, so the templates are exercised, is what keeps it from failing at the moment you need it.

Question 27

How do you keep a secondary region's configuration in sync?

Accepted Answer

Deploy both regions from the same IaC pipeline rather than treating the secondary as a copy made once. Use StackSets or a multi-region pipeline stage, replicate AMIs and container images, replicate secrets with Secrets Manager cross-region replication, and include the secondary in regular deployments so drift is impossible. Drift in the standby is the most common reason DR fails: the secondary was configured a year ago and no longer matches. Deploying to it on every release, even if it serves no traffic, is the practice that keeps it viable.

Question 28

What is the role of caching in availability?

Accepted Answer

A cache absorbs load and can serve stale data when the origin is unavailable, turning a hard failure into a degraded but working experience. The risks are stale data, cache stampedes when a hot key expires, and the origin being unable to cope if the cache itself fails. The cache-failure scenario is the one to raise: a system running comfortably at a 95% hit rate may be receiving twenty times the load if the cache empties, which can take down the origin. Sizing the origin for a cold cache, or warming it, is the mitigation.

Question 29

How do you handle retries safely?

Accepted Answer

Retry only idempotent operations or use idempotency keys; use exponential backoff with jitter; cap the number of attempts; set aggressive timeouts so a retry happens before the client gives up; and avoid retry amplification, where each layer retries and multiplies the load on the failing dependency. Retry amplification is the specific failure to name: three services each retrying three times produces twenty-seven attempts. Retrying at only one layer, usually closest to the caller, is the design rule that prevents it.

Question 30

What is a timeout budget?

Accepted Answer

A timeout budget allocates the total acceptable latency across a call chain, so each downstream call has a timeout smaller than the remaining budget. Without it, a chain of services each with a 30-second timeout can take minutes, long after the user has abandoned the request. Propagating the remaining deadline downstream, so each service knows how long it has, is the sophisticated version. The simple version — timeouts that decrease as you go deeper — already prevents the worst behaviour.

Question 31

How would you handle a regional AWS service impairment?

Accepted Answer

Detect it through health checks and the AWS Health Dashboard; shift traffic to another region if the architecture supports it; if not, degrade gracefully by disabling features that depend on the impaired service; communicate status to users; and avoid making large changes during the incident. Afterwards, review whether the dependency should be regionalised. The point that shows maturity is not attempting a risky architectural change mid-incident. Also worth naming: some AWS services are global with a home region, so a us-east-1 impairment can affect global control planes such as IAM and Route 53 configuration.

Question 32

What AWS services are global rather than regional, and why does it matter?

Accepted Answer

IAM, Route 53, CloudFront, WAF for CloudFront, Organizations and Shield are global, with control planes generally homed in us-east-1. Regional services are independent per region, which is what makes multi-region designs resilient. The reason it matters is that a us-east-1 control-plane impairment can prevent IAM or Route 53 *changes* globally even though the data planes continue working. Designing so recovery does not require control-plane changes is the practical response.

Question 33

How do you back up and restore across accounts and regions?

Accepted Answer

AWS Backup plans with cross-region and cross-account copy into an account with a separate trust boundary, Vault Lock in compliance mode for immutability, and a tested restore procedure. Cross-account is what protects against a compromised or mistakenly-deleted source account. Backups in the same account share the blast radius of a compromised credential, which is the ransomware scenario. Naming cross-account with Vault Lock, rather than only cross-region, is what distinguishes a real resilience answer.

Question 34

What is the difference between backup and replication?

Accepted Answer

Replication maintains a live copy, so it protects against infrastructure failure but faithfully replicates corruption, deletion and malicious changes. A backup is a point-in-time copy you can restore from, so it protects against logical errors. You need both. The point that catches people is that replication is not a backup: an accidental DELETE replicates in seconds. Naming a specific example — a bad migration replicating to the standby — makes the distinction concrete.

Question 35

How would you design for an RPO of zero?

Accepted Answer

Synchronous replication is required, which in practice means within a region — Multi-AZ RDS or Aurora, which acknowledge writes only after replication. Cross-region synchronous replication is impractical because of latency, so a cross-region RPO of zero is generally not achievable; the realistic answer is a very small RPO with continuous asynchronous replication. Being willing to say a requirement is not achievable, and explaining why in terms of the speed of light and write latency, is a strong answer. Interviewers use this to see whether you push back on unrealistic requirements with reasoning.

Question 36

What is the trade-off between consistency and availability in a multi-region system?

Accepted Answer

Under a network partition you must choose. Choosing consistency means refusing writes in the isolated region, preserving correctness at the cost of availability. Choosing availability means accepting writes in both and reconciling later, which requires conflict resolution and may lose data. Applying the choice per data type rather than per system is the mature framing: a payment must be consistent, a view counter need not. DynamoDB global tables choose availability with last-writer-wins, and knowing that is choosing a side is the insight.

Question 37

How do you handle capacity during a failover?

Accepted Answer

Pre-provision or reserve capacity in the recovery region rather than assuming it will be available on demand, since a large regional event drives many customers to the same alternative. Use On-Demand Capacity Reservations for critical capacity, and size the standby so scaling is a smaller step. The assumption that capacity is always available is exactly what fails during a widespread event. Capacity Reservations are the concrete mechanism, and naming them rather than trusting elasticity is what marks a senior answer.

Question 38

What operational practices support availability as much as architecture?

Accepted Answer

Progressive delivery with canaries and fast rollback; change freezes around high-risk periods; runbooks and rehearsed incident response; alerting on user-visible symptoms; capacity planning with quota headroom; and postmortems that produce tracked actions. Most outages are caused by change, not by hardware. That last point is the one to lead with, because it reframes availability as a process property rather than only a design one. A perfectly architected system deployed carelessly will not meet a demanding availability target.

Question 39

Design a highly available, disaster-recoverable architecture for a critical application.

Accepted Answer

Active in one region across three AZs: Auto Scaling or ECS behind an ALB with cross-zone balancing, sized so peak is served on two AZs; Aurora Multi-AZ with replicas; ElastiCache with replication; NAT gateways per AZ. Warm standby in a second region deployed by the same pipeline on every release, with Aurora Global Database replicating and capacity reservations held. Global Accelerator or Route 53 with calculated health checks for failover. AWS Backup with cross-account, Vault-Locked copies. Circuit breakers, timeout budgets, retries with jitter, load shedding and feature flags for degradation. Quarterly failover drills with FIS experiments, and Resilience Hub tracking against stated RTO and RPO. The closing scenario. The senior markers are sizing for AZ loss, deploying to the standby on every release so it cannot drift, holding capacity reservations rather than trusting elasticity, and actually executing the drills — which is where most DR plans fail.

AWS High Availability & Disaster Recovery Interview Questions and Answers

How to use this set