A pipeline is only as trustworthy as what it builds from and what it proves. This set covers two AZ-400 skill areas that are easy to underestimate: package management (feeds, views, upstream sources, and versioning) and testing strategy (test types, publishing results, code coverage, flaky tests, and quality gates). Expect scenario questions that ask you to pick the right feed setup or the right place in the pipeline for a test.
This is the third post in our AZ-400 series (Questions 21-30). The previous set, AZ-400 Questions 11-20: Azure Pipelines, Agents, and YAML Design, covers triggers, agents, and templates. Every question here is an original practice scenario, not a copy of a real exam item.
Question 21: Sharing Internal Libraries
Contoso’s teams build internal NuGet and npm libraries that other teams consume. Code and pipelines are in Azure DevOps. The packages must not be published to public registries. Which service should host them?
A) Azure Artifacts
B) Azure Container Registry
C) Azure Blob Storage with a public container
D) The public nuget.org and npmjs.com registries with private names
👁 Reveal Answer
Correct Answer: A
Explanation: Azure Artifacts provides private feeds for NuGet, npm, Maven, Python, Cargo, and Universal Packages, integrated with Azure DevOps permissions and pipelines. B stores container images and OCI artifacts, not NuGet or npm library feeds for typical consumption. C exposes files publicly and offers no package manager integration. D publishes the code publicly, which violates the requirement. If the code lived in GitHub, GitHub Packages would be the equivalent choice.
Question 22: Controlling Public Dependencies
Fabrikam wants developers to install public npm packages only through the company feed, so that every package version used is saved and still available even if it is later removed from the public registry. What should you configure?
A) A .npmrc file pointing directly to npmjs.com
B) A second feed that mirrors npmjs.com nightly with a script
C) An upstream source from the Azure Artifacts feed to npmjs.com
D) A feed view named @Public
👁 Reveal Answer
Correct Answer: C
Explanation: With an upstream source, developers point only at the company feed. When a package is requested that is not yet in the feed, Azure Artifacts fetches it from the public registry and saves a copy, so that version stays available even if the original disappears. It also gives one place to see and control what is used. B is fragile custom work and copies far more than needed. A bypasses the company feed entirely. D is not how views work — views filter packages already in a feed; they do not connect to external registries.
Question 23: Sharing Only Stable Packages
Northwind Traders publishes every build of a shared library to one Azure Artifacts feed. Consumer teams should see only versions that have passed integration testing. What is the simplest approach?
A) Create a separate feed for each consumer team
B) Promote tested versions to the @Release view and have consumers use that view
C) Delete every untested version after each build
D) Add “-stable” to the description of tested packages
👁 Reveal Answer
Correct Answer: B
Explanation: Feed views share a filtered subset of package versions. Every feed starts with @Local, @Prerelease, and @Release views; promoting a version to @Release after it passes testing makes it visible to consumers who connect to that view, while untested builds stay hidden. A multiplies feeds and duplicates packages. C destroys history and breaks anyone who pinned a version. D changes nothing that package managers can filter on.
Question 24: Versioning a Breaking Change
Your team maintains a library at version 3.4.2 that follows semantic versioning (SemVer). The next release removes a public method that consumers currently call. What should the new version be?
A) 3.4.3
B) 3.5.0
C) 4.0.0
D) 2026.10.0
👁 Reveal Answer
Correct Answer: C
Explanation: SemVer uses MAJOR.MINOR.PATCH. Removing a public method is a breaking change, so the MAJOR number increases and the others reset: 4.0.0. A is for backward-compatible bug fixes. B is for backward-compatible new features. D is calendar versioning (CalVer), which encodes the release date rather than compatibility — useful for applications released on a schedule, but it would not tell consumers this release breaks them. The AZ-400 outline names both SemVer and CalVer, so know when each fits.
Question 25: Package Versions Are Permanent
A developer published version 1.2.0 of a package to Azure Artifacts, then found a bug. They try to publish a corrected package with the same version number, and the push fails. What should they do?
A) Delete 1.2.0 and publish the fix as 1.2.0 again
B) Publish the fix to a different feed as 1.2.0
C) Ask an administrator to disable version checks on the feed
D) Publish the fix as 1.2.1
👁 Reveal Answer
Correct Answer: D
Explanation: Package versions in Azure Artifacts are immutable: once a version is published, that version number cannot be reused, even after deletion. This protects consumers — anyone who restored 1.2.0 always gets the same bits. The right fix is a new version, 1.2.1. A is blocked for exactly this reason. C is not an available setting. B creates two different packages with the same identity, which leads to confusing, hard-to-debug builds. You can deprecate or unlist the faulty version so new consumers avoid it.
Question 26: Where Each Test Belongs
Woodgrove Bank wants fast feedback on every pull request while still validating the full system before production. Which arrangement is best?
A) Run load tests on every pull request and unit tests weekly
B) Run unit tests on every pull request, integration tests after deploying to a test environment, and load tests before production releases
C) Run only manual tests before each production release
D) Run every test type on every commit to every branch
👁 Reveal Answer
Correct Answer: B
Explanation: A good testing strategy follows the test pyramid: many fast, cheap unit tests early (on every PR), fewer integration tests once components are deployed together, and expensive load tests (for example, with Azure Load Testing) closer to release. This balances fast feedback with confidence. A inverts the pyramid — slow, costly tests on every change and fast tests rarely. C gives no automated feedback. D wastes time and money and slows every developer down.
Question 27: Showing Test Results in Azure Pipelines
Your pipeline runs tests with a framework that writes JUnit XML files. You want the results to appear on the pipeline run’s Tests tab, with trends over time. What should you add?
A) A wiki page updated after each run
B) A step that uploads the XML files as a pipeline artifact
C) A script that prints the XML to the log
D) A PublishTestResults task that points to the JUnit files
👁 Reveal Answer
Correct Answer: D
Explanation: The Publish Test Results task reads common result formats such as JUnit, NUnit, xUnit, and VSTest and feeds them into Azure Pipelines test reporting, which powers the Tests tab, failure details, and analytics across runs. Many built-in test tasks publish automatically, but script-based test runs need this task. B stores the files but does not parse them into reports. C clutters logs and gives no analytics. A is manual and disconnected from the run.
Question 28: Measuring What the Tests Cover
Leadership asks how much of the codebase is exercised by automated tests, and wants the figure shown for every build. What should you implement?
A) Code coverage analysis, published to the pipeline run with a code coverage task
B) A count of how many test files exist in the repository
C) A load test that reports requests per second
D) A dashboard widget showing the number of pull requests
👁 Reveal Answer
Correct Answer: A
Explanation: Code coverage tools record which lines or branches run during tests. Publishing the report (for example, Cobertura or JaCoCo format with the Publish Code Coverage Results task) shows coverage on the pipeline run, and you can add a pull request coverage check to stop coverage dropping. B measures effort, not coverage. C measures performance. D measures activity. Remember that high coverage does not prove tests are good — it only shows which code they touched.
Question 29: Tests That Pass and Fail Randomly
A handful of tests in Adventure Works’ pipeline fail roughly one run in ten with no code change, and developers have started ignoring red builds. What is the best first step?
A) Delete every test that has ever failed
B) Add automatic retries to the whole pipeline until it passes
C) Use flaky test detection to identify and quarantine those tests, then fix them
D) Turn off failure notifications
👁 Reveal Answer
Correct Answer: C
Explanation: Flaky tests destroy trust in the pipeline. Azure Pipelines test analytics can flag tests as flaky so their failures stop blocking runs while the team fixes the underlying cause, such as timing issues or shared state. Monitoring flaky tests is listed under pipeline health in the AZ-400 outline. A throws away useful coverage, including tests that caught real bugs. B hides real failures behind retries. D removes the signal entirely.
Question 30: An Automated Quality Gate
Coho Winery wants a deployment to production to proceed only if there are no active Azure Monitor alerts on the staging environment after it has run for 15 minutes. The pipeline uses YAML environments. What should you configure?
A) A manual approval on the production environment
B) A Query Azure Monitor alerts check on the production environment
C) A branch policy requiring two reviewers
D) A sleep 900 script step before deployment
👁 Reveal Answer
Correct Answer: B
Explanation: Environment checks act as automated quality and release gates. The Query Azure Monitor alerts check evaluates alert rules and can be re-evaluated over a time window, so production deployment proceeds only when staging is healthy. A relies on a human looking at dashboards. C controls code merges, not deployments. D waits but never checks anything. Gates can also cover security and governance, such as invoking a REST API that confirms a change ticket is approved.
Study Tips for Packages and Testing
- Know the feed building blocks. Feeds hold packages, upstream sources pull and save public packages, and views (
@Local,@Prerelease,@Release) share filtered subsets. - Memorize SemVer rules. Breaking change: MAJOR. New compatible feature: MINOR. Fix: PATCH. CalVer encodes dates instead.
- Remember immutability. A published package version can never be reused — publish a new version instead.
- Think in the test pyramid. Unit tests early and often, integration tests after deployment, load tests before release.
- Separate publishing from running. Running tests is not enough; publish results and coverage so the pipeline can report and gate on them.
Keep Practicing for AZ-400
Continue with AZ-400 Questions 31-40: Deployment Strategies and Release Safety, which covers blue-green, canary, rings, slots, and feature flags. For reference, read Microsoft’s upstream sources overview alongside Question 22, and check the official AZ-400 study guide for the full skills list.
