AZ-400 Practice Question: Design and implement build and release pipelines

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  DotNetCoreCLI@2

  Why this is correct

  DotNetCoreCLI@2 runs the `dotnet test` command, which discovers and executes unit tests in .NET Core and .NET 5+ projects using the dotnet test runner, supporting VSTest and xUnit/NUnit/MSTest adapters via the `command: test` and `arguments` inputs.

• ✓

  VSTest@2

  Why this is correct

  VSTest@2 is the correct choice when test assemblies have already been compiled into .dll or .exe artifacts. It executes VSTest.console.exe directly, which uses configured test adapters to discover and run tests across frameworks like MSTest, xUnit, and NUnit. This task provides fine-grained control through inputs such as `testAssemblyVer2`, `testFiltercriteria`, and `codeCoverageEnabled`, making it ideal for full-framework or non-SDK-style projects where you don't need a `dotnet test` wrapper. Unlike DotNetCoreCLI@2, it does not restore or build the project, so it runs only the compiled test binaries.

• ✗

  NuGetCommand@2

  Why it's wrong here

  NuGetCommand@2 is scoped exclusively to NuGet package lifecycle operations: restore, pack, and push. It orchestrates the NuGet client to resolve dependencies or publish packages, but it does not reference test assemblies, invoke a test host, or drive a test adapter. Running unit tests requires a command that executes the test runner (e.g., `dotnet test` or VSTest.console.exe), which NuGetCommand@2 cannot do. Even if tests are packaged as NuGet packages, the task only handles the package itself, never its test execution.

• ✗

  PublishBuildArtifacts@1

  Why it's wrong here

  PublishBuildArtifacts@2 handles post-build artifact publication: it uploads files either to Azure Pipelines as pipeline artifacts or to a file share for external retention. Its only responsibility is copying artifacts from a staging directory to the chosen destination, and it has no notion of test discovery, test adapters, or test execution. This task is often placed after tests run to preserve test result files, but it cannot produce those results itself. Because it does not invoke a test runner or parse test metadata, it is completely orthogonal to executing unit tests.

• ✗

  CopyFiles@2

  Why it's wrong here

  CopyFiles@2 is a generic file-copy utility that moves or copies files between local paths using include/exclude patterns, often to stage files for publishing or to gather outputs. It operates solely on the filesystem: given source and target folders, it duplicates matching files without inspecting their content or purpose. It never reads a test assembly, loads a test runner, or triggers a test host process, so it can only support a testing workflow incidentally (e.g., copying compiled test binaries), never actually run the tests. This task's purpose is file transport, not test execution, which is why it is inapplicable here.

Go deeper

Related to this question