DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Enable sticky sessions (session affinity)

  Why it's wrong here

  Session affinity (stickiness) uses a cookie to pin a client to a specific target instance, which is beneficial for stateless-tolerant or stateful applications but does nothing to enable failover. During an AZ outage, the ALB may still route requests to the pinned, now-unhealthy instance, and since the algorithm is forced to avoid switching targets, it cannot redirect traffic to healthy instances in other AZs. This option can actually worsen failover because it actively resists moving sessions away from a failed target.

• ✗

  Configure health checks on the target group

  Why it's wrong here

  Health checks are essential for marking unhealthy targets as out-of-service, but they only influence the target's availability state; they do not change the ALB's zone-routing behavior. With cross-zone load balancing disabled, each ALB node distributes traffic only to targets within its own AZ, so even if health checks mark a target in another AZ as healthy, that node will not route traffic to it. Therefore, health checks alone are necessary but insufficient to achieve cross-AZ failover.

• ✗

  Add more subnets in additional AZs

  Why it's wrong here

  Adding subnets in additional AZs expands the ALB's footprint and can help with the availability of the load balancer nodes themselves, but it does not alter the default per-AZ traffic distribution. Each ALB node resides in its own AZ and, without cross-zone load balancing, will only forward requests to targets in that same AZ. During a failure, a healthy node in a surviving AZ has no way to reach healthy targets in a different AZ unless cross-zone load balancing is enabled, so this option alone does not solve failover.

• ✓

  Enable cross-zone load balancing on the ALB

  Why this is correct

  Cross-zone load balancing on the ALB enables each load balancer node to distribute incoming traffic evenly across all healthy targets in all enabled AZs, rather than limiting each node to its own AZ. With this enabled, if an AZ becomes unhealthy or unreachable, the remaining healthy ALB nodes can seamlessly route traffic to healthy targets in other AZs, ensuring continuous availability. This directly addresses the root cause of an ALB failing to route to instances in other AZs during an outage.

Go deeper

Related to this question