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.

• ✗

  Deploy all instances in a single Availability Zone for consistency

  Why it's wrong here

  Consolidating all instances into a single Availability Zone creates a single point of failure: if that AZ suffers a power outage, network partition, or cooling failure, the entire application becomes unavailable. Placement consistency does not mitigate the loss of the underlying facility, and AWS explicitly recommends distributing workloads across multiple AZs to achieve high availability. This approach sacrifices resilience for ease of management, which is not an acceptable trade-off for production applications.

• ✓

  Use an Auto Scaling group with multiple Availability Zones

  Why this is correct

  An Auto Scaling group configured across multiple Availability Zones automatically distributes instances among those AZs and enforces the desired capacity by replacing any instance that fails its health checks. This provides both high availability and operational automation: if an entire AZ becomes impaired, the ASG launches replacement instances in the remaining healthy AZs, and it also performs capacity rebalancing when AZs become imbalanced. Combined with an Elastic Load Balancer, this is the standard AWS pattern for building a fault-tolerant, self-healing application tier.

• ✓

  Deploy EC2 instances in at least two Availability Zones

  Why this is correct

  Running EC2 instances in at least two Availability Zones ensures that a failure in a single data center does not take down the application, because the remaining AZ continues to serve traffic. This is the foundational requirement for high availability at the infrastructure layer and is often coupled with an Elastic Load Balancer to distribute requests across the healthy AZs. Unlike an Auto Scaling group, this approach may not automatically replace failed instances, but it still eliminates the single-AZ single point of failure.

• ✗

  Use a larger instance type to handle more load

  Why it's wrong here

  Scaling vertically by choosing a larger instance type increases compute, memory, and network capacity, but it does not address availability. A single large instance, even if extremely powerful, remains a single point of failure if its Availability Zone goes down; the 'blast radius' of an outage is actually larger because more workloads depend on that one instance. Resilience in AWS requires redundancy across distinct failure domains, not just more resources inside one domain.

• ✗

  Use CloudWatch alarms to monitor instance health

  Why it's wrong here

  CloudWatch alarms are useful for detecting problems and triggering corrective actions, but monitoring by itself does not prevent downtime or provide high availability. An alarm can notify you that an instance is unhealthy, yet without a mechanism like an Auto Scaling group or a load balancer to replace the instance in a different AZ, the application stays down. Alarm-driven automation can be part of a recovery strategy, but it must be paired with multi-AZ deployment and an actual recovery action to be effective.

Go deeper

Related to this question