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.

• ✓

  Configure the ALB with cross-zone load balancing enabled and connection draining set to a suitable timeout.

  Why this is correct

  Cross-zone load balancing on the ALB ensures that incoming traffic is distributed evenly across all registered targets in every Availability Zone, preventing any single AZ from being overloaded and allowing the ALB to continue serving requests even if one AZ is impaired. Connection draining gives in-flight requests a grace period to complete before an instance is deregistered or replaced, avoiding request interruption during rolling updates or failed health checks. Together, these features support seamless instance replacement without dropping active requests, though they do not on their own preserve stored session data — they protect the connection lifecycle while the application layer (e.g., ElastiCache) handles state.

• ✗

  Deploy an Auto Scaling group with a dynamic scaling policy that adds instances in the remaining AZs.

  Why it's wrong here

  Auto Scaling groups are designed to maintain desired capacity by launching or terminating instances based on scaling policies, but they operate at the infrastructure level and have no awareness of user session state. A dynamic scaling policy that adds instances in the remaining Availability Zones compensates for lost capacity and helps distribute new requests, but sessions that were pinned to the terminated instances' local memory are gone forever, causing users to be logged out or lose in-progress work. This option ignores the fundamental requirement for a persistent, shared session store; scaling out capacity does not provide data redundancy or failover for session data.

• ✓

  Enable cluster mode for the ElastiCache for Redis cluster and configure replica nodes in different Availability Zones.

  Why this is correct

  Enabling cluster mode on an ElastiCache for Redis cluster partitions the dataset across multiple shards (node groups), and placing replica nodes in different Availability Zones ensures that if one AZ fails, another AZ has an up-to-date copy of the session data. With automatic failover, a replica in a surviving AZ is promoted to primary, and the application can continue reading and writing sessions without interruption. This design also scales horizontally by distributing sessions across shards, avoiding the single-node bottleneck that a non-cluster replication group would incur. For a critical application with a shared session store, this provides both high availability and data durability far beyond what simple DNS-based failover or EC2 auto-scaling can offer.

• ✗

  Configure the application to use a custom DNS name with a low TTL pointing to the ElastiCache cluster endpoint.

  Why it's wrong here

  A custom DNS record with a low TTL affects how quickly clients or resolvers refresh the mapping from a friendly name to the ElastiCache cluster endpoint, but it does nothing to preserve session data that already exists on the underlying Redis nodes. If the primary ElastiCache node fails, the DNS record alone cannot redirect traffic to a node that has the same session data — ElastiCache endpoint DNS is managed by AWS and already takes advantage of its own failover mechanisms. Lowering TTL merely reduces the window of stale DNS resolution; it does not add replication, sharding, or automatic failover, so it offers negligible benefit for session state resilience. The real solution must involve ElastiCache's native replication and clustering features, not the application's DNS configuration.

• ✗

  Enable Multi-AZ for the ElastiCache cluster to automatically fail over to a replica in another AZ.

  Why it's wrong here

  While ElastiCache for Redis does support Multi-AZ with automatic failover for replication groups (non-cluster mode), this option is incorrect because it provides only a single replica and does not shard data across multiple nodes. In the scenario, the application uses a shared cluster, implying a need for distributed session storage. Option C (cluster mode with replicas in different AZs) offers better resilience by spreading data across multiple shards and replicas, ensuring session data remains available during an AZ failure without performance degradation.

Go deeper

Related to this question