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.

• ✗

  Run all resources in a single Availability Zone to reduce complexity

  Why it's wrong here

  Running all resources in a single Availability Zone contradicts the core requirement for high availability, as a failure of that single zone would cause total application outage. This approach is tempting because it reduces inter-zone data transfer costs and simplifies network design, and would be correct for a development or test environment where cost minimisation and simplicity take priority over fault tolerance.

• ✗

  Store session data on EC2 instances to improve performance

  Why it's wrong here

  Storing session data on EC2 instances may seem faster due to local memory access, but it introduces a single point of failure: if the instance is terminated, restarted, or replaced by Auto Scaling during a health check replacement, all active sessions are lost, forcing users to re-authenticate. In a highly available architecture, session state must be externalized to a durable, centralized service such as Amazon ElastiCache (for in-memory speed) or DynamoDB (for persistent, transactional session storage), ensuring sessions survive individual instance failures while still providing sub-millisecond access.

• ✓

  Deploy resources across multiple Availability Zones

  Why this is correct

  Deploying across multiple Availability Zones (AZs) is the primary AWS design pattern for high availability because each AZ is an independent failure domain with separate power, cooling, and networking. By placing resources (e.g., application servers behind an Application Load Balancer, and a Multi-AZ database) in at least two AZs, the workload can continue serving traffic if one AZ suffers an outage, as the load balancer automatically routes requests only to healthy instances in the remaining AZs. This approach directly satisfies the requirement for fault tolerance, and when combined with Auto Scaling, it also provides capacity to absorb increased load in the surviving AZs.

• ✓

  Use loosely coupled components, such as queues and asynchronous processing

  Why this is correct

  Loosely coupled components, implemented with services like Amazon SQS or SNS, break the direct synchronous dependency between producers and consumers. If a consumer service fails or experiences a spike in latency, messages accumulate in the queue instead of causing upstream timeouts or cascading failures; once the consumer recovers, it processes the backlog without losing data. This asynchronous pattern also allows each component to scale independently (e.g., based on queue depth), improving overall system availability and making the architecture resilient to partial failures, which is essential for a highly available design.

• ✗

  Use tightly coupled components to reduce latency

  Why it's wrong here

  Tightly coupled components—where a caller blocks on a synchronous request to a dependent service—introduce a cascading failure risk: if the downstream component is slow or unavailable, the upstream component might exhaust its connection pool, time out, or fail entirely, leading to a system-wide outage. The perceived latency benefit is marginal in modern AWS because inter-zone or cross-service network overhead is low, and it is far outweighed by the loss of resilience. For high availability, you should favor asynchronous, event-driven communication with retries and fault tolerance, rather than optimizing for latency at the expense of reliability.

Go deeper

Related to this question

Same concept, more angles

1 more way this is tested on DOP-C02

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.