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

Question 1

You are configuring a release pipeline that deploys to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which type of trigger should you use for the release pipeline?

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

Accepted Answer

Build completion trigger. A build completion trigger ensures that the release pipeline is initiated only after a specific build pipeline completes, allowing the same build artifact to be deployed across multiple environments without rebuilding. This trigger is ideal for multi-environment release pipelines where consistency of the artifact is critical, as it decouples the build from the release and promotes the identical binary through dev, test, and prod.

Answer

Pull request trigger

Answer

Continuous integration (CI) trigger

Answer

Scheduled trigger

Question 2

Your build pipeline uses a self-hosted agent in your on-premises network. The agent pool is configured to use the 'latest' agent version. Recently, a new version of the Azure Pipelines agent was released, and your builds started failing because the new agent requires .NET 6.0, which is not installed on the agent machine. What is the best way to prevent this issue in the future?

Accepted Answer

Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.. It decouples your production pipeline from automatic agent updates. By pinning the agent pool to a known-working version (e.g., '2.210.0'), you can validate new agent releases in a separate test pool before rolling them out. This prevents breaking changes—like a new .NET dependency—from impacting your builds without prior testing.

Answer

Switch to using Microsoft-hosted agents instead of self-hosted.

Answer

Disable automatic agent updates on the self-hosted agents.

Answer

Install .NET 6.0 on the agent machine to meet the new requirement.

Question 3

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

Accepted Answer

push: branches: [main]. In GitHub Actions, merging a pull request into `main` results in a `push` event to `main`. The `push` trigger with `branches: [main]` therefore correctly fires whenever a PR is merged. `pull_request: types: [closed]` fires on any PR closure, whether merged or not, so it would deploy even when a PR is closed without merging. To use `pull_request` for merges, you would need an additional `if: github.event.pull_request.merged == true` check, but the question asks for the event trigger alone.

Answer

pull_request: branches: [main]

Answer

pull_request: types: [closed] branches: [main]

Answer

release: types: [published]

Question 4

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Accepted Answer

Define secrets as pipeline secret variables and reference them as $(secretName).. Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Answer

Store secrets in environment variables on the agent machine.

Answer

Store secrets in a YAML file and include the file in the repository.

Answer

Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.

Question 5

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Accepted Answer

The approver must have the 'Approve pipeline permissions' permission for the environment.. The 'Approvals' feature in Azure Pipelines requires an environment to be defined in the pipeline. You must add an approval check to that environment, which can be done in either a classic release pipeline or a YAML pipeline that references the environment as a resource. Additionally, the approver(s) - whether individual users or groups - must have the 'Approve pipeline permissions' permission on that environment. Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Answer

The approver must be an individual user, not a group.

Answer

The approval must be configured in the release pipeline's pre-deployment conditions.

Question 6

Which TWO are valid strategies for reducing build times in Azure Pipelines? (Choose two.)

Accepted Answer

Implement caching for package dependencies (e.g., npm, NuGet, Maven) to avoid restoring on every build.. Caching package dependencies (e.g., npm, NuGet, Maven) avoids restoring them on every build, reducing download time. Incremental builds (e.g., using 'dotnet build --no-restore' with appropriate flags or MSBuild's incremental building) skip projects that haven't changed, reducing compilation time. Option A is incorrect because reducing parallel jobs and adding steps increases build time. Option B is incorrect because removing unit tests compromises quality and is not a valid strategy. Option E is incorrect because increasing agents without parallelizing jobs or running all jobs on the same agent does not reduce build time.

Answer

Reduce the number of parallel jobs and increase the number of steps in a single job.

Answer

Remove unit tests from the build pipeline and run them only in the release pipeline.

Answer

Increase the number of agents in the pool and run all jobs on the same agent.

Question 7

Which THREE are benefits of using 'Environment' resources in YAML pipelines compared to classic release pipelines? (Choose three.)

Accepted Answer

Environments provide a dashboard showing the deployment history and resource health.. Option A is correct because Azure DevOps Environments provide a dedicated dashboard that surfaces deployment history and the health/status of the associated resources (VMs, Kubernetes, etc.), giving visibility that classic release pipelines lack in a unified view. Option C is correct because Environments support configurable checks such as approvals, business hours, and manual intervention, which gate pipeline stages before deployment proceeds. Option E is correct because an Environment can be backed by a Kubernetes resource, where the target can be a namespace, and the environment tracks the deployed versions/artifacts to that namespace. Option B is incorrect because Environments are designed for YAML pipelines, not classic release pipelines. Option D is incorrect because pre-deployment and post-deployment gates are a classic release pipeline feature, not a benefit of Environments in YAML pipelines.

Answer

Environments can only be used in classic release pipelines.

Answer

Environments allow you to define pre-deployment and post-deployment gates using the classic release pipeline interface.

Question 8

Your team uses Azure Pipelines with GitHub for source control. You need to ensure that whenever a pull request is created against the main branch, a validation build runs automatically. Which YAML trigger should you configure in the pipeline?

Accepted Answer

pr: branches: include: - main. The correct syntax for a pull request trigger in Azure Pipelines YAML. The `pr` trigger requires a `branches` node with `include` or `exclude`, and the verbose form `pr: branches: include: - main` is fully valid. Option B, `pr: main`, is not valid YAML syntax for Azure Pipelines; the shorthand `pr: main` is not recognized and will cause the pipeline to ignore the trigger. Options C and D use the `trigger` keyword, which is for CI builds on push, not for PR validation.

Answer

pr: main

Answer

trigger: branches: exclude: - main

Answer

trigger: main

Question 9

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

Accepted Answer

Canary deployment. Canary deployment is the correct choice because it gradually shifts a small percentage of traffic to the new version while monitoring for errors, allowing you to detect issues early and roll back quickly without impacting all users. In AKS, this can be implemented using a service mesh like Istio or a progressive delivery tool like Flagger, which manages traffic splitting via VirtualService and DestinationRule configurations. This minimizes downtime by ensuring the majority of users remain on the stable version until the new version is verified.

Answer

Recreate deployment

Answer

Blue-green deployment

Answer

Rolling update

Question 10

Your build pipeline uses a self-hosted agent that runs on a Windows machine. The pipeline fails with the error: 'The task 'DotNetCoreCLI' is not supported on this agent.' What is the most likely cause?

Accepted Answer

The agent does not have the required capabilities (e.g., .NET Core SDK installed).. The error 'The task 'DotNetCoreCLI' is not supported on this agent' indicates that the agent lacks the required capabilities to execute the task. In Azure Pipelines, self-hosted agents must have the necessary software (e.g., .NET Core SDK) installed and declared as capabilities for the task to be considered supported. Option B correctly identifies this missing capability as the root cause.

Answer

The agent's execution policy is restricted.

Answer

The agent is not authorized to run the pipeline.

Answer

The agent cannot connect to the internet to download the task.

Question 11

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

Accepted Answer

Pre-deployment approvals on the Production environment. Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Answer

Post-deployment approvals on the Production environment

Answer

Deployment queue settings on the Production environment

Answer

Deployment gates on the Production environment

Question 12

Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?

Accepted Answer

The package path is wrong; the zip file is in $(Build.ArtifactStagingDirectory).. The error 'Could not find the package in the specified path' indicates that the AzureWebApp task is looking for a deployment package (typically a .zip file) at a path that does not exist. In the exhibit, the `dotnet publish` command outputs to `$(Build.ArtifactStagingDirectory)`, but the subsequent AzureWebApp task likely references a different path (e.g., `$(System.DefaultWorkingDirectory)` or a hardcoded path). The correct path should be `$(Build.ArtifactStagingDirectory)/**/*.zip` to match the published artifact. Option A correctly identifies this path mismatch as the root cause.

Answer

The AzureWebApp task input 'appType' is incorrect.

Answer

The dotnet publish command did not generate a zip file.

Answer

The service connection 'MyServiceConnection' is not authorized.

Question 13

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Answer

Environment variables in the workflow YAML

Answer

Hardcode the secrets in the workflow file

Answer

Azure Key Vault with Azure DevOps encrypted variables

Question 14

You have a multi-stage YAML pipeline that builds and deploys a Java application. The pipeline runs on a Microsoft-hosted agent. The build stage fails intermittently with 'OutOfMemoryError: Java heap space'. What should you do to resolve this issue?

Accepted Answer

Set the environment variable 'MAVEN_OPTS' to '-Xmx2048m'.. The 'OutOfMemoryError: Java heap space' in a Maven build indicates that the JVM running Maven needs more heap memory. Setting the environment variable 'MAVEN_OPTS' to '-Xmx2048m' increases the maximum heap size for the Maven JVM process to 2048 MB, which resolves the memory issue. This is the standard and correct approach for Maven-based builds.

Answer

Use a self-hosted agent with more memory.

Answer

Set the environment variable 'GRADLE_OPTS' to '-Xmx2048m'.

Answer

Use the 'Maven@3' task with the 'jdkVersion' option set to 'jdk11'.

Question 15

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

Accepted Answer

Blue-green deployment. This strategy is a blue-green deployment because it uses two complete environments (primary and secondary regions). The new version is deployed to the secondary (green) environment first, then Traffic Manager priority routing switches all traffic from the primary (blue) to the secondary (green). The primary is then updated while idle. This is the classic blue-green pattern applied across regions, not a rolling deployment.

Answer

Canary deployment

Answer

Red/Black deployment

Answer

Rolling deployment across regions