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.

• ✓

  Configure Auto Scaling to maintain a minimum number of instances.

  Why this is correct

  Auto Scaling with a minimum instance count is the core corrective mechanism for this scenario: it continuously monitors instance health and replaces any failed instance by launching a new one in its place, while also maintaining the desired capacity across healthy instances. Without a minimum, a single instance failure or an Availability Zone disturbance can drop the fleet to zero and take the stateless web application offline. The auto scaling group also integrates with Elastic Load Balancing to stop sending traffic to unhealthy instances, reinforcing both self-healing and capacity preservation.

• ✗

  Use Amazon CloudFront as an origin for the ALB.

  Why it's wrong here

  CloudFront is a content delivery network that caches and serves static and dynamic content from edge locations, and while it can use an ALB as an origin, it does not add compute fault tolerance for the EC2 instances behind that ALB. CloudFront only affects the path from users to the ALB; if the underlying EC2 instances fail, CloudFront will still forward requests to the ALB, which has no healthy targets and will return errors. It provides geographic distribution and latency reduction, not automated recovery or replacement of failed compute capacity, so it is irrelevant to ensuring the EC2 fleet remains available.

• ✓

  Deploy EC2 instances across multiple Availability Zones.

  Why this is correct

  Deploying EC2 instances across multiple Availability Zones eliminates a single data center as a point of failure by distributing the fleet so that if one AZ becomes unavailable, the remaining AZs can continue serving traffic. This is a necessary complement to Auto Scaling because it ensures that the minimum instance count is maintained even without a whole-AZ failure—though Auto Scaling will still need to replace instances if a Zone goes down. Multi-AZ placement alone does not self-heal; it only reduces the blast radius of an AZ failure, so it is correct but insufficient without active capacity management.

• ✗

  Disable termination protection on EC2 instances.

  Why it's wrong here

  Disabling termination protection on EC2 instances actually increases operational risk because it removes a safeguard that prevents accidental termination through the console or API, which could drop capacity and cause an outage. This action has no bearing on fault tolerance or high availability; it does not make instances more resilient to failures, nor does it contribute to maintaining a minimum number of instances. In fact, for a stateless web application you would typically keep termination protection enabled on any non-replaceable resource, though for Auto Scaling managed instances it is often unnecessary because the ASG will launch replacements.

• ✗

  Use larger EC2 instance types.

  Why it's wrong here

  Using larger EC2 instance types (scale up) increases the capacity per instance—more vCPUs, memory, and network bandwidth—but does nothing to increase the number of independent failure domains or the ability to tolerate an instance failure. A single larger instance is still a single point of failure; if it crashes or the underlying hardware fails, the application goes down just as it would with a smaller instance. The correct scaling pattern for fault tolerance is horizontal scaling (adding more instances) combined with Auto Scaling and multi-AZ placement, not vertical scaling to bigger, more expensive machines.

Go deeper

Related to this question