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.

• ✗

  Create a CloudWatch alarm that monitors the health check endpoint

  Why it's wrong here

  Simply creating a CloudWatch alarm that monitors the health check endpoint does nothing unless the alarm is explicitly associated with the CodeDeploy deployment group as a rollback trigger. CodeDeploy will not automatically react to an alarm's state change; you must reference the alarm name in the deployment group's 'rollback when alarm is triggered' configuration. Without that association, the alarm remains an isolated monitoring artifact and cannot initiate a deployment rollback.

• ✓

  Configure the deployment group to roll back when a CloudWatch alarm is triggered

  Why this is correct

  Configuring the deployment group to roll back when a CloudWatch alarm is triggered is the correct action because CodeDeploy natively supports this as a rollback trigger. An alarm can monitor any custom metric—including a health check endpoint—and when it transitions to ALARM, CodeDeploy automatically rolls back the deployment to the last known-good revision. This mechanism directly ties the health check's failure signals to the deployment lifecycle, enabling the desired rollback behavior.

• ✗

  Set the Auto Scaling group health check grace period to 5 minutes

  Why it's wrong here

  The Auto Scaling group health check grace period only delays when Amazon EC2 Auto Scaling begins checking instance health after a scale-out or replacement event; it does not influence CodeDeploy's deployment evaluation. CodeDeploy uses its own lifecycle hooks (e.g., ValidateService) and configured CloudWatch alarms to determine success or failure, not ASG health checks. Modifying the grace period affects ASG-driven replacements but cannot cause a CodeDeploy rollback based on an unhealthy application endpoint.

• ✗

  Set the deployment configuration's 'timeout' to 5 minutes

  Why it's wrong here

  CodeDeploy deployment configurations do not include a field called 'timeout' for health checks; the only timeout-like setting governs the overall deployment time, not endpoint health validation. The MinimumHealthyHosts parameter defines the fraction of instances that must remain healthy to proceed, but it does not place a time limit on how long an instance can stay unhealthy. Since this option refers to a nonexistent configuration attribute, it cannot be used to trigger a rollback for a prolonged health check failure.

Go deeper

Related to this question