SOA-C02 Reliability and Business Continuity 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.

• ✓

  Update the Auto Scaling group to remove the affected Availability Zone from the list of enabled AZs.

  Why this is correct

  Removing the affected Availability Zone from the Auto Scaling group's enabled AZ list stops the ASG from launching any new instances in that unhealthy AZ. The ASG will then rebalance instances across the remaining healthy AZs, and because the group is regional, it can continue to maintain capacity. This directly addresses the root cause by eliminating the faulty location from the placement logic, allowing existing instances in healthy AZs to serve traffic without additional risk.

• ✗

  Manually terminate all instances in the affected Availability Zone.

  Why it's wrong here

  Manually terminating all instances in the affected Availability Zone immediately reduces the running capacity, potentially dropping below the desired or minimum thresholds and causing a service outage. The Auto Scaling group would react by launching replacement instances, but if the affected AZ remains enabled, those replacements may be placed in the same unhealthy AZ, recreating the problem. This action is therefore both risky and ineffective compared to simply removing the AZ from the group's configuration.

• ✓

  Increase the desired capacity of the Auto Scaling group to account for the lost capacity.

  Why this is correct

  Increasing the desired capacity forces the Auto Scaling group to launch additional instances in the remaining healthy Availability Zones, which can temporarily compensate for the lost capacity and maintain service availability. However, this is only a stopgap because the group may still attempt to launch instances in the affected AZ if it is still enabled, and the higher desired capacity could become permanent if not reverted after the incident. The proper solution is to first remove the affected AZ, then adjust capacity based on the actual requirements.

• ✗

  Create a new launch configuration with a different AMI.

  Why it's wrong here

  Creating a new launch configuration with a different AMI does not address the issue because the problem is an Availability Zone failure, not an AMI defect or configuration error. The ASG would still use its existing AZ placement logic and could launch instances in the same affected AZ, regardless of the AMI chosen. Even if the new AMI were somehow more resilient, it does not mitigate the underlying loss of the AZ or ensure capacity in healthy zones.

• ✗

  Disable the dynamic scaling policy to prevent scaling.

  Why it's wrong here

  Disabling the dynamic scaling policy prevents the Auto Scaling group from adding or removing instances in response to load, but it does nothing to restore the lost capacity from the affected Availability Zone. If the policy was previously scaling out, disabling it could leave the group under-provisioned; if it was scaling in, it might keep unhealthy instances running. The correct remediation is to remove the faulty AZ from the group's enabled list and then let scaling policies operate normally to maintain appropriate capacity.

Go deeper

Related to this question