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

Question 1

You have a pipeline that uses Azure Repos Git. You need to enforce that all commits to the main branch are associated with a work item. Which branch policy should you enable?

Accepted Answer

Require linked work items. The 'Require linked work items' branch policy in Azure Repos blocks any pull request from completing unless every commit is associated with at least one work item. This directly enforces traceability between code changes and tracked work, which is exactly what the scenario demands. It is configured per branch under Repos > Branches > Branch policies.

Answer

Limit merge types

Answer

Require a minimum number of reviewers

Answer

Check for comment resolution

Question 2

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

Accepted Answer

Use Azure Key Vault task to fetch secrets during deployment. The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Answer

Hardcode credentials in the script and encrypt the script file

Answer

Store credentials as pipeline variables and reference them

Answer

Use environment variables on the target machines

Question 3

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

Accepted Answer

Set 'trigger: branches: include: - release/*'. The YAML trigger configuration 'trigger: branches: include: - release/*' explicitly specifies that the pipeline should run only when changes are pushed to any branch matching the 'release/*' wildcard pattern. This is the standard way to define branch-based triggers in Azure Pipelines YAML, ensuring that only pushes to release branches initiate the build.

Answer

Set 'trigger: none' in YAML

Answer

Set 'trigger: branches: include: - main'

Answer

Set 'trigger: tags: include: - v*'

Question 4

Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?

Accepted Answer

Define a reusable workflow with 'on: workflow_call'. A reusable workflow in GitHub Actions is defined by placing a workflow file in .github/workflows/ and adding the 'on: workflow_call' trigger. This allows the workflow to be called from other workflows in the same repository or organization, enabling centralized build and test logic. Unlike composite actions, reusable workflows can contain multiple jobs and run on their own runners, making them ideal for orchestrating complex CI/CD pipelines like building and testing a Node.js app.

Answer

Define a standard workflow in .github/workflows/build.yml

Answer

Use a composite action to encapsulate the build steps

Answer

Create a custom action and reference it in multiple workflows

Question 5

You are deploying a multi-container application to Azure Kubernetes Service (AKS) using Azure Pipelines. You need to ensure that the deployment rollback automatically if the health checks fail. Which strategy should you implement?

Accepted Answer

Configure a rolling update with readiness and liveness probes. A rolling update with readiness and liveness probes is the correct strategy because Kubernetes automatically monitors pod health via these probes. If a new pod fails its readiness probe, the rolling update pauses; if the liveness probe fails, the pod is restarted. Azure Pipelines can be configured to detect probe failures and trigger a rollback to the previous stable ReplicaSet, ensuring automated recovery without manual intervention.

Answer

Use a blue-green deployment strategy

Answer

Use Helm charts with pre-upgrade hooks

Answer

Implement a canary deployment with manual verification

Question 6

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

Accepted Answer

Use a conditional step that runs only when the build succeeds to tag the image as 'latest'. It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Answer

Use the build ID as the tag and manually update 'latest'

Answer

Use the Git commit hash as the tag and push 'latest' separately

Answer

Always tag the image as 'latest' regardless of build status

Question 7

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Accepted Answer

Grant the least privilege to service connections. Granting the least privilege to service connections (Option A) is a core security principle that limits the permissions of automated processes to only what is strictly necessary, reducing the blast radius of a compromised connection. Using Azure Key Vault to store secrets and fetch them at runtime (Option B) ensures that sensitive values like API keys and passwords are never exposed in pipeline definitions or logs, and are securely retrieved via managed identities or service principals at execution time.

Answer

Use the default hosted agent for all builds

Answer

Store secrets as plain text in pipeline variables

Answer

Allow contributors to bypass the required reviewer policy

Question 8

Which TWO features of Azure Pipelines help you manage build artifacts across stages? (Choose two.)

Accepted Answer

Download Pipeline Artifact task. The Publish Pipeline Artifact task (option E) makes files available to subsequent stages by uploading them to Azure Pipelines, while the Download Pipeline Artifact task (option D) retrieves those artifacts in later stages. Together, they form the primary mechanism for passing build outputs across stages in a pipeline.

Answer

Pipeline variables

Answer

Release gates

Answer

Build tags

Question 9

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

Accepted Answer

The Azure Container Registry name is incorrect. The error 'The resource with name 'myregistry' could not be found' indicates that the pipeline is trying to reference an Azure Container Registry that does not exist or is misspelled. The most likely cause is that the registry name in the pipeline configuration is incorrect, such as a typo or wrong environment variable. This is a resource resolution error, not a permissions or tooling issue.

Answer

The build ID variable is not defined

Answer

The service connection does not have permission to access the registry

Answer

The Azure CLI is not installed on the agent

Question 10

The pipeline fails because the artifact is empty. What is the most likely cause?

Accepted Answer

The build output is not copied to the staging directory. The most common reason for an empty artifact in Azure Pipelines is that the build output files were not copied to the staging directory (typically $(Build.ArtifactStagingDirectory)) before the PublishBuildArtifacts task runs. The PublishBuildArtifacts task publishes whatever is in the staging directory; if no files are copied there, the artifact will be empty. This is a standard pattern where a Copy Files task or similar step must explicitly place the build outputs into the staging directory.

Answer

The projects pattern '**/*.csproj' does not match any files

Answer

The task 'PublishBuildArtifacts@1' is misspelled

Answer

The artifact name 'drop' is invalid

Question 11

Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.

Answer

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

Answer

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

Answer

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

Question 12

Your organization uses GitHub Actions for CI/CD. You need to implement a deployment strategy where a new version of the application is gradually shifted from the stable environment to a canary environment, and if health checks pass, the traffic is fully shifted to the canary. Which GitHub Actions deployment strategy should you use?

Accepted Answer

Canary deployment. A canary deployment gradually shifts traffic from the stable environment to a new canary environment, using health checks to validate the new version before fully routing all traffic to it. This matches the requirement of a gradual shift with health-check gating. GitHub Actions supports this via deployment strategies like `canary` in environments or custom workflows with traffic-splitting tools.

Answer

Recreate deployment

Answer

Blue-green deployment

Answer

Rolling deployment

Question 13

Your team uses Azure Pipelines to build a .NET application. You notice that the build takes 15 minutes because of dependency restoration. You want to cache the NuGet packages to speed up subsequent builds. Which task should you add to your pipeline?

Accepted Answer

Cache task with a key based on the package lock file. The Cache task (D) is the correct choice because it allows you to cache the NuGet packages folder (typically `~/.nuget/packages`) based on a key derived from the package lock file (e.g., `packages.lock.json`). This ensures that when the lock file hasn't changed, the cached packages are restored from the pipeline cache instead of being downloaded from the NuGet feed, significantly reducing build time. The key is computed from the lock file's content hash, so any change in dependencies automatically invalidates the cache.

Answer

DownloadBuildArtifacts task

Answer

NuGet restore task with the 'noCache' option set to false

Answer

DotNetCoreCLI task with the 'restore' command

Question 14

Your team uses Azure Pipelines with Microsoft-hosted agents. You need to ensure that sensitive variables like API keys are securely passed to build tasks, but not exposed in logs. Which approach should you use?

Accepted Answer

Store the API key as a secret variable in the pipeline library or variable group. Secret variables in Azure Pipelines are encrypted at rest and masked in logs, ensuring sensitive values like API keys are never exposed. Storing the API key as a secret in a pipeline library or variable group allows it to be securely referenced by tasks without appearing in output or debug logs.

Answer

Retrieve the API key from Azure Key Vault at runtime using the Azure Key Vault task, but do not mark the output as secret

Answer

Define the API key in a variable template with 'isSecret: false'

Answer

Store the API key as a plain text variable in the pipeline and use it as an environment variable

Question 15

Your organization uses GitHub Actions and needs to enforce that all workflows pass required checks before a pull request can be merged. Which GitHub feature should you configure?

Accepted Answer

Branch protection rules with required status checks. Branch protection rules with required status checks enforce that all configured GitHub Actions workflows must pass before a pull request can be merged. This ensures that any workflow defined in the repository (e.g., CI, linting, security scans) produces a successful check run, and the merge is blocked if any required check fails or is pending.

Answer

Workflow triggers

Answer

Required reviewers

Answer

Environment protection rules