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.

• ✗

  Increase the CPU and memory limits for the ECS task definition.

  Why it's wrong here

  Increasing the CPU and memory limits only changes the individual task's resource footprint; it does not add additional task instances, so there is no capacity to absorb a spike in order traffic and no redundancy to survive an Availability Zone failure. In fact, larger tasks can reduce deployment density across the cluster and make it harder for the ECS placement algorithms to distribute tasks evenly across AZs. Vertical scaling also does nothing to protect the RDS database, which remains a single point of failure. The correct approach for sudden load is horizontal scaling via ECS Service Auto Scaling and for AZ failure is multi-AZ task placement and a Multi-AZ database.

• ✗

  Place an Amazon CloudFront distribution in front of the order service.

  Why it's wrong here

  Amazon CloudFront is an edge caching service that primarily accelerates distribution of static content and can cache some dynamic responses, but an order service receives non-idempotent transactional writes that must reach the backend in real time; a CDN cannot absorb write traffic or provide a failover for the ECS tasks or RDS instance. CloudFront does not perform health checks against the order service to reroute traffic, and even if an origin group were configured, the order service itself and the database would still need to be deployed redundantly across Availability Zones. Using CloudFront here would only add latency for uncached POST requests and create a misleading sense of resilience.

• ✓

  Deploy the RDS instance in a Multi-AZ configuration.

  Why this is correct

  Deploying RDS in a Multi-AZ configuration creates a synchronous standby replica in a different Availability Zone, and Amazon RDS automatically fails over to the standby if the primary instance becomes unhealthy or the AZ fails. The DNS name stays the same, so the ECS order service can reconnect without code changes, and the standby is continuously updated with synchronous replication to prevent data loss. This directly addresses the database as a single point of failure, which is necessary because the order service depends on durable transactions to record orders.

• ✓

  Configure the ECS service to run tasks in multiple Availability Zones.

  Why this is correct

  Configuring the ECS service to run tasks in multiple Availability Zones spreads the stateless order service compute across isolated infrastructure, so if an entire AZ becomes unavailable, the Application Load Balancer can route traffic only to healthy targets in the remaining AZs. ECS orchestrates task placement across the subnets you specify in different AZs, and with Service Auto Scaling you can maintain desired task counts and replace failed tasks. For complete resilience, the RDS database must also be Multi-AZ so both tiers of the application can survive an AZ outage.

• ✗

  Use RDS Proxy to manage database connections.

  Why it's wrong here

  RDS Proxy is a connection-pooling layer that sits between the application and the database, improving scalability and reducing database CPU/memory overhead by reusing connections, but it does not replicate data or provide a standby database. If the RDS instance is in a single Availability Zone and that AZ fails, the proxy has no healthy database to route to; RDS Proxy is itself highly available but cannot rescue a single-AZ database. It can complement a Multi-AZ deployment by keeping connection churn low during failover, but it should never be used as a substitute for Multi-AZ.

Go deeper

Related to this question