DOP-C02 - Resilient Cloud Solutions (15% of the exam) - Section 3.1

Implement highly available architectures using Multi-AZ deployments, Elastic Load Balancing, Amazon Route 53 and loosely coupled designs.

Design highly available architectures by spreading workloads across Multiple Availability Zones with Elastic Load Balancing and Amazon Route 53 routing policies. Apply loose coupling patterns so that failure in one component does not cascade to dependent services.

Multi-AZ deploymentsElastic Load BalancingAmazon Route 53Loose coupling

Practice question for this objective

Free sampleResilient Cloud Solutionsmedium

A team runs a stateless web service in a single Amazon EC2 Auto Scaling group fronted by an Application Load Balancer, but every instance and both load balancer nodes currently sit in one Availability Zone. An architecture review flags that the loss of that Availability Zone would take the whole service offline, and the business now requires the tier to keep serving if any single Availability Zone fails. The team wants the most direct configuration changes to make the existing tier survive a zonal failure. Which TWO actions together meet this requirement? (Select TWO.)

AExtend the Auto Scaling group to span subnets in at least two more Availability Zones so it launches and balances instances across multiple zones. Correct
BAdd the subnets of the additional Availability Zones to the Application Load Balancer so it provisions nodes and routes to targets in every chosen zone. Correct
CReplace the Application Load Balancer with a Gateway Load Balancer so that traffic is inspected by appliances before it reaches the web instances in the zone.
DEnable termination protection on the running instances so the Auto Scaling group cannot remove them when an Availability Zone becomes impaired.

Surviving an Availability Zone failure requires both the Auto Scaling group and its load balancer to span multiple Availability Zones. High availability across zones depends on capacity being distributed, so the Auto Scaling group must launch into multiple Availability Zone subnets and the Application Load Balancer must have nodes in those same zones; only then does the loss of one zone leave a working fleet behind a still-reachable endpoint.

Why A is correct: Spreading the Auto Scaling group across multiple Availability Zone subnets means a zonal failure removes only part of the fleet, and the group relaunches the lost capacity in the surviving zones.

Why B is correct: Enabling extra Availability Zone subnets on the load balancer gives it nodes in each zone, so the public endpoint stays reachable and can route to healthy targets even when one zone is lost.

Why C is wrong: A Gateway Load Balancer fronts third-party inspection appliances rather than balancing web traffic, so it is tempting as a load balancer swap but does nothing to spread the web tier across Availability Zones.

Why D is wrong: Termination protection looks like a way to keep capacity, but it only blocks manual termination and cannot keep instances alive when their Availability Zone fails, leaving the single-zone exposure in place.

See more DOP-C02 practice questions, answers explained.

Exam traps in Resilient Cloud Solutions

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Reduce the target group deregistration delay to zero seconds so failing instances are removed from the load balancer immediately once the deployment marks them as outdated.
Why it is wrong: Deregistration delay only controls connection draining when a target is deliberately removed; it does nothing to detect an instance that is silently returning errors while still passing the port check.
Keep two Availability Zones but double desired capacity to eight instances so four healthy instances remain in the surviving Availability Zone after one zone fails.
Why it is wrong: Doubling capacity in only two zones still loses half the fleet when one zone fails and permanently runs twice the steady-state cost, so it is both less resilient and more expensive than spreading wider.
Add an Amazon RDS read replica in a second Availability Zone and point the application at the replica when the primary is unreachable.
Why it is wrong: A read replica improves read scaling and looks like a failover path, but it is asynchronous, does not promote automatically, and read replicas cannot accept the writes the order tier needs during an outage.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.