DOP-C02 - SDLC Automation (22% of the exam) - Section 1.3

Integrate automated unit, integration and security testing into pipelines using AWS CodeBuild test reports and pipeline quality gates.

Integrate unit, integration, and static analysis steps into a pipeline so that CodeBuild test reports surface failures before a deployment proceeds. Use quality gates to halt a pipeline stage when test or coverage thresholds are not met.

CodeBuild test reportsQuality gatesIntegration testingStatic analysis

Practice question for this objective

Free sampleSDLC Automationmedium

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.

CodeBuild renders per-test history and coverage only from declared report groups of type TEST and CODE_COVERAGE in the buildspec. CodeBuild parses test and coverage data into the console reporting view solely from report groups declared in the buildspec reports section, so a "TEST" group over the JUnit files and a "CODE_COVERAGE" group over the Cobertura file are both needed; raw logs and S3 artifacts hold the same data but are never parsed into reports.

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.

See more DOP-C02 practice questions, answers explained.

Exam traps in SDLC Automation

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Add an "Amazon CloudWatch" custom metric publish step that emits a pass count and a fail count from the build, then build a dashboard from those two metrics.
Why it is wrong: Custom metrics show aggregate counts but not per-test results, durations, or failure history, so this fails to deliver the requested visibility and adds scripting overhead.
Put the acceptance tests in a separate pipeline that runs nightly against staging, and let the production stage in the main pipeline deploy on its own schedule regardless of the latest test result.
Why it is wrong: Decoupling the tests onto a nightly schedule means production can deploy without the current build having passed, breaking the requirement that a failing test must stop promotion.
Attach an internet gateway route to the build subnets so the default out-of-VPC builds can reach the private endpoints over public addresses.
Why it is wrong: An internet gateway route is tempting for connectivity, but the private resources have no public access, so the route cannot reach them and out-of-VPC builds still lack interfaces in those subnets.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.