A team runs unit and integration tests inside an "AWS CodeBuild" build action in "AWS CodePipeline". The tests already write results in JUnit XML and the build also produces a Cobertura coverage file, but the console only shows pass or fail in the raw logs, with no per-test history and no coverage figures, and leadership now wants both surfaced in the CodeBuild console after every run. The team wants to expose this visibility natively without bolting on a separate dashboard. Which TWO buildspec changes together make both the test outcomes and the coverage appear as structured reports? (Select TWO.)
- AAdd a reports section that declares a report group of type "TEST" pointing at the JUnit XML files so CodeBuild ingests them as a test report. Correct
- BAdd a second report group of type "CODE_COVERAGE" in the reports section pointing at the Cobertura file so CodeBuild parses line and branch coverage. Correct
- CPipe the JUnit and coverage output to standard out and raise the build log retention so engineers can scroll the raw logs for results.
- DPublish the JUnit and Cobertura files as build artifacts to Amazon S3 and grant the console read access to that bucket for browsing.
Why A is correct: Declaring a "TEST" report group over the JUnit files makes CodeBuild parse them into a test report with per-test pass, fail, duration and history in the console.
Why B is correct: A "CODE_COVERAGE" report group over the Cobertura file makes CodeBuild surface line and branch coverage as a structured report alongside the test results.
Why C is wrong: Longer log retention keeps the same raw text and feels like more visibility, but it never produces the parsed test and coverage reports the console view requires.
Why D is wrong: Storing the files as S3 artifacts preserves them and is tempting, but CodeBuild only renders test and coverage reports from declared report groups, not from artifacts in a bucket.