AZ-400 - Design and Implement Build and Release Pipelines - 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.

More in this domain

Back to all Design and Implement Build and Release Pipelines objectives, or the AZ-400 cert hub.

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