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.

• ✗

  Synchronous communication between services to ensure consistency

  Why it's wrong here

  Synchronous communication between services creates tight temporal coupling, where the caller thread blocks and waits for the downstream response, increasing latency and reducing availability. If the downstream service experiences a transient failure or latency spike, the upstream service also fails or exhausts its resources, leading to cascading failures. This approach sacrifices the independence and fault tolerance that microservices are meant to provide, and it is not a resilience pattern; consistency should instead be handled via asynchronous patterns like sagas with compensation.

• ✗

  Single shared database to maintain data consistency

  Why it's wrong here

  A single shared database creates a single point of failure and a performance bottleneck because all services contend for the same schema, connections, and I/O capacity. It tightly couples services at the data layer, preventing independent schema evolution, deployment, and scaling, which violates the database-per-service principle. During transient failures in one service, database locks and resource contention can propagate and degrade all other services, making the overall system less resilient rather than more.

• ✓

  Retry with exponential backoff for transient failures

  Why this is correct

  Retry with exponential backoff is a core resilience pattern that reattempts an operation after an exponentially increasing delay, typically with jitter to avoid synchronized retries, which prevents a thundering herd. It specifically targets transient failures, such as network timeouts, database connection drops, or throttling (e.g., API Gateway 429s or DynamoDB throttling), where the operation may succeed on a subsequent attempt if the original failure was short-lived. This pattern preserves system stability by giving the dependency time to recover and reducing continuous load, and it is widely supported in AWS SDKs and infrastructure.

• ✓

  Bulkhead pattern to isolate critical services from non-critical ones

  Why this is correct

  The bulkhead pattern isolates services into independent resource pools, such as separate thread pools, connection pools, queues, or even separate compute containers, so a resource exhaustion in one pool cannot starve another pool. This limits the blast radius by ensuring that a non-critical service, such as logging or reporting, cannot consume the threads or connections needed by a critical transaction service during a traffic spike or failure. Each bulkhead fails independently, maintaining the availability of critical services even when adjacent services are overwhelmed.

• ✓

  Circuit breaker pattern to stop calls to a failing service

  Why this is correct

  The circuit breaker pattern monitors a downstream service's failures and, when the failure rate crosses a threshold, opens the circuit to stop all further calls for a recovery window, allowing the service to stabilize. This prevents cascading failures by short-circuiting calls to an unhealthy service, avoiding timeouts and resource exhaustion in the caller, and enabling fast failure responses to the requesting client. After the cooldown, it transitions to half-open to probe with limited traffic; successful probes close the circuit. It is invaluable for handling dependency failures that are likely to persist longer than typical transient errors.

Go deeper

Related to this question