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

Question 1

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

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

Accepted Answer

Continuous deployment trigger on the release pipeline. A continuous deployment trigger on the release pipeline automatically starts a new release deployment whenever a new build artifact is available, ensuring the same build artifact is deployed to each environment without rebuilding. This is the correct choice because the requirement is to deploy the same artifact across multiple environments, and the continuous deployment trigger is designed to initiate a release pipeline after a build completes, preserving the artifact for downstream stages.

Answer

Pull request trigger

Answer

Schedule trigger

Answer

Build completion trigger

Question 2

Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?

Accepted Answer

Add a PowerShell task that wraps the NuGet restore in a retry loop. Adding a PowerShell task that wraps the NuGet restore command in a retry loop directly addresses transient network failures by reattempting the download. This approach is lightweight, customizable (e.g., using `Start-Sleep` between retries), and does not require changing pipeline architecture or relying on external infrastructure.

Answer

Increase the number of parallel jobs to average out failures

Answer

Use a deployment group to deploy the build to a staging environment

Answer

Configure a build retention policy to automatically retry failed builds

Question 3

You are implementing a multi-stage YAML pipeline in Azure Pipelines for a microservices application. You need to ensure that the 'deploy' stage only runs if the 'build' stage succeeds and that the 'test' stage runs in parallel with 'build' for different services. How should you structure the pipeline?

Accepted Answer

Define stages 'build', 'test', 'deploy' with 'dependsOn: []' on 'test' and 'dependsOn: build' on 'deploy'. Setting `dependsOn: []` on the 'test' stage removes any implicit dependency, allowing it to run in parallel with the 'build' stage (since stages without explicit dependencies default to running sequentially after the previous stage). The 'deploy' stage with `dependsOn: build` ensures it only runs after the 'build' stage succeeds, as Azure Pipelines stages by default only run if all dependencies succeed. This structure meets the requirement: 'test' runs in parallel with 'build' for different services, and 'deploy' depends on 'build' success.

Answer

Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy' but use 'condition: always()' on test

Answer

Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy'

Answer

Define stages 'build', 'test', 'deploy' with no dependsOn; by default they run sequentially

Question 4

Your Azure Pipelines build uses a self-hosted agent that runs on a Windows VM. The build fails with the error 'Access to the path 'C:\agent\_work\1\s\bin' is denied.' What is the most likely cause?

Accepted Answer

The agent service account does not have write permissions on the working directory. The error 'Access to the path ... is denied' indicates a permissions issue. Self-hosted agents run under a specific Windows service account (e.g., Network Service, Local System, or a custom domain account). If that account lacks write permissions on the working directory (e.g., `C:\agent\_work\1\s\bin`), the agent cannot create or modify files during the build, causing the failure. This is the most common cause when using self-hosted agents on Windows VMs.

Answer

The agent is not configured to use the correct agent pool

Answer

The build is trying to overwrite a file that is locked by another process

Answer

The source code checkout failed due to incorrect credentials

Question 5

You are setting up a GitHub Actions workflow to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate to the AKS cluster using a service principal. What is the recommended way to store and use the service principal credentials?

Accepted Answer

Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action. GitHub Actions secrets are the recommended secure mechanism for storing sensitive credentials like a service principal's client ID and secret. The 'azure/login' action can directly reference these secrets (e.g., `${{ secrets.AZURE_CREDENTIALS }}`) to authenticate to Azure, and then the 'azure/aks-set-context' action uses that authenticated session to connect to the AKS cluster. This approach avoids hardcoding credentials in the workflow file and leverages GitHub's encrypted storage.

Answer

Use managed identity for GitHub Actions and assign it to the AKS cluster

Answer

Store the service principal credentials in a Kubernetes secret in the AKS cluster

Answer

Store the service principal credentials as environment variables in the workflow file

Question 6

Your team uses Azure Pipelines to build a .NET Core application. You notice that the build takes too long because it restores NuGet packages every time. What is the best way to improve build performance?

Accepted Answer

Enable the 'Cache' task to cache the NuGet packages folder. The best way to improve build performance is to cache the NuGet packages folder using the 'Cache' task in Azure Pipelines. This avoids re-downloading packages on each run. Option A (self-hosted agent) is not guaranteed to cache the packages folder across builds unless caching is explicitly configured. Option B (faster network) may help but doesn't eliminate the restore time. Option C (larger SKU) improves CPU/memory but does not cache packages. Therefore, option D is correct.

Answer

Configure the build to use a self-hosted agent with previously restored packages

Answer

Use a private agent with a faster network connection

Answer

Use a Microsoft-hosted agent with a larger SKU

Question 7

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Accepted Answer

The agent software installed on the target machine. The self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Answer

A deployment group target

Answer

Azure VM extension for Azure Pipelines Agent

Question 8

Which TWO triggers can start a release in Azure Pipelines?

Accepted Answer

Schedule. In Azure Pipelines, a release can be triggered by a schedule, which allows you to define a cron-based trigger to deploy at specific times (e.g., nightly builds). The 'Build completion' trigger starts a release when a specific build pipeline completes, enabling chained deployments. Both are native release triggers in classic release pipelines.

Answer

Continuous integration

Answer

Work item state change

Answer

Pull request

Question 9

You have a multi-stage YAML pipeline that deploys to multiple environments. You want to enforce that a manual approval is required before deploying to the production environment, but not for other environments. How should you configure the pipeline?

Accepted Answer

Create an environment named 'Production', add an approval check, and reference the environment in the deployment job.. Azure Pipelines allows you to add an approval check on a specific environment. By creating an environment named 'Production' and attaching an approval check to it, any deployment job that references that environment will require manual approval before proceeding. This ensures that only the production deployment is gated, while other environments deploy automatically.

Answer

Set a pipeline-level approval check that applies to all stages.

Answer

Add an approval gate on the 'Production' stage in the pipeline settings.

Answer

Configure branch policy on the main branch to require approval for all changes.

Question 10

Your build pipeline fails intermittently with the error: 'The job running on agent 'Azure Pipelines' exceeded the maximum execution time of 60 minutes.' How can you resolve this issue?

Accepted Answer

Increase the 'timeoutInMinutes' property in the pipeline YAML for the job.. The error indicates the job exceeded the default 60-minute timeout for Azure Pipelines hosted agents. Increasing the 'timeoutInMinutes' property in the pipeline YAML for the job explicitly extends the maximum execution time, directly resolving the timeout issue. This property can be set at the job level to allow longer-running tasks without changing the pipeline structure.

Answer

Split the pipeline into multiple stages to reduce job duration.

Answer

Enable parallel jobs to run the pipeline faster.

Answer

Use a self-hosted agent with more CPU cores.

Question 11

You are designing a release pipeline for a critical application. The pipeline must automatically roll back to the previous version if the deployment to staging fails health checks. Which deployment strategy should you implement?

Accepted Answer

Rolling update with health checks and automatic rollback.. A rolling update with health checks and automatic rollback is the only strategy that fully automates the deployment, validates health after each batch of pods is updated, and automatically reverts to the previous version if health checks fail. This meets the requirement for an automated rollback on staging health check failure without manual intervention.

Answer

Canary deployment with manual promotion.

Answer

Blue-green deployment with manual swap.

Answer

Recreate deployment by redeploying the same version.

Question 12

Your CI pipeline includes a step that runs unit tests. You want to fail the pipeline if code coverage drops below 80%, but continue if tests pass with lower coverage. How should you configure the test step?

Accepted Answer

Use the 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting.. The 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting is correct because it allows you to define a minimum coverage percentage (e.g., 80%) and fail the pipeline if that threshold is not met, while still allowing the pipeline to continue if tests pass but coverage is lower. This task evaluates the coverage report after tests run and enforces the threshold as a build failure condition, not a test failure.

Answer

Configure a quality gate in the release pipeline to check coverage.

Answer

Add a script task that reads the coverage report and prints a warning.

Answer

Use the VSTest task with the 'codeCoverageEnabled' option set to true.

Question 13

Your team uses GitHub Actions for CI/CD. You need to ensure that only specific branches can trigger the deployment workflow to production. Which workflow trigger should you configure?

Accepted Answer

on: push: branches: [main]. The `on: push: branches: [main]` trigger ensures that the deployment workflow runs only when a push event occurs on the `main` branch. This directly enforces the requirement that only specific branches (here, `main`) can trigger production deployments, preventing accidental or unauthorized deployments from other branches.

Answer

on: pull_request: branches: [main]

Answer

on: workflow_dispatch: inputs: branch: description: 'Select branch'

Answer

on: schedule: cron: '0 0 * * *'

Question 14

You have a YAML pipeline that builds a .NET application. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

Accepted Answer

Cache task with a key based on the packages.lock.json hash.. The Cache task in Azure Pipelines allows you to cache NuGet packages by specifying a key derived from the hash of `packages.lock.json`. This ensures that the cache is invalidated only when the lock file changes, which accurately reflects changes in package dependencies. The cached `~/.nuget/packages` folder is then restored on subsequent runs, significantly reducing restore time.

Answer

CopyFiles task to copy packages to a staging directory.

Answer

NuGet restore task with 'cacheRestore' option.

Answer

PublishBuildArtifacts task to upload packages.

Question 15

Your release pipeline deploys to Azure App Service using slots. You need to ensure that after swapping, the warmup request is sent to the production slot before traffic is fully routed. What should you configure?

Accepted Answer

Enable auto swap for the deployment slot and configure a custom warmup path.. Enabling auto swap with a custom warmup path sends a warmup request to the target slot before the swap completes, ensuring the production slot is warmed up. Option B is incorrect because a health check is used for monitoring instance health, not for warmup before swap. Option C is incorrect because a manual swap does not include automatic warmup; you would need to implement custom logic. Option D is incorrect because slot-specific app settings are sticky and not swapped; they do not enable warmup.

Answer

Add a health check to the App Service.

Answer

Perform a manual swap and then send a warmup request via a script.

Answer

Configure slot-specific app settings to enable warmup.