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

Question 1

Your team uses Azure Pipelines for CI/CD. You need to enforce that all pipeline runs use approved agents from a specific agent pool with the latest security patches. The agents are self-hosted on Azure VMs. What should you implement?

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

Accepted Answer

Add a demand on the agent for a custom capability that only approved agents have. By adding a demand for a custom capability (e.g., 'SecurityPatchLevel = latest') on the pipeline, only agents that possess that capability can run the pipeline. This allows you to enforce that only approved, patched agents are used. Option C is incorrect because 'setting an agent pool to use a specific agent queue with an isolation scope' is not a recognized Azure Pipelines feature; agent pools use demands, not isolation scopes, to filter agents. Options A and B are also incorrect because configuring pool permissions or creating a deployment pool does not enforce that only agents with specific patches are used; they only control access or assignment but not the selection logic based on capabilities.

Answer

Configure pipeline permissions for the agent pool

Answer

Create a deployment pool and assign the agents to it

Answer

Set the agent pool to use a specific agent queue with an isolation scope

Question 2

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub Actions are not exposed in logs. A developer accidentally logs a secret using 'echo ${{ secrets.API_KEY }}' in a workflow step. What is the default behavior?

Accepted Answer

The secret value is masked with asterisks in the log output. GitHub Actions automatically masks secrets in workflow logs. When a secret is used in a step (e.g., via `${{ secrets.API_KEY }}`), GitHub replaces any occurrence of the secret's value in the log output with `***`. This redaction happens at runtime, so even if a developer accidentally echoes the secret, the log will show asterisks instead of the actual value.

Answer

The secret value is replaced with an empty string in the log

Answer

The workflow run fails with an error about secret exposure

Answer

The secret is redacted before the step runs, and the step fails if it tries to use the secret

Question 3

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?

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 4

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 5

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 6

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 7

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 8

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. To set up a self-hosted agent pool in Azure Pipelines, you must install the agent software on the target machine (option A), which provides the listener that polls Azure DevOps for jobs and runs them locally. You also need to configure the agent with the agent pool name and the URL of the Azure DevOps organization (option C), since the agent registers itself into a specific pool under a specific organization endpoint. Authentication requires a personal access token (option E) with the appropriate scope (typically Agent Pools read/manage), which the agent uses during configuration to register with the service. Option B is incorrect because deployment groups are a separate feature for classic release pipelines targeting machines, not the mechanism for creating an agent pool. Option D is incorrect because the Azure VM extension for Azure Pipelines Agent is an optional convenience for provisioning agents on Azure VMs, not a required component of a self-hosted agent pool.

Answer

A deployment group target

Answer

Azure VM extension for Azure Pipelines Agent

Question 9

Which TWO triggers can start a release in Azure Pipelines?

Accepted Answer

Schedule. Option B (Schedule) is correct because Azure Pipelines release pipelines support scheduled triggers, configured via the pipeline's Triggers tab or YAML scheduled triggers, which start a release at defined times (e.g., cron-based schedules). Option C (Build completion) is correct because a release can be triggered when a specified build (artifact source) completes successfully, using the build completion trigger that monitors a chosen build pipeline. Option A (Continuous integration) is not a release trigger in this context; CI triggers start builds, not releases (the release equivalent is the continuous deployment trigger on an artifact). Option D (Work item state change) is not a supported release trigger in Azure Pipelines. Option E (Pull request) is a build/CI trigger (PR triggers on branches), not a release trigger.

Answer

Continuous integration

Answer

Work item state change

Answer

Pull request

Question 10

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 11

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 12

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 13

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 14

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 15

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.