AZ-400 - Design and Implement Build and Release Pipelines (53% of the exam) - Section 3.3

Design and implement a testing strategy in pipelines, including unit, integration, and load tests, test tasks, and test agents.

Design a pipeline testing strategy that layers unit tests, integration tests, and load testing at appropriate stages, and configure test tasks to publish results back to Azure Pipelines or GitHub Actions. Recognise how test result integration enables trend analysis and quality gates that block promotion on regression.

unit testsintegration testsload testingtest taskstest result integration

Practice question for this objective

Free sampleDesign and Implement Build and Release Pipelinesmedium

A team runs an "Azure Load Testing" test as a step in a release pipeline and wants the pipeline to fail automatically when the load run shows the API's 95th percentile response time exceeding 800 milliseconds, so a slow build never promotes to production. The load test already runs and reports metrics, but a breach currently leaves the pipeline green. What should the team configure so the breach fails the run?

AAdd a manual approval check on the production environment so a reviewer inspects the "Azure Load Testing" dashboard after the run and rejects the deployment when the response time looks too high.
BLower the configured number of virtual users in the load test so the API is pushed less hard and the 95th percentile response time stays under the target during the run.
CAdd an "Application Insights" smart detection rule on response time so an anomaly alert is raised after deployment and the on-call engineer rolls the release back when it fires.
DDefine a pass or fail criterion in the load test that fails the test when the 95th percentile response time metric exceeds 800 milliseconds, so the failing test fails the pipeline step. Correct

Define pass or fail criteria in an Azure Load Testing test so a metric breach fails the load test and therefore the pipeline step. Azure Load Testing evaluates pass or fail criteria against aggregate metrics such as percentile response time, error rate, or requests per second. When a criterion is breached the test result is marked failed, and because the pipeline task reports that result the step fails, blocking promotion without any manual review.

Why A is wrong: A manual approval relies on a person reading the dashboard, which is neither automatic nor a property of the load run, so it does not make the breach itself fail the pipeline.

Why B is wrong: Reducing the load hides the problem by easing the test rather than enforcing a limit, so a genuinely slow build would still pass and reach production.

Why C is wrong: Smart detection alerts on live telemetry after release rather than gating the load run, so the build still promotes before anyone reacts to the alert.

Why D is correct: A pass or fail criterion evaluates the chosen metric against the threshold and marks the load test failed when breached, and a failed test fails the pipeline step automatically without human action.

See more AZ-400 practice questions, answers explained.

Exam traps in Design and Implement Build and Release Pipelines

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

Add the "Publish Pipeline Artifact" task pointed at the JUnit file, so the results file is uploaded with the run and the Tests tab reads it from the stored artifact.
Why it is wrong: Publishing an artifact only uploads the file for download and does not parse test results, so the Tests tab stays empty even though the file is attached to the run.
Configure each job to upload its results file with the "Publish Pipeline Artifact" task, so the four files arrive together under one artifact and the Tests tab reads the combined artifact.
Why it is wrong: Publishing artifacts only stores the files for download and never parses test results, so the Tests tab gains nothing and the four sets are still not consolidated.
Supply an OpenAPI specification of the API, so "Azure Load Testing" reads the endpoint definitions and generates the request mix and ramp-up automatically from the schema.
Why it is wrong: An OpenAPI document describes endpoints but does not encode the team's request mix, ramp-up, or think times, so it cannot reuse the existing performance script as the load definition.

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