CCNA Build Release Pipelines Questions — Page 4 of 5

226

MCQmedium

You are configuring a release pipeline in Azure Pipelines that deploys a web app to Azure App Service. The pipeline uses a stage with a deployment job. You need to ensure that the deployment uses a specific deployment slot named 'staging' and then swaps it with the production slot after successful deployment. Which task should you use?

A.AzureRmWebAppDeployment@4 with the 'DeployToSlotOrASE' option enabled and the 'SlotName' set to 'staging'.

B.Use AzureRmWebAppDeployment@4 to deploy to the 'staging' slot, followed by AzureAppServiceManage@0 to swap the 'staging' slot with production.

C.AzureRmWebAppDeployment@4 with the 'SwapSlot' input set to 'staging'.

D.AzureAppServiceManage@0 with the 'Action' set to 'Swap Slots' and the 'SourceSlot' set to 'staging'.

AnswerB

This combination first deploys the app to the staging slot using AzureRmWebAppDeployment@4 with the SlotName set to 'staging'. Then, AzureAppServiceManage@0 with the Swap Slots action swaps the staging slot with the production slot. This meets the requirement of deploying to a specific slot and then swapping. It is a common pattern for zero-downtime deployments.

Why this answer

The correct approach is to use two tasks: first, deploy to the staging slot using AzureRmWebAppDeployment@4 with the slot name specified; second, use AzureAppServiceManage@0 to swap the staging slot with production. This ensures the new version is deployed to staging, tested if desired, and then swapped into production. The other options either miss the deployment step or the swap step.

Exam trap

The trap here is assuming that the deployment task can also perform a slot swap, when in fact a separate task is required.

Practice this question →

227

MCQhard

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?

A.Create an environment named 'Production', add an approval check, and reference the environment in the deployment job.

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

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

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

AnswerA

In Azure Pipelines, manual approval checks are attached to environments, not to stages or the pipeline as a whole. By defining a 'Production' environment, adding an approval check to it, and referencing that environment in the deployment job's `environment:` keyword, you create a pre-deployment gate that prompts a designated approver before the job executes, yielding controlled, auditable production deployments.

Why this answer

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.

Exam trap

The trap here is that candidates confuse environment-level approval checks with stage-level gates or pipeline-level settings, thinking they can add an approval directly on a stage in the pipeline settings UI, which is not supported.

How to eliminate wrong answers

Option B is wrong because a pipeline-level approval check applies to all stages in the pipeline, which would force manual approval for non-production environments as well, violating the requirement. Option C is wrong because there is no such thing as an 'approval gate on a stage' in Azure Pipelines; approvals are configured on environments or as pre-deployment gates, not directly on stages. Option D is wrong because branch policies control code changes to the repository, not deployment approvals; they cannot enforce manual approval for a specific deployment environment.

Practice this question →

228

Multi-Selectmedium

Which TWO actions should you take to implement a gated deployment strategy in Azure Pipelines?

Select 2 answers

A.Use deployment gates to evaluate metrics like error rate before allowing the next stage.

B.Configure a dashboard to monitor application health.

C.Use a multi-stage YAML pipeline.

D.Configure a rollback strategy if deployment fails.

E.Add manual approval checks before deployment to production.

AnswersA, E

Deployment gates query external metrics such as error rate or incident counts before releasing a stage, automatically blocking promotion when thresholds are breached. This satisfies the gated deployment requirement by enforcing automated, metric-based verification rather than relying solely on human judgement.

Why this answer

Option A is correct because deployment gates in Azure Pipelines are precisely the mechanism that queries external sources—such as Azure Monitor alerts, REST APIs, or work items—to evaluate metrics like error rate and automatically decide whether the stage may proceed, which is the core of a gated deployment. Option E is correct because manual approval checks (approvals and checks configured on an environment or service connection) pause the pipeline before production deployment so a human can verify readiness, which is a standard gating control in a gated release strategy. Option B is not correct because a dashboard is a monitoring and visualization tool; it reports health but does not itself gate or block a pipeline stage.

Option C is not correct because a multi-stage YAML pipeline is just the structural definition of stages and does not by itself implement gating logic. Option D is not correct because a rollback strategy is a recovery measure after a failed deployment, not a gate that controls whether deployment proceeds.

Exam trap

The trap here is that candidates often confuse monitoring (dashboard) or pipeline structure (multi-stage YAML) with the actual gating mechanism, forgetting that gates require explicit evaluation of health metrics or approvals to block or allow the release.

Practice this question →

229

MCQmedium

You are designing a build pipeline for a Node.js application. The pipeline must run unit tests and publish code coverage results to Azure Pipelines. Which task should you use to ensure coverage results are available in the pipeline summary?

A.PublishTestResults@2

B.VSTest@2

C.CopyFiles@2

D.PublishCodeCoverageResults@1

AnswerD

PublishCodeCoverageResults@1 is the correct task because it directly consumes coverage report files in Cobertura or JaCoCo format and renders an interactive coverage summary in the Azure DevOps pipeline UI, including per-file and line-level percentages. It is language-agnostic, so it works for Node.js applications as long as the test runner (e.g., Jest with the Istanbul/Cobertura reporter) produces the required XML artifact. Unlike tasks that merely copy files or publish test outcomes, this task parses the coverage data and exposes it for direct visibility and monitoring within the pipeline.

Why this answer

The PublishCodeCoverageResults@1 task is specifically designed to publish code coverage results (e.g., Cobertura, JaCoCo, or .coverage formats) to Azure Pipelines, making them visible in the pipeline summary and the Tests tab. This task consumes coverage data files generated by a previous test run and integrates them into the pipeline's reporting UI.

Exam trap

The trap here is that candidates confuse PublishTestResults@2 (which publishes test outcomes) with PublishCodeCoverageResults@1 (which publishes coverage metrics), assuming a single task handles both, when in fact Azure Pipelines requires separate tasks for test results and code coverage.

How to eliminate wrong answers

Option A is wrong because PublishTestResults@2 publishes test pass/fail results (e.g., JUnit, NUnit, VSTest) to the Tests tab, not code coverage data; it does not make coverage percentages or file-level coverage available in the pipeline summary. Option B is wrong because VSTest@2 is a Visual Studio test runner task that executes tests and can optionally publish test results, but it does not natively publish code coverage results to the pipeline summary; coverage data would require a separate task. Option C is wrong because CopyFiles@2 is a file copy task used to copy files from source to destination (e.g., for artifact staging) and has no capability to parse or publish coverage results.

Practice this question →

230

MCQeasy

You have a multi-stage YAML pipeline that builds and deploys a Node.js application. You want to ensure that the build stage runs only when changes are made to the 'src' folder. Which trigger configuration should you use?

A.Trigger with 'batch' set to true

B.Trigger with 'branches' filter

C.Trigger with 'paths' filter

D.Disable CI trigger and use a scheduled trigger

AnswerC

Using a 'paths' filter in the CI trigger allows you to specify include or exclude patterns for file paths, so the pipeline only triggers when changes under the target folder (e.g., /frontend) are detected. This is the exact mechanism to scope triggers to a specific folder or set of files, making it the correct solution.

Why this answer

Azure Pipelines supports path-based triggers that allow you to specify which file paths should trigger a pipeline run. By configuring a trigger with a 'paths' filter that includes only the 'src' folder, the build stage will only execute when changes are detected within that specific directory, ignoring changes elsewhere in the repository.

Exam trap

The trap here is that candidates often confuse path filters with branch filters or batch settings, mistakenly thinking that branch filters or batching can restrict triggers to specific folders, when in fact only path filters provide that capability.

How to eliminate wrong answers

Option A is wrong because setting 'batch' to true controls whether multiple pending CI builds are batched into a single run, not which paths trigger the pipeline. Option B is wrong because a 'branches' filter restricts triggers to specific branches (e.g., main or feature branches), not to specific folders or file paths. Option D is wrong because disabling the CI trigger and using a scheduled trigger would run the pipeline on a fixed schedule regardless of any code changes, which does not achieve the goal of triggering only on changes to the 'src' folder.

Practice this question →

231

MCQmedium

You have a release pipeline that deploys to multiple stages. You want to ensure that a manual approval is required before deploying to the production stage. Which approach should you use?

A.Add a pre-deployment approval on the production stage.

B.Add a post-deployment approval on the staging stage.

C.Configure a deployment gate with a manual intervention task.

D.Use a pipeline decorator to inject approval step.

AnswerA

A pre-deployment approval on the production stage is the correct approach because it prevents the pipeline from starting the production deployment until a designated user or group explicitly approves the release, providing a manual control point before any changes reach the live environment.

Why this answer

Pre-deployment approvals in Azure Pipelines allow you to require manual sign-off before a release proceeds to a specific stage. By adding a pre-deployment approval on the production stage, the pipeline will pause and wait for designated approvers to approve the deployment, ensuring that no code reaches production without explicit authorization.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which occur after a stage completes) with pre-deployment approvals (which occur before a stage starts), or they mistakenly think a manual intervention task inside a deployment gate can replace the native stage-level approval feature.

Why the other options are wrong

Post-deployment happens after deployment, not before.

Gates evaluate conditions, but manual approval is simpler and more direct.

Decorators are for injecting steps, not for approvals.

Practice this question →

232

MCQeasy

Your team uses Azure Repos Git and wants to enforce a policy that all pushes to the main branch must pass a build validation pipeline. The pipeline runs unit tests and code analysis. You need to configure this in the branch policy. Which setting should you enable?

A.Require comment resolution

B.Linked work items

C.Limit merge types

D.Build validation

AnswerD

Build validation automatically triggers a configured build pipeline on each push to a pull request and blocks completion until the build succeeds. It acts as a continuous integration gate that catches compilation errors, test failures, and other issues, thereby enforcing a successful build on every code change.

Why this answer

The Build validation policy in Azure Repos Git enforces that a specified pipeline must succeed before a pull request can be merged into the target branch. This directly meets the requirement to run unit tests and code analysis on all pushes to the main branch, blocking merges if the build fails.

Exam trap

The trap here is that candidates may confuse Build validation with other PR policies like Require comment resolution or Linked work items, mistakenly thinking those options also enforce automated checks, when in fact only Build validation triggers a pipeline execution.

How to eliminate wrong answers

Option A is wrong because Require comment resolution ensures all PR comments are resolved before merging, but it does not trigger or validate any build pipeline. Option B is wrong because Linked work items requires that a PR be associated with a work item, which enforces traceability but does not run any automated validation. Option C is wrong because Limit merge types restricts the merge strategies (e.g., squash, rebase) available for a PR, but it does not execute any build or test pipeline.

Practice this question →

233

Multi-Selecthard

Your team uses Azure Pipelines to build a Java application. The build must produce a JAR file and publish it as a pipeline artifact. Which THREE steps should be included in the build pipeline?

Select 3 answers

A.Use a Maven or Gradle task to compile and package the application.

B.Use the DotNetCoreCLI task to build the application.

C.Use the Publish Build Artifacts task to upload the staging directory.

D.Use the Copy Files task to copy the JAR to $(Build.ArtifactStagingDirectory).

E.Use the NuGetCommand task to pack the JAR.

AnswersA, C, D

The Maven/Gradle task is the correct Java build step: it invokes the project's build tool (e.g., `mvn clean package` or `gradle build`), compiles the Java sources, runs tests, and packages the output into a deployable JAR (or WAR). Without this task, no Java artifact exists to publish.

Why this answer

A Maven or Gradle task is the standard way to compile and package a Java application into a JAR file. These tasks invoke the build tool's lifecycle (e.g., `mvn package` or `gradle build`) to produce the artifact, which is a prerequisite for publishing.

Exam trap

The trap here is that candidates may confuse the DotNetCoreCLI or NuGetCommand tasks with Java tooling, or assume any packaging task works for any language, but Azure Pipelines tasks are language-specific and must match the build toolchain.

Practice this question →

234

MCQhard

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

A.Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.

B.Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.

C.Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.

D.Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.

AnswerB

The default Kubernetes rolling update strategy, triggered by `kubectl apply`, replaces pods incrementally and waits for readiness probes before continuing, which minimizes downtime. Adding a post-deployment step that checks `kubectl rollout status` allows the pipeline to detect a stuck or failed rollout (e.g., crashlooping pods or failed readiness checks). If that status check returns a failure, running `kubectl rollout undo` reverts the Deployment to its previous ReplicaSet, restoring the last known-good configuration without custom scripting.

Why this answer

It directly implements the required behavior: using `kubectl apply` for a rolling update (which inherently supports zero-downtime by gradually replacing pods), followed by a post-deployment step that checks the rollout status. If the rollout fails (e.g., due to health check failures), the pipeline runs `kubectl rollout undo` to automatically revert to the previous version, ensuring rollback on failure.

Exam trap

The trap here is that candidates confuse 'monitoring and reporting failure' (Option C) with 'automatically executing a rollback'—the KubernetesManifest task's rollout status option only checks and reports, it does not perform the undo action; you must explicitly add a separate rollback step.

How to eliminate wrong answers

Option A is wrong because a canary deployment shifts traffic gradually and monitors error rates, but it does not inherently perform a rollback of the Kubernetes Deployment object; it typically requires additional manual or custom logic to revert the Deployment revision. Option C is wrong because the 'KubernetesManifest' task with 'rollout status' only monitors the rollout and reports failure—it does not automatically execute a rollback; you must explicitly add a rollback step. Option D is wrong because blue-green with two separate AKS clusters is overcomplicated and not a single-pipeline rolling update; it also does not automatically roll back the Deployment—it only switches traffic back, leaving the failed Deployment still active.

Practice this question →

235

MCQmedium

Your Azure DevOps pipeline deploys a web app to Azure App Service using a YAML pipeline. The deployment fails intermittently with the error 'Conflict' when updating deployment slots. What is the most likely cause?

A.Another deployment or swap operation is already in progress on the slot.

B.The service connection is using expired credentials.

C.The slot name is misspelled in the pipeline configuration.

D.The web app is locked by a file handle from a previous deployment.

AnswerA

Azure App Service serializes deployment and swap operations per slot, returning an HTTP 409 Conflict when a second operation is attempted concurrently. This error indicates that a previous deployment or swap has not yet completed, so you must wait for it to finish or cancel it before retrying.

Why this answer

The 'Conflict' error during an Azure App Service deployment slot update indicates that the slot is currently locked by another operation, such as an ongoing deployment or a swap. Azure App Service enforces mutual exclusion on slot operations to prevent race conditions, so if a previous deployment or swap has not completed, the new request is rejected with HTTP 409 Conflict.

Exam trap

The trap here is that candidates may confuse a 'Conflict' error with authentication or configuration issues, but Azure specifically returns HTTP 409 only when a resource-level lock prevents the operation, not for credential or naming problems.

How to eliminate wrong answers

Option B is wrong because expired credentials would cause an authentication failure (e.g., HTTP 401 Unauthorized or 403 Forbidden), not a Conflict error. Option C is wrong because a misspelled slot name would result in a 'ResourceNotFound' or HTTP 404 error, as the slot does not exist. Option D is wrong because file handle locks from a previous deployment are an on-premises IIS concept; Azure App Service isolates deployments via slot infrastructure and does not expose file handles that cause HTTP Conflict errors.

Practice this question →

236

MCQeasy

Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?

A.on: workflow_run: workflows: ["Build"] types: [completed]

B.on: issue_comment: types: [created]

C.on: pull_request: types: [labeled] branches: [main]

D.on: pull_request_target: types: [opened, synchronize] branches: [main]

AnswerC

This is correct because the `pull_request` event supports the `labeled` activity type, and the `branches: [main]` filter scopes it to pull requests targeting the main branch. When a label is added to such a PR, this workflow triggers exactly as intended; note it uses the workflow file from the base branch context for security.

Why this answer

The `pull_request` trigger with `types: [labeled]` is the correct event to detect label additions. However, it triggers for any label, not just 'safe-to-deploy'. To ensure the workflow runs only when that exact label is applied, you must combine this trigger with a job-level conditional, e.g., `if: github.event.label.name == 'safe-to-deploy'`.

The answer option C is still the correct trigger, but the explanation must clarify this additional required condition.

Exam trap

The trap here is that candidates may confuse `pull_request` with `pull_request_target` or think that `issue_comment` can detect label changes, but only the `labeled` activity type on `pull_request` directly responds to label additions.

How to eliminate wrong answers

Option A is wrong because `workflow_run` triggers on the completion of another workflow, not on pull request labeling; it would run after a 'Build' workflow finishes, regardless of labels. Option B is wrong because `issue_comment` triggers on comments in issues or pull requests, not on label additions; it would fire when a comment is created, not when a label is applied. Option D is wrong because `pull_request_target` with `types: [opened, synchronize]` triggers on PR creation or new commits, not on labeling; it also runs with a different security context (base repo secrets) and does not respond to label events.

Practice this question →

237

MCQeasy

A team uses Azure Pipelines to build a .NET Core application. The build pipeline runs successfully, but the release pipeline fails when deploying to Azure App Service with the error: 'ERROR_FILE_IN_USE'. What is the most likely cause?

A.The deployment slot is not configured correctly.

B.The 'Take App Offline' setting is not enabled in the deployment task.

C.The Azure App Service plan is not scaled appropriately.

D.The build configuration is set to Release instead of Debug.

AnswerB

The 'Take App Offline' setting instructs the Web App to place an app_offline.htm file in the site root, which gracefully shuts down the app and releases any locks on its assemblies and files. Without this, the running process holds the DLLs, causing 'file in use' errors when the pipeline tries to overwrite them.

Why this answer

The 'ERROR_FILE_IN_USE' error occurs when the deployment process tries to overwrite files that are currently locked by the running application. Enabling the 'Take App Offline' setting in the Azure App Service deploy task places an app_offline.htm file in the wwwroot directory, which gracefully shuts down the application and releases all file locks before the new binaries are copied. Without this setting, the running process holds locks on the DLLs, causing the deployment to fail.

Exam trap

The trap here is that candidates often confuse 'ERROR_FILE_IN_USE' with a slot configuration or scaling issue, but the root cause is always the running process holding file locks, which is directly resolved by the 'Take App Offline' setting in the deployment task.

How to eliminate wrong answers

Option A is wrong because an incorrectly configured deployment slot would cause routing or swapping issues, not a file-lock error during deployment. Option C is wrong because scaling the App Service plan affects performance and resource allocation, not the ability to overwrite locked files. Option D is wrong because the build configuration (Release vs.

Debug) affects optimization and debugging symbols, not file-locking behavior during deployment.

Practice this question →

238

MCQmedium

You are designing a release pipeline that must deploy to multiple environments in sequence: Dev, Test, and Prod. Each environment requires manual approval before deployment. You want to minimize the number of approvals while ensuring that Prod is never deployed without approval. What should you do?

A.Use a single approval for all environments by adding an approval to the pipeline.

B.Add a pre-deployment approval only to the Prod environment.

C.Add a post-deployment approval to the Test environment.

D.Add a pre-deployment approval to each environment.

AnswerB

Adding a pre-deployment approval only to Prod ensures that Prod deployments require manual approval, while Dev and Test can deploy automatically. This minimizes the number of approvals to just one per release, satisfying the requirement that Prod is never deployed without approval. It balances control and efficiency.

Why this answer

Configuring a pre-deployment approval only on the Prod environment ensures that Prod deployments are gated by manual approval, while Dev and Test deploy automatically. This reduces the total number of approvals to one per release, meeting the requirement to minimize approvals and protect Prod. It is the most efficient approach for sequential environments.

Exam trap

The trap here is thinking that approvals must be applied to every environment to be safe, which unnecessarily increases manual steps.

Practice this question →

239

Multi-Selectmedium

Which two of the following are valid strategies to implement conditional deployment in a YAML pipeline? (Choose 2)

Select 2 answers

A.Use the 'condition' property on a stage

B.Use template expressions with parameters

C.Configure stage filters in the triggers section

D.Use dependency conditions like 'succeededOrFailed'

E.Add a PowerShell script to check environment

AnswersA, B

The 'condition' property on a stage in Azure Pipelines evaluates expressions at runtime, such as `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, and is the native, declarative way to control whether a stage executes during a pipeline run, making it ideal for conditional deployment strategies.

Why this answer

Both 'condition' property and template expressions with parameters are valid strategies for conditional deployment in YAML pipelines. The 'condition' property (e.g., `eq(variables['Build.SourceBranch'], 'refs/heads/main')`) controls at runtime whether a stage, job, or step runs, based on variables or expressions. Template expressions with parameters (e.g., `${{ if eq(parameters['environment'], 'prod') }}`) allow you to conditionally include or exclude parts of the pipeline at compile time, making them a powerful tool for conditional deployment based on parameters.

Exam trap

The trap here is that candidates confuse dependency conditions (like `succeededOrFailed`) with custom conditional logic, not realizing that dependency conditions are predefined and not a general-purpose strategy for implementing conditional deployment based on arbitrary criteria like branch names or variables.

Why the other options are wrong

Stage filters are for triggers, not conditions within a pipeline.

Dependency conditions are built-in for run order, not for custom conditional logic.

While possible, it's not a pipeline-native strategy; the question asks for valid strategies in YAML.

Practice this question →

240

MCQhard

Refer to the exhibit. A release pipeline deploys this ARM template. The deployment fails with error: 'The template parameters 'adminPassword' is not a valid input.' What is the most likely cause?

A.The VM size is not available in the specified location.

B.The parameter 'adminPassword' is not defined in the parameters section of the template.

C.The resource group location is invalid.

D.The parameter 'adminPassword' is misspelled in the template.

AnswerB

In Azure Resource Manager (ARM) templates, any parameter referenced within the resources section must first be declared in the parameters section of the template. This template's osProfile block references an 'adminPassword' value, but no corresponding parameter definition exists, so the ARM template validation engine rejects the template with a 'parameter not defined' error before any deployment attempt. The remedy is to add a declaration such as "adminPassword": { "type": "securestring" } to the parameters section, ensuring the reference resolves correctly.

Why this answer

The error 'The template parameters 'adminPassword' is not a valid input' occurs when the ARM template does not declare a parameter named 'adminPassword' in its parameters section. Even if the parameter is referenced elsewhere, it must be explicitly defined in the parameters block to be accepted. Therefore, the most likely cause is that the parameter is missing from the template's parameters definition.

Exam trap

AZ-400 often tests the distinction between parameter declaration and usage, so candidates may overlook that a parameter must be explicitly defined in the parameters section even if it is referenced in the resources section.

How to eliminate wrong answers

Option A is wrong because VM size availability would produce a different error, such as 'The requested VM size is not available in the location'. Option C is wrong because an invalid resource group location would cause an error about the location not being valid, not about a parameter. Option D is wrong because a misspelling would typically result in an error about an undefined parameter or variable, but the error specifically states the parameter is not a valid input, which indicates it is not defined at all.

Practice this question →

241

MCQeasy

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

A.pull_request: branches: [main]

B.pull_request: types: [closed] branches: [main]

C.push: branches: [main]

D.release: types: [published]

AnswerC

This push trigger activates on any push to the main branch, including direct pushes, force pushes, or pushes from branch creation, not just pushes resulting from a pull request merge. It does not distinguish between a merge commit and a direct push, so it would trigger on all commits pushed to main, violating the requirement to only respond to PR merges.

Why this answer

In GitHub Actions, merging a pull request into `main` results in a `push` event to `main`. The `push` trigger with `branches: [main]` therefore correctly fires whenever a PR is merged. `pull_request: types: [closed]` fires on any PR closure, whether merged or not, so it would deploy even when a PR is closed without merging. To use `pull_request` for merges, you would need an additional `if: github.event.pull_request.merged == true` check, but the question asks for the event trigger alone.

Exam trap

The trap is that `pull_request: types: [closed]` is not the same as 'merged'. A merge to a branch is a push event, not a pull_request event. Candidates may incorrectly choose the `pull_request` trigger, but the correct trigger for a merge is `push`.

How to eliminate wrong answers

Option A is wrong because `pull_request: branches: [main]` triggers on any pull request activity (e.g., opened, synchronized, reopened) targeting main, not just when it is merged, leading to premature or repeated deployments. Option C is wrong because `push: branches: [main]` triggers on any push to main, including direct commits or pushes that are not pull request merges, which bypasses the intended merge-only deployment policy. Option D is wrong because `release: types: [published]` triggers only when a GitHub Release is published, which is a separate manual or automated process unrelated to pull request merges.

Practice this question →

242

MCQmedium

You are designing a build pipeline that produces an artifact. You need to ensure that the artifact is only published if the build succeeds. The pipeline includes multiple jobs: Build, Test, and Publish. Which condition should you use on the Publish job to achieve this?

A.condition: always()

B.condition: failed()

C.condition: succeeded()

D.condition: eq(variables['Build.Status'], 'Succeeded')

AnswerC

The succeeded() condition returns true only if all previous jobs in the dependency chain have succeeded. By setting this condition on the Publish job, it will only run if the Build and Test jobs succeed. This ensures the artifact is published only on successful builds.

Why this answer

The succeeded() condition ensures that the Publish job runs only if all previous jobs in the dependency chain have succeeded. This is the standard way to gate a job on the success of prior jobs. Other conditions either run unconditionally, on failure, or use invalid variables.

Exam trap

The trap here is using a variable like Build.Status, which does not exist for job status; the correct approach is to use the succeeded() function.

Practice this question →

243

MCQmedium

You are designing a build pipeline for a Java application hosted in Azure Repos. The pipeline needs to run unit tests, package the application as a JAR file, and publish the build artifact. Which task should you use to publish the JAR file as a pipeline artifact?

A.Publish Build Artifacts task

B.Copy Files task

C.Archive Files task

D.Publish Pipeline Artifact task

AnswerD

Publish Pipeline Artifact uploads files, directories, or archives to Azure Pipelines' pipeline artifact storage, making them downloadable and consumable by later stages in the same pipeline. It is the modern, YAML-native artifact-publishing task, and by default subsequent stages automatically download published pipeline artifacts into the Pipeline.Workspace directory. This is the correct task when the goal is to pass build outputs from a Java build stage to later deployment or test stages.

Why this answer

The Publish Pipeline Artifact task (D) is the correct choice because it is the modern, recommended way to publish artifacts from a pipeline in Azure DevOps. It stores the JAR file as a pipeline artifact, making it available for subsequent stages or releases, and it supports both file and folder paths directly without requiring an intermediate staging directory.

Exam trap

The trap here is that candidates often confuse the legacy Publish Build Artifacts task (A) with the modern Publish Pipeline Artifact task (D), not realizing that the latter is the recommended approach in current Azure DevOps pipelines and offers better performance and integration.

How to eliminate wrong answers

Option A is wrong because the Publish Build Artifacts task is a legacy task that publishes artifacts to Azure Pipelines, but it requires an explicit staging directory and is less efficient than the newer Publish Pipeline Artifact task. Option B is wrong because the Copy Files task only copies files from source to a target folder within the agent's workspace; it does not publish anything as a pipeline artifact. Option C is wrong because the Archive Files task compresses files into a ZIP or other archive format but does not publish the archive as a pipeline artifact; it only creates the archive file locally.

Practice this question →

244

MCQhard

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. You need to require manual approval before deploying to prod. The approver should be able to review the changes and approve or reject. Which feature should you use?

A.Pre-deployment conditions.

B.Environment checks.

C.Approval gates.

D.Manual intervention task.

AnswerA

Pre-deployment conditions in Azure Pipelines include artifact filters, schedule times, and pre-deployment approvals, but the approval itself is a separate gate that must be explicitly configured. Merely having pre-deployment conditions does not implement a manual approval workflow by default; it only defines when and under what circumstances the deployment is triggered.

Why this answer

In Azure DevOps release pipelines, to require manual approval before deploying to a specific stage, you configure the pre-deployment conditions of that stage, specifically assigning pre-deployment approvers. These approvers can review the changes and then approve or reject the deployment. This satisfies the requirement directly.

Exam trap

Candidates may mistake 'Approval gates' for a valid feature, but Azure DevOps only supports 'approvals' and 'gates' as separate features. Manual approval is achieved via pre-deployment approvers under 'Pre-deployment conditions', not via gates, which are automated checks.

How to eliminate wrong answers

Option A is wrong because pre-deployment conditions include triggers, gates, and approvals, but the specific feature that enables manual approval by a reviewer is the 'Approvals' section within pre-deployment conditions, not the conditions themselves. Option B is wrong because environment checks are automated evaluations (e.g., querying Azure Monitor or REST endpoints) that run before or after deployment; they do not provide a manual approval workflow. Option D is wrong because the Manual Intervention task is a pipeline agent job step that pauses the pipeline and waits for a manual input, but it runs inside the deployment job on the agent, not as a pre-deployment gate, and it does not integrate with the release pipeline's approval history or notification system.

Practice this question →

245

MCQmedium

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?

A.The agent service account does not have write permissions on the working directory

B.The agent is not configured to use the correct agent pool

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

D.The source code checkout failed due to incorrect credentials

AnswerA

The agent service account is the OS-level account under which the self-hosted agent process runs. When a pipeline job starts, the agent creates a working directory under its _work folder (e.g., _work/1/s) to clone the source and perform build outputs. If that account lacks write permissions (NTFS Modify or POSIX write/execute) on the working directory, any file creation or modification fails with an access-denied error—even though the agent itself successfully connected and started the job. To resolve this, grant the service account full control (Windows) or write+execute (Unix) on the entire _work directory.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse a permissions error with a file-locking error (Option C), but Azure Pipelines specifically uses distinct error messages for each scenario, and 'access denied' always points to NTFS permissions, not file locks.

How to eliminate wrong answers

Option B is wrong because an incorrect agent pool configuration would prevent the build from being assigned to the agent at all, resulting in a 'no agent found' or 'agent offline' error, not a file access denied error. Option C is wrong because a file locked by another process would produce a specific error like 'The process cannot access the file because it is being used by another process', not a generic 'access denied' error. Option D is wrong because source code checkout failures due to incorrect credentials would manifest as authentication errors (e.g., 'Authentication failed', 'Repository not found'), not as a local file path access denied error.

Practice this question →

246

MCQhard

Your release pipeline deploys a .NET Core web app to Azure App Service using a slot swap strategy. The pipeline runs acceptance tests on the staging slot before swapping. After a recent change, the acceptance tests pass but the production site becomes unresponsive after the swap. What is the most likely cause?

A.The staging slot had different app settings that were swapped into production, causing the site to fail.

B.The acceptance tests are not comprehensive enough and missed a regression.

C.The acceptance tests should have been run after the swap.

D.The slot swap was not 'warm-up' and caused downtime.

AnswerA

Slot swaps exchange app settings marked as swappable, so staging-specific values (connection strings, endpoints) migrate into production and break it, while acceptance tests still pass because they ran against staging's own configuration. The unresponsiveness stems from production receiving staging's incompatible settings during the swap, not from code or warm-up failures.

Why this answer

The most likely cause is that the staging slot had different app settings (e.g., connection strings, environment variables, or feature flags) that were swapped into production. During a slot swap, Azure App Service automatically moves all slot-specific configuration (app settings, connection strings, and other deployment slot settings) to the target slot. If the staging slot was configured with settings intended only for testing (like a staging database or debug mode), those settings would overwrite the production settings, causing the production site to become unresponsive.

This is a common pitfall because acceptance tests may pass against the staging environment but fail when the same code runs with production configuration.

Exam trap

The trap here is that candidates often assume acceptance tests are sufficient to catch all issues, or they misunderstand the slot swap mechanism—thinking it causes downtime—when the real problem is the automatic migration of non-sticky configuration settings between slots.

How to eliminate wrong answers

Option B is wrong because the acceptance tests passing on the staging slot does not guarantee that the production configuration is correct; the issue is a configuration mismatch, not a code regression. Option C is wrong because running acceptance tests after the swap would not prevent the swap from occurring and would only detect the problem after the site is already broken. Option D is wrong because Azure App Service slot swaps include automatic warm-up of the staging slot before the swap completes; the swap itself does not cause downtime unless the warm-up fails, but the scenario states the site becomes unresponsive after the swap, which points to a configuration issue, not a warm-up failure.

Practice this question →

247

Multi-Selecteasy

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

Select 2 answers

A.Pipeline variables

B.Release gates

C.Build tags

D.Download Pipeline Artifact task

E.Publish Pipeline Artifact task

AnswersD, E

The Download Pipeline Artifact task is correct because it downloads pipeline artifacts from a previous build or pipeline run into the current job, enabling the job to consume build outputs that were published earlier. This task is a fundamental part of managing build artifacts across stages and pipelines.

Why this answer

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.

Exam trap

The trap here is that candidates confuse pipeline variables (which pass simple values) with artifact tasks (which pass files), or mistakenly think release gates or build tags have a role in artifact management across stages.

Practice this question →

248

Multi-Selecthard

Which TWO of the following are valid strategies to reduce the build time of a container image in Azure Pipelines?

Select 2 answers

A.Combine multiple RUN commands into a single RUN instruction to reduce layers.

B.Build multiple images in parallel using matrix strategy.

C.Use Docker layer caching with a registry cache.

D.Disable security scanning for the image.

E.Use a larger build agent with more CPU cores.

AnswersC, E

Using Docker layer caching with a registry cache is a valid strategy because it reuses previously built and stored layers from a container registry (e.g., ACR) instead of rebuilding unchanged steps. This dramatically accelerates builds, particularly in CI/CD pipelines with frequent commits or shared base layers, as only the modified layers are rebuilt and the rest are pulled from cache.

Why this answer

The correct strategies to reduce build time for a container image in Azure Pipelines are using Docker layer caching with a registry cache (C) and using a larger build agent with more CPU cores (E). Layer caching avoids rebuilding unchanged layers, while a larger agent provides more parallelism for CPU-bound build steps. Combining RUN commands (A) can hurt cache efficiency and is not a reliable way to reduce build time.

Building multiple images in parallel (B) reduces overall pipeline time when you have multiple images, but it does not reduce the build time of a single image. Disabling security scanning (D) is not a valid practice.

Exam trap

The trap is that candidates often assume combining RUN commands (Option A) always reduces build time, but it can harm cache efficiency. Another is assuming that parallelizing multiple images (B) affects the build time of a single image; it does not.

Practice this question →

249

MCQhard

You have a classic release pipeline that deploys to Azure App Service. You need to implement a canary deployment strategy where 10% of traffic is routed to the new version for 30 minutes before full rollout. What should you use?

A.Configure multiple deployment slots and use Traffic Manager to distribute traffic.

B.Use the 'Azure App Service deploy' task with the 'Deploy to Slot' option, then manually adjust routing rules.

C.Deploy to a staging slot and then use Azure CLI to update routing rules after deployment.

D.Use slot swap with 'Swap with preview' and set traffic percentage in the swap settings.

AnswerC

Using Azure CLI to update routing rules after deploying to a staging slot is a manual, scripted step that lacks the automatic warm-up, validation, and controlled traffic shifting provided by swap with preview. This approach also doesn't integrate with release pipeline gates or provide a clear path to roll back if issues are detected during the canary phase.

Why this answer

Canary deployment on Azure App Service is achieved by deploying to a deployment slot and then configuring routing rules to send a percentage of traffic to that slot. In a classic release pipeline, you can use the Azure App Service deploy task to deploy to a slot, followed by an Azure CLI task to set the traffic percentage (e.g., az webapp traffic-routing set). The 'Swap with preview' feature is for multi-phase swap validation, not for setting traffic percentages.

Exam trap

Candidates confuse Traffic Manager (DNS-level) and slot-based routing, but also mistakenly assume 'Swap with preview' supports traffic percentage. The correct tool is slot routing rules, not swap-based traffic shifting.

How to eliminate wrong answers

Option A is wrong because Traffic Manager is a DNS-based traffic routing service that operates at the domain level, not at the slot level within a single App Service; it cannot route a percentage of traffic between deployment slots of the same app. Option B is wrong because the 'Azure App Service deploy' task with 'Deploy to Slot' deploys to a slot but does not automatically adjust routing rules; manual adjustment of routing rules is not a built-in feature of the task and would require additional scripting. Option C is wrong because deploying to a staging slot and then using Azure CLI to update routing rules is possible but less integrated; the 'Swap with preview' feature provides a more streamlined, built-in approach with traffic percentage control during the swap process.

Practice this question →

250

MCQmedium

Your team uses Azure Pipelines with GitHub for source control. You need to ensure that whenever a pull request is created against the main branch, a validation build runs automatically. Which YAML trigger should you configure in the pipeline?

A.pr: branches: include: - main

B.pr: main

C.trigger: branches: exclude: - main

D.trigger: main

AnswerA

This is the correct YAML for a pull request trigger that runs the pipeline when a PR targets the `main` branch. The `pr` keyword specifically enables pull request validation for GitHub repos, and the `branches: include` list tells Azure Pipelines which target branches should trigger a run. Without this configuration, PRs to `main` would rely on the default policy and might not run automatically.

Why this answer

The correct syntax for a pull request trigger in Azure Pipelines YAML. The `pr` trigger requires a `branches` node with `include` or `exclude`, and the verbose form `pr: branches: include: - main` is fully valid. Option B, `pr: main`, is not valid YAML syntax for Azure Pipelines; the shorthand `pr: main` is not recognized and will cause the pipeline to ignore the trigger.

Options C and D use the `trigger` keyword, which is for CI builds on push, not for PR validation.

Exam trap

The trap is that some documentation or online examples might incorrectly suggest the shorthand `pr: main` is valid, but Azure Pipelines requires the explicit `pr: branches: include:` structure. Candidates may choose the seemingly simpler format and fail.

How to eliminate wrong answers

Option A is wrong because while it uses the `pr` trigger, the syntax `pr: branches: include: - main` is invalid; the correct shorthand for a single branch is `pr: main`. Option C is wrong because `trigger: branches: exclude: - main` configures a CI trigger that excludes the main branch, meaning it would run on pushes to other branches but not on pull requests, which does not meet the requirement. Option D is wrong because `trigger: main` is a CI trigger that runs on pushes to the main branch, not on pull request creation, so it would not trigger a validation build for PRs.

Practice this question →

251

MCQhard

Refer to the exhibit. You deploy this Bicep template to create an Azure App Service with a custom container. The deployment succeeds, but the container fails to start with an error 'Container didn't respond to HTTP pings'. What is the most likely missing configuration?

A.The template is missing the 'healthCheckPath' property in siteConfig.

B.The container image is not publicly accessible.

C.The WEBSITES_ENABLE_APP_SERVICE_STORAGE should be set to 'true'.

D.The template is missing the app setting 'WEBSITES_PORT'.

AnswerA

The template omits the healthCheckPath property in siteConfig, which is required for App Service to route /health requests to the container's endpoint and remove unhealthy instances from the load balancer. Without this property, the container's custom health endpoint is never probed, so the deployment fails validation if the container requires a specific path.

Why this answer

The error 'Container didn't respond to HTTP pings' indicates that Azure App Service's built-in health check mechanism is failing to reach the container. By default, App Service pings the root path ('/') on the container's exposed port. If the container's application does not respond on that path, the health check fails.

Adding the 'healthCheckPath' property in siteConfig allows you to specify a custom endpoint (e.g., '/health') that the container can respond to, resolving the issue.

Exam trap

The trap here is that candidates often confuse the health check path with the container port setting (WEBSITES_PORT), assuming the ping failure is due to a port mismatch rather than the HTTP endpoint not being reachable on the default path.

How to eliminate wrong answers

Option B is wrong because the container image not being publicly accessible would cause a deployment failure (e.g., 'ImagePullBackOff'), not a post-startup HTTP ping failure. Option C is wrong because WEBSITES_ENABLE_APP_SERVICE_STORAGE controls persistent file storage for Windows containers, not HTTP health check behavior; it is irrelevant to the ping failure. Option D is wrong because WEBSITES_PORT defines the internal port the container listens on, but if the container is already listening on the default port (e.g., 80 or 8080) and the ping fails, the issue is the response path, not the port.

Practice this question →

252

MCQhard

Your team is adopting Infrastructure as Code (IaC) using Bicep. You have a multi-stage YAML pipeline that deploys Azure resources to dev, test, and prod environments. You need to ensure that the Bicep files are validated and deployed consistently, and that any changes to the infrastructure are approved for production. You also want to use the latest version of the Azure CLI task. What is the recommended approach?

A.Use the Azure Resource Manager Template Deployment task with the 'templateLocation' parameter pointing to the compiled ARM JSON.

B.Create three separate pipelines for each environment, each using the ARM Template Deployment task.

C.Use the AzureCLI task with inline script to run 'az deployment group validate' and 'az deployment group create'. Add environments with approval gates for production.

D.Use a PowerShell task with the 'New-AzResourceGroupDeployment' cmdlet.

AnswerC

The Azure CLI task natively supports Bicep files, so you can run 'az deployment group validate' to catch template errors before deploying, then 'az deployment group create' to apply the resource definitions. Adding environments with approval gates for production lets you control promotions and gain auditability, all within one pipeline and without any precompilation step.

Why this answer

It uses the AzureCLI task with the 'az deployment group validate' and 'az deployment group create' commands, which natively support Bicep files. This approach integrates with multi-stage YAML pipelines and allows adding approval gates for production environments. Option A is incorrect because the Azure Resource Manager Template Deployment task requires a compiled ARM JSON file, adding an unnecessary compilation step and not leveraging Bicep's native capabilities.

Option B is incorrect because creating separate pipelines for each environment duplicates effort and does not take advantage of the multi-stage YAML pipeline structure with environment approvals. Option D is incorrect because using a PowerShell task with 'New-AzResourceGroupDeployment' cmdlet lacks native Bicep support and may require manual compilation.

Practice this question →

253

MCQhard

Your YAML pipeline uses a self-hosted agent pool. You need to ensure that only the pipeline can trigger builds on that pool, preventing other projects from using it. What should you do?

A.Set the agent pool to 'Disabled' for other projects

B.Configure pipeline permissions in the agent pool security settings

C.Use a deployment group instead of an agent pool

D.Create a separate agent pool for each project

AnswerB

Configuring pipeline permissions in the agent pool security settings is the correct approach because Azure DevOps agent pools support role-based access control (Reader, User, Administrator) and you can grant or deny the 'Use' permission to specific pipelines or groups. This allows you to restrict which pipelines can consume the agents in the pool.

Why this answer

Azure DevOps agent pool security settings allow you to restrict which pipelines or projects can use a specific agent pool. By configuring pipeline permissions, you can grant the 'Use' permission only to the intended pipeline, preventing other projects from triggering builds on that pool. This ensures exclusive access without disabling the pool for all other uses.

Exam trap

The trap here is that candidates often confuse disabling the pool for other projects (Option A) with permission-based restrictions, not realizing that disabling removes all access, including the intended pipeline's ability to use it.

Why the other options are wrong

Disabling the pool prevents all usage, including the intended pipeline.

Deployment groups are for targeting specific servers, not for access control.

That would work but is not necessary; you can secure a single pool with permissions.

Practice this question →

254

Multi-Selecteasy

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

Select 2 answers

A.trigger: branches: exclude: - main

B.trigger: branches: include: - main

C.branches: include: - main

D.trigger: branches: main

E.trigger: branches: include: - release/*

AnswersB, E

This is correct: the trigger block with branches/include and a main entry tells Azure Pipelines to start the CI pipeline only when changes are pushed to main, using the required YAML syntax where branches filters are lists under include or exclude.

Why this answer

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.

Exam trap

The trap here is that candidates often forget the `trigger:` keyword (as in Option C) or misuse `exclude` when `include` is needed (as in Option A), and they may also incorrectly assume a simple list syntax like `branches: main` is valid without the `include` keyword.

Practice this question →

255

MCQmedium

You are implementing a CI pipeline for a Node.js application. The pipeline must run unit tests and generate code coverage reports. You want to publish the coverage results to Azure DevOps and enforce a minimum coverage threshold of 80%. Which tasks should you use?

A.Use the Publish Test Results task to publish coverage data.

B.Use the Publish Build Artifacts task with coverage files.

C.Use the Copy Files task to copy coverage files and then the Publish Build Artifacts task.

D.Use the Publish Code Coverage Results task and configure the threshold in the task settings.

AnswerD

The Publish Code Coverage Results task is the correct solution because it natively consumes coverage files (e.g., Cobertura, JaCoCo) and publishes them to the pipeline summary. It also has threshold settings to enforce minimum coverage percentages, which can fail the build if the thresholds are not met, satisfying both reporting and quality gate requirements.

Why this answer

The Publish Code Coverage Results task is specifically designed to publish code coverage data (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps and supports configuring a minimum coverage threshold directly in its settings. This meets both requirements: publishing results and enforcing the 80% threshold. Other tasks like Publish Test Results or Publish Build Artifacts do not natively handle coverage threshold enforcement.

Exam trap

The trap here is that candidates confuse 'publishing test results' with 'publishing code coverage results,' assuming the Publish Test Results task can handle coverage data, when in fact coverage requires a dedicated task with threshold enforcement.

How to eliminate wrong answers

Option A is wrong because the Publish Test Results task publishes test execution results (e.g., JUnit XML), not code coverage data, and cannot enforce coverage thresholds. Option B is wrong because the Publish Build Artifacts task only uploads raw files as build artifacts without any analysis or threshold enforcement for coverage. Option C is wrong because while Copy Files and Publish Build Artifacts can move coverage files, they lack the built-in capability to parse coverage reports and fail the pipeline if the threshold is not met.

Practice this question →

256

MCQeasy

You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?

A.Slot swap

B.Canary deployment

C.Rolling update

D.Blue-green deployment

AnswerD

Blue-green deployment maintains two fully separate environments (blue and green) with the new version deployed to the idle environment before switching traffic via a load balancer or DNS; although conceptually similar, App Service slots provide this capability within a single app as a swap, so slot swap is the precise Azure-native implementation, not a distinct blue-green setup.

Why this answer

Blue-green deployment is a release strategy that uses two identical environments (blue and green). The new version is deployed to the staging slot (green), smoke tests are run, and traffic is switched to the staging slot by swapping it with the production slot (blue). Slot swap is the Azure App Service mechanism used to implement blue-green deployment, but the strategy itself is blue-green.

Exam trap

The trap is that 'slot swap' is an Azure-specific implementation mechanism, not the deployment strategy. Candidates may answer 'slot swap' because they recognize the step, but the question asks for the strategy, which is blue-green.

How to eliminate wrong answers

Option B is wrong because canary deployment routes a small percentage of traffic to the new version gradually, which is not the same as a full slot swap after smoke tests; Azure App Service does not natively support canary routing without additional traffic manager or feature flags. Option C is wrong because rolling update replaces instances one by one, which is not how Azure App Service deployment slots work; slots are swapped atomically, not instance-by-instance. Option D is wrong because blue-green deployment is the general pattern, but the question asks for the specific deployment strategy to use in Azure Pipelines with App Service slots, and the correct Azure-specific term is 'slot swap'.

Practice this question →

257

MCQeasy

You need to configure a release pipeline that deploys to Azure App Service. The deployment should use the 'slot swap' strategy to minimize downtime. Which deployment slot should you initially deploy to?

A.Production slot

B.Warmup slot

C.Staging slot

D.All slots simultaneously

AnswerC

Deploying to a Staging slot is the correct approach because it lets you validate the build and perform pre-production checks without impacting live traffic. Once verified, you perform a swap between the Staging and Production slots, which is an atomic operation that keeps the app continuously available and enables quick rollback by swapping again if needed.

Why this answer

The slot swap strategy in Azure App Service deploys to a non-production slot (typically 'staging') first, allowing validation before swapping with the production slot. This eliminates downtime by warming up the staging slot and then routing traffic to it via a zero-downtime swap operation. Deploying directly to production would cause downtime or require manual traffic management.

Exam trap

The trap here is that candidates may think 'Warmup slot' is a real Azure slot name due to the term 'warmup' being used in Azure App Service settings (like application initialization), but Azure only provides 'production' and 'staging' as default slots, and custom slots must be explicitly created.

How to eliminate wrong answers

Option A is wrong because deploying directly to the Production slot would cause downtime during the deployment process, as the app would be restarted or updated in-place, defeating the purpose of a slot swap strategy. Option B is wrong because 'Warmup slot' is not a standard Azure App Service slot name; Azure uses 'staging' as the default non-production slot, and warmup is a process (e.g., application initialization) not a slot. Option D is wrong because deploying to all slots simultaneously would overwrite production and staging at the same time, eliminating the ability to validate changes before swapping and potentially causing downtime or failed rollbacks.

Practice this question →

258

MCQhard

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

A.The reference function cannot be used in a properties object.

B.The reference function syntax is incorrect.

C.The Application Insights component is not defined as a resource in the template.

D.The apiVersion for the config resource is outdated.

AnswerC

The deployment fails because ARM cannot resolve a reference to a resource absent from the template. Application Insights requires an explicit `Microsoft.Insights/components` resource declaration; without it, the App Service's instrumentation settings reference a non-existent resource, satisfying the stem's "not defined in the template" constraint.

Why this answer

The error 'The resource 'Microsoft.Insights/components/...' is not defined in the template' indicates that the ARM template references an Application Insights component (e.g., via the `reference()` function or a `dependsOn` property) that is not declared as a resource within the template's `resources` array. In ARM templates, every resource you reference must be explicitly defined; otherwise, the deployment engine cannot resolve it, causing this validation error.

Exam trap

The trap here is that candidates often confuse a missing resource definition with a syntax error in the `reference()` function or an API version issue, but the error message explicitly says 'not defined', which points directly to the resource not being declared in the template's `resources` section.

How to eliminate wrong answers

Option A is wrong because the `reference()` function can be used in a `properties` object to retrieve runtime values from other resources, as long as those resources are defined in the template. Option B is wrong because the error message specifically states the resource is 'not defined', not that the syntax of `reference()` is incorrect; a syntax error would produce a different parsing error. Option D is wrong because an outdated `apiVersion` would cause a different error (e.g., 'The apiVersion parameter ... is not supported'), not a 'not defined' error for the resource itself.

Practice this question →

259

Multi-Selectmedium

Which TWO actions should you take to implement a secure build pipeline that uses Azure Key Vault to store secrets? (Choose two.)

Select 2 answers

A.Store the Key Vault name and secret names in a secure file in the repository.

B.Define secrets as pipeline variables and mark them as secret.

C.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.

D.Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.

E.Use the 'Azure Key Vault' task to download secrets as pipeline variables.

AnswersC, E

Granting the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault is a mandatory prerequisite for the pipeline to retrieve secret names and values; without these permissions, the Azure Key Vault task fails, so you must configure an access policy or RBAC role assignment for the service principal.

Why this answer

The Azure DevOps service principal (the identity used by Azure Pipelines) must be granted 'Get' and 'List' permissions on the Key Vault's access policy. This allows the pipeline to retrieve secret values securely without storing credentials in the repository or pipeline configuration. Without these permissions, any attempt to read secrets from the vault will fail with an authorization error.

Exam trap

The trap here is that candidates often think storing secrets as pipeline variables (Option B) is sufficient, but the question specifically requires using Azure Key Vault, so the correct approach is to retrieve secrets from Key Vault at runtime using the dedicated task, not to hardcode them as pipeline variables.

Practice this question →

260

MCQmedium

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

A.The script type 'pscore' is not supported on Ubuntu.

B.The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.

C.Parameters cannot be used in YAML pipelines; they must be defined in a template.

D.The 'trigger: none' prevents the pipeline from running.

AnswerB

The macro syntax `$(environment)` in a variable resolves to a runtime variable named 'environment', not to a pipeline parameter. Parameters are expanded at compile time via `${{ parameters.environment }}`, so this use would produce a null/empty value and cause the resource group name to be incorrect or undefined.

Why this answer

In Azure DevOps YAML pipelines, the `$()` syntax is used to reference runtime variables, not parameters. Parameters are defined using `parameters:` and are referenced with `${{ parameters.parameterName }}`. Using `$(environment)` attempts to resolve a variable named 'environment', but since 'environment' is defined as a parameter, it is not available as a variable at runtime, causing the resource group name to remain unresolved and the pipeline to fail.

Exam trap

The trap here is that candidates confuse the syntax for referencing parameters (`${{ }}`) with the syntax for referencing variables (`$()`), assuming both are interchangeable in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because the script type 'pscore' (PowerShell Core) is fully supported on Ubuntu agents in Azure Pipelines; it runs pwsh, which is cross-platform. Option C is wrong because parameters are fully supported in YAML pipelines directly, not only in templates; they can be defined at the pipeline level using the `parameters:` keyword. Option D is wrong because `trigger: none` only disables CI triggers, but the pipeline can still be run manually or via other triggers; it does not cause a failure due to unresolved variables.

Practice this question →

261

MCQeasy

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

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

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

C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

D.condition: ne(variables['Build.Reason'], 'PullRequest')

AnswerA

This condition is correct because the Build.SourceBranch variable returns the full ref path, such as 'refs/heads/main', so the equality check accurately triggers only when the build originates from the main branch, ignoring other branches or tags.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Exam trap

The trap here is that candidates often assume `Build.SourceBranch` contains only the short branch name (like `main`) rather than the full Git ref path (`refs/heads/main`), leading them to choose Option B.

Why the other options are wrong

Missing 'refs/heads/' prefix, so it won't match.

This checks PR target branch, not the source branch.

This excludes PRs but does not limit to main branch.

Practice this question →

262

MCQhard

Your YAML pipeline uses the 'AzureResourceManagerTemplateDeployment' task to deploy ARM templates. You need to handle incremental deployments and ensure that the task fails if any resource already exists and cannot be updated. Which deployment mode should you specify?

A.Incremental

B.Complete

C.Validate

D.CreateOrUpdate

AnswerA

Incremental mode is the default ARM deployment mode that only adds, updates, or deletes resources that are specified in the template, leaving all other resources in the resource group untouched. This allows users to perform partial updates by modifying only the relevant resources without affecting the entire resource group's existing configuration.

Why this answer

The 'Incremental' deployment mode in the AzureResourceManagerTemplateDeployment task handles only changes specified in the template, leaving existing resources unchanged. If a resource already exists and cannot be updated (e.g., due to a property conflict or immutable resource), the deployment fails, meeting the requirement to fail on such conflicts. This mode is the standard for additive, non-destructive ARM template deployments.

Exam trap

The trap here is that candidates confuse 'Incremental' with 'Complete' mode, mistakenly thinking 'Complete' is safer for incremental updates, when in fact 'Complete' can delete resources not in the template, leading to data loss.

Why the other options are wrong

Complete mode deletes resources not in the template; it does not fail on existing resources that cannot be updated.

Validate mode only validates the template without actually deploying resources.

There is no deployment mode named 'CreateOrUpdate'; it is a behavior of Incremental mode.

Practice this question →

263

MCQeasy

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

A.Use a custom action to manually mask secrets in the logs.

B.Define secrets as environment variables directly in the workflow YAML.

C.Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.

D.After the workflow runs, delete the logs from GitHub.

AnswerC

This is the recommended approach because GitHub encrypts secrets at rest, restricts access to authorized users/actions, and automatically detects the exact secret value used in the workflow to redact it from all log output. Referencing secrets via ${{ secrets.SECRET_NAME }} keeps the actual value out of the YAML source and ensures that any accidental printing of that value is masked in real time.

Why this answer

GitHub automatically masks secrets referenced via the ${{ secrets.SECRET_NAME }} syntax in workflow logs. When a secret is used in a workflow, GitHub Actions scans the log output and replaces any occurrence of the secret value with '***', preventing exposure. This built-in mechanism is the recommended best practice as it requires no additional configuration and works across all steps and actions.

Exam trap

The trap here is that candidates may think manual masking or log deletion is necessary, overlooking GitHub's built-in automatic secret masking that works seamlessly when secrets are properly referenced via the ${{ secrets.SECRET_NAME }} syntax.

How to eliminate wrong answers

Option A is wrong because using a custom action to manually mask secrets is error-prone and unnecessary; GitHub already provides automatic masking for secrets referenced in the standard way. Option B is wrong because defining secrets as environment variables directly in the workflow YAML file would expose the secret values in plain text within the repository, defeating the purpose of secure storage. Option D is wrong because deleting logs after a run does not prevent exposure during the run or before deletion, and it also removes valuable debugging information; the correct approach is to prevent exposure proactively.

Practice this question →

264

Multi-Selectmedium

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

Select 2 answers

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

B.Use the 'Approvals and gates' settings in the release pipeline stage.

C.Configure branch policy on the release branch to require approvals.

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

E.Add a pre-deployment approval gate to the Staging and Production stages.

AnswersB, E

In classic release pipelines, the 'Approvals and gates' settings are configured per stage and allow you to add pre-deployment and post-deployment approvals, as well as gates such as query-based checks or Azure Monitor alerts. Pre-deployment approvals are the built-in mechanism to pause the pipeline before a stage runs, ensuring authorized reviewers approve the release before it reaches environments like Staging and Production.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which happen after deployment) with pre-deployment approvals (which gate the deployment), or they incorrectly think branch policies or manual validation tasks are the correct way to add manual approval gates in a release pipeline.

Practice this question →

265

MCQeasy

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

A.Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

B.Create a copy of the template and modify the step directly.

C.Use a conditional 'if' statement in the template to skip steps based on a parameter.

D.Use template parameters with a 'steps' object that can be injected to override the step.

AnswerD

This is the supported pattern: declare a template parameter of type 'steps' and pass it through to the steps section of a job or stage. For example, define `parameters: - name: stepsOverride type: steps default: []` and then use `steps: ${{ parameters.stepsOverride }}` in the template; the caller can supply a list of steps as an argument to replace the default behavior. Because the parameter is a full steps object, the calling pipeline can inject any arbitrary step definitions without modifying the template file itself. This approach keeps the template reusable while allowing per-pipeline overrides.

Why this answer

Azure DevOps YAML templates support parameterized steps objects. By defining a template parameter of type 'steps' with a default value, the calling pipeline can pass a custom steps object as an argument to that parameter, effectively overriding the default steps without modifying the template. No 'replace' keyword is used; the override is achieved by directly injecting the steps object via the parameter.

Exam trap

The trap here is that candidates may confuse the fictional 'overrides' keyword (Option A) with a real feature, or incorrectly assume that conditional logic in the template (Option C) is the only way to control step execution, when in fact Azure DevOps provides a dedicated parameter injection pattern for step replacement using a steps object parameter.

How to eliminate wrong answers

Option A is wrong because Azure DevOps YAML does not support an `overrides` keyword; this is a fictional construct. Option B is wrong because creating a copy of the template defeats the purpose of reuse and introduces maintenance overhead, which is not the intended solution for overriding steps without modifying the template. Option C is wrong because using a conditional `if` statement in the template requires modifying the template itself, which violates the requirement to avoid modifying the template.

Practice this question →

266

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. What built-in feature of GitHub Actions automatically prevents this?

A.Audit log monitoring

B.Secret scanning alerts

C.Required reviewers on workflows

D.Automatic log redaction

AnswerD

Automatic log redaction is the correct answer because GitHub Actions detects values of configured secrets in a job's output and replaces them with '***' in real time across all workflow run logs, effectively preventing secrets from appearing.

Why this answer

GitHub Actions includes a built-in feature that automatically redacts secrets from workflow run logs. When a secret is printed to the console, GitHub detects the secret value and replaces it with '***' in the log output, preventing accidental exposure. This redaction happens at the log rendering layer, not in the workflow execution, so the secret is never visible to users viewing the logs.

Exam trap

The trap here is that candidates often confuse secret scanning (which detects secrets in source code) with log redaction (which prevents secrets from appearing in CI/CD output), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because audit log monitoring records administrative actions and events in the organization, but it does not prevent secrets from appearing in build logs—it only provides a historical record after the fact. Option B is wrong because secret scanning alerts detect secrets committed to repositories (e.g., in code or configuration files), not secrets printed during workflow execution in logs. Option C is wrong because required reviewers on workflows enforce approval for pull request workflows, but they do not inspect or redact log output for secrets.

Practice this question →

267

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

A.Add a YAML template that includes the signing task and require all pipelines to extend it.

B.Set a branch policy requiring a signed build status.

C.Configure a manual approval gate on the build pipeline.

D.Use a Pipeline decorator to inject the signing task into every build pipeline.

AnswerD

Pipeline decorators are extension-based components that automatically inject a set of tasks into every pipeline (or a filtered subset) at either the start or end of a job, at the organization level. Because the decorator runs outside the individual pipeline definition, it cannot be bypassed by pipeline authors and does not require changes to existing YAML or classic builds. This provides the required guarantee that the signing task is applied to every build pipeline.

Why this answer

Pipeline decorators allow injecting tasks (like signing) into every pipeline globally without modifying individual pipeline definitions. Option A is wrong because YAML templates require each pipeline to explicitly extend them; they do not enforce automatic inclusion. Option B is wrong because branch policies control pull request merge conditions, not build steps.

Option C is wrong because manual approval gates are used in release pipelines to control promotion, not to enforce signing during build.

Practice this question →

268

MCQeasy

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

A.Publish Test Results task

B.Copy Files task

C.npm test

D.Publish Build Artifacts task

AnswerA

The Publish Test Results task is correct because it explicitly consumes test result files (e.g., JUnit, NUnit, VSTest) and uploads them to Azure Pipelines, enabling test analytics, failure reporting, and trend dashboards in the build summary.

Why this answer

The Publish Test Results task (A) is correct because it specifically ingests test result files (e.g., JUnit, NUnit, xUnit, or TRX formats) and publishes them to Azure DevOps, enabling test analytics, trend charts, and pass/fail reporting in the pipeline summary. For a Node.js application, after running unit tests with a framework like Jest or Mocha, the test results are typically output as JUnit XML files, and this task is required to make those results visible in the DevOps portal.

Exam trap

The trap here is that candidates confuse running tests (npm test) with publishing test results, not realizing that Azure DevOps requires a separate task to ingest and display test outcomes in the pipeline UI.

How to eliminate wrong answers

Option B (Copy Files task) is wrong because it only copies files from source to a destination folder; it does not parse or publish test results. Option C (npm test) is wrong because it is a script step that runs the test command defined in package.json, but it does not publish test results to Azure DevOps—it only executes the tests locally in the pipeline. Option D (Publish Build Artifacts task) is wrong because it publishes build outputs (e.g., compiled code, binaries) as artifacts for deployment, not test result files for reporting.

Practice this question →

269

MCQhard

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

A.The variable 'BuildConfiguration' is misspelled.

B.The branch 'main' does not exist.

C.All agents in the pool are currently busy.

D.The pipeline definition ID is incorrect.

AnswerC

When a build is queued without explicit agent demands, Azure Pipelines can run it on any agent in the specified pool. If all agents in that pool are currently executing other jobs, the build will remain in a queued state until an agent becomes available—this is a common cause of a build appearing stuck. The queue shows the build as 'Queued' or 'Waiting for agent' without raising an immediate error, which matches the exhibit behavior.

Why this answer

When a build remains in 'notStarted' status for an extended period, it typically means the pipeline is waiting for an available agent. Since the pipeline has no demands and priority is normal, the most likely cause is that all agents in the specified agent pool are currently busy executing other jobs, so the build is queued until an agent becomes free.

Exam trap

The trap here is that candidates often assume a 'notStarted' status is caused by a configuration error (like a missing branch or misspelled variable) rather than recognizing it as a classic symptom of agent pool exhaustion or queue saturation.

How to eliminate wrong answers

Option A is wrong because a misspelled variable like 'BuildConfiguration' would cause a build-time error or unexpected behavior during the build process, not prevent the build from starting; the build would still be assigned to an agent and run. Option B is wrong because if the branch 'main' does not exist, the build would fail at the source fetch step or trigger a 'not found' error, but the build would still be assigned to an agent and attempt to run, not remain 'notStarted'. Option D is wrong because the pipeline definition ID is used internally by Azure DevOps to identify the pipeline; an incorrect ID would prevent the build from being queued at all, resulting in an error when triggering the build, not a 'notStarted' status.

Practice this question →

270

MCQmedium

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

A.Use a Docker Compose task in the pipeline to start the database container before running integration tests.

B.Configure the pipeline to use a self-hosted agent that has the database already installed and running.

C.Install the database as a service in the pipeline using the Service Fabric task.

D.Use a PowerShell script in the pipeline to install and start the database on the build agent.

AnswerA

A Docker Compose task starts the database container as a service before the integration test step runs, so the dependency is available when tests execute. This satisfies the requirement that integration tests need a running database, and the task fails the pipeline if the container cannot start.

Why this answer

Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Exam trap

The trap here is that candidates may confuse the Docker Compose task with other Azure DevOps tasks like Service Fabric or generic scripting, failing to recognize that Docker Compose is the standard, built-in method for managing container dependencies in a pipeline.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with a pre-installed database introduces statefulness and environment drift, making builds non-reproducible and harder to maintain across agents. Option C is wrong because the Service Fabric task is designed for deploying and managing microservices on Azure Service Fabric, not for starting a database container as a service in a build pipeline. Option D is wrong because using a PowerShell script to install and start a database on the build agent is error-prone, slow, and pollutes the agent's environment, whereas Docker Compose provides a cleaner, containerized solution.

Practice this question →

271

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to pass a status check before merging. The status check should be provided by a pipeline that runs when a pull request is created. Which type of trigger should you configure in the pipeline YAML?

A.Push trigger

B.Manual trigger

C.PR trigger

D.Scheduled trigger

AnswerC

A PR trigger in Azure Pipelines automatically starts a pipeline whenever a pull request is created or gets new commits, enabling validation of code changes before merging. This is the correct trigger type for validating pull requests, as it directly responds to PR events.

Why this answer

A PR trigger (pr:) in Azure Pipelines YAML automatically runs the pipeline when a pull request is created or updated against a specified branch. This allows the pipeline to produce a status check that GitHub enforces as a required check before merging, fulfilling the policy requirement.

Exam trap

The trap here is that candidates often confuse push triggers with PR triggers, thinking a push to the target branch will suffice, but the status check must be tied to the PR's merge commit or head branch, which only a PR trigger can automate.

How to eliminate wrong answers

Option A is wrong because a push trigger runs the pipeline on commits to a branch, not on pull request creation, so it cannot provide a status check tied to the PR lifecycle. Option B is wrong because a manual trigger requires a user to explicitly start the pipeline, which is not automated and cannot enforce a required status check without human intervention. Option D is wrong because a scheduled trigger runs the pipeline at specified times (e.g., nightly), independent of pull request events, so it cannot provide a real-time status check for PRs.

Practice this question →

272

MCQhard

You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?

A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.

B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.

C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.

D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.

AnswerD

Auto-revert is a native environment setting that, when enabled, automatically redeploys the previously successful version (the last known good deployment) whenever post-deployment conditions, such as health-check gates, mark the current deployment as failed. This provides the automatic rollback behavior required without human intervention or a classic release pipeline, and it is fully integrated with YAML multi-stage pipelines. Setting post-deployment conditions ensures that the health check is evaluated before the revert trigger fires.

Why this answer

Azure DevOps environments support an 'Auto-revert' setting that automatically triggers a rollback to the previous successful deployment when a post-deployment health check (defined via post-deployment conditions) fails. This combines manual approval (pre-deployment approvals on the environment) with automatic rollback, meeting both requirements without additional tasks or release pipelines.

Exam trap

The trap here is that candidates confuse 'Auto-revert' with classic release pipeline features or assume manual intervention tasks are needed for rollback, overlooking the environment-level automatic rollback capability in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with pre-deployment approvals and a post-deployment automatic rollback trigger, but the question specifies a multi-stage YAML pipeline, not a classic release pipeline; the 'Auto-revert' feature is environment-specific and not a release pipeline trigger. Option B is wrong because configuring a post-deployment gate that fails the deployment does not automatically roll back; it only marks the deployment as failed, requiring manual intervention to revert. Option C is wrong because adding a manual intervention task to roll back contradicts the requirement for automatic rollback; manual intervention tasks require human action, not automation.

Practice this question →

273

Multi-Selectmedium

You manage a release pipeline for a Java application that is deployed to Azure App Service. The pipeline currently uses manual approval gates. You need to implement automated quality gates to reduce manual intervention. Which THREE conditions can you use in the 'Post-deployment approvals' settings of a release pipeline? (Choose three.)

Select 3 answers

A.Azure Policy

B.Manual approval

C.Invoke Azure Functions

D.REST API

E.Query Azure Monitor alerts

AnswersC, D, E

Invoke Azure Functions is a native release gate that executes an Azure Function with the release context, using the function's response (e.g., success/failure, custom payload) to determine if the deployment should proceed. This enables robust, custom quality logic to be hosted serverlessly and automatically evaluated.

Why this answer

'Invoke Azure Functions' is a valid gate type in Azure DevOps release pipelines. It allows you to call an Azure Function as a quality gate, enabling custom automated checks (e.g., validating deployment health or running custom logic) without manual intervention. This directly supports the goal of reducing manual approvals by automating post-deployment validation.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) with a pipeline gate, or think that manual approval can be automated, when in fact the question explicitly asks for automated quality gates that reduce manual intervention.

Practice this question →

274

Multi-Selectmedium

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

Select 2 answers

A.Grant the least privilege to service connections

B.Use Azure Key Vault to store secrets and fetch them at runtime

C.Use the default hosted agent for all builds

D.Store secrets as plain text in pipeline variables

E.Allow contributors to bypass the required reviewer policy

AnswersA, B

Granting least privilege to service connections means configuring each Azure Pipelines service connection with only the minimum permissions required for its intended tasks, limiting the blast radius if credentials are compromised and preventing accidental or malicious overreach to unrelated Azure resources.

Why this answer

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.

Exam trap

The trap here is that candidates may think using default hosted agents is secure because Microsoft manages them, but they overlook the risk of unpatched vulnerabilities or unnecessary software in the default image, and they may also mistakenly believe that storing secrets as pipeline variables is acceptable if they are marked as 'secret' in the UI, when in fact they are still stored in the pipeline's metadata and can be exposed in logs.

Practice this question →

275

MCQmedium

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

A.Post-deployment approvals on the Production environment

B.Deployment queue settings on the Production environment

C.Deployment gates on the Production environment

D.Pre-deployment approvals on the Production environment

AnswerD

Pre-deployment approvals are explicitly designed to pause the release pipeline before a deployment to an environment begins, requiring a designated approver to review and approve the release. For a Production environment, this ensures that a human sign-off is obtained before any code is deployed to Production.

Why this answer

Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Exam trap

The trap here is confusing pre-deployment approvals with deployment gates, as both can pause a deployment, but gates are automated checks (e.g., monitoring metrics) while approvals require explicit human action from a designated group.

How to eliminate wrong answers

Option A is wrong because post-deployment approvals occur after the deployment has already completed, not before, so they cannot gate the deployment to Production. Option B is wrong because deployment queue settings control how releases are queued and parallel execution, not manual approval requirements for a specific environment. Option C is wrong because deployment gates evaluate health metrics or external conditions automatically (e.g., via Azure Monitor or REST APIs) and do not provide manual approval from a specific group of users.

Practice this question →

276

MCQmedium

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

A.parameters:

B.arguments:

C.inputs:

D.variables:

AnswerA

Template parameters are defined under the `parameters:` key at the top of a YAML template file, allowing values to be passed from the calling pipeline via `${{ parameters.paramName }}` syntax. This makes templates reusable and configurable at compile time, before the pipeline runs.

Why this answer

The 'parameters' key in a YAML template is used to define parameters that can be passed to the template, allowing conditional execution based on the parameter value. Option B is incorrect: 'arguments' is not a standard YAML key for passing parameters to templates; it is used for specifying script arguments. Option C is incorrect: 'inputs' is used for task inputs within a step, not for template parameters.

Option D is incorrect: 'variables' are used to define pipeline variables, not for passing parameters to templates.

Practice this question →

277

MCQmedium

Refer to the exhibit. A developer commits code to the 'develop' branch. The pipeline does not trigger. What is the most likely reason?

A.The trigger is configured to only run on the 'main' branch.

B.The pipeline requires a manual trigger.

C.The pipeline has a CI trigger disabled.

D.The pool 'ubuntu-latest' is not available.

AnswerA

The YAML pipeline defines a CI trigger using `trigger: - main`, which instructs Azure Pipelines to start a run only for pushes that land on the `main` branch. A commit pushed to `devel` does not match that branch filter, so no pipeline run is created. Therefore the reason for the missing run is scope, not a bad agent pool or manual mode.

Why this answer

The pipeline did not trigger on a commit to the 'develop' branch. The most likely reason is that the YAML pipeline's trigger is configured to only include the 'main' branch, so commits to 'develop' are ignored. Azure Pipelines CI triggers default to all branches unless specified, but if the trigger explicitly includes only 'main', then 'develop' commits won't trigger.

Other options are less likely: manual trigger would require explicit run, but the question implies automatic trigger expected; CI trigger disabled would prevent any automatic trigger, but the question specifies 'develop' branch, suggesting other branches might work; pool availability would cause failure after trigger, not prevent trigger.

Exam trap

The trap is assuming that the pipeline triggers on all branches by default. In Azure DevOps, if you explicitly specify a trigger for only 'main', commits to other branches like 'develop' will not trigger the pipeline. Candidates often overlook the branch filters in the YAML.

How to eliminate wrong answers

Option B is wrong because if the pipeline required a manual trigger, it would not trigger on any branch automatically, but the scenario implies that commits to other branches might trigger, or the expectation is automatic. Option C is wrong because if the CI trigger were disabled entirely, no commits would trigger the pipeline, but the question focuses on the 'develop' branch specifically, implying that other branches might trigger. Option D is wrong because pool availability affects where the pipeline runs, not whether it triggers; an unavailable pool would cause the pipeline to fail after triggering, not prevent the trigger.

Practice this question →

278

MCQhard

Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?

A.Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.

B.Keep the single pipeline but add caching for dependencies.

C.Use a single pipeline but add conditional stages to skip unchanged services.

D.Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.

AnswerA

This approach uses path-based triggers to run individual service pipelines only when their source changes, reducing build time and resource usage. The additional comprehensive pipeline, triggered only by modifications to shared libraries, ensures cross-service integration tests still run when dependencies change, preserving integration testing without unnecessary builds.

Why this answer

It uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.

Exam trap

The trap here is that candidates may think caching (Option B) or conditional stages (Option C) are sufficient, but they fail to address the need for integration tests across services when shared libraries change, which requires a separate comprehensive pipeline with path triggers.

How to eliminate wrong answers

Option B is wrong because caching dependencies reduces build time for repeated steps but does not address the core issue of running the entire pipeline for every commit, including unchanged services. Option C is wrong because conditional stages to skip unchanged services still require evaluating the entire pipeline, and Azure Pipelines does not natively support skipping stages based on changed paths without complex scripting; it also does not solve the integration test problem for shared library changes. Option D is wrong because disabling the comprehensive pipeline means integration tests that span multiple services will not run when shared libraries change, breaking the requirement to maintain quality.

Practice this question →

279

MCQmedium

Your Azure DevOps project uses Git for source control. You want to enforce that all code changes are reviewed before merging into the main branch. Which branch policy should you enable?

A.Allow only comment resolution.

B.Require a successful build before merging.

C.Limit merge types to squash merge.

D.Require a minimum number of reviewers.

AnswerD

Setting a minimum number of reviewers is the branch policy that directly enforces code review: a pull request cannot be completed until the specified number of distinct users have explicitly approved it. This ensures that changes receive independent human verification before they are merged into the target branch.

Why this answer

The 'Require a minimum number of reviewers' branch policy in Azure DevOps enforces that a specified number of approvers must sign off before a pull request can be completed, directly satisfying the requirement that all code changes are reviewed before merging. This policy can be set on the main branch and optionally reset votes on new pushes. It is the standard mechanism for mandatory code review in Azure Repos.

Exam trap

AZ-400 often tests the confusion between build validation policies (CI gates) and reviewer policies (human approval), leading candidates to choose 'Require a successful build' when the question explicitly asks for code review.

How to eliminate wrong answers

Option A is wrong because 'Allow only comment resolution' merely requires that comments be resolved before merge; it does not require any reviewer approval, so changes could merge without review. Option B is wrong because requiring a successful build enforces CI quality gates but does not mandate human review; a build can pass without any reviewer. Option C is wrong because limiting merge types to squash merge controls commit history shape, not review requirements.

Practice this question →

280

MCQmedium

Refer to the exhibit. A release is created with the above command. The Dev environment starts deploying, but the Prod environment does not. Which is the most likely reason?

A.The Prod environment requires manual approval before deployment.

B.The release definition ID 5 is incorrect.

C.The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.

D.The build artifact with ID 123 is not accessible.

AnswerC

The Prod environment's pre-deployment condition is configured to trigger only after a successful deployment to the Dev environment. In Azure DevOps release pipelines, environment-level pre-deployment gates can be set to 'After environment' and specify a dependency on a prior environment's completion. If that condition is set to require Dev to succeed, the Prod deployment will remain in a 'Waiting' state until Dev finishes, which precisely matches the observed behavior. This is the default dependency model when you add environments sequentially, and it explains why Prod is delayed even though the artifact is valid and no approvals are configured.

Why this answer

The exhibit shows a release pipeline with a sequential deployment strategy where the Prod environment has a pre-deployment condition configured to wait for the Dev environment to succeed. In Azure DevOps, pre-deployment conditions can be set to trigger only after a specific environment (like Dev) completes successfully. Since the Dev environment is still deploying, the Prod environment remains in a waiting state and does not start.

Exam trap

The AZ-400 exam often tests the distinction between manual approval and sequential environment dependencies, where candidates mistakenly assume a missing approval gate when the real issue is a pre-deployment condition waiting for a prior environment to succeed.

How to eliminate wrong answers

Option A is wrong because while manual approval is a common pre-deployment condition, the exhibit does not show any approval gates configured; the most likely reason based on the default behavior is the sequential dependency. Option B is wrong because the release definition ID 5 is used to create the release, and if it were incorrect, the release creation itself would fail, not just the Prod deployment. Option D is wrong because if the build artifact with ID 123 were not accessible, the release creation or Dev deployment would fail first, not specifically block Prod while Dev is deploying.

Practice this question →

281

Multi-Selecteasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Select 2 answers

A.pull_request: branches: [ main ]

B.push: branches: [ main ]

C.release

D.workflow_dispatch

E.schedule

AnswersA, B

The `pull_request` event triggers the workflow when a pull request is opened, synchronized, or reopened, and the `branches: [ main ]` filter ensures it only runs for PRs whose base branch is `main`. This is the correct choice because it enables CI on proposed changes before merging, catching issues early in the review process while avoiding runs for PRs targeting other branches.

Why this answer

The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

Exam trap

The trap here is that candidates often confuse `pull_request` with `pull_request_target` or forget that `push` and `pull_request` are separate events, leading them to select only one trigger or add irrelevant triggers like `release` or `schedule`.

Practice this question →

282

MCQeasy

Your team is using GitHub Actions to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate the workflow to AKS without storing credentials in the repository. What should you use?

A.Use OpenID Connect (OIDC) with a federated identity credential.

B.Use the GITHUB_TOKEN to authenticate to Azure.

C.Use an SSH deploy key to authenticate to AKS.

D.Store an Azure service principal password as a GitHub secret.

AnswerA

OpenID Connect (OIDC) with a federated identity credential is the recommended approach because it eliminates static secrets: GitHub Actions exchanges a short-lived token with Azure AD, and Azure trusts the federated identity without requiring you to store any passwords or client secrets. This provides passwordless, rotation-free authentication that is more secure and easier to manage.

Why this answer

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token for Azure credentials using a federated identity credential, eliminating the need to store any long-lived secrets in the repository. This is the recommended approach for secure, passwordless authentication to Azure services, including AKS, because it uses token-based authentication that automatically rotates and is scoped to specific workflows.

Exam trap

The trap here is that candidates often confuse the GITHUB_TOKEN (which is for GitHub API calls) with an Azure authentication token, or they assume that storing a service principal password as a secret is acceptable, missing the security and compliance benefits of OIDC-based federated identity.

How to eliminate wrong answers

Option B is wrong because the GITHUB_TOKEN is scoped to the GitHub repository and cannot authenticate to Azure resources; it is used for GitHub API operations only. Option C is wrong because SSH deploy keys are used for Git repository access (e.g., cloning private repos), not for authenticating to Azure Kubernetes Service or any Azure resource. Option D is wrong because storing an Azure service principal password as a GitHub secret still requires managing a long-lived credential, which violates the requirement to avoid storing credentials in the repository and introduces security risks such as secret rotation and exposure.

Practice this question →

283

MCQeasy

You are configuring a release pipeline to deploy to Azure App Service. You want to use the 'Deploy Azure App Service' task. Which authentication method should you use to securely connect Azure DevOps to the Azure subscription?

A.Azure CLI authentication with a user account.

B.Azure Resource Manager service connection using a service principal.

C.Use a SAS token for the App Service.

D.Managed Identity assigned to the Azure DevOps agent.

AnswerB

An Azure Resource Manager service connection using a service principal is the recommended secure, automated authentication method for CI/CD pipelines; it uses an app registration with a secret or certificate, enables fine-grained role-based access control, and avoids interactive login requirements.

Why this answer

The 'Deploy Azure App Service' task requires a secure, non-interactive connection between Azure DevOps and Azure. An Azure Resource Manager service connection using a service principal is the recommended and supported method because it uses Azure AD authentication with a client secret or certificate, enabling automated, credential-free deployments without user interaction or token expiry issues.

Exam trap

The trap here is that candidates confuse SAS tokens (used for storage-level access) with service principal authentication, or mistakenly think Managed Identity can be directly assigned to a non-Azure-hosted DevOps agent, when in fact service connections require a service principal for secure, automated subscription access.

How to eliminate wrong answers

Option A is wrong because Azure CLI authentication with a user account requires interactive login and is not suitable for automated pipelines; it also lacks the necessary service principal permissions for headless deployment. Option C is wrong because a SAS token is used for granting delegated access to Azure Storage resources (like blobs or files), not for authenticating Azure DevOps to the Azure subscription or App Service management plane. Option D is wrong because Managed Identity cannot be assigned directly to an Azure DevOps agent; it is a feature for Azure resources (e.g., VMs, App Services) and is not supported as an authentication method for Azure DevOps service connections.

Practice this question →

284

MCQmedium

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

A.Add the tool as a capability of the agent pool and use the 'Install Tool' task.

B.Add the 'Run Security Scan' task from the Azure DevOps marketplace.

C.Create a custom service hook to trigger the scan externally and wait for results.

D.Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.

AnswerD

A Command-Line, Bash, or PowerShell task can directly invoke any installed security scanning executable (e.g., Trivy, OWASP ZAP, a custom CLI, or a vendor's command-line tool) with the appropriate arguments, run it against the repository workspace, and fail the pipeline based on the tool's exit code. This is the standard, supported way to integrate command-line-based security scanning into an Azure Pipeline because it runs inside the agent job and can produce actionable results.

Why this answer

The security scan tool is installed on a self-hosted agent but not available as a built-in task or marketplace extension. Using a command-line task (Bash or PowerShell) allows you to directly invoke the tool's executable from the agent's file system, passing necessary parameters and capturing exit codes to determine success or failure. This approach integrates seamlessly with Azure Pipelines' standard task execution model without requiring custom extensions or external service hooks.

Exam trap

The trap here is that candidates may assume a marketplace task or service hook is required for any third-party tool, overlooking the simplicity and directness of using a command-line task when the tool is already installed on a self-hosted agent.

How to eliminate wrong answers

Option A is wrong because the 'Install Tool' task is designed to download and install tools from a specified URL or Azure storage, not to execute a tool already installed on the agent; adding the tool as a capability only labels the agent for targeting, it does not run the scan. Option B is wrong because the 'Run Security Scan' task from the marketplace does not exist for this specific third-party tool; marketplace tasks are pre-built integrations, and if the tool is not available there, you cannot use a generic marketplace task to execute it. Option C is wrong because creating a custom service hook to trigger the scan externally and wait for results introduces unnecessary complexity, latency, and potential failure points; service hooks are for event-driven notifications, not for synchronous execution of a local tool within a pipeline job.

Practice this question →

285

MCQhard

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?

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

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

C.Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action

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

AnswerC

GitHub Actions secrets are encrypted at rest, masked in logs, and injected into the workflow runtime only when explicitly referenced, making them the secure, supported way to pass service principal credentials. The 'azure/login' action accepts these credentials via secret inputs (e.g., 'client-id', 'client-secret', 'subscription-id', 'tenant-id') and uses them to establish an authenticated session with Azure, so storing them as GitHub Actions secrets and referencing them in that action is the correct, best-practice approach.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse storing credentials in Kubernetes secrets (which is valid for in-cluster applications) with the initial authentication needed from an external CI/CD system, or they may think managed identities can be directly assigned to GitHub Actions runners, which is not supported.

How to eliminate wrong answers

Option A is wrong because managed identity for GitHub Actions is not directly supported for authenticating to AKS; managed identities are Azure resources that cannot be assigned to GitHub Actions runners, and the AKS cluster would need to trust the GitHub runner's identity, which is not a standard authentication flow. Option B is wrong because storing service principal credentials in a Kubernetes secret within the AKS cluster does not help the GitHub Actions workflow authenticate to the cluster initially; the workflow needs credentials to access the cluster before it can read any Kubernetes secrets. Option D is wrong because storing credentials as environment variables in the workflow file exposes them in plain text in the workflow logs and repository, violating security best practices and potentially leaking secrets.

Practice this question →

286

MCQhard

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?

A.Configure a rolling update with readiness and liveness probes

B.Use a blue-green deployment strategy

C.Use Helm charts with pre-upgrade hooks

D.Implement a canary deployment with manual verification

AnswerA

Configure a rolling update with readiness and liveness probes: This approach leverages Kubernetes' native deployment controller to gradually replace pods while continuously checking health signals. If a readiness probe fails on new pods, the rollout immediately stops and Kubernetes automatically rolls back to the last healthy replica set, ensuring zero manual intervention and no downtime.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse deployment strategies (blue-green, canary) with the mechanism for automated health-check-based rollback, overlooking that Kubernetes native probes combined with rolling updates provide the simplest and most automatic solution.

How to eliminate wrong answers

Option B is wrong because blue-green deployment requires manual or scripted traffic switching and does not inherently provide automatic rollback based on health checks; it typically relies on external verification. Option C is wrong because Helm pre-upgrade hooks run before the upgrade and are used for tasks like database migrations, not for monitoring health after deployment or triggering rollbacks. Option D is wrong because canary deployment with manual verification depends on human approval to proceed or roll back, which contradicts the requirement for automatic rollback based on health checks.

Practice this question →

287

Multi-Selecthard

Which THREE features are available in GitHub Actions for managing secrets across environments?

Select 3 answers

A.Encrypted variables in workflows

B.Organization-level secrets

C.Secret scanning alerts

D.Environment-specific secrets

E.Repository-level secrets

AnswersB, D, E

Organization-level secrets are a core GitHub Actions feature that lets administrators define secrets once at the organization level so they are available to all repositories within that organization, enabling centralized management and consistent access across multiple workflows without duplicating sensitive values.

Why this answer

GitHub Actions supports three types of secrets for managing sensitive data: organization-level secrets, which are encrypted and shared across multiple repositories within an organization; repository-level secrets, which are available to all workflows in a single repository; and environment-specific secrets, which are scoped to a particular environment (e.g., production) within a repository. Together these allow centralized and scoped management of secrets across different environments and repositories. Options A and C are incorrect: 'encrypted variables in workflows' is not the official GitHub Actions secret feature, and secret scanning alerts is a reactive security service, not a secret management feature.

Exam trap

The trap here is that candidates confuse 'secret scanning alerts' (a reactive security feature) with proactive secret management features, or assume 'encrypted variables' is a valid term when GitHub Actions officially uses 'secrets' for encrypted sensitive data.

Practice this question →

288

MCQeasy

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

A.Set 'trigger: none' in YAML

B.Set 'trigger: branches: include: - release/*'

C.Set 'trigger: branches: include: - main'

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

AnswerB

Setting 'trigger: branches: include: - release/*' configures the pipeline to automatically run on every push to any branch matching the release/* wildcard. This precisely matches the requirement to trigger only for release branches, making it the correct choice.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse branch triggers with tag triggers or forget that omitting a trigger defaults to 'include all branches', leading them to incorrectly select a tag-based option or a branch that doesn't match the required pattern.

How to eliminate wrong answers

Option A is wrong because 'trigger: none' disables all CI triggers, meaning the pipeline will never run automatically on any branch push, which contradicts the requirement to trigger on 'release/*' branches. Option C is wrong because it includes only the 'main' branch, which does not match the 'release/*' pattern and would ignore pushes to release branches. Option D is wrong because it configures a tag-based trigger (tags starting with 'v'), not a branch-based trigger; tags are separate from branches and do not respond to branch pushes.

Practice this question →

289

Multi-Selecthard

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Hardcode secrets in the pipeline YAML for simplicity.

B.Store secrets as plain text variables in YAML pipelines.

C.Use Azure Key Vault to store secrets.

D.Use a library variable group linked to Azure Key Vault.

E.Reference secrets as secret variables in pipeline tasks.

AnswersC, D, E

Use Azure Key Vault to store secrets because it is a centralized, cloud-based secret management service that provides strong encryption, granular access policies with Azure AD authentication, audit logging, and automated secret rotation, ensuring secrets are never exposed in code or logs.

Why this answer

Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Exam trap

The trap here is that candidates may think storing secrets as plain text variables is acceptable if they are marked as 'secret' in the pipeline UI, but those values are still stored in the pipeline definition and can be exposed in logs or exports, whereas Key Vault provides centralized, audited secret management.

Practice this question →

290

MCQhard

The exhibit shows a parameters file for an ARM template deployment. During a release pipeline, the deployment fails with the error 'The provided value for the template parameter 'sku' is not valid'. The ARM template defines the 'sku' parameter as an allowed value set of ['F1', 'D1', 'B1', 'S1']. What could be the issue?

A.The parameter file contains an extra space or hidden character in the 'sku' value.

B.The parameter file is missing the '$schema' property.

C.The 'sku' parameter is defined in the 'variables' section instead of 'parameters'.

D.The ARM template expects a different API version for the resource.

AnswerA

ARM parameter validation compares the supplied string against the allowed value set exactly, so a trailing space or non-printing character makes 'S1 ' fail to match 'S1'. The template rejects the value as invalid even though it looks correct in the file.

Why this answer

ARM parameter files are JSON, and the allowed-values check is a strict string comparison against the template's allowed set. A trailing space, non-breaking space, or hidden Unicode character in the 'sku' value (for example 'F1 ' instead of 'F1') causes the value to fail the allowed-values validation even though it looks correct in the editor. This is the classic cause of 'The provided value for the template parameter is not valid' when the value visually matches the allowed list.

Exam trap

The trap is that the value looks identical to an allowed value on screen, so candidates assume the problem must be structural (schema, variables, API version) rather than an invisible character in the string.

How to eliminate wrong answers

Option B is wrong because a missing '$schema' property in a parameter file does not cause a parameter value validation error — it may cause schema validation warnings but not the allowed-values failure. Option C is wrong because if 'sku' were defined in variables rather than parameters, the deployment would fail with a different error about an undefined parameter, not an invalid value. Option D is wrong because an API version mismatch produces errors about the resource type or API version, not a parameter value validation failure against the allowed set.

Practice this question →

291

MCQhard

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

A.Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

B.Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.

C.Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

D.Use a classic release pipeline with pre-deployment approvals on the production stage.

AnswerB

This approach leverages a single YAML pipeline with multiple stages, where the staging stage deploys and runs tests, publishing results as artifacts. A pre-deployment gate on the production stage uses those published test results (e.g., pass rate or coverage) to automatically block or allow the promotion, ensuring the exact same build that passed staging is deployed. Because gates are evaluated automatically before the stage starts, no manual approval is required, yet the release is safely gated by objective quality signals.

Why this answer

A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.

Exam trap

The trap here is that candidates often confuse stage-level gates with task-level conditions, assuming a single stage with conditional tasks can achieve the same result, but gates operate at the stage boundary and can evaluate aggregated results from the entire previous stage, not just individual task outcomes.

How to eliminate wrong answers

Option A is wrong because using a single stage with conditional tasks does not provide a true stage-level gate; tasks within a stage run sequentially and cannot block the entire stage based on results from a previous stage, leading to potential deployment to production even if tests fail. Option C is wrong because using two separate pipelines with a pipeline trigger does not allow the production pipeline to evaluate test results from the staging pipeline; triggers only start the next pipeline upon completion, not based on test outcomes. Option D is wrong because pre-deployment approvals are manual and not automated based on test results; they require human intervention and do not evaluate integration test pass/fail status.

Practice this question →

292

MCQhard

You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: - Each service must have its own pipeline that triggers on pushes to the main branch. - Deployment to AKS must use Helm charts. - The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository. - Security scanning must be performed on container images before deployment. - The pipeline must support manual approval for production deployment. - All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs. You need to design the workflow. What is the best course of action?

A.Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.

B.Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.

C.Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.

D.Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.

AnswerB

Using OIDC eliminates long-lived Azure credentials by exchanging short-lived tokens from GitHub Actions, satisfying secure auth without storing secrets. Helm manages releases with chart version increments and rollback capabilities, and committing the bumped chart back maintains GitOps traceability. GitHub environments provide protected branches and approval gates per stage, while Trivy or Docker Scout scans container images for vulnerabilities before deployment.

Why this answer

Option B satisfies every stated requirement using native GitHub Actions capabilities: reusable workflows provide DRY pipeline logic across the 15 service repos, OIDC federation eliminates long-lived AKS/registry credentials by exchanging short-lived tokens with Microsoft Entra ID, GitHub Environments supply the manual approval gate for production, and Trivy/Docker Scout integrate cleanly as a scanning step before Helm deployment. Helm handles chart versioning, and committing the bumped chart back to the repo closes the GitOps loop.

Exam trap

AZ-400 often tests whether candidates recognize that OIDC plus GitHub Environments replaces the older pattern of storing Azure service principal secrets and using Azure DevOps approval gates, so answers that keep static credentials or switch tools get eliminated.

How to eliminate wrong answers

Option A is wrong because migrating to Azure Pipelines contradicts the stated GitHub Actions requirement and adds no AKS capability that GitHub Actions lacks via OIDC and azure/k8s-deploy actions. Option C is wrong because kubectl bypasses Helm (violating the Helm requirement), a single shared GitHub secret violates least-privilege and secret isolation, and skipping scanning violates an explicit security requirement. Option D is wrong because storing AKS credentials as static GitHub secrets ignores the OIDC requirement, and using Azure CLI instead of Helm-native actions breaks the chart versioning/commit-back workflow.

Practice this question →

293

MCQhard

Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?

A.The package path is wrong; the zip file is in $(Build.ArtifactStagingDirectory).

B.The AzureWebApp task input 'appType' is incorrect.

C.The dotnet publish command did not generate a zip file.

D.The service connection 'MyServiceConnection' is not authorized.

AnswerA

The AzureWebApp task's `package` input is configured with an incorrect file path. The `dotnet publish` command, when run in a YAML pipeline, defaults to publishing the zip package into `$(Build.ArtifactStagingDirectory)`, not into a subfolder like `$(System.DefaultWorkingDirectory)/published` unless explicitly redirected. Because the package path does not point to that staging directory, the task fails with a 'file not found' or 'no package found' error before deployment can begin. Setting `package: '$(Build.ArtifactStagingDirectory)/**/*.zip'` resolves the issue by correctly referencing the output location.

Why this answer

The error 'Could not find the package in the specified path' indicates that the AzureWebApp task is looking for a deployment package (typically a .zip file) at a path that does not exist. In the exhibit, the `dotnet publish` command outputs to `$(Build.ArtifactStagingDirectory)`, but the subsequent AzureWebApp task likely references a different path (e.g., `$(System.DefaultWorkingDirectory)` or a hardcoded path). The correct path should be `$(Build.ArtifactStagingDirectory)/**/*.zip` to match the published artifact.

Option A correctly identifies this path mismatch as the root cause.

Exam trap

The trap here is that candidates often assume the error is due to a missing zip file (Option C) or a misconfigured service connection (Option D), but the actual cause is a path variable mismatch between the publish output and the deployment task input.

How to eliminate wrong answers

Option B is wrong because the `appType` input (e.g., 'webApp' or 'webAppLinux') affects runtime stack selection but does not cause a 'package not found' error; it would instead cause a deployment failure related to incorrect app settings or runtime. Option C is wrong because the `dotnet publish` command with `--output $(Build.ArtifactStagingDirectory)` does generate a zip file (if configured) or at least the published output; the error is about the path, not the absence of a zip. Option D is wrong because an unauthorized service connection would result in an authentication/authorization error (e.g., 401 or 403), not a 'package not found' error, which is a file system issue.

Practice this question →

294

MCQhard

Refer to the exhibit. A build pipeline produces the above logs. Which change would resolve the build failure?

A.Change the build configuration from Release to Debug.

B.Add a definition for 'MyMethod' in the 'MyClass' class.

C.Remove the '--no-build' flag from the test step.

D.Add the '--no-restore' flag to the build step.

AnswerB

The build error is a CS1061 compilation error: the C# compiler cannot find a member named 'MyMethod' on the type 'MyClass'. This means the calling code references a method that is not declared anywhere in the class definition. Adding a method with the exact name 'MyMethod' and a compatible signature (parameter list and return type) to the 'MyClass' class is the only way to satisfy the compiler. Without this addition, any downstream steps (like tests) will have no valid assembly to run.

Why this answer

The build failure is caused by a missing method definition. The logs indicate that the test step is attempting to invoke 'MyMethod' on an instance of 'MyClass', but the compiler cannot find it. Adding the missing method to the class resolves the compilation error, which is the root cause of the pipeline failure.

Exam trap

The trap here is that candidates may focus on build flags like '--no-build' or configuration settings, overlooking the actual compilation error message that clearly indicates a missing method definition.

How to eliminate wrong answers

Option A is wrong because switching from Release to Debug configuration does not fix a missing method; it only changes optimization and debug symbols. Option C is wrong because removing the '--no-build' flag would force a rebuild before tests, but the failure is a compilation error in the test project itself, not a stale build artifact. Option D is wrong because adding '--no-restore' skips NuGet package restore, which would likely cause additional dependency errors and does not address the missing method definition.

Practice this question →

295

MCQmedium

Refer to the exhibit. You have a YAML pipeline that references a repository resource with a tag. When will this pipeline trigger?

A.When a new tag v1.0 is pushed to the referenced repository.

B.When changes are pushed to any branch of the referenced repository.

C.When changes are pushed to the main branch of the current repository.

D.The pipeline will never trigger because no trigger is defined.

AnswerC

The YAML pipeline defines a branch trigger with `branches.include: main` for the current repository, so any push to the main branch of that repository will automatically start the pipeline. This is the standard CI trigger behavior in Azure Pipelines.

Why this answer

By default, a YAML pipeline triggers on changes to the main branch of the repository where the pipeline definition resides, even when a repository resource with a tag is referenced. The tag in the repository resource only controls which version of the resource is used at runtime, not the trigger behavior. Without an explicit trigger section, the pipeline uses the default CI trigger on the main branch of the self-repo.

Exam trap

The trap here is that candidates assume a referenced repository resource with a tag will automatically trigger the pipeline on tag pushes, but Azure Pipelines does not trigger on resource changes unless a pipeline resource trigger is explicitly configured.

How to eliminate wrong answers

Option A is wrong because a tag push to the referenced repository does not trigger the pipeline unless a trigger is explicitly defined for tags (e.g., using `trigger: tags: include: ['v1.0']`). Option B is wrong because changes to any branch of the referenced repository do not trigger the pipeline; only changes to the main branch of the current repository trigger it by default. Option D is wrong because a default CI trigger exists for the main branch of the current repository when no trigger is defined, so the pipeline will trigger on pushes to that branch.

Practice this question →

296

MCQeasy

Your Azure DevOps pipeline uses a YAML template that defines variables. You want to override a variable value when running the pipeline manually. What is the best approach?

A.Create a variable group and link it to the pipeline.

B.Edit the template YAML file to hardcode the desired value.

C.Use the 'Variables' tab in the pipeline run UI to set a new value for the variable.

D.Define a parameter in the template and pass the value via the 'Override' parameter in the pipeline.

AnswerC

The pipeline run UI's Variables tab provides a runtime override mechanism specifically designed for this scenario: when you start a manual run, you can expand the 'Variables' section and enter a new value for a YAML-defined variable, and that value is used for that run only without modifying the repository. This works because YAML variables are evaluated at runtime (after the pipeline is triggered), so the override seamlessly replaces the default value defined in the template or pipeline. Crucially, this approach requires zero changes to version-controlled files and leaves the pipeline definition untouched, making it the intended, non-invasive method for ad-hoc manual overrides.

Why this answer

Azure Pipelines allows you to override the value of a YAML-defined variable directly in the pipeline run UI via the 'Variables' tab when manually triggering a run. This approach is the simplest and most flexible way to change a variable's value without modifying the YAML template or pipeline definition, and it supports runtime parameterization for manual runs.

Exam trap

The trap here is that candidates often confuse variables with parameters, assuming that parameters are the only way to pass values at runtime, but Azure Pipelines explicitly supports overriding YAML-defined variables via the UI without needing to convert them to parameters.

How to eliminate wrong answers

Option A is wrong because variable groups are used to manage sets of variables across pipelines, but they cannot override a variable already defined in a YAML template at runtime; they are linked at queue time and have lower precedence than variables set in the UI. Option B is wrong because hardcoding a value in the template YAML file defeats the purpose of dynamic override and requires a commit to the repository, which is not a runtime override mechanism. Option D is wrong because while parameters can be used to pass values into templates, there is no 'Override' parameter in Azure Pipelines; the correct way to pass a parameter value is via the pipeline run UI's 'Parameters' section (if defined as a parameter), but the question specifically asks about overriding a variable, not a parameter.

Practice this question →

297

MCQeasy

You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?

A.UseDotNet@2

B.NuGetToolInstaller@1

C.DotNetCoreCLI@2

D.PowerShell@2

AnswerA

UseDotNet@2 is the correct task because it explicitly installs a specified .NET Core/.NET SDK version on the build agent, making that SDK available for subsequent pipeline steps. It can also read a global.json to select the exact SDK version, ensuring the pipeline uses the intended toolset.

Why this answer

The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.

Exam trap

The trap here is that candidates often confuse DotNetCoreCLI@2 (which runs .NET commands) with UseDotNet@2 (which installs the SDK), assuming the build task itself can set the SDK version, but DotNetCoreCLI@2 only uses whatever SDK is already available.

Why the other options are wrong

This installs NuGet, not the .NET SDK.

This runs .NET commands but does not install a specific SDK version.

PowerShell can install SDK but it's not the built-in task for this purpose.

Practice this question →

298

MCQhard

You are designing a build pipeline that must run on Microsoft-hosted agents. The pipeline has a dependency on a native library that is not pre-installed. You want to minimize pipeline duration. Which approach should you use?

A.Use a container job with a custom Docker image that includes the library

B.Use a self-hosted agent with the library pre-installed

C.Add a script step to install the library using a package manager

D.Download the library from Azure Blob Storage in each build

AnswerA

Using a container job with a custom Docker image that includes the library allows the pipeline to run on Microsoft-hosted agents while avoiding the time needed to install the library in each run. This minimizes pipeline duration and meets the requirement.

Why this answer

Using a container job with a custom Docker image that includes the native library allows the pipeline to run on Microsoft-hosted agents while eliminating installation overhead, thus minimizing pipeline duration. This approach meets the requirement of using Microsoft-hosted agents and avoids the time cost of installing the library in each run.

Exam trap

Candidates may think self-hosted agents are required for pre-installed dependencies, but container jobs on Microsoft-hosted agents achieve the same benefit with less management overhead and still meet the requirement.

How to eliminate wrong answers

Option A is wrong because container jobs with custom Docker images still require pulling the image on each run, which adds significant time and does not leverage the pre-installed nature of a self-hosted agent. Option C is wrong because adding a script step to install the library using a package manager incurs runtime installation overhead, increasing pipeline duration. Option D is wrong because downloading the library from Azure Blob Storage in each build adds network transfer time and does not avoid the installation step, thus not minimizing duration.

Practice this question →

299

MCQeasy

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?

A.$(System.JobId)

B.$(System.TeamProject)

C.$(Build.BuildNumber)

D.$(Build.BuildId)

AnswerC

Build.BuildNumber is a human-readable, configurable build name that often includes non-alphanumeric characters like colons, dashes, or custom text. Docker tags must be lowercase alphanumeric and may contain only periods, underscores, and hyphens, so directly using BuildNumber risks invalid tags that fail the build unless the value is sanitized.

Why this answer

The `$(Build.BuildNumber)` variable represents the build number, which is the name of the completed build. It's often customized to include versioning information, and it's the appropriate variable to use when tagging Docker images based on the build number. `$(Build.BuildId)` is a unique numeric ID for the build record, but it is not the build number.

Exam trap

Candidates may confuse `Build.BuildNumber` (the human-readable build name) with `Build.BuildId` (the internal numeric ID). The stem explicitly says 'based on the build number', so `Build.BuildNumber` is the correct choice.

How to eliminate wrong answers

Option A is wrong because `$(System.JobId)` is a unique identifier for a specific job run within a pipeline, not the overall build number, and is not intended for image tagging. Option B is wrong because `$(System.TeamProject)` contains the name of the Azure DevOps project, which is static and does not provide a unique or incrementing value for tagging. Option C is wrong because `$(Build.BuildNumber)` is a user-defined or default formatted string (e.g., '20250401.1') that can contain non-numeric characters and is not guaranteed to be strictly incrementing or unique across parallel builds, making it less reliable for Docker tags than the integer `$(Build.BuildId)`.

Practice this question →

300

MCQmedium

You are designing a pipeline to build a .NET Core application. The build must run unit tests and publish code coverage results. Which task should you use to publish the code coverage results to Azure DevOps?

A.Use the 'PublishCodeCoverageResults@1' task.

B.Use the 'PublishTestResults@2' task.

C.Use the 'DotNetCoreCLI@2' task with the 'test' command.

D.Use the 'VSTest@2' task with the 'codeCoverageEnabled' option.

AnswerA

The PublishCodeCoverageResults@1 task is the dedicated Azure DevOps task for publishing code coverage data generated by test runs to the pipeline UI and build summary. It accepts coverage files in formats like Cobertura or JaCoCo, making it the correct choice for publishing .NET Core coverage reports.

Why this answer

The 'PublishCodeCoverageResults@1' task is the correct choice because it is specifically designed to publish code coverage results (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps, making them visible in the build summary and pipeline artifacts. This task consumes the coverage data file generated by a previous test run (e.g., via 'DotNetCoreCLI@2' with '--collect "Code Coverage"') and uploads it to the Azure DevOps service for reporting.

Exam trap

The trap here is that candidates confuse the task that runs tests with coverage collection (e.g., VSTest@2 or DotNetCoreCLI@2) for the task that publishes the coverage results, forgetting that publishing is a separate, explicit step required to surface the data in Azure DevOps.

How to eliminate wrong answers

Option B is wrong because 'PublishTestResults@2' publishes test pass/fail results (e.g., TRX, JUnit XML) to the Tests tab, not code coverage data. Option C is wrong because 'DotNetCoreCLI@2' with the 'test' command runs tests and can collect coverage data (e.g., via Coverlet), but it does not publish the coverage results to Azure DevOps; a separate publish task is required. Option D is wrong because 'VSTest@2' with 'codeCoverageEnabled' runs tests with coverage instrumentation (using the Visual Studio coverage engine), but it does not publish the results; the coverage data must still be published using a dedicated task like 'PublishCodeCoverageResults@1'.

Practice this question →