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

Question 1

You are configuring a continuous integration (CI) trigger for your YAML pipeline. The trigger should run the pipeline when changes are pushed to the 'main' branch or any release branch matching 'release/*'. Which TWO trigger configurations are valid? (Choose two.)

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

Accepted Answer

trigger:
  branches:
    include:
      - main. The `trigger` section with `branches: include: - main` explicitly specifies that the pipeline should run on pushes to the `main` branch. Option E is correct because `trigger: branches: include: - release/*` uses the wildcard pattern `release/*` to include all branches matching that pattern, such as `release/v1.0` or `release/2.0`. Both configurations are valid YAML trigger definitions for Azure Pipelines.

Answer

trigger:
  branches:
    exclude:
      - main

Answer

branches:
  include:
    - main

Answer

trigger:
  branches:
    main

Question 2

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

Accepted Answer

Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.. The AzureResourceManagerTemplateDeployment task's `overrideParameters` property allows you to dynamically pass parameter values at deployment time. By setting a pipeline variable named `environment` (which can be scoped per stage) and referencing it as `$(environment)` in `overrideParameters`, you can inject the correct value ('dev', 'qa', or 'prod') based on the release stage without modifying the Bicep file or its defaults.

Answer

Define the parameter in the 'parameters:' section of the YAML pipeline.

Answer

Use a task to replace the string '${environment}' in the Bicep file before deployment.

Answer

Modify the Bicep file to include a default value for environment.

Question 3

Your release pipeline uses a multi-stage YAML with environments. You need to ensure that only one deployment runs at a time to a production environment to avoid conflicts. Which feature should you use?

Accepted Answer

Configure an exclusive lock policy on the production environment.. An exclusive lock policy on an environment ensures that only one deployment can run at a time to that environment. When a deployment starts, it acquires a lock on the environment; subsequent deployments are queued until the lock is released. This prevents conflicts from concurrent deployments to the same production environment.

Answer

Use a condition to check if a previous deployment is in progress.

Answer

Add a pre-deployment approval gate.

Answer

Set the 'parallel' deployment option to 1.

Question 4

You need to integrate Azure Pipelines with GitHub to trigger a build when a release is published in GitHub. Which trigger type should you use in the pipeline?

Accepted Answer

resources:
  repositories:
    - repository: self
      type: github
      trigger:
        release: true. Azure Pipelines supports a GitHub release trigger through the `resources` definition, where you specify a `trigger` with `release: true` under the repository configuration. This tells the pipeline to automatically start a build whenever a new release is published in the linked GitHub repository, which directly matches the requirement.

Answer

pr:

Answer

trigger:

Answer

schedules:

Question 5

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

Accepted Answer

Use a Docker Compose task in the pipeline to start the database container before running integration tests.. Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Answer

Configure the pipeline to use a self-hosted agent that has the database already installed and running.

Answer

Install the database as a service in the pipeline using the Service Fabric task.

Answer

Use a PowerShell script in the pipeline to install and start the database on the build agent.

Question 6

Your organization uses GitHub Actions for CI/CD. You need to ensure that deployment to production only occurs after a successful deployment to a staging environment and requires approval from a senior developer. The deployment workflow is defined in a single YAML file. What is the most efficient way to achieve this?

Accepted Answer

Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.. GitHub Actions supports deployment environments with required reviewers. By defining separate 'staging' and 'production' environments, you can use a conditional step to deploy to staging first, and then require manual approval from a senior developer before the production deployment proceeds. This approach is built into GitHub Actions and does not require external webhooks or manual workflow triggers, making it the most efficient and secure method.

Answer

Add a step that pauses the pipeline until a manual approval is received via a custom webhook.

Answer

Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.

Answer

Use a build matrix to run staging and production deployments in parallel.

Question 7

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

Accepted Answer

Use template parameters with a 'steps' object that can be injected to override the step.. Azure DevOps YAML templates support parameterized steps objects. By defining a template parameter of type 'steps' with a default value, the calling pipeline can pass a custom steps object as an argument to that parameter, effectively overriding the default steps without modifying the template. No 'replace' keyword is used; the override is achieved by directly injecting the steps object via the parameter.

Answer

Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

Answer

Create a copy of the template and modify the step directly.

Answer

Use a conditional 'if' statement in the template to skip steps based on a parameter.

Question 8

Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?

Accepted Answer

Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.. Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.

Answer

Manually update the production slot settings to match staging before each swap.

Answer

Perform a swap with preview and then complete the swap after verifying the staging slot.

Answer

Write a custom PowerShell script to copy configuration from staging to production before swapping.

Question 9

Your organization uses Azure Pipelines to build a large monolithic application. The build takes over 60 minutes. Management wants to reduce the build time to under 30 minutes. The application has multiple independent modules that could be built in parallel. What is the most effective strategy to reduce build time?

Accepted Answer

Refactor the build pipeline to use multiple parallel jobs, each building a separate module.. The build time is dominated by sequential compilation of independent modules. By refactoring the pipeline to use multiple parallel jobs, each building a separate module, Azure Pipelines can leverage its built-in parallelism to reduce wall-clock time significantly. This directly addresses the root cause—lack of concurrency—without sacrificing code quality or infrastructure cost.

Answer

Reduce the number of unit tests run during the build.

Answer

Upgrade the build agent to a larger VM size with more CPU and memory.

Answer

Move the build to a self-hosted agent in the same network as the source code repository.

Question 10

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

Accepted Answer

Reference the variable as $(VariableName) in the pipeline tasks.. When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required. Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Answer

Reference the variable as $(VariableName) but only in a script task using 'env' mapping.

Answer

Use the 'task.getVariable' method in a PowerShell script.

Answer

Use the Azure Key Vault task to retrieve the secret and then reference the output variable.

Question 11

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

Accepted Answer

pull_request: branches: [main] types: [opened]. The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure. If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

Answer

pull_request_target: branches: [main]

Answer

workflow_dispatch

Answer

push: branches: [main]

Question 12

Your Azure DevOps pipeline deploys a microservice to a Kubernetes cluster using Helm. The Helm chart requires a values file that contains environment-specific configurations. You want to store the values file securely and use it during deployment. What is the recommended approach?

Accepted Answer

Store the values file as a secure file in Azure Pipelines library.. Azure Pipelines provides a 'Secure files' library feature specifically designed to store files (like Helm values files, certificates, or keystores) that need to be downloaded securely during a pipeline run. The DownloadSecureFile task retrieves the file at runtime, and it can then be passed to the HelmDeploy task, keeping environment-specific configuration out of source control.

Answer

Store the values in a variable group and map them to Helm values.

Answer

Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.

Answer

Store the values file in a separate Git repository and clone it during the pipeline.

Question 13

Your team uses Azure Repos for source control. You need to enforce that all builds must pass unit tests before code can be merged into the main branch. Which branch policy should you configure?

Accepted Answer

Add a build validation policy that triggers the CI pipeline and requires it to succeed.. Azure Repos branch policies allow you to add a build validation policy that triggers a CI pipeline (e.g., a YAML or classic build pipeline) and requires it to succeed before a pull request can be completed. This ensures that all code merged into the main branch has passed unit tests, enforcing quality gates directly in the PR workflow.

Answer

Require a linked work item.

Answer

Require a minimum number of reviewers.

Answer

Require comment resolution.

Question 14

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Accepted Answer

Continuous deployment trigger after a build completes.. Azure DevOps release pipelines can be triggered in multiple ways. A continuous deployment trigger (A) automatically creates a release whenever a build artifact is successfully produced. A scheduled release trigger (E) creates a release at a defined time (e.g., nightly). Manual release creation via the 'Create release' button (C) is a manual action, not an automated configured trigger. Pull request triggers (D) are valid only for build pipelines, not release pipelines. 'Source version trigger' (B) is not a standard release trigger type. Therefore, the two valid trigger types are A and E.

Answer

Source version trigger.

Answer

Manual trigger via the 'Create release' button.

Answer

Pull request trigger.

Question 15

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Accepted Answer

Rolling deployment.. Rolling deployment is a valid strategy in Azure DevOps release pipelines, where instances of the previous version are gradually replaced with the new version, typically by updating a subset of instances (e.g., in a virtual machine scale set or Kubernetes cluster) while the rest continue serving traffic. Blue-green deployment is also valid, maintaining two identical environments and switching all traffic from the blue (old) to the green (new) environment after validation, often implemented using deployment slots or Kubernetes namespaces. Canary deployment is a third valid strategy, where a small percentage of traffic is routed to the new version initially, gradually increasing it while monitoring health, commonly implemented with deployment slots or progressive exposure in Kubernetes. Red-black, while sometimes used as a synonym for blue-green, is not a distinct deployment strategy recognized in Azure DevOps documentation, and linear deployment is not a recognized industry-standard pattern.

Answer

Red-black deployment.

Answer

Linear deployment.