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.

• ✗

  The deployment failed because the ECS service was using the rolling update deployment controller. Change to blue/green deployment.

  Why it's wrong here

  The deployment controller type—rolling update versus blue/green—does not determine whether a deployment fails when new tasks cannot reach a healthy state; both controllers will mark the deployment as failed if the new task set cannot stabilize. Switching to blue/green would delegate traffic shifting and rollback to AWS CodeDeploy, but without an ECS-level circuit breaker, the underlying service would still have no automatic way to detect task launch failures and revert to the last stable version. The real root cause is the missing deployment circuit breaker, which is required to trigger an automatic rollback regardless of the controller used.

• ✓

  The deployment failed because the ECS service did not have the deployment circuit breaker enabled. Enable the circuit breaker with rollback.

  Why this is correct

  The correct fix is to enable the ECS deployment circuit breaker with rollback. This feature monitors the deployment for indicators such as repeated task launch failures, container exits, and health check failures; when it detects that the deployment is failing beyond a configured threshold, it stops the deployment and automatically restores the service to the most recent successful task set definition. This preserves service availability by keeping the existing stable tasks running and eliminates the need for you to manually roll back a bad task definition. Without the circuit breaker, a deployment with continuously crashing tasks will eventually time out and leave the service in a FAILED state with no automatic recovery.

• ✗

  The deployment failed because the desired count was too low. Increase the desired count to 6.

  Why it's wrong here

  The desired count is purely a capacity setting that specifies how many task copies the service should run; it has no bearing on whether a task definition is valid or whether a container starts correctly. If the image or environment is fundamentally broken, every replica will fail regardless of whether the desired count is 2 or 6, so increasing it only adds more failing tasks. Deployment success depends on new tasks passing health checks and becoming stable, which can only be enforced and rolled back automatically through the deployment circuit breaker.

• ✗

  The deployment failed because the health check grace period was too short. Increase the grace period.

  Why it's wrong here

  The health check grace period gives newly launched tasks a buffer during which Elastic Load Balancing health checks are temporarily paused, allowing the container to finish initializing before being judged healthy. However, it does nothing to address tasks that crash immediately at startup, are killed by OOM or other runtime errors, or have an invalid command that prevents the process from execyuting; such tasks never become RUNNING, so the grace period cannot prevent them from failing. Therefore, tuning the grace period only masks latency in health check accuracy and cannot rescue an invalid task definition; the deployment circuit breaker is the mechanism that detects those failures and rolls back automatically.

Go deeper

Related to this question