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.

• ✗

  Configure the Elastic Beanstalk environment to run integration tests after deployment via a custom platform hook.

  Why it's wrong here

  Custom platform hooks in Elastic Beanstalk require modifying the platform or adding .ebextensions to run scripts during the deployment lifecycle. This approach is significantly more complex than a pipeline stage, and because the hook executes inside the Elastic Beanstalk environment, test failures must be handled manually (e.g., via script exit codes) and won't automatically block the deployment pipeline. It also mixes deployment and validation into a single step, making it harder to isolate failures and integrate with CI/CD best practices. A separate CodePipeline test stage is simpler and provides native gating.

• ✗

  Use Amazon CloudWatch alarms to trigger a Lambda function that runs the tests.

  Why it's wrong here

  CloudWatch alarms are designed to monitor metric thresholds and trigger actions like Lambda or SNS notifications, not to orchestrate a test run after a deployment completes. You would need to emit custom metrics from the application, then configure an alarm to fire, which introduces asynchronous latency and no direct feedback to the pipeline. The Lambda function would run independently, and if the tests fail, there is no automatic mechanism to stop the pipeline or flag the deployment as failed. This pattern is brittle, roundabout, and lacks the structured lifecycle that CodePipeline stages provide.

• ✗

  Add a post-deployment script in the CodeDeploy appspec file to run tests.

  Why it's wrong here

  The appspec file is a CodeDeploy artifact used to define deployment lifecycle hooks for EC2/On-Premises instances, but here the application is deployed with Elastic Beanstalk, which does not use appspec. Even if CodeDeploy were used, adding a post-deployment script to run tests would only execute on the deployed instances, and a failure would not gracefully roll back or update the pipeline status. It also duplicates logic that belongs in a separate validation stage. The correct integration is to use CodePipeline with a CodeBuild test stage, as that works across deployment targets.

• ✓

  Add a test stage in CodePipeline after the deploy stage that uses CodeBuild to run integration tests.

  Why this is correct

  Adding a test stage after the deploy stage in CodePipeline leverages CodeBuild to run integration tests against the live application. This is the simplest and most automated solution because CodePipeline natively supports test actions, and a build project can be configured with the test commands and reporting. If the tests fail, the pipeline stops and marks the execution as failed, preventing the change from progressing to subsequent environments. This pattern keeps deployment and validation isolated, adheres to CI/CD best practices, and requires no extra infrastructure or custom lifecycle scripts.

Go deeper

Related to this question