Task 1.2: Integrate automated testing into CI/CD pipelines.

• AAdd a test stage with a CodeBuild action to the existing pipeline, directly after its source stage

  Incorrect

  The existing pipeline starts on pushes to main, so the tests would run only after a change is merged, too late for the reviewers.

• BCreate a CodeBuild project with a GitHub webhook whose filter group matches the PULL_REQUEST_CREATED and PULL_REQUEST_UPDATED events

  Correct

  Webhook filter groups decide which GitHub events start a build, and these two events cover a new pull request and new commits pushed to it.

• CCreate a CodeBuild project with a GitHub webhook whose filter group matches the PUSH event with a head reference of main

  Incorrect

  A push to main happens when the pull request is merged, so this also tests the code only after the merge.

• DRun the CodeBuild project every 15 minutes with EventBridge Scheduler and have the build find and test the newest open pull request

  Incorrect

  A schedule misses pull requests and commits between runs and needs code to find them. Webhook events start a build for each one.

Tests that gate a merge have to run on pull request events. A CodeBuild webhook with a filter group for pull request creation and updates starts a build for each new pull request and for every new commit on it.

• AA metric filter on the build's CloudWatch Logs log group that extracts the coverage percentage from the test output

  Incorrect

  A metric filter turns values in log events into a CloudWatch metric. It gives no test case results and no coverage report in CodeBuild.

• BAn artifacts section that uploads the test output folder to Amazon S3, with an Amazon Athena table defined over that folder

  Incorrect

  This builds and runs extra infrastructure for something CodeBuild reports already provide, and the results do not appear in the CodeBuild console.

• CAWS X-Ray tracing turned on for the build project and for the test runner's HTTP client

  Incorrect

  X-Ray collects data about requests an application serves. It does not record test outcomes or code coverage.

• DA reports section in the buildspec with one report group for the JUnit XML files and one for the JaCoCo XML report

  Correct

  CodeBuild creates test reports from JUnit XML and coverage reports from JaCoCo XML when the buildspec names a report group, and keeps a new report for each run.

CodeBuild reports need no separate setup: naming a report group in the buildspec creates it on the first run. Test reports accept formats such as JUnit XML, and coverage reports accept JaCoCo XML, Cobertura XML, Clover XML and SimpleCov JSON.

• AThe function never reports the job result; it must call PutJobFailureResult or PutJobSuccessResult with the job ID from the event

  Correct

  A function used by this action must call one of these two APIs. Otherwise the action execution hangs until the action times out.

• BThe function's own timeout is set too high; lowering it to 30 seconds makes the action fail as soon as the function stops running

  Incorrect

  Lambda's function timeout is separate from the CodePipeline action timeout, so a shorter function timeout does not end the action.

• CThe action declares no output artifact; adding one lets CodePipeline see that the function has finished

  Incorrect

  Output artifacts are optional and are uploaded by the function itself. Completion is reported only through the job result APIs.

• DThe pipeline's service role lacks lambda:InvokeFunction, so CodePipeline cannot tell when the function has finished

  Incorrect

  The function runs and writes its log, so the invocation succeeds. What is missing is the call that reports the job's result.

CodePipeline waits for the function to report success or failure for the job it was given. A failed check should call PutJobFailureResult, which fails the action at once instead of leaving it to time out.

• ASplit the suite into seven CodeBuild projects that run as parallel pipeline actions, and merge their reports in a final Lambda action

  Incorrect

  This works but adds seven projects and custom merge code. CodeBuild batch builds already split tests and combine the reports.

• BMove the project to a larger compute type and run the test runner with several threads in the same build container

  Incorrect

  Multithreading runs tests in one process space, which needs changes to the tests and brings shared-state and race condition problems.

• CTurn on local caching for the project so that dependencies are not downloaded again for every build

  Incorrect

  A cache reuses parts of the build environment across builds. It does not shorten the time the tests themselves take to run.

• DUse a batch build with build-fanout and a parallelism of 7, and start the suite with the codebuild-tests-run command

  Correct

  Build fanout starts identical builds that each run a share of the tests that codebuild-tests-run assigns, and CodeBuild combines their test reports at the batch level.

Independent tests can run in separate, isolated environments. In a CodeBuild batch build, the parallelism value sets how many builds run the suite and codebuild-tests-run splits the test files among them, so the wall-clock time drops roughly with the number of builds.

• ARun an AWS Fault Injection Service experiment against the staging environment before each release

  Incorrect

  FIS injects faults such as stopped instances to test resilience; it does not generate user traffic or run JMeter scripts.

• BDeploy Distributed Load Testing on AWS, then start the JMeter scenario in the three Regions and read its results through the solution's API

  Correct

  The solution runs JMeter tests on Fargate containers across several Regions without servers to provision, and its API creates test scenarios and returns success percentages and latency percentiles.

• CCreate CloudWatch Synthetics canaries in the three Regions that run the staging user journeys once a minute

  Incorrect

  Canaries are scripted checks that follow the routes of a customer to monitor availability and latency; they do not simulate thousands of users or run JMeter scripts.

• DLaunch an EC2 Auto Scaling group of JMeter instances in each Region from a CloudFormation stack that the pipeline creates for each test

  Incorrect

  This can generate the load, but the team would build and maintain the generator fleet and the code that coordinates it, which it wants to avoid.

Distributed Load Testing on AWS deploys containers on Amazon ECS on AWS Fargate that simulate tens of thousands of users across Regions with JMeter, k6 or Locust scripts. Its API lets a pipeline create a scenario and read the results of each test run.

• ASnapshot tests that compare the whole synthesized template with a stored baseline

  Incorrect

  Any template change, such as a new tag or a CDK upgrade, would fail the snapshot.

• BDeploying the construct to a test account and checking the buckets in the console after each change

  Incorrect

  This is a manual check in the cloud, not a unit test in the pipeline.

• Ccdk synth in the pipeline with no assertions, relying on synthesis errors to find problems

  Incorrect

  Synthesis succeeds even when encryption or versioning is missing.

• DFine-grained assertions that check the bucket properties in the synthesized template

  Correct

  Fine-grained assertions test specific resource properties and catch regressions without failing on unrelated changes.

The CDK assertions module supports fine-grained assertions on specific template properties and snapshot tests against a baseline. Fine-grained assertions are the most common and suit regression checks.

• Aon-failure: CONTINUE in the build phase so that the build moves on to the next phase

  Incorrect

  CONTINUE moves on to the next phase instead of running the failed work again.

• Bon-failure: RETRY-2 in the build phase, so that CodeBuild retries the build

  Correct

  RETRY-count retries the build the given number of times when the phase fails, which works on CodeBuild's EC2 compute images.

• CAutomatic retry on stage failure for the test stage, with the retry failed actions mode

  Incorrect

  Stage retry reruns only the failed actions without custom code, but automatic retry on stage failure makes only one retry attempt.

• DA finally block in the build phase that starts the build again with the AWS CLI when the suite fails

  Incorrect

  This is custom retry logic of the kind the team wants to avoid, and the on-failure setting already provides it.

Each buildspec phase can set on-failure to ABORT, CONTINUE or a RETRY variant, and RETRY-count sets the number of retries. The setting is not supported on Lambda compute or reserved capacity. CodePipeline's automatic stage retry is limited to a single attempt.

• AUse a stage variable for the integration's function name, fn:beta in test and fn:live in prod

  Correct

  Stage variables can name a different Lambda function or alias for each stage of one API, and the function's permissions must be added for the names that the variable resolves to.

• BCreate a second REST API for testing that copies every resource, method and authorizer of the first one

  Incorrect

  This keeps beta away from production, but the team would maintain two API definitions that drift apart.

• CConfigure weighted routing on the live alias that sends 10 percent of invocations to the version behind the beta alias

  Incorrect

  This keeps one API definition, but it routes a share of production requests to beta code, and testers cannot choose which version runs.

• DCreate a function URL on the beta alias with the AWS_IAM auth type and give testers its endpoint

  Incorrect

  Testers would reach beta directly, but function URLs support only IAM or no authentication and skip the API's authorizer and request validation.

Stage variables are name-value pairs attached to a stage. They can supply parts of the integration, such as a Lambda alias, so one API definition serves several stages that each call different code.

• Asam local invoke with event files that are committed to the repository

  Incorrect

  Committed files can be shared and run from the command line, but this runs the code in a local container instead of the deployed function.

• Bsam remote invoke with shareable test events, managed with sam remote test-event

  Correct

  sam remote invoke calls deployed resources from the command line, and shareable test events are stored in the account and shared with others in it.

• CShareable test events that the developers create and run on the Test tab of the Lambda console

  Incorrect

  These events are shared in the account and run against the deployed function, but the console cannot run them from the CI job or a terminal.

• DAn EventBridge rule that sends the sample events to the function every five minutes

  Incorrect

  Scheduled events run in the cloud but are not on-demand tests from the command line.

sam remote invoke interacts with resources deployed in the AWS Cloud. Shareable test events are stored in an EventBridge schema registry in the account, and sam remote test-event retrieves, uploads and deletes them.