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.

• ✓

  Use a launch template with a pre-provisioned AMI.

  Why this is correct

  A pre-provisioned (pre-warmed) AMI has the application binary, runtime, and all dependencies already installed and initialized during image creation. When the Auto Scaling group launches a new instance from a launch template using this AMI, the app is immediately ready to serve traffic, avoiding the need for first-boot user-data scripts to install and configure software. This directly reduces the instance's "time to healthy" and is the correct way to speed up scaling in a stateless web tier.

• ✗

  Add a lifecycle hook to delay instance termination.

  Why it's wrong here

  A lifecycle hook pauses instances at launch or termination to let you run custom actions, such as draining connections or for cleanup. Adding a hook to delay instance termination would only keep the old instance in the "Terminating:Wait" state longer; it does nothing to accelerate the launch or initialization of replacement instances. In fact, if your scaling policy waits for the old instance to fully terminate before launching a new one, the hook extends the overall delay, making the problem worse rather than better.

• ✗

  Increase the cooldown period for the scaling policy.

  Why it's wrong here

  The cooldown period is a buffer that prevents Auto Scaling from launching or terminating additional instances for a set number of seconds after a scaling activity completes. Increasing the cooldown would make Auto Scaling wait even longer before reacting to rising demand, so new instances would be launched later, not sooner. It has no effect on how fast an individual instance boots or initializes after launch; it only throttles the frequency of scaling actions.

• ✗

  Use a larger instance type.

  Why it's wrong here

  A larger instance type provides more vCPUs and memory, but the time required for an application to become healthy is typically dominated by software initialization, such as loading dependencies, connecting to configuration services, and running startup scripts, not by raw compute capacity. Unless the startup is strictly CPU-bound, a larger instance may not meaningfully reduce boot time and could even be slower if the application image or init process is the bottleneck. The proper solution is to pre-provision the application into a golden AMI so no post-launch configuration is needed.

Go deeper

Related to this question