A team of developers is using an AWS CodePipeline pipeline as a continuous integration and continuous delivery (CI/CD) mechanism for a web application. A developer has written unit tests to programmat

Question

Options

• AWrite a Git pre-commit hook that runs the tests before every commit. Ensure that each developer
• BAdd a new stage to the pipeline. Use AWS CodeBuild as the provider. Add the new stage after
• CAdd a new stage to the pipeline. Use AWS CodeBuild as the provider. Add the new stage before
• DAdd a new stage to the pipeline. Use Jenkins as the provider. Configure CodePipeline to use

• A
  11% (3)
• B
  11% (3)
• C
  74% (20)
• D
  4% (1)

Explanation

Option C is correct because AWS CodeBuild integrates natively with CodePipeline and supports test reports out of the box - no additional infrastructure to manage. Critically, the new stage must be added before the deploy stage so that a test failure blocks the deployment, enforcing the "fail fast" principle of CI/CD.

Why the distractors fail:

• A is wrong because pre-commit hooks run on each developer's local machine, requiring per-developer setup and offering no centralized enforcement - high operational effort with low reliability.
• B is wrong for the same reason as C is right: placing tests after deployment means broken code has already reached the environment, defeating the purpose of automated testing.
• D is wrong because Jenkins requires you to provision, maintain, and scale your own Jenkins server, which is significantly more operational overhead than the fully managed CodeBuild service.

Memory tip: Think of the pipeline as a gate - tests are the bouncer who checks IDs before letting anyone into the club (production). AWS-native = least effort, so always prefer CodeBuild over Jenkins when the question mentions "least operational overhead."

No community discussion yet for this question.