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

Question 1

You need to create a pipeline that triggers only when changes are made to files in the 'src/api' folder. Which trigger configuration should you use?

Accepted Answer

trigger: paths: include: - 'src/api/*'. The `trigger: paths: include: - 'src/api/*'` configuration tells Azure Pipelines to only trigger the pipeline when changes are detected in files matching that path pattern. This is the standard way to scope pipeline triggers to specific folders or file patterns in YAML pipelines, ensuring that unrelated changes elsewhere in the repository do not start the pipeline.

Answer

trigger: branches: include: - 'main'

Answer

trigger: paths: exclude: - 'src/api/*'

Answer

trigger: tags: include: - 'v*'

Question 2

Which TWO are valid strategies for managing secrets in Azure Pipelines?

Accepted Answer

Use a variable group linked to Azure Key Vault and mark variables as secret.. Linking a variable group to Azure Key Vault allows secrets to be securely referenced without exposing them in plaintext; when variables are marked as secret, Azure Pipelines masks their values in logs. Alternatively, the Azure Key Vault task can fetch secrets at runtime and map them to pipeline variables for use in tasks, which also keeps secrets out of YAML and logs. Both approaches are valid strategies for secret management.

Answer

Store secrets in plain text in a variable group.

Answer

Store secrets in a Git repository and read them during build.

Answer

Embed secrets directly in the pipeline YAML file.

Question 3

Which THREE are required to set up a self-hosted agent for Azure Pipelines?

Accepted Answer

Network connectivity to Azure DevOps services.. B is correct because the self-hosted agent must communicate with Azure Pipelines to receive job assignments and report status. This requires outbound HTTPS connectivity (port 443) to Azure DevOps services (e.g., dev.azure.com). Without network connectivity, the agent cannot register, poll for jobs, or send logs, making it non-functional.

Answer

A virtual machine running in Azure.

Answer

Docker installed on the agent machine.

Question 4

Which TWO conditions must be met to use multi-stage YAML pipelines with approvals?

Accepted Answer

An environment must be created and approval checks configured on it.. Multi-stage YAML pipelines in Azure DevOps require that an environment be created and approval checks configured on it to enable manual approvals. Additionally, the deployment job within the pipeline must reference a specific environment, as the approval check is associated with that environment resource. Without these two conditions, the pipeline cannot enforce approval gates before deployment.

Answer

The pipeline must be triggered by a pull request.

Answer

The pipeline must have at least one stage defined in a separate release pipeline.

Answer

The pipeline must be created using the classic release editor.

Question 5

You have the YAML pipeline exhibit above. The pipeline fails with: 'The pipeline is not valid. Could not find the template file shared-templates/build-steps.yml.' What is the most likely cause?

Accepted Answer

The template path is incorrect because it should be relative to the repository root; the repository name is 'myorg/shared-templates', so the path should be 'build-steps.yml'.. When referencing a template from another repository in Azure Pipelines, the `repository` property specifies the repository name (e.g., `myorg/shared-templates`), and the template path must be relative to the root of that repository. The error indicates the pipeline cannot find the file, meaning the path `shared-templates/build-steps.yml` is incorrect; it should be just `build-steps.yml` since the repository name is already declared in the `repository` field. The path should not include the repository name again.

Answer

The checkout step for 'shared-templates' must be before the template reference, which it is.

Answer

The template file is missing from the shared-templates repository.

Answer

The ref 'refs/heads/main' does not exist in the shared-templates repository.

Question 6

The pipeline above fails with: 'The deployment job 'DeployToProd' references environment 'Production' which does not exist.' What should you do to resolve this error?

Accepted Answer

Create an environment named 'Production' in Azure DevOps project settings.. The error indicates that the Azure DevOps pipeline references an environment named 'Production' that does not exist in the project. Environments must be explicitly created in Azure DevOps project settings before they can be used in deployment jobs. Option D resolves this by creating the required environment, allowing the deployment job to target it correctly.

Answer

Remove the 'environment' property from the deployment job.

Answer

Change the deployment strategy from 'runOnce' to 'rolling'.

Answer

Add a script step before the deployment job to create the environment.

Question 7

Your pipeline has the following YAML trigger configuration:

trigger:
  paths:
    include:
    - src/app/**

A developer pushes changes to a file in 'src/app/config.json' on a branch named 'release/v1'. Which statement is true about the build trigger?

Accepted Answer

The build will be triggered.. The provided YAML trigger includes a path filter that matches 'src/app/**'. The push to 'src/app/config.json' matches that include pattern, so the build triggers. No branch filter is specified, so the trigger applies to all branches including 'release/v1'. Therefore, option B is correct.

Answer

The build will be triggered but only if no other builds are running.

Answer

The build will not be triggered because the path filter is too restrictive.

Answer

The build will not be triggered because the branch is not 'main'.

Question 8

You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?

Accepted Answer

Blue-green deployment. Blue-green deployment is a release strategy that uses two identical environments (blue and green). The new version is deployed to the staging slot (green), smoke tests are run, and traffic is switched to the staging slot by swapping it with the production slot (blue). Slot swap is the Azure App Service mechanism used to implement blue-green deployment, but the strategy itself is blue-green.

Answer

Slot swap

Answer

Canary deployment

Answer

Rolling update

Question 9

Your release pipeline uses a 'Run Azure CLI' task to execute a script. The script authenticates using a service principal. However, the deployment fails with 'insufficient privileges to complete the operation'. What is the most likely cause?

Accepted Answer

The service principal lacks the necessary RBAC role on the target resource.. The error 'insufficient privileges to complete the operation' indicates that the service principal successfully authenticated but lacks the required Azure RBAC role on the target resource. Even with a valid secret and a logged-in Azure CLI session, the service principal must have an assigned role (e.g., Contributor, Owner, or a custom role) that grants the specific permissions needed for the deployment operation.

Answer

The Azure CLI task is not logged in.

Answer

The service principal secret has expired.

Answer

The service principal does not have a secret.

Question 10

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

Accepted Answer

Provision self-hosted agents.. Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Answer

Increase the number of parallel jobs in the organization.

Answer

Use more pipeline triggers.

Answer

Reduce the number of parallel jobs.

Question 11

You run the above Azure CLI command to deploy a Bicep template. The deployment fails with 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists'. What is the most likely cause?

Accepted Answer

The storage account 'mystgaccount' already exists in the resource group.. The error message 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists' indicates that the storage account 'mystgaccount' already exists in the target resource group, which prevents the deployment from creating it again. This directly supports option A as the correct answer. Option B is incorrect because 'az deployment group validate' only validates the template and does not perform a deployment; the error occurs during the actual deployment, not validation. Option C is incorrect because Bicep defaults to incremental mode, not complete mode, and even if complete mode were used, the error would be about a resource existing in the template but not in the resource group, which is not the case here. Option D is incorrect because if the resource group did not exist, the error would be something like 'ResourceGroupNotFound', not an already-exists error.

Answer

The command should use 'az deployment group validate' instead.

Answer

The Bicep file uses 'complete' mode.

Answer

The resource group 'MyRG' does not exist.

Question 12

Your release pipeline deploys to multiple environments (dev, test, prod). You need to ensure that only authorized users can approve production deployments. Which TWO actions should you take?

Accepted Answer

Add a 'Approval' check on the production environment.. The correct actions to ensure only authorized users can approve production deployments are to add an 'Approval' check on the production environment (option D) and to add a pre-deployment approval to the production stage (option E). Both methods require explicit user approval before deployment proceeds. Option A is incorrect because a manual intervention task pauses the pipeline for interactive validation but does not enforce user authorization checks; it is typically used for prompts, not approval gates. Option B is incorrect because environment permissions control who can create releases or manage environments, not who can approve deployments to production—they manage access at a higher level. Option C is incorrect because deployment gates are automated health checks (e.g., monitoring metrics) that can block deployment based on conditions, but they do not handle user approval; approval is a separate check type.

Answer

Use a manual intervention task in the pipeline.

Answer

Set environment permissions to allow only specific users to create releases.

Answer

Configure deployment gates to check for user approval.

Question 13

Your build pipeline uses a YAML template that references variables from a variable group. The variable group is linked to a library. You need to ensure that sensitive variables are not exposed in logs. Which THREE actions should you take?

Accepted Answer

Store the secrets in Azure Key Vault and reference them in the variable group.. To keep sensitive variables out of pipeline logs, you should store secrets in Azure Key Vault and reference them in a variable group (B), mark variables as secret in the variable group (D), and configure permissions on the library to restrict which pipelines can use the variable group (E). Key Vault integration and secret marking ensure that values are masked automatically, while restricting access limits the risk of unauthorized pipelines that could expose secrets.

Answer

Set the variable group to 'Allow access to all pipelines'.

Answer

Use 'Write-Host' to output the variable values for debugging.

Question 14

Your team wants to implement automated testing in the build pipeline. You need to ensure that tests run and results are published. Which TWO tasks should you include?

Accepted Answer

Visual Studio Test task. The correct tasks are Visual Studio Test task (option C) which runs the tests, and Publish Test Results task (option D) which publishes the test results to Azure Pipelines. Option A (Publish Build Artifacts) publishes build outputs but not test results. Option B (Copy Files) copies files between locations and does not run tests. Option E (Azure PowerShell) runs PowerShell scripts and is not for testing.

Answer

Publish Build Artifacts task

Answer

Copy Files task

Answer

Azure PowerShell task

Question 15

You have the above YAML task in a pipeline. The task runs but no secrets are available in subsequent tasks. What is the most likely cause?

Accepted Answer

The secrets are not automatically mapped to environment variables; you must reference them using $(secretName).. By default, secrets downloaded from Azure Key Vault in a pipeline task are not automatically mapped to environment variables for subsequent tasks. You must explicitly reference them using the macro syntax `$(secretName)` or map them as environment variables with the `env` keyword. Without this explicit mapping, the secret values remain inaccessible to later tasks, even though the download task succeeds.

Answer

The SecretsFilter is set to '*' which is invalid.

Answer

The service principal does not have 'Get' permission on the key vault.

Answer

The key vault name 'mykv' does not exist.