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

Question 1

Match each Azure Monitor feature to its use case.

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.. Option C is correct because 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.. Option A is correct because the rolling deployment with traffic shifting and automatic rollback is best achieved using Azure App Service deployment slots with auto-swap and monitoring. Option B is wrong because blue-green with manual swap does not provide gradual traffic shift. Option C is wrong because canary with manual approval does not automate rollback. Option D is wrong because A/B testing is not a native deployment strategy in Azure Pipelines.

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'). Option C is correct because 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.. Option A is correct because, 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 does not include the 'resetOnPush' property (or its equivalent in the REST API), which is required to invalidate existing approvals. Without that setting, approvals remain valid even after new commits are pushed.

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.. Option C is correct because setting 'clean: true' in the checkout step ensures the working directory is cleaned before each build. Option A is wrong because the 'workspace' cleanup option in agent configuration is not a pipeline setting. Option B is wrong because 'Delete Files' task is manual and not automatic. Option D is wrong because 'Cleanup' task is not a built-in task.

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:. Option A is correct because 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 the `main` branch, so configuring `pr: main` ensures the pipeline runs on PR creation 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 a pipeline with a trigger condition set to 'main' for the Build stage only. The Test stage has no trigger condition defined, meaning it will only run if explicitly triggered by a preceding stage or a separate trigger. When a developer pushes a commit to the main branch, only the Build stage is triggered because it is the only stage with a branch filter matching 'main'. The Test stage does not have a trigger, so it will not run automatically.

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.. Option A is correct because pre-deployment approvals can be set on each stage. Option D is correct because approval gates are configured in the release pipeline editor. Option B is wrong because post-deployment approvals are after deployment. Option C is wrong because branch policies are for PRs, not releases. Option E is wrong because YAML pipelines use 'approvals' keyword, not a separate task.

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.. Option B is correct because enabling NuGet package caching in Azure Pipelines stores downloaded packages on the agent, avoiding repeated downloads from the NuGet feed on subsequent builds. This significantly reduces build time, especially when the same packages are used across multiple pipeline runs, as network latency and package restore operations are minimized.

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. Options A and B are correct. Option A uses exact branch name. Option B uses wildcard for release branches. Option C is wrong because 'include' should be a list. Option D is wrong because 'branches' is nested under 'trigger'. Option E is wrong because 'exclude' is not needed.

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.. Option B is correct because you can set the 'environment' parameter as a pipeline variable and pass it to the Bicep deployment task. Option A is wrong because ARM template parameters are not set in the YAML file directly. Option C is wrong because the Bicep file does not have a default value. Option D is wrong because you cannot modify the Bicep file dynamically.

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.. Option D is correct because 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.