DOP-C02 Resilient Cloud Solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use a larger instance type and enable detailed CloudWatch monitoring

  Why it's wrong here

  Scaling up the EC2 instance size and enabling detailed CloudWatch monitoring improves per-instance resource capacity and metric granularity, but it does nothing to eliminate the single-AZ dependency. If the Availability Zone hosting the fleet suffers an outage, every target registered with the NLB becomes unreachable regardless of its size or how frequently CloudWatch emits metrics. Detailed monitoring merely reduces the CloudWatch metric interval to one minute for faster alarms; it cannot create automatic failover to another location. High availability requires replicating workloads across separate Availability Zones, so this change only postpones or masks performance issues.

• ✗

  Replace the NLB with an Application Load Balancer and enable cross-zone load balancing

  Why it's wrong here

  Replacing the Network Load Balancer with an Application Load Balancer and toggling cross-zone load balancing changes the load-balancer type but still leaves all targets in a single Availability Zone. ALB is a regional service and supports cross-zone routing among existing healthy targets, but it cannot route traffic to a zone that has no registered targets. NLB itself already supports cross-zone load balancing, so the replacement is unnecessary; the real requirement is to add target capacity in a second AZ. Moreover, moving from L4 to L7 would alter the IP-preservation and TLS offload characteristics of the existing NLB without addressing availability.

• ✗

  Create an Auto Scaling group with a scheduled scaling policy to add instances during peak hours

  Why it's wrong here

  An Auto Scaling group with a scheduled scaling policy is designed to adjust capacity based on predictable time-based demand such as peak business hours, not to react to an unexpected Availability Zone failure. If the underlying AZ goes down, all instances in that ASG become unavailable, and unless the ASG spans multiple AZs, it cannot replace them anywhere else. Even if it did span AZs, a scheduled policy timed for 'peak hours' would not be triggered by an outage occurring at 3 a.m. This option confuses scalability (adding resources) with high availability (surviving a component failure), so it does nothing to maintain service when an entire zone becomes isolated.

• ✓

  Launch EC2 instances in a second Availability Zone and register them with the NLB target group

  Why this is correct

  Launching additional EC2 instances in a second Availability Zone and registering them with the NLB target group creates a multi-AZ target fleet, allowing the load balancer to route new connections to healthy instances in the surviving zone when the original zone has an outage. To make this work you must also configure the NLB itself with subnets in at least two AZs so its nodes are geographically distributed; then the target group's health checks automatically remove failed instances and keep the service available. This is the correct architecture for fault tolerance because it eliminates the single AZ as a point of failure and aligns with AWS's region-based resiliency patterns.

Go deeper

Related to this question