SOA-C02 Deployment, Provisioning, and Automation 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 an 'availability-zone' health check type in the Auto Scaling group.

  Why it's wrong here

  The 'availability-zone' health check type in an Auto Scaling group determines how the group assesses the health of its instances (using EC2 status checks or Elastic Load Balancing health checks), but it has absolutely no bearing on where new instances are initially launched. Instance distribution across Availability Zones is driven solely by the subnets you specify in the Auto Scaling group's launch configuration or template. Changing the health check type only alters detection and replacement of unhealthy instances, not the placement strategy for initial capacity.

• ✓

  Create subnets in multiple Availability Zones and specify them in the Auto Scaling group.

  Why this is correct

  By creating subnets in multiple Availability Zones and then referencing those all subnets in the Auto Scaling group's network configuration, you enable the group to automatically distribute instances across all the specified AZs. This is the canonical method for achieving high availability, as the Auto Scaling group will balance instances among the AZs and, if one AZ becomes unhealthy or has insufficient capacity, it can launch replacement instances in the other AZs. Without this multi-subnet specification, the group cannot spread itself across AZs, because it can only launch instances into the subnets explicitly provided.

• ✗

  Create the Auto Scaling group with a single subnet in one Availability Zone.

  Why it's wrong here

  Creating the Auto Scaling group with a single subnet confined to one Availability Zone means every instance the group launches will reside in that same AZ, creating a single point of failure. If that AZ experiences an outage or becomes constrained on capacity, all instances in the group are affected and the Auto Scaling group cannot fail over to another AZ because no other subnets are available. This sacrifices the horizontal fault tolerance that Auto Scaling is designed to provide and is not recommended for production workloads that require high availability.

• ✗

  Create subnets in multiple Availability Zones but assign them to the same placement group.

  Why it's wrong here

  While placing subnets across multiple Availability Zones is the right foundation for distribution, assigning all those subnets to the same placement group defeats the purpose—not because placement groups cause harm, but because they are designed for low-latency, high-bandwidth network connectivity for tightly coupled workloads, not for ensuring geographic or availability-zone dispersion. In fact, some placement group types, such as cluster placement groups, cannot span multiple AZs, so forcing this configuration could prevent the instances from even launching. The correct way to achieve AZ distribution is to let the Auto Scaling group manage placement using the subnets alone, without a placement group that constrains topology.

Go deeper

Related to this question