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.

• ✓

  Disable sticky sessions on the ALB and configure the application to store session data in an external session store like Amazon ElastiCache for Redis.

  Why this is correct

  Disabling sticky sessions and moving session state to an external service like ElastiCache for Redis decouples user session data from individual EC2 instance lifecycles. When an ALB routes requests to any healthy instance, the instance can retrieve the session from Redis, so a failed or terminated instance does not lose state. Because ElastiCache replicates across AZs, sessions also survive single-cache-node failures, making the app tier effectively stateless and highly resilient.

• ✗

  Increase the stickiness duration to a very high value so that sessions are not lost during brief interruptions.

  Why it's wrong here

  Increasing the stickiness duration only affects how long the ALB's session cookie keeps routing a user to the same target instance. It does nothing to persist the session data independently of that instance; if the instance crashes, is deregistered, or fails its health checks, the ALB must send the user to another instance, but the session data stored locally on the dead instance is permanently gone. This option also worsens load distribution because long-lived affinity can pin too many users to a single instance.

• ✗

  Change the Auto Scaling group to use a larger instance type to handle more sessions per instance, reducing the likelihood of session loss.

  Why it's wrong here

  Moving to a larger instance type simply adds more local capacity for in-memory session state, meaning the instance can hold more sessions before running low on memory. It does not add any redundancy: every session is still stored exclusively on the instance that served it, so any failure of that instance—whether from a hardware fault, OS panic, or AZ outage—immediately deletes all active sessions. A larger instance also increases the blast radius because more users are affected when that single instance goes down.

• ✗

  Configure the Auto Scaling group to use a larger minimum size and a lower maximum, so instances are less likely to be terminated.

  Why it's wrong here

  Raising the minimum and lowering the maximum in the Auto Scaling group reduces how often scale-in events terminate instances, but it cannot prevent an instance from failing due to underlying hardware, a health check failure, or a spot interruption. The session data remains on each instance's local filesystem or memory, so the loss of any single instance still destroys the sessions it carried. Moreover, this configuration caps elasticity and introduces underutilization during demand spikes, while still offering no data-level durability.

Go deeper

Related to this question