CCNA Design and implement build and release pipelines Questions — Page 4 of 6

226

MCQhard

You are implementing a build pipeline for a .NET application that uses GitHub Advanced Security (GHAS) for code scanning. The pipeline must run CodeQL analysis on every pull request to the main branch. You have added the CodeQL task to the pipeline. However, the analysis results are not appearing in the 'Security' tab of the repository on GitHub. What is the most likely cause?

A.The pipeline is missing the 'Publish Security Analysis Logs' step to upload SARIF results to GitHub.

B.The GitHub repository is private, so security alerts are disabled.

C.The .NET project is not supported by CodeQL.

D.CodeQL analysis is not supported on pull request triggers.

AnswerA

In Azure DevOps, CodeQL results are produced as SARIF files, but they do not automatically appear in the GitHub Security tab. You must explicitly include the 'Publish Security Analysis Logs' task (or equivalent) to upload those SARIF logs to GitHub, which is what enables the findings to be displayed in the security alerts. Without this step, the analysis may run but the results are never surfaced.

Why this answer

CodeQL analysis results are uploaded to GitHub as SARIF files. Without the 'Publish Security Analysis Logs' step (or the equivalent 'upload-sarif' action), the SARIF file generated by CodeQL is not sent to GitHub, so the findings never appear in the Security tab. The pipeline must explicitly include this step to complete the integration with GitHub Advanced Security.

Exam trap

The trap here is that candidates assume adding the CodeQL analysis task alone is sufficient, overlooking the mandatory SARIF upload step that bridges the analysis output to GitHub's security dashboard.

How to eliminate wrong answers

Option B is wrong because GitHub Advanced Security and security alerts are fully supported on private repositories; the repository's visibility does not block results from appearing. Option C is wrong because CodeQL supports .NET (including C#, VB.NET, and F#) via the standard CodeQL queries; .NET is a first-class supported language. Option D is wrong because CodeQL analysis is explicitly supported on pull request triggers; the issue is not the trigger but the missing upload step.

Practice this question →

227

Multi-Selecteasy

Which TWO triggers can start a release in Azure Pipelines?

Select 2 answers

A.Continuous integration

B.Schedule

C.Build completion

D.Work item state change

E.Pull request

AnswersB, C

A schedule trigger starts a release at a specified time.

Why this answer

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

Exam trap

The trap here is that candidates confuse triggers that apply to build pipelines (CI, PR) with those that apply to release pipelines, leading them to select 'Continuous integration' or 'Pull request' as valid release triggers.

Practice this question →

228

MCQeasy

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

A.on: push: branches: [main]

B.on: pull_request: branches: [main]

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

D.on: schedule: cron: '0 0 * * *'

AnswerA

This trigger fires the workflow automatically on every push to the main branch. The branch filter ensures that only commits pushed to main start the CI pipeline, so builds and tests run on the intended integration branch while ignoring feature branches.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `pull_request` triggers with `push` triggers, thinking a PR merge to `main` counts as a push, but `pull_request` triggers on PR lifecycle events (like `opened` or `synchronize`), not the merge commit itself, which would require a `push` trigger on `main`.

How to eliminate wrong answers

Option B is wrong because `on: pull_request: branches: [main]` triggers the workflow on pull request events (opened, synchronized, etc.) targeting `main`, not on direct pushes; this would run the workflow in the context of a PR, not a production deployment, and could lead to unintended executions during code review. Option C is wrong because `workflow_dispatch` allows manual triggering from the GitHub UI or API with a branch input, but it does not restrict execution to specific branches by default—any user with write access can select any branch, violating the requirement for branch-specific restriction. Option D is wrong because `on: schedule: cron: '0 0 * * *'` triggers the workflow on a time-based schedule (daily at midnight), which is unrelated to branch-based triggers and would not enforce branch restrictions at all.

Practice this question →

229

MCQhard

You are configuring a branch policy for the main branch using the Azure DevOps REST API. The JSON above is the policy configuration. A developer pushes a new commit to an existing pull request. What happens to the existing approvals?

A.The existing approvals remain valid.

B.The policy blocks the push until re-reviewed.

C.The pull request is automatically rejected.

D.All existing approvals are reset.

AnswerA

Correct: resetOnPush: false means approvals are not reset.

Why this answer

By default, Azure DevOps branch policies do not automatically reset approvals when a new commit is pushed to a pull request. The policy configuration shown includes the 'resetOnPush' property set to false (or it is not enabled), which means existing approvals remain valid even after new commits are pushed. Only if 'resetOnPush' is explicitly set to true would approvals be invalidated.

Exam trap

The trap here is that candidates often assume any new commit to a pull request automatically resets approvals, but Azure DevOps requires explicit configuration (the 'resetOnPush' property) to enable that behavior.

How to eliminate wrong answers

Option B is wrong because the policy does not block the push; Azure DevOps allows pushes to pull requests by default, and only blocks them if a 'Require a minimum number of reviewers' policy with 'Reset on push' is enabled. Option C is wrong because the pull request is not automatically rejected; rejection only occurs if the policy explicitly requires re-approval after a push, which is not configured here. Option D is wrong because approvals are not reset unless the policy configuration includes the 'resetOnPush' property set to true; without it, existing approvals persist.

Practice this question →

230

MCQmedium

Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?

A.The pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.

B.The service connection lacks permission to access the web app.

C.The web app is configured with a Windows runtime stack.

D.The build output does not include the web.config file.

AnswerA

On Linux-based Azure App Service, the runtime is containerized and requires an explicit entry point to start the application. The AzureWebApp@1 task (or AzureWebAppContainer@1 when deploying a container) exposes a StartupCommand parameter that injects this command (for example, `pm2 start /home/site/wwwroot/server.js`) into the App Service configuration. Without that parameter, the platform falls back to a default command that may not exist, producing the exact error about a missing startup command. The fix is to add the task with the appropriate StartupCommand, or to configure the startup command in the app's Application settings.

Why this answer

The Kudu service on Linux web apps requires a startup command to launch the .NET Core application. The 'AzureWebApp@1' task's 'StartupCommand' parameter specifies this command (e.g., 'dotnet myapp.dll'). Without it, Kudu cannot start the process, causing the deployment failure.

Exam trap

The trap here is that candidates might think the issue is a missing web.config file (common for Windows deployments) or a permission problem, but on Linux, the startup command is the critical missing piece, not a configuration file.

How to eliminate wrong answers

Option B is wrong because a permission issue would typically cause an authorization error (e.g., 403) during deployment, not a Kudu startup failure. Option C is wrong because the error explicitly occurs on a Linux web app; a Windows runtime stack would not cause a missing startup command error on Linux. Option D is wrong because .NET Core applications on Linux do not require a web.config file; they rely on a startup command or a process file (e.g., 'server.js' for Node.js) to start.

Practice this question →

231

MCQhard

Your organization uses a monorepo in Azure Repos containing multiple microservices. You need to design a build pipeline that only builds and tests the services that have changed in a given commit, to optimize build times. The pipeline must trigger on any push to any branch, but only the affected services should be built. You also need to ensure that dependent services are rebuilt if their dependencies change. The services are located in subdirectories: /services/serviceA, /services/serviceB, etc. Each service has a Dockerfile and a unit test project. You plan to use a script to determine which services changed. Which approach should you use to implement this pipeline?

A.Use a script step to determine which services changed, then output variables to dynamically create a job matrix or use the 'each' keyword to iterate over changed services.

B.Create a multi-stage pipeline where each stage represents a service, and use a 'dependsOn' condition to run stages only if the corresponding service changed.

C.Create a single job that runs all unit tests for all services on every commit. Use caching to speed up the build.

D.Create a job for each service that runs in parallel on every commit. Use conditions to skip jobs if the service has not changed, but the conditions would need to check every service, which is complex.

AnswerA

A script step can run `git diff` against the previous commit or merge target to identify which services changed, then set output variables such as `ChangedServices=true,false`. The pipeline can later use these variables with YAML's `matrix` strategy or the `each` directive in template expressions to dynamically generate one job per changed service, ensuring only affected services are built and tested while keeping the pipeline fully data-driven and scalable.

Why this answer

Use a script to determine which services changed, then output variables to dynamically create a job matrix. This satisfies the requirement to only build affected services and handle dependency rebuilding if the script includes dependency detection. Option B is wrong because it requires a stage for every service upfront and is less dynamic.

Option C is wrong because it does not optimize build times. Option D is wrong because it creates all jobs and uses complex conditions to skip unchanged services.

Practice this question →

232

MCQhard

Refer to the exhibit. A build pipeline fails at the 'Publish Artifact' step. The pipeline has two jobs: 'Build' and 'Test'. Both jobs have a 'PublishBuildArtifacts' task with artifact name 'drop'. What is the most likely cause?

A.The artifact name 'drop' contains invalid characters.

B.The artifact is too large to publish.

C.Two jobs are publishing artifacts with the same name.

D.The pipeline does not have permission to publish artifacts.

AnswerC

When two or more jobs in the same pipeline publish artifacts with an identical artifact name, the Azure DevOps PublishPipelineArtifact task fails because artifact names must be unique within the entire pipeline run. The second job's attempt to publish 'drop' conflicts with the first job's already published artifact, causing the build to fail.

Why this answer

Artifact names must be unique within a build. Both jobs publish with the same name 'drop', causing a conflict.

Practice this question →

233

MCQeasy

You need to create a build pipeline that runs on a Microsoft-hosted agent. You want to use the latest Ubuntu image. Which YAML snippet should you use?

A.pool: vmImage: 'ubuntu-latest'

B.pool: name: 'ubuntu-latest'

C.agent: vmImage: 'ubuntu-latest'

D.resources: vmImage: 'ubuntu-latest'

AnswerA

In Azure Pipelines YAML, the `pool` keyword defines the execution agent, and for Microsoft-hosted agents you must specify the VM image using the `vmImage` property. `'ubuntu-latest'` is a valid alias that resolves to the current stable Ubuntu LTS image, so this is the correct syntax.

Why this answer

In Azure Pipelines YAML, the `pool` keyword is used to specify the agent pool, and `vmImage` is a sub-property that defines the virtual machine image for Microsoft-hosted agents. Setting `vmImage: 'ubuntu-latest'` within the `pool` section selects the latest Ubuntu LTS image provided by Microsoft, ensuring the build runs on a current, maintained environment.

Exam trap

The trap here is that candidates confuse the `pool.name` property (used for self-hosted agents) with `pool.vmImage` (used for Microsoft-hosted agents), leading them to select option B, or they mistakenly use `agent` or `resources` as top-level keys for specifying the VM image.

Why the other options are wrong

The 'name' property is for agent pools, not VM images.

'agent' is not a valid top-level key; use 'pool'.

Resources are for external resources, not agent specification.

Practice this question →

234

Multi-Selectmedium

Which TWO are valid ways to pass build artifacts from one stage to another in a multi-stage YAML pipeline in Azure Pipelines?

Select 2 answers

A.Use the Pipeline Artifact task to publish artifacts, which are automatically available to subsequent stages without download.

B.Use the Publish Pipeline Artifact task in the first stage and Download Pipeline Artifact task in the second stage.

C.Use the Publish Build Artifacts task and then the Download Build Artifacts task.

D.Use the Copy Files task to copy artifacts to a shared network drive.

E.Define variables in the first stage and reference them in the second stage.

AnswersB, D

Correct. The Publish Pipeline Artifact task in the first stage publishes artifacts, and the Download Pipeline Artifact task in the second stage retrieves them. This is the standard and recommended method.

Why this answer

The Publish Pipeline Artifact task in the first stage makes the artifact available to the pipeline, and the Download Pipeline Artifact task in the second stage explicitly retrieves it. This is the standard, supported method for passing artifacts between stages in a multi-stage YAML pipeline. Option D is also correct because the Copy Files task can copy artifacts to a shared network drive accessible by subsequent stages, which is a valid alternative method.

Options A and C are incorrect: A is wrong because published pipeline artifacts are not automatically available without a download task; C is wrong because the Publish/Download Build Artifacts tasks are legacy and not the recommended way for multi-stage YAML pipelines, and they do not work seamlessly across stages without additional configuration.

Exam trap

The trap here is that candidates often confuse the legacy Build Artifacts tasks (Publish/Download Build Artifacts) with the modern Pipeline Artifact tasks, or assume that variables can pass complex build outputs between stages, when in fact only artifacts provide a reliable, cross-stage file transfer mechanism.

Practice this question →

235

MCQmedium

Your team uses a multi-stage YAML pipeline. The 'Build' stage compiles the code and runs unit tests. The 'Deploy' stage deploys to a staging environment. You notice that if the 'Build' stage fails, the 'Deploy' stage still starts because it depends on a condition that always evaluates to true. How should you modify the pipeline to prevent the 'Deploy' stage from running if the 'Build' stage fails?

A.Add 'condition: succeeded()' to the Deploy stage.

B.Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.

C.Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.

D.Add 'dependsOn: Build' to the Deploy stage.

AnswerA

The 'succeeded()' function is a predefined pipeline expression that evaluates to true only if all prior stages and jobs in the pipeline have completed successfully, so adding 'condition: succeeded()' to the Deploy stage ensures it runs only after the Build stage succeeds, which is exactly the desired behavior.

Why this answer

The `succeeded()` function in Azure Pipelines evaluates whether all previous stages (or jobs, depending on context) have completed successfully. By adding `condition: succeeded()` to the Deploy stage, the stage will only run if the Build stage (its implicit or explicit dependency) succeeded. This directly prevents the Deploy stage from starting when the Build stage fails.

Exam trap

The trap here is that candidates often think `dependsOn` alone enforces success, but it only sets the dependency order; without an explicit `condition: succeeded()`, a custom condition that always evaluates to true will still trigger the stage regardless of the dependency's status.

How to eliminate wrong answers

Option B is wrong because `variables['Build.Succeeded']` is not a predefined variable in Azure Pipelines; the correct variable is `Agent.JobStatus` or you must use the `succeeded()` function. Option C is wrong because it combines an invalid variable reference with `succeeded()`, which is redundant and still relies on a non-existent variable. Option D is wrong because adding `dependsOn: Build` only establishes the dependency order but does not enforce a success condition; without an explicit condition, the Deploy stage will still run even if the Build stage fails, as the default condition is `succeeded()` only when `dependsOn` is used without a custom condition—but here the question states a condition that always evaluates to true overrides that default, so `dependsOn` alone is insufficient.

Practice this question →

236

Multi-Selecthard

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Select 3 answers

A.Inline secret variables defined in the YAML file

B.Secret variables defined in the pipeline UI

C.Azure Key Vault task to fetch secrets at runtime

D.Variable groups linked to Azure Key Vault

E.Environment variables set on the build agent

AnswersB, C, D

Secret variables defined in the pipeline UI are stored encrypted in Azure DevOps and automatically masked in all logs, ensuring they are never exposed during the build or release execution. They can be scoped to the pipeline run and are the recommended way to handle non-Key Vault secrets.

Why this answer

Secret variables defined in the pipeline UI (B) are encrypted at rest and masked in logs, preventing exposure in source control. The Azure Key Vault task (C) retrieves secrets from Azure Key Vault at runtime, avoiding storage in Azure DevOps. Variable groups linked to Azure Key Vault (D) allow you to reference Key Vault secrets directly as pipeline variables, keeping them out of YAML and providing centralized access control.

All three approaches ensure secrets are not stored in plaintext in repositories or pipeline definitions.

Exam trap

The trap here is that candidates may think inline YAML secrets (Option A) are secure because they are marked as 'secret' in the YAML, but they are still stored in plaintext in the repository, which is a common security misconception.

Practice this question →

237

Multi-Selecthard

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Select 3 answers

A.The approver must be an individual user, not a group.

B.The approval must be configured in the release pipeline's pre-deployment conditions.

C.The approver must have the 'Approve pipeline permissions' permission for the environment.

D.The pipeline must be a Release Pipeline or a YAML pipeline that uses the 'environment' resource.

E.You must create an environment in Azure Pipelines and add an approval check to it.

AnswersC, D, E

To successfully approve a deployment to an environment, the designated approver must have the 'Approve pipeline permissions' permission on that environment. This permission is managed through the environment's security settings and is separate from permissions like 'View' or 'Manage'. Without this permission, even if a user is listed as an approver, they will not be able to approve the deployment.

Why this answer

The 'Approvals' feature in Azure Pipelines requires an environment to be defined in the pipeline. You must add an approval check to that environment, which can be done in either a classic release pipeline or a YAML pipeline that references the environment as a resource. Additionally, the approver(s) - whether individual users or groups - must have the 'Approve pipeline permissions' permission on that environment.

Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Exam trap

The trap here is that candidates often assume approvals must be configured in the release pipeline's pre-deployment conditions only, but Azure Pipelines also supports approvals in post-deployment conditions and as environment-level checks in YAML pipelines, making option B a common distractor.

Practice this question →

238

MCQeasy

Your team uses Azure Pipelines for CI/CD. The pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that only the main branch triggers a build of the Docker image. What should you configure in the pipeline YAML?

A.Set 'pr: branches: include: - main'

B.Add a condition: 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' to the job.

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

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

AnswerD

Setting `trigger: branches: include: - main` defines the CI trigger to fire only on commits pushed to the `main` branch. This ensures that pushes to feature or other branches do not create pipeline runs, while any commit to `main` correctly starts a new CI build, satisfying the requirement to restrict builds to the main branch.

Why this answer

Setting `trigger: branches: include: - main` in the pipeline YAML configures a CI trigger that only starts a new pipeline run when changes are pushed to the `main` branch. This ensures that the Docker image build and push to ACR occurs exclusively for the main branch, meeting the requirement.

Exam trap

The trap here is that candidates often confuse CI triggers (`trigger`) with PR triggers (`pr`) or try to use job-level conditions to filter branches, not realizing that conditions only skip job execution but still trigger the pipeline, wasting resources and potentially causing unintended side effects like failed runs or unnecessary ACR pushes.

How to eliminate wrong answers

Option A is wrong because `pr: branches: include: - main` configures a pull request (PR) trigger, not a CI build trigger; it would cause the pipeline to run when a PR targets main, not when code is pushed directly to main. Option B is wrong because adding a condition like `eq(variables['Build.SourceBranch'], 'refs/heads/main')` to a job would still allow the pipeline to be triggered by any branch, but the job would be skipped for non-main branches; this does not prevent the pipeline from being triggered at all, which is inefficient and does not meet the requirement to 'only trigger a build' on main. Option C is wrong because `trigger: branches: include: - *` uses a wildcard that includes all branches, which would trigger the pipeline on every push to any branch, not just main.

Practice this question →

239

MCQmedium

You are configuring a multi-stage YAML pipeline that builds a .NET Core application and deploys it to Azure Kubernetes Service (AKS). The build stage produces a container image that is pushed to Azure Container Registry (ACR). The deploy stage needs to use the image from ACR. How should you pass the image tag from the build stage to the deploy stage?

A.Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.

B.Define a pipeline variable at the top level and set it in the build stage.

C.Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.

D.Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.

AnswerC

Output variables are the intended mechanism for sharing a value between stages: a job in the build stage sets the variable with `task.setvariable` and `isoutput=true`, making it available in the job's output context. A subsequent stage's job can then retrieve that exact value at runtime using the syntax `$[stageDependencies.buildStage.buildJob.outputs['imageTag']]` in a variable definition, condition, or argument. This guarantees the consuming stage receives the precise tag produced by the build, independent of ordering or naming conventions, and avoids the overhead of publishing artifacts for a single string value.

Why this answer

Azure DevOps supports cross-stage output variables, allowing a job in the build stage to set a variable (e.g., imageTag) that can be consumed in the deploy stage using the stageDependencies syntax. This avoids the overhead of artifacts or external queries and ensures the exact tag produced during the build is used in deployment.

Exam trap

The trap here is that candidates often assume artifacts are the only way to pass data between stages, overlooking the built-in cross-stage variable feature that is more efficient and purpose-built for this scenario.

How to eliminate wrong answers

Option A is wrong because writing the image tag to a file and publishing it as a build artifact introduces unnecessary complexity and latency; artifacts are designed for binary files, not simple variable passing, and require extra steps to download and parse. Option B is wrong because pipeline variables defined at the top level are static and cannot be dynamically set by a stage; they are evaluated at pipeline start, not updated during execution. Option D is wrong because querying ACR for the latest image tag is unreliable—there may be multiple tags, race conditions, or no guarantee that the tag corresponds to the specific build just completed, leading to deployment of the wrong image.

Practice this question →

240

MCQhard

Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?

A.Migrate all workflows to GitHub-hosted runners.

B.Reduce the number of concurrent jobs in each workflow.

C.Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.

D.Increase the size of the existing self-hosted runner VMs to handle more jobs.

AnswerC

Implementing auto-scaling for self-hosted runners using a scale set or Kubernetes-based Actions Runner Controller dynamically matches runner count to job demand, provisioning new runners during peak times and scaling to zero when idle, which optimizes both latency and cost.

Why this answer

Auto-scaling self-hosted runners using a scale set or a Kubernetes-based runner controller (e.g., actions-runner-controller) dynamically provisions and deprovisions runner instances based on workflow demand. This eliminates idle runner waste while ensuring sufficient capacity during peak loads, directly addressing the bottleneck without adding permanent infrastructure.

Exam trap

The trap here is that candidates often confuse vertical scaling (increasing VM size) with horizontal scaling (adding more runner instances), mistakenly believing a larger VM can process multiple jobs concurrently when in fact each self-hosted runner handles only one job at a time.

How to eliminate wrong answers

Option A is wrong because migrating to GitHub-hosted runners may increase costs and does not leverage existing self-hosted infrastructure; it also does not solve the core issue of scaling capacity dynamically. Option B is wrong because reducing concurrent jobs limits parallelism and throughput, which would worsen performance rather than improve it. Option D is wrong because increasing VM size (vertical scaling) does not increase the number of concurrent jobs a runner can handle; a single runner processes one job at a time regardless of its size.

Practice this question →

241

MCQeasy

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

A.Increase the 'timeoutInMinutes' property in the pipeline YAML for the job.

B.Split the pipeline into multiple stages to reduce job duration.

C.Enable parallel jobs to run the pipeline faster.

D.Use a self-hosted agent with more CPU cores.

AnswerA

Increasing the timeoutInMinutes property in the pipeline YAML for the job extends the maximum allowed duration for the job, preventing Azure DevOps from cancelling it when it exceeds the default 60-minute limit. This directly addresses the intermittent timeout error by giving the job more time to complete. Note: for Microsoft-hosted agents, the max is 360 minutes, while self-hosted agents can use 0 for no limit.

Why this answer

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

Exam trap

The trap here is that candidates may confuse job timeout with pipeline performance, incorrectly assuming that optimizing speed (parallelism or faster agents) resolves a timeout error, when the actual fix is to adjust the timeout limit.

How to eliminate wrong answers

Option B is wrong because splitting the pipeline into multiple stages does not reduce the execution time of a single job; it only organizes the workflow, and each stage still runs within its own job timeout. Option C is wrong because enabling parallel jobs runs multiple jobs concurrently but does not affect the timeout of an individual job that exceeds 60 minutes. Option D is wrong because using a self-hosted agent with more CPU cores may improve performance but does not change the maximum execution time limit; the job would still fail if it runs longer than the default or configured timeout.

Practice this question →

242

Multi-Selectmedium

Which TWO are valid strategies for reducing build times in Azure Pipelines? (Choose two.)

Select 2 answers

A.Reduce the number of parallel jobs and increase the number of steps in a single job.

B.Remove unit tests from the build pipeline and run them only in the release pipeline.

C.Implement caching for package dependencies (e.g., npm, NuGet, Maven) to avoid restoring on every build.

D.Configure incremental builds by enabling 'Build in parallel' and using 'msbuild' or 'dotnet' build with appropriate flags to skip unchanged projects.

E.Increase the number of agents in the pool and run all jobs on the same agent.

AnswersC, D

Caching package dependencies avoids redundant network downloads of unchanged packages across pipeline runs, which is often the biggest time sink in a cold build. Use Azure Pipelines' Cache task or built-in caching (keyed on lockfiles) so restores are near-instant when dependencies haven't changed.

Why this answer

Caching package dependencies (e.g., npm, NuGet, Maven) avoids restoring them on every build, reducing download time. Incremental builds (e.g., using 'dotnet build --no-restore' with appropriate flags or MSBuild's incremental building) skip projects that haven't changed, reducing compilation time. Option A is incorrect because reducing parallel jobs and adding steps increases build time.

Option B is incorrect because removing unit tests compromises quality and is not a valid strategy. Option E is incorrect because increasing agents without parallelizing jobs or running all jobs on the same agent does not reduce build time.

Practice this question →

243

Multi-Selecteasy

Which TWO practices help you manage build artifacts efficiently in Azure Pipelines?

Select 2 answers

A.Set retention policies to automatically delete old artifacts

B.Copy artifacts to each agent's local storage

C.Download all artifacts manually after each build

D.Publish build artifacts using the Publish Build Artifacts task

E.Store artifacts as large single files to reduce number of files

AnswersA, D

Setting retention policies automatically prunes outdated build artifacts, preventing storage bloat and reducing costs without manual intervention. You can define branch-specific or pipeline-specific retention rules, and the system cleans up old runs and their associated artifacts while preserving recent or stable builds. This ensures storage remains manageable and aligns with governance and compliance requirements.

Why this answer

Setting retention policies (A) helps automate cleanup of old artifacts, reducing storage waste. Using the Publish Build Artifacts task (D) is the standard way to store artifacts from builds efficiently. Option B (copying to each agent) is wasteful because it duplicates artifacts unnecessarily.

Option C (manual download) is inefficient because it requires human intervention and does not scale. Option E (large single files) makes downloads and incremental updates difficult.

Practice this question →

244

MCQmedium

Your build pipeline runs on a self-hosted agent pool. You need to ensure that only authorized pipelines can use these agents. Which security measure should you implement?

A.Set permissions on the agent pool

B.Use agent tokens

C.Use variable groups

D.Configure agent queues

AnswerA

Set permissions on the agent pool to control which pipelines can queue jobs on that pool. In Azure Pipelines, agent pool security roles (Reader, User, Administrator) govern authorization at the pool level, so you can restrict a pipeline or project from using specific self-hosted agents by modifying these permissions.

Why this answer

Agent pool permissions allow restricting which pipelines can use the agents, ensuring only authorized pipelines can access the self-hosted agents. Option B (agent tokens) is for registering agents, not for authorizing pipelines. Option C (variable groups) is for storing variables and secrets, not for agent access control.

Option D (agent queues) is a legacy concept that does not provide granular pipeline-level permissions.

Practice this question →

245

MCQhard

Refer to the exhibit. An Azure CLI command outputs the configuration of an Azure Web App. Your pipeline deploys to this Web App using the 'AzureWebApp@1' task. The deployment fails with an error indicating that the runtime stack is not supported. What is the most likely cause?

A.The Web App is not a Linux app.

B.The ASPNETCORE_ENVIRONMENT setting is incorrect.

C.The runtime stack (DOTNETCORE|6.0) is not compatible with the deployed application.

D.The resource group name is incorrect.

AnswerC

If the application targets a different runtime version, the deployment fails.

Why this answer

The error 'runtime stack is not supported' indicates that the Azure Web App's configured runtime stack (DOTNETCORE|6.0) does not match the application being deployed. The AzureWebApp@1 task uses the Web App's stack setting to determine how to deploy and run the code; if the deployed app requires a different runtime (e.g., .NET 8.0 or a non-.NET framework), the deployment fails. Option C correctly identifies this mismatch as the root cause.

Exam trap

The trap here is that candidates often confuse runtime stack errors with environment variable misconfigurations (like ASPNETCORE_ENVIRONMENT) or OS-level issues, but the error message directly points to a mismatch between the Web App's configured stack and the deployed application's framework.

How to eliminate wrong answers

Option A is wrong because the runtime stack error is unrelated to whether the Web App is Linux or Windows; both platforms support runtime stack configurations, and the error specifically points to an unsupported stack, not the OS type. Option B is wrong because the ASPNETCORE_ENVIRONMENT setting controls the environment name (e.g., Development, Production) and does not affect runtime stack compatibility; it is an application-level configuration, not a deployment-level one. Option D is wrong because an incorrect resource group name would cause a different error (e.g., 'Resource group not found') during the task's initial resource lookup, not a runtime stack error during deployment.

Practice this question →

246

Multi-Selectmedium

Which TWO are true about Azure Pipelines YAML templates? (Choose two.)

Select 2 answers

A.Templates must be stored in the same repository as the main pipeline.

B.Template expressions are evaluated at compile time.

C.Templates require parameters to be defined.

D.Templates can be nested by including other templates.

E.Templates can only define a single job.

AnswersB, D

Expressions like '${{ variables.var }}' are expanded when the pipeline is compiled, before any runtime execution. This enables conditional inclusion of stages, jobs, or steps based on parameters or compile-time variables, but they cannot reference runtime values like agent-specific variables.

Why this answer

Template expressions in Azure Pipelines YAML are evaluated at compile time, before the pipeline runs. This allows the template to inject variables, conditions, and other logic into the pipeline definition statically, ensuring that the final pipeline structure is fully resolved before execution begins.

Exam trap

The trap here is that candidates often confuse compile-time evaluation with runtime evaluation, leading them to think template expressions can use runtime variables, or they mistakenly believe templates must be in the same repo or require parameters, when in fact templates are flexible and optional in their structure.

Practice this question →

247

MCQmedium

You need to implement a build retention policy that automatically deletes old builds after 30 days, but keeps the latest 5 builds regardless of age. Which configuration should you use?

A.Set 'Number of days to keep runs' to 30 and 'Number of runs to keep' to 5

B.Set 'Maximum retention policy' to 30 days and 'Number of builds to retain' to 5

C.Set 'Days to keep builds' to 30 and 'Minimum number of builds to keep' to 5

D.Set 'Number of days to keep artifacts' to 30 and 'Number of artifacts to keep' to 5

AnswerC

Deletes builds older than 30 days but keeps at least 5.

Why this answer

In Azure Pipelines, the 'Days to keep builds' and 'Minimum number of builds to keep' settings work together to enforce a retention policy that deletes builds older than 30 days while ensuring that at least the latest 5 builds are retained, even if they exceed the age limit. This configuration directly matches the requirement to delete old builds after 30 days but keep the latest 5 builds regardless of age.

Exam trap

The trap here is that candidates confuse the 'Minimum number of builds to keep' with a maximum limit, or they misremember the exact field names (e.g., 'Number of runs to keep' or 'Number of builds to retain'), leading them to select options that do not exist in the Azure DevOps UI.

How to eliminate wrong answers

Option A is wrong because 'Number of days to keep runs' and 'Number of runs to keep' are not valid retention policy fields in Azure Pipelines; the correct fields are 'Days to keep builds' and 'Minimum number of builds to keep'. Option B is wrong because 'Maximum retention policy' and 'Number of builds to retain' are not standard terms in Azure DevOps; the retention policy uses 'Days to keep builds' and 'Minimum number of builds to keep' to define the retention behavior. Option D is wrong because 'Number of days to keep artifacts' and 'Number of artifacts to keep' apply only to artifact retention, not to build pipeline runs, and do not control the deletion of old builds themselves.

Practice this question →

248

Multi-Selecthard

You are designing a release pipeline for a .NET Core application that must comply with regulatory requirements. The pipeline must sign the assembly with a code-signing certificate stored in Azure Key Vault. Which THREE actions should you perform?

Select 3 answers

A.Add a step to download the certificate from Key Vault using the AzureKeyVault task.

B.Use a script task to invoke the signing tool (e.g., signtool.exe) after the build.

C.Grant the Azure Pipelines service principal access to the Key Vault.

D.Store the certificate in a secure file in the build artifact.

E.Package the application before signing to avoid signature corruption.

AnswersA, B, C

The task retrieves the certificate securely.

Why this answer

The AzureKeyVault task can download the certificate from Azure Key Vault. Option B is correct because after downloading the certificate, a script task like signtool.exe must be used to sign the assembly. Option C is correct because the Azure Pipelines service principal must be granted access to the Key Vault to retrieve the certificate.

Option D is incorrect because the certificate should not be stored in a secure file in the build artifact; it should remain in Key Vault for security. Option E is incorrect because signing should occur before packaging; packaging after signing is typical to avoid corruption.

Practice this question →

249

MCQmedium

Your team uses Azure DevOps for CI/CD. You want to ensure that only code from the main branch is deployed to production. The release pipeline has a pre-deployment condition that requires approval. However, you notice that a release created from a feature branch was approved and deployed. What is the most likely cause?

A.The deployment queue settings were set to 'Deploy all in parallel'.

B.The pre-deployment condition did not include a branch filter on the artifact.

C.The artifact was published from a build pipeline that allowed any branch.

D.The pre-deployment condition was set to 'After release' instead of 'Before deployment'.

AnswerB

Branch filters must be configured on the artifact trigger or pre-deployment condition to restrict branches.

Why this answer

The pre-deployment condition in Azure DevOps release pipelines can include a branch filter on the artifact to restrict which branches trigger a release. If this filter is not configured, any release—regardless of the source branch—can proceed through the approval gate. Since the feature branch release was approved and deployed, the most likely cause is that the pre-deployment condition lacked a branch filter to enforce that only artifacts from the main branch are eligible.

Exam trap

The trap here is that candidates often assume that requiring approval alone is sufficient to control which branches are deployed, but Azure DevOps separates branch filtering from the approval gate, so without an explicit artifact branch filter, any branch can be approved and deployed.

How to eliminate wrong answers

Option A is wrong because 'Deploy all in parallel' controls how multiple pending releases are deployed simultaneously, not which branches are allowed to trigger a release. Option C is wrong because the artifact source branch is determined by the build pipeline's trigger or manual run, but the release pipeline's pre-deployment condition is where branch filtering should be enforced; allowing any branch in the build pipeline does not bypass the release gate if the filter is set. Option D is wrong because 'After release' vs 'Before deployment' refers to the timing of the approval gate relative to the deployment stage, not to branch filtering; setting it to 'After release' would still not prevent a feature branch release from being approved.

Practice this question →

250

MCQeasy

You are designing a build pipeline for a Python application that uses multiple external packages from PyPI. You want to ensure that builds are reproducible and not affected by package updates. Which strategy should you use?

A.Use a Pipfile and Pipfile.lock without version pinning.

B.Use a dependency update tool like Dependabot weekly.

C.Pin exact versions in requirements.txt.

D.Use 'pip install <package>' without version specifiers.

AnswerC

Pinning exact versions in requirements.txt using `==` (e.g., `package==1.2.3`) forces pip to install the same version every time, regardless of when or where the install runs. This makes the build deterministic, ensuring that all environments—development, CI, and production—use the exact same library versions, which is the core requirement for reproducible builds.

Why this answer

Pinning exact versions in requirements.txt ensures that the same package versions are installed every time, making builds reproducible. Option A is wrong because while Pipfile.lock contains exact resolved versions, the Pipfile itself typically uses version ranges; if the lock file is regenerated (e.g., via 'pipenv lock'), it may resolve to different package versions, breaking reproducibility. Option B is wrong: Dependabot is a tool for automated dependency updates, which introduces version changes and thus breaks reproducibility.

Option D is wrong because 'pip install <package>' without version specifiers fetches the latest version, causing non-deterministic builds.

Exam trap

A common trap is assuming that using a Pipfile.lock guarantees reproducibility. While Pipfile.lock does contain exact resolved versions, the Pipfile itself may specify version ranges, and if the lock file is regenerated (e.g., via 'pipenv lock'), it could resolve to different versions if the range allows updates. For true reproducibility, pinning exact versions in requirements.txt is more robust.

Practice this question →

251

MCQmedium

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

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

B.Use a composite action to encapsulate the build steps

C.Create a custom action and reference it in multiple workflows

D.Define a reusable workflow with 'on: workflow_call'

AnswerD

Defining a reusable workflow with on: workflow_call is correct because it makes the workflow callable from other workflows using the uses: syntax (e.g., uses: ./.github/workflows/build.yml), allowing you to create a standard build pipeline that can be referenced by many workflows without duplicating job definitions.

Why this answer

Reusable workflows are defined in a separate file with workflow_call trigger. Option A is wrong because it defines a workflow that cannot be reused. Option B is wrong because actions are different from workflows.

Option C is wrong because composite actions are for multiple steps, not entire workflows.

Practice this question →

252

MCQmedium

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

A.Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

B.Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

C.Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.

D.Use the same config file for all environments and override settings using pipeline variables based on branch name.

AnswerC

App Service configuration handles non-secrets, variable groups for secrets, and token replacement for environment values.

Why this answer

The recommended approach is to store environment-specific settings (non-secret) in Azure App Service configuration settings, and store secrets in Azure Pipelines variable groups. During deployment, use token replacement in the config file to replace placeholders with actual values. This ensures secrets are not exposed in logs or stored in the repository, and supports local development by using config transforms.

Option A exposes secrets by storing them in the repository. Option B uses a single config file and sticky settings, which does not address environment-specific configurations and can be insecure. Option D relies on branch-based pipeline variables, which may not support local development and can lead to secrets exposure in logs if not properly handled.

Practice this question →

253

MCQhard

You are implementing a release pipeline for a containerized application using Azure Kubernetes Service (AKS). The pipeline should use canary deployments to gradually shift traffic from the stable version to the new version. Which strategy should you use to manage the traffic shift?

A.Blue-green deployment strategy

B.Rolling update strategy

C.A/B testing with feature flags

D.Canary deployment using a service mesh (e.g., Istio)

AnswerD

Canary deployment using a service mesh (e.g., Istio) is correct because Istio's traffic management rules (VirtualService and DestinationRule) allow precise percentage-based traffic splitting between the stable and canary versions of a containerized workload. This enables gradual exposure, real-time metrics collection, and automated or manual rollback, making it the ideal strategy for safely validating a new release in production.

Why this answer

A service mesh like Istio provides fine-grained traffic management capabilities (e.g., using VirtualService and DestinationRule resources) that allow you to route a specific percentage of traffic to the new canary version while the rest goes to the stable version. This enables gradual traffic shifting without modifying application code, and supports advanced routing rules based on headers or weights, which is essential for canary deployments in AKS.

Exam trap

The trap here is that candidates confuse canary deployments with blue-green or rolling updates, not realizing that only a service mesh (or similar traffic-splitting mechanism) provides the precise, percentage-based traffic shifting required for a true canary release in Kubernetes.

How to eliminate wrong answers

Option A is wrong because blue-green deployment switches all traffic at once between two environments (blue and green), not gradually shifting traffic as required by canary deployments. Option B is wrong because a rolling update replaces pods incrementally but does not allow fine-grained traffic splitting between versions; it updates all pods to the new version over time without a controlled canary phase. Option C is wrong because A/B testing with feature flags controls feature exposure at the application level (e.g., via code toggles), not at the network/traffic level, and does not inherently manage traffic shifting between container versions in a Kubernetes cluster.

Practice this question →

254

Drag & Dropmedium

Drag and drop the steps to implement infrastructure as code with Azure Resource Manager (ARM) templates into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order for implementing infrastructure as code with ARM templates is: first define the ARM template, then parameterize it to make it reusable, then store it in version control (e.g., Git) to track changes, then validate the deployment using the what-if operation to preview changes, and finally deploy the template to Azure.

Practice this question →

255

MCQhard

You have the YAML pipeline snippet shown in the exhibit. The first run produces version 1.0.0. What will be the version produced on the third run?

A.1.0.1

B.1.0.3

C.1.0.2

D.1.0.0

AnswerC

The counter expression returns 0 on the first run, 1 on the second, and 2 on the third for a given key. With the prefix '1.0', the third run correctly produces 1.0.2, matching the exhibit.

Why this answer

The YAML pipeline uses a counter expression `$[counter(format('{0}.{1}', variables['major'], variables['minor']), 0)]` for the patch version. The counter starts at 0 for the first run, producing version 1.0.0. Each subsequent run increments the counter by 1, so the second run produces 1.0.1, and the third run produces 1.0.2.

Therefore, option C is correct.

Exam trap

The trap here is that candidates may mistakenly think the counter starts at 1 or that the version increments by more than 1 per run, leading them to choose 1.0.1 or 1.0.3 instead of understanding the exact sequential increment from the seed value.

How to eliminate wrong answers

Option A is wrong because 1.0.1 would be the version produced on the second run, not the third. Option B is wrong because 1.0.3 would be the version produced on the fourth run, as the counter increments by 1 each run. Option D is wrong because 1.0.0 is the version produced on the first run, and the counter does not reset to 0 on subsequent runs.

Practice this question →

256

MCQhard

Refer to the exhibit. The workflow runs successfully but the deployment fails because the Azure CLI is not authenticated. What should you add to the workflow to authenticate?

A.Add the 'azure/login' action with Azure credentials

B.Add the 'actions/setup-node' action

C.Add the 'azure/webapps-deploy' action

D.Add the 'actions/github-script' action to use the GitHub token

AnswerA

Adding the 'azure/login' action with Azure credentials is correct because it authenticates the Azure CLI with a service principal, establishing an Azure session (via the `AZURE_CREDENTIALS` secret containing client ID, client secret, tenant ID, and subscription ID) that subsequent steps can use to run `az` commands. Without this authentication step, any Azure CLI command in the workflow fails with an authentication error, even if the workflow itself runs successfully.

Why this answer

The Azure CLI in the workflow requires authentication to interact with Azure resources. Adding the 'azure/login' action with valid Azure credentials (e.g., service principal secrets or OpenID Connect) establishes the necessary authentication context before any Azure CLI commands are executed, resolving the 'not authenticated' error.

Exam trap

The trap here is that candidates may assume any Azure action (like 'azure/webapps-deploy') implicitly handles authentication, but in reality, authentication must be explicitly performed before any Azure CLI or SDK calls.

How to eliminate wrong answers

Option B is wrong because 'actions/setup-node' sets up a Node.js environment and has no role in Azure authentication. Option C is wrong because 'azure/webapps-deploy' deploys to Azure Web Apps but does not authenticate the Azure CLI; it relies on prior authentication from 'azure/login'. Option D is wrong because 'actions/github-script' runs scripts using the GitHub token, which is not valid for authenticating to Azure resources.

Practice this question →

257

MCQhard

Your release pipeline uses a 'Run Azure CLI' task to execute a script. The script authenticates using a service principal. However, the deployment fails with 'insufficient privileges to complete the operation'. What is the most likely cause?

A.The Azure CLI task is not logged in.

B.The service principal secret has expired.

C.The service principal lacks the necessary RBAC role on the target resource.

D.The service principal does not have a secret.

AnswerC

The service principal is authenticated but does not have the required Azure RBAC role (e.g., Contributor, Reader, or a custom role) on the target resource or resource group. Azure CLI commands that attempt to perform an action without the necessary role assignment will return an authorization error, so assigning the appropriate RBAC role resolves the issue.

Why this answer

The error 'insufficient privileges to complete the operation' indicates that the service principal successfully authenticated but lacks the required Azure RBAC role on the target resource. Even with a valid secret and a logged-in Azure CLI session, the service principal must have an assigned role (e.g., Contributor, Owner, or a custom role) that grants the specific permissions needed for the deployment operation.

Exam trap

The trap here is that candidates confuse authentication failures (invalid credentials, expired secrets) with authorization failures (insufficient RBAC permissions), leading them to incorrectly select options related to credential issues when the error message explicitly states 'insufficient privileges'.

How to eliminate wrong answers

Option A is wrong because the 'Run Azure CLI' task automatically handles authentication via the service principal connection; if the task were not logged in, the error would be an authentication failure (e.g., 'login failed' or 'unable to acquire token'), not an authorization error. Option B is wrong because an expired secret would cause an authentication failure (e.g., 'invalid client secret' or 'AADSTS7000222'), not an 'insufficient privileges' error which occurs after successful token acquisition. Option D is wrong because if the service principal had no secret, the Azure CLI task would fail to authenticate entirely, producing a credential-related error rather than an RBAC authorization error.

Practice this question →

258

MCQeasy

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

A.Pull request trigger

B.Continuous deployment trigger on the release pipeline

C.Schedule trigger

D.Build completion trigger

AnswerB

A continuous deployment trigger on the release pipeline is the artifact trigger that watches a connected build artifact for a successful build. When a new version of that artifact is produced, the trigger automatically creates a release and promotes that exact artifact through every stage, so all environments test and receive the same immutable build. This precisely matches the requirement to use the same artifact without rebuilding or recompiling.

Why this answer

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

Exam trap

The trap here is that candidates often confuse build completion triggers (which chain builds) with continuous deployment triggers (which chain builds to releases), leading them to select build completion trigger thinking it will automatically deploy to environments, but it only triggers another build pipeline, not a release.

How to eliminate wrong answers

Option A is wrong because a pull request trigger is used to validate code changes in a build pipeline, not to deploy existing artifacts to multiple environments; it triggers a build on PR creation, not a release deployment. Option C is wrong because a schedule trigger runs the release pipeline at specified times, which does not guarantee that the same build artifact is used across environments and may deploy outdated or different artifacts if builds occur between scheduled runs. Option D is wrong because a build completion trigger is used to chain build pipelines, not release pipelines; it triggers another build pipeline when a build completes, not a release deployment.

Practice this question →

259

MCQhard

Your company uses Azure DevOps for CI/CD. You have a YAML build pipeline that builds a .NET Core application and publishes artifacts. The build runs on a Microsoft-hosted agent. Recently, the build started failing with the error 'The process cannot access the file because it is being used by another process.' This occurs intermittently during the 'dotnet build' step. The pipeline uses multiple jobs that run in parallel. You suspect that one job is interfering with another because they share the same workspace on the agent. You need to ensure that each job runs in its own isolated workspace. What should you do?

A.Add a 'demands' section to the job to ensure each job runs on a different agent.

B.Set 'workspace: clean' in the pipeline root.

C.Use a 'multi-job' configuration with a matrix to run each job in separate folders.

D.Set 'clean: all' on the checkout step in each job.

AnswerD

Setting `clean: all` on the checkout step in each job is the correct fix because it deletes the entire workspace, including all files from previous jobs, before the repository is checked out. This guarantees a fresh, isolated environment for every job, preventing stale artifacts from affecting the build.

Why this answer

Setting 'clean: all' on the checkout step ensures that the workspace is cleaned before each job runs, preventing file conflicts caused by shared workspace on the agent. Option A is wrong because 'demands' are for selecting agents with specific capabilities, not for workspace isolation. Option B is wrong because 'workspace: clean' is not a valid setting at the pipeline root; workspace cleaning is configured per checkout step.

Option C is wrong because a multi-job configuration with a matrix is used for parallelizing builds across different configurations, not for isolating workspaces.

Practice this question →

260

MCQhard

Refer to the exhibit. A developer queues a build with a variable 'BuildConfiguration' set to 'Release'. The pipeline definition has a default variable 'BuildConfiguration' set to 'Debug' and does not allow overrides at queue time. What will be the value of 'BuildConfiguration' during the build?

A.Debug

B.Release

C.null

D.The build fails with an error

AnswerA

Because the variable has a default value defined in the pipeline and overrides at queue time are not enabled, the build uses the configured default "Debug". The system substitutes this value before any tasks run, so the build executes as if Debug were explicitly set.

Why this answer

The pipeline definition does not allow overrides at queue time, so the variable value passed in the queue command is ignored; the default value 'Debug' is used.

Practice this question →

261

MCQhard

Your organization uses Azure DevOps Server (on-premises) and plans to migrate to Azure DevOps Services. You have hundreds of classic build and release pipelines. You need to design a migration strategy that minimizes downtime and allows for a gradual transition. The team wants to use the new YAML-based pipelines after migration. What should you do?

A.Export the classic pipeline definitions as JSON, and manually recreate them as YAML pipelines in Azure DevOps Services.

B.Recreate all pipelines from scratch using YAML in the new organization.

C.Use the Azure DevOps Migration Tools to automatically convert classic pipelines to YAML.

D.Migrate all pipelines as-is (classic) and then plan a separate project to convert them to YAML.

AnswerA

This allows gradual migration while maintaining existing pipelines.

Why this answer

Exporting classic pipeline definitions as JSON and manually recreating them as YAML pipelines in Azure DevOps Services allows for a gradual migration, minimizing downtime. The team can convert pipelines incrementally, ensuring familiarity with YAML syntax and validating each pipeline before moving the next. Option B is wrong because recreating all pipelines from scratch is inefficient, error-prone, and does not leverage the existing pipeline logic.

Option C is wrong because the Azure DevOps Migration Tools are designed for data migration (work items, repos, etc.) and do not automatically convert classic pipelines to YAML. Option D is wrong because migrating pipelines as classic first and then planning a separate conversion project delays the adoption of YAML and introduces additional rework.

Practice this question →

262

Multi-Selectmedium

Which TWO features can you use to enforce quality gates before a production deployment in Azure Pipelines?

Select 2 answers

A.Scheduled triggers

B.Branch policies on repositories

C.Pipeline decorators

D.Approval checks on environments

E.Deployment gates evaluating health metrics

AnswersD, E

Approval checks on environments are a valid quality gate feature in Azure Pipelines. They require designated users or groups to explicitly approve a deployment before it is released to that environment, providing manual sign-off as a gate.

Why this answer

Approval checks on environments allow you to require manual sign-off before a release proceeds to a production stage. This enforces a quality gate by ensuring that a designated approver reviews and authorizes the deployment. Option E is correct because deployment gates evaluate health metrics (e.g., from Azure Monitor or Application Insights) automatically, blocking or allowing the deployment based on predefined conditions such as error rates or performance thresholds.

Exam trap

The trap here is that candidates confuse pre-deployment quality checks (like branch policies or scheduled triggers) with the specific deployment-time gates and approvals that Azure Pipelines provides for production environments.

Practice this question →

263

Multi-Selecteasy

Which THREE are true about using deployment groups in Azure Pipelines? (Choose 3)

Select 3 answers

A.Each machine in a deployment group must have the Azure Pipelines agent installed.

B.Deployment groups can only be used with Windows-based machines.

C.Deployment groups allow you to deploy an application to multiple machines in a rolling fashion.

D.Deployment groups can be used in classic release pipelines.

E.Deployment groups are tied to a specific environment.

AnswersA, C, D

The Azure Pipelines agent is required on every machine in a deployment group because it is the execution engine that receives and runs tasks from the pipeline. Without the agent, the deployment group cannot communicate with Azure Pipelines or execute any deployment steps on that target machine.

Why this answer

Each target machine in a deployment group requires the Azure Pipelines agent (either the Windows or Linux agent) to be installed and configured. The agent is responsible for executing the deployment tasks on that machine, and without it, the deployment group cannot communicate with or deploy to the machine.

Exam trap

The trap here is that candidates often confuse deployment groups with environments, assuming they are the same concept, but deployment groups are a legacy feature for multi-machine deployments while environments are a newer, more flexible abstraction that supports Kubernetes, virtual machines, and other resources.

Practice this question →

264

MCQmedium

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

A.DownloadBuildArtifacts task

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

C.DotNetCoreCLI task with the 'restore' command

D.Cache task with a key based on the package lock file

AnswerD

The Cache task can cache NuGet packages based on the lock file hash, speeding up subsequent restores.

Why this answer

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

Exam trap

The trap here is that candidates often confuse the NuGet local HTTP cache (controlled by the 'noCache' option) with the pipeline-level Cache task. The 'noCache' option only disables the HTTP cache on the local agent, but that cache persists across builds on that agent. It does not provide a distributed cache across different agents.

The pipeline Cache task caches files in Azure DevOps and restores them on any agent, which is why it's the correct approach for speeding up builds across runs.

How to eliminate wrong answers

Option A is wrong because the DownloadBuildArtifacts task is used to download build artifacts from a previous pipeline run, not to cache NuGet packages for dependency restoration. Option B is wrong because the NuGet restore task's 'noCache' option controls whether NuGet uses its local HTTP cache, not the pipeline-level cache; setting it to false does not introduce pipeline caching. Option C is wrong because the DotNetCoreCLI task with the 'restore' command performs a standard restore without any built-in caching mechanism; it would still download packages from the feed each time unless combined with a separate Cache task.

Practice this question →

265

MCQmedium

Refer to the exhibit. The YAML pipeline triggers on commits to main and develop branches, and pull requests targeting develop. A developer pushes a commit directly to main. What will happen?

A.The pipeline does not run because the PR trigger requires a pull request.

B.The pipeline runs once for the CI trigger.

C.The pipeline runs twice: once for the CI trigger and once for the PR trigger.

D.The pipeline runs once for the PR trigger only.

AnswerB

The CI trigger explicitly includes the main branch, so a push to main immediately queues one pipeline run. Since this is a direct push and not a pull request, the PR trigger does not apply, resulting in exactly one build.

Why this answer

The pipeline is configured with a CI trigger for both main and develop branches, and a PR trigger only for pull requests targeting develop. When a developer pushes a commit directly to main, the CI trigger fires because the push matches the main branch, causing the pipeline to run once. The PR trigger does not activate because there is no pull request involved.

Exam trap

The trap here is that candidates often assume a PR trigger fires for any branch change or that a push to main also triggers a PR evaluation, but PR triggers only respond to pull request events, not direct pushes.

How to eliminate wrong answers

Option A is wrong because the CI trigger is configured for main, so the pipeline does run on a direct push to main, not just on PRs. Option C is wrong because the PR trigger only applies to pull requests targeting develop, and a direct push to main does not create a pull request, so only the CI trigger fires once. Option D is wrong because the PR trigger does not fire at all for a direct push to main; the pipeline runs due to the CI trigger, not the PR trigger.

Practice this question →

266

MCQmedium

You are designing a multi-stage YAML pipeline that builds a Docker image and deploys it to Azure Kubernetes Service (AKS). You want to reuse the Docker build steps across multiple stages. What is the best approach?

A.Use a stage template.

B.Define the steps as variables and reference them.

C.Create a YAML template and reference it from each stage.

D.Create a separate job and call it from each stage.

AnswerC

A YAML template is the standard Azure Pipelines mechanism for reusing steps, jobs, or even entire stages. By extracting the Docker build steps into a `steps` template file and referencing it with `template:` inside each stage's `steps`, you avoid duplication and keep the build logic consistent and maintainable.

Why this answer

YAML templates in Azure Pipelines allow you to define reusable step, job, or stage definitions in a separate file and reference them using the `template` keyword. This approach promotes DRY (Don't Repeat Yourself) principles, simplifies maintenance, and ensures consistency when the same Docker build steps are needed across multiple stages in a multi-stage pipeline.

Exam trap

The trap here is that candidates often confuse stage templates with step templates, thinking that reusing an entire stage is the same as reusing steps within a stage, but the question specifically asks for reusing 'Docker build steps' across stages, not entire stages.

How to eliminate wrong answers

Option A is wrong because stage templates reuse entire stages, not just the Docker build steps; using a stage template would force you to duplicate the entire stage structure, which is overkill and less flexible when you only need to reuse steps within different stages. Option B is wrong because variables in Azure Pipelines are key-value pairs used for parameterization, not for encapsulating executable logic; you cannot define steps as variables and reference them to execute build commands. Option D is wrong because creating a separate job and calling it from each stage would introduce unnecessary job-level overhead and complexity; jobs are independent execution units that cannot be directly 'called' from within a stage without using deployment job patterns or template references, making this approach less straightforward and not the best practice for reusing steps.

Practice this question →

267

MCQmedium

Your team uses GitHub Actions for CI/CD. You need to enforce that all pull requests to the main branch pass a required status check that runs a security scan. The security scan is a GitHub Action that runs on pull_request events. However, the status check is not appearing as required in the branch protection rules. What should you do?

A.Add 'types: [opened, synchronize]' to the pull_request trigger.

B.Change the trigger from 'pull_request' to 'pull_request_target'.

C.Use a GitHub App instead of the default GITHUB_TOKEN for the action.

D.Ensure the workflow has a name that matches the status check name in the branch protection rule.

AnswerD

The status check name is based on the workflow name and job name. If the workflow name is different, the check won't match.

Why this answer

GitHub branch protection rules require the status check name to exactly match the workflow name (or the job name within the workflow) as it appears in the GitHub Actions UI. If the names do not match, the check will not appear as an option in the required status checks list. The security scan action runs on pull_request events, so the status check is generated, but the mismatch prevents it from being selectable as a required check.

Exam trap

The trap here is that candidates often focus on event triggers or authentication tokens, overlooking the simple but critical requirement that the status check name must exactly match the workflow or job name in the branch protection rule.

How to eliminate wrong answers

Option A is wrong because adding 'types: [opened, synchronize]' is the default behavior for pull_request triggers and does not affect the appearance of the status check in branch protection rules; the issue is a naming mismatch, not the event type. Option B is wrong because changing the trigger to 'pull_request_target' alters the security context (runs in the base branch context) but does not resolve the naming mismatch; it could introduce security risks if not carefully managed. Option C is wrong because using a GitHub App instead of GITHUB_TOKEN changes authentication but does not affect how the status check name is registered; the check name is derived from the workflow or job name, not the token used.

Practice this question →

268

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 →

269

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

Metrics-based gates are a key part of gated deployment.

Why this answer

Deployment gates in Azure Pipelines allow you to define pre-deployment or post-deployment conditions that evaluate external metrics (e.g., error rate from Azure Monitor, Application Insights, or other monitoring systems) before allowing the release to proceed to the next stage. This is a core mechanism for implementing a gated deployment strategy, as it automatically pauses the pipeline until the specified health criteria are met, ensuring that only healthy releases progress. Option E is correct because manual approval checks act as a human-driven gate, requiring explicit sign-off before a deployment proceeds to production, which is a common pattern in gated deployments to add oversight.

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 →

270

MCQhard

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

A.Canary deployment with manual promotion.

B.Blue-green deployment with manual swap.

C.Recreate deployment by redeploying the same version.

D.Rolling update with health checks and automatic rollback.

AnswerD

Health checks trigger automatic rollback on failure.

Why this answer

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

Exam trap

The trap here is that candidates often confuse 'canary' or 'blue-green' with automatic rollback, but those strategies typically require manual promotion or swap, whereas rolling update with health checks and automatic rollback is the only option that fully automates the rollback process.

How to eliminate wrong answers

Option A is wrong because canary deployment with manual promotion requires a human to approve the promotion to full rollout, which violates the 'automatically roll back' requirement. Option B is wrong because blue-green deployment with manual swap requires a manual switch of traffic to the new environment, and while it can support rollback by swapping back, the manual step breaks the automatic rollback requirement. Option C is wrong because recreate deployment simply destroys all existing pods and creates new ones; it does not support health checks during deployment and cannot automatically roll back to a previous version if the new version fails.

Practice this question →

271

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 →

272

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 →

273

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 →

274

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 →

275

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 →

276

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 →

277

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 →

278

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 →

279

Multi-Selectmedium

Your team uses Azure Pipelines to build a .NET application. You need to implement a secure build pipeline that meets the following requirements: - Secrets must be injected at build time without being exposed in logs or YAML files. - The build must use Microsoft-hosted agents. - All builds must be auditable. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Enable 'Allow scripts to access the OAuth token' on the agent job and use the token in scripts.

B.Use a variable group linked to Azure Key Vault to store secrets, and reference the variable group in the pipeline.

C.Store secrets as plain-text environment variables in the pipeline YAML file.

D.Use the 'Replace Tokens' task to substitute secrets from pipeline variables into configuration files.

E.Deploy a self-hosted agent on-premises to keep secrets within the corporate network.

AnswersB, D

A variable group linked to Azure Key Vault securely stores secrets outside the pipeline definition and injects them at runtime as masked variables. This approach avoids hardcoding secrets in YAML, leverages Key Vault's access policies and audit logs, and simplifies secret rotation by updating the vault without editing the pipeline.

Why this answer

To securely inject secrets without exposing them in logs or YAML, use a variable group linked to Azure Key Vault (B) to store secrets, and then use a token replacement task like Replace Tokens (D) to inject those secret variables into configuration files during the build. This avoids putting secrets in YAML, masks them in logs, and is auditable via Azure Key Vault and Azure DevOps audit logs. Option A, while the token is masked, is for Azure DevOps API access, not secret injection, and enabling it increases exposure risk.

Exam trap

The trap is confusing the OAuth token (System.AccessToken) with secret management. Although the OAuth token is masked, it is not a secret injection mechanism; it provides API access only. The correct approach combines Key Vault variable groups with token replacement tasks.

Practice this question →

280

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 →

281

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 →

282

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 template references a parameter 'adminPassword' that is not defined in the parameters section. It must be declared as a parameter to be provided during deployment.

Practice this question →

283

Multi-Selecthard

Which TWO are best practices for securing Azure Pipelines? (Choose two.)

Select 2 answers

A.Use variable groups linked to Azure Key Vault for secrets.

B.Scope service connections to specific resource groups with 'Contributor' role.

C.Grant 'Administrator' role to all service connections for ease of management.

D.Store all pipeline variables in the YAML file as plain text.

E.Disable pipeline logging for all jobs.

AnswersA, B

Key Vault integration securely stores and retrieves secrets.

Why this answer

Variable groups linked to Azure Key Vault allow you to securely store and manage secrets (e.g., API keys, passwords) outside of pipeline definitions. Azure Pipelines retrieves these secrets at runtime via the Azure Key Vault REST API, ensuring they are never exposed in logs or YAML files. This follows the principle of least privilege and secrets management best practices.

Exam trap

The trap is thinking that scoping service connections to specific resource groups with 'Contributor' role is too permissive. While 'Contributor' is broader than a custom role, Microsoft recommends it for resource group-scoped connections because it provides the minimum permissions needed for most Azure DevOps tasks without overcomplicating management. The real risk is using overly broad scopes like subscriptions or 'Owner' roles, not 'Contributor' on specific resource groups.

Practice this question →

284

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 →

285

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 →

286

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 →

287

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 →

288

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 swap swaps all settings, so if staging settings are not suited for production, the site can become unresponsive.

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 →

289

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 →

290

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 →

291

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 →

292

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 →

293

MCQeasy

Your organization uses Azure DevOps and GitHub. You need to ensure that secrets such as API keys are not exposed in pipeline logs. What should you do?

A.Store the API key in a plain text variable and reference it as $(apiKey)

B.Store the API key in Azure Key Vault and use a variable group linked to the vault

C.Store the API key in a secret variable

D.Use the Logging Command to suppress output

AnswerB, C

Azure Key Vault integration is a valid way to store secrets, but it requires creating a variable group, linking it to the vault, and configuring a service connection with appropriate Key Vault access policies. This approach works but is heavier-weight than a simple secret variable and still requires the pipeline to reference the secret explicitly, so it is not the most direct secure option.

Why this answer

Both secret variables and variable groups linked to Azure Key Vault are masked in pipeline logs. Azure Pipelines automatically masks secret variables, and variables from Key Vault variable groups are also treated as secrets. Therefore, both B and C prevent exposure.

The question asks 'what should you do?' without requiring a single best method, so both B and C should be considered correct.

Practice this question →

294

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 →

295

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 →

296

Multi-Selecthard

Which THREE options are valid strategies to reduce build times in Azure Pipelines? (Choose three.)

Select 3 answers

A.Enable incremental builds by using the 'Clean: false' option.

B.Use a self-hosted agent with a local cache of dependencies.

C.Break the pipeline into multiple stages running sequentially.

D.Increase the number of parallel jobs in the pipeline.

E.Use the 'Cache' task to cache folders like node_modules or .m2.

AnswersA, B, E

Setting 'Clean: false' preserves outputs from the previous build so the incremental compiler can skip unchanged projects and only recompile modified code, dramatically shortening build time for large solutions by avoiding full rebuilds.

Why this answer

Setting 'Clean: false' enables incremental builds by retaining the workspace from the previous run. This means only changed files are rebuilt, significantly reducing build time by avoiding a full clean checkout and rebuild of unchanged code.

Exam trap

The trap here is that candidates confuse parallelism (multiple jobs) with build acceleration for a single pipeline, or assume sequential stages reduce time when they actually add overhead.

Practice this question →

297

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 →

298

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 →

299

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 →

300

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 →