DOP-C02 SDLC Automation 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.

• ✗

  Change the deployment configuration to use AllAtOnce to avoid health checks.

  Why it's wrong here

  AllAtOnce changes the deployment strategy to target all instances simultaneously instead of gradually, but it does not disable or modify CodeDeploy's health-check validation. CodeDeploy still runs the ValidateService hook or ELB health check after install; if the endpoint returns HTTP 500, the deployment is marked failed and instances are flagged. Moreover, AllAtOnce actually increases risk by eliminating batch isolation, so it would turn a broken application into a full-site outage.

• ✗

  Increase the health check grace period in the Auto Scaling group.

  Why it's wrong here

  The Auto Scaling group health check grace period only delays the start of ASG's own EC2 status/ELB health checks on newly launched instances; it has no effect on CodeDeploy's deployment validation. CodeDeploy performs its health check immediately after application start or through the load balancer's target group, independent of ASG grace settings. Even if the grace period postpones the check, the moment it runs the endpoint still returns 500 and the deployment fails.

• ✗

  Disable the health check in the CodeDeploy deployment configuration.

  Why it's wrong here

  CodeDeploy deployment configurations control the minimum number of healthy hosts needed during a deployment, not a separate 'health check' toggle; health checks are implemented via the ValidateService hook or the load balancer's target group health checks. Skipping or disabling those checks would prevent CodeDeploy from detecting the broken endpoint and could allow traffic to be served by a failing application, which is exactly what the team needs to avoid. This option addresses the symptom by hiding the problem rather than fixing the application.

• ✓

  Modify the application to handle the health check endpoint correctly and return HTTP 200.

  Why this is correct

  The only root-cause solution is to fix the application so the health check endpoint responds with HTTP 200 (or another configured success code) once the service is up. CodeDeploy and the associated load balancer rely on that HTTP status to determine whether an instance is healthy; a 500 response signals a failed deployment and triggers rollback. Once the endpoint returns 200, the health check passes, instances remain in service, and the deployment completes successfully.

Go deeper

Related to this question