TL;DR: Spread every tier across at least two availability zones behind a load balancer, put the database in Multi-AZ so a standby can take over, and keep state out of the instances. That gets you through a zone failure. Surviving a region failure is a different and much more expensive conversation.
How to approach it
Go tier by tier and say what failure each choice survives, because "use multiple AZs" without the reasoning is the answer everyone gives. Be precise that database high availability is a failover with downtime measured in a minute or two, since candidates often imply it is instant and it is not.
A strong answer
Start with what an availability zone is, because the design rests on it: separate physical data centres within a region, with independent power and cooling, connected by low-latency links. A zone can fail without the others failing, and that is the failure the whole architecture is built around.
Edge and web tier. An Application Load Balancer, which is itself zone-redundant, with subnets registered in at least two zones. Behind it an Auto Scaling group spanning those zones, so the group replaces an unhealthy instance and rebalances if a zone disappears. Set the minimum so that losing a zone still leaves enough capacity: with two zones and a minimum of two, a zone failure leaves one instance carrying everything, so the honest minimum is four across two zones, or a spread across three.
The ALB health check is what makes this work, and it should hit an endpoint that exercises the application's real dependencies rather than returning 200 from a static handler. An instance that is up but cannot reach the database should be taken out of rotation.
Application tier. Same pattern, in private subnets, reached only from the load balancer's security group. The property that matters here is statelessness: no session data on the instance, no uploaded files on local disk. Sessions go to ElastiCache or a cookie-based token, uploads go to S3. An instance that holds state cannot be replaced freely, and everything above depends on replacing instances freely.
Database tier. RDS in Multi-AZ, which keeps a synchronous standby in another zone. On failure, AWS promotes the standby and the DNS endpoint moves. Be precise about what this gives you: typically a failover in the region of a minute or two, during which writes fail. That is high availability, not continuous availability, and applications need retry logic and connection pools that reconnect rather than holding a dead connection. The standby is not readable, so scaling reads means read replicas, which are asynchronous and can lag.
Storage. S3 is already replicated across zones within a region, so static assets and uploads there need nothing extra. EBS volumes are zonal, which is the constraint people forget: a volume cannot be attached from another zone, so anything with an attached volume is pinned to its zone until it is restored from a snapshot.
DNS and the front door. Route 53 with health checks, and CloudFront in front for static content, which also absorbs load and reduces the blast radius of an origin problem.
On region failure, be honest about the cost. Multi-region active-passive means replicating data continuously, keeping infrastructure warm, and rehearsing a failover you will rarely use. Active-active adds conflict resolution and roughly doubles the bill. Most businesses are correctly served by multi-AZ plus tested backups, and the question to ask before designing for region failure is what the recovery objectives actually are in minutes and in acceptable data loss.
What interviewers probe next
"What is the difference between high availability and disaster recovery?" High availability is surviving a component or zone failure automatically, usually inside one region. Disaster recovery is restoring after a larger loss, measured in recovery time and recovery point objectives, and often involving a restore rather than a failover.
"How do you test it?" Terminate an instance and watch the group replace it. Force an RDS failover from the console, which is a supported operation, and measure how long writes actually failed. A failover nobody has triggered is an assumption.
"Two zones or three?" Three, where the region has them, because losing one of three costs you a third of capacity instead of half, and quorum-based systems need an odd number.
Common mistakes
Spreading instances across zones while leaving session state on them, so replacing one logs users out.
Sizing the Auto Scaling minimum for normal load rather than for load with a zone missing.
Describing Multi-AZ RDS as though nothing breaks, when it is a failover with a real interruption and requires retries in the application.
Forgetting that EBS is zonal, and designing a "multi-AZ" service around a volume that can only attach in one zone.