AZ-400 Design and implement build and release pipelines Practice Test 14 — 15 Questions

Question 1

You are configuring a release pipeline to deploy to Azure App Service. You want to use the 'Deploy Azure App Service' task. Which authentication method should you use to securely connect Azure DevOps to the Azure subscription?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Azure Resource Manager service connection using a service principal.. The 'Deploy Azure App Service' task requires a secure, non-interactive connection between Azure DevOps and Azure. An Azure Resource Manager service connection using a service principal is the recommended and supported method because it uses Azure AD authentication with a client secret or certificate, enabling automated, credential-free deployments without user interaction or token expiry issues.

Answer

Azure CLI authentication with a user account.

Answer

Use a SAS token for the App Service.

Answer

Managed Identity assigned to the Azure DevOps agent.

Question 2

Your team is using GitHub Actions for CI/CD. The workflow builds a container image and pushes it to Azure Container Registry (ACR). However, the workflow fails with an authentication error when pushing to ACR. What is the most likely cause?

Accepted Answer

The workflow does not include an 'azure/login' step to authenticate with Azure.. GitHub Actions workflows that push container images to Azure Container Registry (ACR) must first authenticate with Azure. Without an 'azure/login' step (using Azure CLI or Azure PowerShell actions), the workflow lacks the necessary OAuth2 tokens or service principal credentials to authorize the 'docker push' command against the ACR endpoint. The authentication error occurs because the Docker client cannot obtain a valid ACR access token without prior Azure authentication.

Answer

The repository name in the workflow is incorrect.

Answer

The Dockerfile is missing a required LABEL instruction.

Answer

The ACR allows anonymous pull access.

Question 3

You need to implement a strategy to manage secrets for your multi-stage YAML pipeline. The pipeline runs on Microsoft-hosted agents. Which approach should you use to securely pass secrets to pipeline tasks?

Accepted Answer

Use pipeline variables with 'secret: true' and reference them as $(variableName).. Azure Pipelines supports secret pipeline variables that are encrypted at rest and never exposed in logs or output. By defining a variable with `secret: true` in the YAML or via the UI, you can reference it securely as `$(variableName)` in tasks, ensuring the secret value is masked during execution.

Answer

Define the secrets as environment variables in the pipeline YAML directly.

Answer

Use the Azure Key Vault task to download secrets and then pass them as parameters.

Answer

Store secrets in a file in the repository and read it during the build.

Question 4

Your build pipeline uses the 'NuGetCommand@2' task to restore NuGet packages. You want to use packages from an Azure Artifacts feed that requires authentication. How should you configure the pipeline to authenticate with the feed?

Accepted Answer

Add a 'NuGetAuthenticate@1' task before the NuGet restore task.. The 'NuGetAuthenticate@1' task is the correct way to authenticate with Azure Artifacts feeds in a pipeline because it automatically handles credential acquisition using the built-in Azure Artifacts credential provider. It works without needing to store or manage Personal Access Tokens (PATs) manually, and it integrates seamlessly with the pipeline's identity (e.g., the project collection build service). This task must be placed before the 'NuGetCommand@2' restore task to ensure the credentials are available for package restoration.

Answer

Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.

Answer

Create an Azure Artifacts service connection and select it in the NuGet task.

Answer

Install the NuGet credential provider on the agent manually.

Question 5

Your release pipeline deploys to multiple environments (Dev, QA, Prod) using approvals. You need to ensure that the deployment to Prod only proceeds if the deployment to QA succeeded and an approval is granted. Which combination of triggers and pre-deployment conditions should you configure?

Accepted Answer

Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.. It configures the Prod stage trigger to 'After stage' with QA selected as the preceding stage, ensuring that the release to Prod only starts after QA completes successfully. Adding a pre-deployment approval on Prod then enforces that a manual approval is granted before the deployment actually begins. This combination satisfies both conditions: dependency on QA success and required approval.

Answer

Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.

Answer

Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.

Answer

Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.

Question 6

You are designing a pipeline to build a .NET Core application. The build must run unit tests and publish code coverage results. Which task should you use to publish the code coverage results to Azure DevOps?

Accepted Answer

Use the 'PublishCodeCoverageResults@1' task.. The 'PublishCodeCoverageResults@1' task is the correct choice because it is specifically designed to publish code coverage results (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps, making them visible in the build summary and pipeline artifacts. This task consumes the coverage data file generated by a previous test run (e.g., via 'DotNetCoreCLI@2' with '--collect "Code Coverage"') and uploads it to the Azure DevOps service for reporting.

Answer

Use the 'PublishTestResults@2' task.

Answer

Use the 'DotNetCoreCLI@2' task with the 'test' command.

Answer

Use the 'VSTest@2' task with the 'codeCoverageEnabled' option.

Question 7

Which TWO of the following are valid strategies to reduce the build time of a container image in Azure Pipelines?

Accepted Answer

Use Docker layer caching with a registry cache.. The correct strategies to reduce build time for a container image in Azure Pipelines are using Docker layer caching with a registry cache (C) and using a larger build agent with more CPU cores (E). Layer caching avoids rebuilding unchanged layers, while a larger agent provides more parallelism for CPU-bound build steps. Combining RUN commands (A) can hurt cache efficiency and is not a reliable way to reduce build time. Building multiple images in parallel (B) reduces overall pipeline time when you have multiple images, but it does not reduce the build time of a single image. Disabling security scanning (D) is not a valid practice.

Answer

Combine multiple RUN commands into a single RUN instruction to reduce layers.

Answer

Build multiple images in parallel using matrix strategy.

Answer

Disable security scanning for the image.

Question 8

Which THREE of the following are true about GitHub Actions self-hosted runners?

Accepted Answer

They can have custom software installed.. GitHub Actions self-hosted runners are machines you manage, allowing you to install any custom software, libraries, or tools required by your workflows. Unlike GitHub-hosted runners, which have a fixed set of pre-installed software, self-hosted runners give you full administrative control over the environment, enabling you to meet specific build or test dependencies.

Answer

They are automatically scaled by GitHub.

Answer

They are free and do not incur any costs.

Question 9

You are implementing a release pipeline with multiple stages. You want to automatically trigger the next stage only if the previous stage succeeds and the build is from the 'main' branch. Which TWO conditions should you configure?

Accepted Answer

Add a condition that checks if the source branch is 'main'.. The correct answers are A and B. To automatically trigger the next stage only when the previous stage succeeds and the build is from the 'main' branch, you need two configurations: first, set the stage trigger to 'After stage' and select the previous stage (option B), which ensures the stage runs after the previous stage completes successfully. Second, add a condition that checks the source branch—Option A correctly identifies this need, though the exact expression should be `eq(variables['Build.SourceBranch'], 'refs/heads/main')`. Option D is incorrect because `succeeded()` only checks that all previous stages succeeded but does not enforce the branch condition. Option C is wrong due to incorrect syntax (missing 'refs/heads/'). Option E is also incorrect because the syntax shown is not correct; the correct syntax requires 'refs/heads/main'.

Answer

Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.

Answer

Add a condition: 'succeeded()' to the stage.

Answer

Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.

Question 10

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

Accepted Answer

Publish Test Results task. The Publish Test Results task (A) is correct because it specifically ingests test result files (e.g., JUnit, NUnit, xUnit, or TRX formats) and publishes them to Azure DevOps, enabling test analytics, trend charts, and pass/fail reporting in the pipeline summary. For a Node.js application, after running unit tests with a framework like Jest or Mocha, the test results are typically output as JUnit XML files, and this task is required to make those results visible in the DevOps portal.

Answer

Copy Files task

Answer

npm test

Answer

Publish Build Artifacts task

Question 11

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

Accepted Answer

Add a post-deployment script that runs a rollback script on failure.. It directly addresses the requirement to automatically roll back the deployment when a database schema migration fails. By adding a post-deployment script that runs a rollback script on failure, you can execute custom logic (e.g., reverting schema changes using SQL scripts or tools like Entity Framework migrations) immediately after the deployment step detects an error. This approach provides fine-grained control over the rollback process, which is essential for database migrations that cannot be handled by Azure Pipelines' built-in auto-rollback feature, which only reverts the application deployment (e.g., swapping slots or restoring files) and does not execute custom rollback scripts.

Answer

Enable 'Auto-rollback' in the release pipeline settings.

Answer

Use a multi-stage YAML pipeline with manual intervention.

Answer

Configure pre-deployment approval gates.

Question 12

You are designing a build pipeline that uses Microsoft-hosted agents. The pipeline must build a .NET Framework 4.8 application and run on a Windows agent. Due to compliance, the build must use a specific version of Visual Studio that is not pre-installed on the Microsoft-hosted agents. What should you do?

Accepted Answer

Use a self-hosted agent that has the required version of Visual Studio installed.. To use a specific version of Visual Studio not pre-installed on Microsoft-hosted agents, you can either use a self-hosted agent with that version installed, or run the build in a Docker container that includes the required Visual Studio/Build Tools version. Microsoft-hosted agents have Docker installed and can run Windows containers, so option B is viable. Options C and D do not install a full Visual Studio version.

Answer

Specify the 'vsVersion' parameter in the MSBuild task to target the required version.

Answer

Use the 'Visual Studio Test Platform Installer' task to install the required version at build time.

Question 13

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to ensure that only pull requests from specific branches trigger a build pipeline. Which trigger configuration should you use?

Accepted Answer

pr:
  branches:
    include:
      - main
      - develop. The `pr` trigger in Azure Pipelines controls which pull requests trigger a pipeline. By using `branches` with `include`, you specify that only PRs targeting the `main` and `develop` branches should trigger the build. This directly meets the requirement to restrict PR triggers to specific branches.

Answer

pr:
  paths:
    include:
      - main
      - develop

Answer

pr:
  branches:
    only:
      - main

Answer

trigger:
  branches:
    include:
      - main
      - develop

Question 14

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

Accepted Answer

Add an additional approver in the pre-deployment approval settings.. Adding an additional approver in the pre-deployment approval settings allows another authorized user (e.g., a backup manager or team lead) to approve the deployment while the primary manager is unavailable. This maintains the required governance and security controls without blocking the critical release. Azure Pipelines supports multiple approvers, and any one of them can approve to proceed.

Answer

Skip the approval for this deployment by overriding the settings.

Answer

Configure the approval to time out after 24 hours and automatically approve.

Answer

Remove the approval requirement from the pipeline.

Question 15

Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?

Accepted Answer

on:
  pull_request:
    types: [labeled]
    branches: [main]. The `pull_request` trigger with `types: [labeled]` is the correct event to detect label additions. However, it triggers for any label, not just 'safe-to-deploy'. To ensure the workflow runs only when that exact label is applied, you must combine this trigger with a job-level conditional, e.g., `if: github.event.label.name == 'safe-to-deploy'`. The answer option C is still the correct trigger, but the explanation must clarify this additional required condition.

Answer

on:
  workflow_run:
    workflows: ["Build"]
    types: [completed]

Answer

on:
  issue_comment:
    types: [created]

Answer

on:
  pull_request_target:
    types: [opened, synchronize]
    branches: [main]