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

Question 1

Match each Azure Monitor feature to its use case.

Accepted Answer

Log Analytics: Collects and queries log data from Azure resources.. The correct matches are Log Analytics for log collection and querying, Application Insights for live web application monitoring, and Azure Monitor Metrics for numeric performance data. The distractors swap the definitions of Log Analytics and Application Insights.

Answer

Log Analytics: Monitors live web applications.

Answer

Application Insights: Collects and queries log data.

Question 2

You are designing a build pipeline for a Java application that uses Maven. The build must run unit tests and integration tests separately. You want to publish test results to Azure Pipelines. Which task configuration should you use?

Accepted Answer

Use two Maven tasks with goals 'test' and 'verify', and configure the Publish Test Results task to publish results from both runs.. It uses two separate Maven tasks with the 'test' and 'verify' goals, which allows unit tests and integration tests to run independently. The Publish Test Results task is then configured to consume the test result files (typically JUnit XML reports) from both runs, enabling Azure Pipelines to display a unified test summary. This approach aligns with the requirement to run unit and integration tests separately while still publishing all results.

Answer

Use two Gradle tasks, one for unit tests and one for integration tests.

Answer

Use a single Maven task with goals 'test verify', and configure the task to publish test results.

Answer

Use two Visual Studio Test tasks, one for unit tests and one for integration tests.

Question 3

Your release pipeline deploys to Azure App Service using deployment slots. You need to ensure that traffic is gradually shifted to the new slot over 30 minutes, and if performance issues occur, it should automatically roll back. Which deployment strategy should you implement?

Accepted Answer

Use the 'Deploy to Azure App Service' task with the 'Deploy to Slot' option and configure auto-swap with monitoring.. The 'Deploy to Azure App Service' task with 'Deploy to Slot' and auto-swap with monitoring enables a gradual traffic shift over a specified duration (e.g., 30 minutes) using Azure's swap-with-preview and auto-rollback capabilities. When performance issues are detected via Application Insights or health checks, the swap is automatically aborted, rolling back to the previous slot. This meets the requirement for gradual shifting and automatic rollback without manual intervention.

Answer

Use two separate deployment slots (blue/green) and manually swap after validation.

Answer

Use a canary deployment with multiple slots and manual approval gate.

Answer

Use an A/B testing deployment by deploying to two different App Services and routing traffic via Traffic Manager.

Question 4

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Answer

condition: variables['Build.SourceBranch'] == 'main'

Answer

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Answer

condition: eq(variables['Build.SourceBranch'], 'main')

Question 5

You are configuring a branch policy for the main branch using the Azure DevOps REST API. The JSON above is the policy configuration. A developer pushes a new commit to an existing pull request. What happens to the existing approvals?

Accepted Answer

The existing approvals remain valid.. By default, Azure DevOps branch policies do not automatically reset approvals when a new commit is pushed to a pull request. The policy configuration shown includes the 'resetOnPush' property set to false (or it is not enabled), which means existing approvals remain valid even after new commits are pushed. Only if 'resetOnPush' is explicitly set to true would approvals be invalidated.

Answer

The policy blocks the push until re-reviewed.

Answer

The pull request is automatically rejected.

Answer

All existing approvals are reset.

Question 6

Your build pipeline uses a self-hosted agent. The agent is running low on disk space. You need to clean up the agent's working directory after each build. Which option should you configure in the pipeline?

Accepted Answer

Use the 'clean' parameter in the checkout step of the YAML pipeline.. The `clean` parameter in the YAML checkout step is the native, built-in way to instruct the agent to delete the sources directory before or after the build. Setting `clean: true` or `clean: all` ensures the working directory is purged, directly addressing the low disk space issue without requiring additional tasks or marketplace extensions.

Answer

Set the 'Clean' option to 'Sources' in the pipeline settings.

Answer

Add a 'Delete Files' task at the end of the pipeline to delete the sources directory.

Answer

Add a 'Cleanup' task from the marketplace to clean the agent.

Question 7

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that allows rolling back to the previous version quickly if a deployment fails. The pipeline should also support canary deployments. Which tool or feature should you use?

Accepted Answer

Helm package manager with Helm deploy task.. Helm is the correct choice because it provides native support for rollbacks via `helm rollback`, which can revert a release to a previous revision quickly. Additionally, Helm supports canary deployments through its upgrade strategy (e.g., `--set canary.enabled=true`) and integration with tools like Flagger or Argo Rollouts, enabling fine-grained traffic shifting. The Helm deploy task in Azure Pipelines wraps these capabilities, making it the most suitable tool for both rollback and canary requirements.

Answer

Terraform with Kubernetes provider.

Answer

Azure Pipelines Kubernetes manifest task with kubectl apply.

Answer

Kubectl task with rolling update strategy.

Question 8

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to trigger a pipeline automatically when a pull request is created against the main branch. Which trigger type should you configure in the YAML pipeline?

Accepted Answer

pr:. The `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for all branches; however, to ensure the pipeline only runs for PRs targeting `main`, you configure `pr: main`. This triggers the pipeline on PR creation/update without needing a separate branch policy.

Answer

trigger:

Answer

schedules:

Answer

resources:

Question 9

You have a build pipeline that produces several artifacts. You need to publish these artifacts to Azure Artifacts feed, but only if the build succeeds. Which task should you add to the pipeline?

Accepted Answer

Add a 'Publish Build Artifacts' task and then a 'Universal Publish' task.. The 'Publish Build Artifacts' task makes the build outputs available as pipeline artifacts, and the 'Universal Publish' task is the correct way to publish those artifacts to an Azure Artifacts feed (which supports Universal Packages). This combination ensures artifacts are only published after the build succeeds because both tasks run in the pipeline's job sequence, and by default, subsequent tasks execute only if the previous task succeeded.

Answer

Add an 'npm publish' task to publish packages.

Answer

Add a 'Copy Files' task to copy artifacts to the feed location.

Answer

Add a 'NuGet push' task to push packages to the feed.

Question 10

Refer to the exhibit. A developer pushes a commit to the main branch. Which stages will run?

Accepted Answer

Only the Build stage.. The exhibit shows that the Build stage has a trigger condition that matches the 'main' branch, and the Test stage does not have a trigger condition that is satisfied by the push (e.g., it is set to a different branch condition or to manual). Therefore, when a commit is pushed to main, only the Build stage is triggered automatically; the Test stage does not run.

Answer

Only the Test stage.

Answer

Neither stage.

Answer

Both Build and Test stages.

Question 11

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Accepted Answer

Use the 'Approvals and gates' settings in the release pipeline stage.. The 'Approvals and gates' settings in a release pipeline stage allow you to configure pre-deployment approvals, which require designated users to approve the deployment before it proceeds. This is the standard mechanism in Azure DevOps for implementing manual approval gates. Option E is correct because adding a pre-deployment approval gate specifically to the Staging and Production stages ensures that deployments to these environments are blocked until the required approvals are granted, meeting the requirement for manual approval before Staging and Production.

Answer

Add a post-deployment approval gate to the Dev and QA stages.

Answer

Configure branch policy on the release branch to require approvals.

Answer

Add a 'Manual Validation' task in the YAML pipeline.

Question 12

Your organization uses Azure Pipelines with Microsoft-hosted agents. The pipeline runs a .NET Core application build. You notice that the build takes longer than expected. Which THREE actions can you take to improve build performance? (Choose three.)

Accepted Answer

Enable caching for NuGet packages.. Enabling NuGet package caching reduces build time by avoiding repeated downloads of packages. Using a self-hosted agent with pre-installed dependencies eliminates the need to install and download tools on each run, further reducing overhead. Additionally, structuring the pipeline as a multi-stage build and running tests in parallel across multiple agents can significantly shorten overall pipeline duration by executing independent test suites concurrently. Together, these optimizations improve build performance.

Answer

Add more build steps to the pipeline.

Answer

Increase the number of parallel jobs in the pipeline.

Question 13

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.)

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 14

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 15

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.