CCNA Build Release Pipelines Questions — Page 3 of 5

151

MCQeasy

You need to integrate Azure Pipelines with GitHub to trigger a build when a release is published in GitHub. Which trigger type should you use in the pipeline?

A.pr:

B.trigger:

C.resources: repositories: - repository: self type: github trigger: release: true

D.schedules:

AnswerC

Defining a `resources.repositories` entry with `type: github` and `repository: self` references the GitHub repository, and adding `trigger: release: true` under that repository enables the pipeline to start automatically when a GitHub release is published. This is the correct event-driven trigger for GitHub releases, as it explicitly subscribes to release activity from the connected repository.

Why this answer

Azure Pipelines supports a GitHub release trigger through the `resources` definition, where you specify a `trigger` with `release: true` under the repository configuration. This tells the pipeline to automatically start a build whenever a new release is published in the linked GitHub repository, which directly matches the requirement.

Exam trap

The trap here is that candidates often confuse the `trigger:` keyword (which handles CI branch triggers) with the release trigger syntax, or mistakenly think a simple `trigger:` can be configured to listen for GitHub release events, when in fact it requires the nested `resources` structure with `release: true`.

How to eliminate wrong answers

Option A is wrong because `pr:` is used to trigger builds on pull request events, not on release publications. Option B is wrong because `trigger:` at the pipeline root configures CI triggers for branch pushes or path filters, not for GitHub release events. Option D is wrong because `schedules:` defines cron-based scheduled triggers, which are time-driven and unrelated to GitHub release events.

Practice this question →

152

MCQeasy

Refer to the exhibit. The pipeline uses a variable group 'ReleaseVariables' that contains a variable named 'EnvironmentName' with value 'Staging'. What environment will the deployment target?

A.Staging

B.VirtualMachine

C.Production

D.DeployWeb

AnswerC

Production is the correct environment because the pipeline defines EnvironmentName: Production at the root level, and in YAML pipelines, variables defined at the pipeline level take precedence over variables in variable groups when the same key exists. The variable group provides EnvironmentName=Staging, but the pipeline variable overrides it, causing the deployment job's environment reference $(EnvironmentName) to evaluate to Production. Therefore the deployment is targeted to the Production environment, not Staging.

Why this answer

The pipeline uses a variable group 'ReleaseVariables' with a variable 'EnvironmentName' set to 'Staging', but the deployment job's environment field is explicitly set to 'Production' (as shown in the exhibit). Variable groups are used for sharing values across pipelines, but they do not override the environment specified directly in the YAML job definition. Therefore, the deployment target is 'Production'.

Exam trap

The trap here is that candidates assume a variable group's variable named 'EnvironmentName' automatically sets the deployment environment, but the environment field in the YAML is a static value unless explicitly parameterized, so the explicit 'Production' value takes precedence.

How to eliminate wrong answers

Option A is wrong because 'Staging' is the value of the variable 'EnvironmentName' in the variable group, but the deployment job's environment is explicitly set to 'Production' in the YAML, and variable groups do not override the environment field. Option B is wrong because 'VirtualMachine' is a resource type, not an environment name; the environment field expects a logical environment name like 'Production' or 'Staging', not a resource type. Option D is wrong because 'DeployWeb' is the name of the deployment job, not the environment target; the environment is specified separately in the 'environment' property of the job.

Practice this question →

153

MCQhard

You are designing a multi-stage YAML pipeline in Azure DevOps that builds, tests, and deploys a .NET Core application. The pipeline must use a self-hosted agent pool for compliance. You need to minimize agent idle time while ensuring that the agent is always available for builds. What should you do?

A.Provision a virtual machine scale set with a fixed number of agents

B.Install multiple agents on a single VM to maximize utilization

C.Deploy a scale set agent pool with autoscaling enabled

D.Use a single persistent agent and queue builds when idle

AnswerC

Deploying a scale set agent pool with autoscaling enabled is the correct approach because it dynamically adds or removes agent VMs based on job queue length, ensuring sufficient capacity during build bursts while minimizing idle compute costs during quiet periods.

Why this answer

A scale set agent pool with autoscaling enabled dynamically provisions and deprovisions Azure virtual machines based on the pipeline's demand, minimizing idle time while ensuring agents are available when builds are triggered. This approach aligns with the requirement for a self-hosted agent pool for compliance and optimizes cost by scaling down when no jobs are pending.

Exam trap

The trap here is that candidates may confuse 'minimizing idle time' with 'maximizing utilization' and choose Option B (multiple agents on one VM), not realizing that resource contention and lack of horizontal scaling make it unsuitable for concurrent builds and compliance-driven self-hosted pools.

How to eliminate wrong answers

Option A is wrong because provisioning a virtual machine scale set with a fixed number of agents does not minimize idle time; it keeps a constant number of VMs running regardless of demand, leading to wasted resources when no builds are queued. Option B is wrong because installing multiple agents on a single VM can cause resource contention (CPU, memory, disk I/O) and does not scale horizontally to handle concurrent builds efficiently, violating the goal of minimizing idle time while ensuring availability. Option D is wrong because using a single persistent agent and queuing builds when idle results in builds waiting if the agent is busy, increasing pipeline latency and not minimizing idle time—it also fails to scale for multiple concurrent builds.

Practice this question →

154

Multi-Selectmedium

Which TWO conditions must be met to use multi-stage YAML pipelines with approvals?

Select 2 answers

A.The pipeline must be triggered by a pull request.

B.An environment must be created and approval checks configured on it.

C.The pipeline must have at least one stage defined in a separate release pipeline.

D.The deployment job must reference a specific environment.

E.The pipeline must be created using the classic release editor.

AnswersB, D

Approval checks in YAML pipelines attach to environments, not to stages directly. Creating an environment and configuring approval checks on it satisfies the stem's requirement, because the pipeline's deployment job references that environment and pauses there until the designated approvers grant permission, enabling gated multi-stage releases.

Why this answer

Multi-stage YAML pipelines in Azure DevOps require that an environment be created and approval checks configured on it to enable manual approvals. Additionally, the deployment job within the pipeline must reference a specific environment, as the approval check is associated with that environment resource. Without these two conditions, the pipeline cannot enforce approval gates before deployment.

Exam trap

The trap here is that candidates often think approvals are configured directly on the pipeline or stage in YAML, but they must be set on the environment resource and the deployment job must explicitly reference that environment.

Practice this question →

155

Multi-Selectmedium

Which TWO actions should be taken to secure secrets in Azure Pipelines? (Choose two.)

Select 2 answers

A.Use secret variables with the 'secret' input type to mask them in logs.

B.Use a variable group without Key Vault integration for easier management.

C.Store secrets directly in the YAML pipeline file.

D.Store secrets in a variable group linked to Azure Key Vault.

E.Disable CI triggers to reduce exposure.

AnswersA, D

In Azure Pipelines, defining variables with the `secret` input type (e.g., via the pipeline UI or YAML `${{ variables.secret }}`) ensures they are encrypted at rest and automatically masked in all pipeline logs, preventing accidental exposure. This is a fundamental practice for handling sensitive data in CI/CD, as it protects against log leakage while still allowing tasks to reference the variable securely.

Why this answer

Azure Pipelines allows you to mark variables as secret by using the 'secret' input type in the pipeline settings UI or by setting `secret: true` in YAML. This ensures the variable's value is masked with asterisks in all logs and output, preventing accidental exposure during build or release execution. Additionally, storing secrets in a variable group linked to Azure Key Vault provides a secure, centralized way to manage secrets, with access control, versioning, and auditability, making it a best practice for protecting sensitive data.

Exam trap

The trap here is that candidates may think disabling CI triggers (Option E) reduces secret exposure, but it only affects build automation, not the security of the secrets themselves, which is a common misconception about pipeline security controls.

Practice this question →

156

MCQhard

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

A.1 build, because batchChanges is true.

B.0 builds, because the excluded path takes precedence.

C.3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.

D.2 builds, one for each modified folder.

AnswerA

With batchChanges set to true, all commits and file changes from a single push are coalesced into one build invocation; you don't get a separate build per modified file or folder. Because at least one changed path matches an include pattern, the pipeline queues exactly one batched build for that change set.

Why this answer

The trigger configuration has `batchChanges` set to `true`. When `batchChanges` is enabled, Azure Pipelines groups all commits that arrive while a build is in progress into a single build, rather than triggering a separate build for each commit. In this scenario, the developer pushes a single commit that modifies files in both `/src/app/` and `/src/tests/`.

Since `batchChanges` is true, only one build is triggered for that commit, regardless of the number of modified folders.

Exam trap

The trap here is that candidates often confuse `batchChanges` with `maxConcurrentBuildsPerBranch`, thinking that batching affects concurrency limits, or mistakenly believe that modifying multiple folders in a single commit triggers multiple builds.

How to eliminate wrong answers

Option B is wrong because the excluded path (`/src/tests/`) does not take precedence over the included paths; the trigger includes `/src/app/**` and `/src/tests/**`, so the commit modifies files in both included paths, and the exclusion is not configured. Option C is wrong because `maxConcurrentBuildsPerBranch` controls how many builds can run concurrently for the same branch, not the number of builds triggered; `batchChanges` does not override it but works alongside it to batch commits. Option D is wrong because the number of builds is not determined by the number of modified folders; with `batchChanges` set to true, a single commit that modifies multiple folders still triggers only one build.

Practice this question →

157

MCQmedium

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

A.Require linked work items

B.Limit merge types

C.Require a minimum number of reviewers

D.Check for comment resolution

AnswerA

This branch policy enforces that every pull request must have at least one linked work item before it can be completed. By blocking completion without a work item link, it provides full traceability from code changes back to the original requirement or task, which is critical for audit and compliance.

Why this answer

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

Exam trap

AZ-400 often tests the distinction between branch policies that govern code quality (reviewers, comments, merge types) and those that govern traceability (linked work items) — read the requirement for the word 'work item' and match it directly.

How to eliminate wrong answers

Option B is wrong because 'Limit merge types' only restricts which merge strategies (basic, squash, rebase, semi-linear) can be used to complete a pull request — it has nothing to do with work item linkage. Option C is wrong because 'Require a minimum number of reviewers' enforces peer approval counts, not commit-to-work-item association. Option D is wrong because 'Check for comment resolution' ensures all PR comments are resolved before completion, which addresses review hygiene rather than work item traceability.

Practice this question →

158

MCQhard

Your Azure Pipelines build is failing with the error: '##[error]No agent found in pool 'Default' that satisfies the specified demands: Agent.Version -gtVersion 2.200.0'. The pool 'Default' contains agents of various versions. What is the most likely cause?

A.The pipeline YAML has a syntax error in the 'demands' section.

B.The pipeline is configured to run on an agentless job.

C.The 'demands' keyword is not supported in Azure Pipelines.

D.The 'Default' agent pool has no agents with version greater than 2.200.0.

AnswerD

The pipeline includes a demand such as 'Agent.Version -gtVersion 2.200.0', but every agent in the Default pool runs an agent version less than or equal to 2.200.0. As a result, no agent satisfies the demand, causing the build to fail with an error that no matching agent could be found.

Why this answer

The error message explicitly states that no agent in the 'Default' pool satisfies the demand 'Agent.Version -gtVersion 2.200.0'. Since the pool contains agents of various versions, the most likely cause is that none of those agents have a version greater than 2.200.0. This demand is set in the pipeline YAML or classic editor to ensure the agent meets a minimum version requirement.

Exam trap

The trap here is that candidates may assume the error is due to a syntax or configuration issue, when in fact it is a straightforward version mismatch — the pool simply lacks agents meeting the version demand.

How to eliminate wrong answers

Option A is wrong because a syntax error in the 'demands' section would produce a YAML parsing error, not a specific 'No agent found' message with the exact demand string. Option B is wrong because an agentless job does not use an agent pool at all, so it would not trigger an agent demand error. Option C is wrong because the 'demands' keyword is fully supported in Azure Pipelines to specify required agent capabilities or versions.

Practice this question →

159

MCQmedium

Your team uses Azure Pipelines with a YAML pipeline. You need the pipeline to run only when changes are pushed to the main branch, but also run on a nightly schedule. Which trigger configuration should you implement?

A.Use only a `schedules` trigger with a cron expression and remove the `trigger` block.

B.Use a `schedules` trigger with a cron expression and a `trigger` block that includes only the main branch.

C.Use a `pipeline` trigger with `branches: include: [main]` and a `cron` trigger.

D.Use a `trigger` block with `branches: include: [main]` and add a `pr` trigger for the main branch.

AnswerB

The `trigger` block with `branches: include: [main]` ensures the pipeline runs on pushes to main, while `schedules` with a cron expression enables nightly runs. Both triggers can coexist in the same YAML file. This configuration meets the requirement of running on main pushes and on a schedule without unwanted runs on other branches.

Why this answer

The correct configuration uses a `trigger` block that includes only the main branch to run on pushes, plus a `schedules` block with a cron expression for nightly runs. Both triggers can be defined in the same YAML file and operate independently. This satisfies the need to run on main branch changes and on a schedule without extraneous runs.

Exam trap

The trap here is confusing pull request triggers with push triggers, or assuming that a schedule trigger alone can also handle branch pushes.

Practice this question →

160

Multi-Selecthard

Which TWO actions are required to securely use Azure Key Vault secrets in an Azure Pipelines build? (Choose 2)

Select 2 answers

A.Set the 'secrets' output variable to 'true' in the pipeline.

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

C.Use the 'Environment Variables' section in the pipeline to map secrets.

D.Reference the secret identifier directly in the pipeline YAML.

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

AnswersB, E

The Azure Key Vault task authenticates to the Key Vault using the Azure DevOps service principal, retrieves the specified secrets, and injects them as pipeline variables, automatically marking them as secret and masked in logs. This is the recommended, supported method for consuming Key Vault secrets in a pipeline.

Why this answer

The Azure Key Vault task in Azure Pipelines is the recommended way to securely download secrets from a Key Vault and expose them as pipeline variables. This task automatically handles authentication and ensures that secret values are masked in logs, preventing accidental exposure. It eliminates the need to manually manage secret retrieval and mapping in YAML.

For the task to succeed, the Azure DevOps service principal (from the Azure Resource Manager service connection) must have 'Get' and 'List' permissions on the Key Vault. Without these permissions, the task cannot retrieve the secrets. Therefore, both using the Azure Key Vault task and granting the appropriate permissions are required actions.

Exam trap

The trap here is that candidates often think they can directly reference the secret identifier in YAML (Option D) or use environment variables (Option C) to securely retrieve secrets, but these approaches bypass the secure authentication and masking provided by the dedicated Azure Key Vault task.

Practice this question →

161

MCQmedium

Your team uses Azure DevOps to manage a monolithic .NET Framework application that is deployed to on-premises Windows servers. You plan to modernize the application by containerizing it and moving it to Azure Kubernetes Service (AKS). The existing build pipeline uses the .NET Framework build task and MSBuild. The release pipeline uses WinRM-based deployment to copy files to on-premises servers. You need to design a new CI/CD pipeline that builds a Docker image, pushes it to Azure Container Registry (ACR), and deploys it to AKS. Your solution should minimize changes to the existing codebase and leverage Azure Pipelines. What should you do?

A.Keep the existing build pipeline as is, and add a script to build the Docker image in the release pipeline before deploying.

B.Modify the existing build pipeline by adding a 'Docker' task to build and push the image, and modify the release pipeline to use a 'Kubernetes' task for deployment.

C.Create a new build pipeline from scratch using the 'Docker' template and a new release pipeline with the 'Deploy to Kubernetes' template.

D.Use self-hosted agents to build the Docker image and deploy to AKS.

AnswerB

This is the correct approach because it extends the existing CI/CD flow with minimal disruption: add a Docker task to the build pipeline to compile, build, and push the container image to a registry, then replace the release pipeline's deployment step with a Kubernetes task that applies manifests to AKS. This keeps the build artifact (the image) produced during CI and consumes it in CD, which is the recommended practice.

Why this answer

The correct approach is to extend the existing Azure Pipelines definitions rather than rebuild them: add a Docker task to the build pipeline to build and push the image to ACR, and swap the WinRM release step for a Kubernetes task that deploys to AKS. This preserves the existing .NET Framework build logic (MSBuild task) so the codebase and build steps remain largely untouched, satisfying the 'minimize changes' requirement. Azure Pipelines natively supports both the Docker task and the Kubernetes task, so no custom scripting or new pipelines are needed.

Exam trap

AZ-400 often tests whether candidates reflexively choose 'create a new pipeline from scratch' when the requirement explicitly says to minimize changes — the trap is ignoring the constraint and picking the cleanest-sounding rebuild option.

How to eliminate wrong answers

Option A is wrong because building the Docker image in the release pipeline separates build from release, breaks the CI artifact model, and leaves the existing build pipeline producing non-container artifacts that the release stage would have to reconcile. Option C is wrong because creating brand-new pipelines from templates discards the existing .NET Framework build configuration, contradicting the requirement to minimize changes to the codebase and pipeline. Option D is wrong because self-hosted agents are an infrastructure choice, not a pipeline design; they don't by themselves build the image, push to ACR, or deploy to AKS, and the question asks what to do to the pipeline.

Practice this question →

162

MCQeasy

You are designing a build pipeline for a Java application that uses Maven. You want to publish the compiled JAR file as a build artifact. Which task should you use?

A.PublishBuildArtifacts@1

B.Maven@3

C.ArchiveFiles@2

D.CopyFiles@2

AnswerA

PublishBuildArtifacts@1 uploads a specified directory or file to the Azure Pipelines artifact store, assigning it a name so it can be downloaded from the build summary or consumed by subsequent jobs, stages, and release pipelines. This task is the definitive way to make build outputs available as build artifacts.

Why this answer

The Publish Build Artifacts task publishes files as pipeline artifacts. Option B (Maven@3) is wrong because it builds the project but does not publish artifacts. Option C (ArchiveFiles@2) is wrong because it creates a zip but does not publish.

Option D (CopyFiles@2) is wrong because it only copies files within the agent.

Practice this question →

163

MCQeasy

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

A.Pull request trigger

B.Continuous integration (CI) trigger

C.Scheduled trigger

D.Build completion trigger

AnswerD

A build completion trigger fires the release when the specified build pipeline finishes, so the same artefact produced by that build flows into dev, test and prod without recompilation. This directly satisfies the requirement to deploy one identical artefact across all environments.

Why this answer

A build completion trigger ensures that the release pipeline is initiated only after a specific build pipeline completes, allowing the same build artifact to be deployed across multiple environments without rebuilding. This trigger is ideal for multi-environment release pipelines where consistency of the artifact is critical, as it decouples the build from the release and promotes the identical binary through dev, test, and prod.

Exam trap

The trap is that candidates may confuse the build pipeline's CI trigger (which does rebuild code on every commit) with a release pipeline's continuous deployment trigger (which does not rebuild; it deploys the artifact produced by the specified build). For ensuring the same artifact across multiple environments, the build completion trigger is the correct choice because it is directly tied to a specific build pipeline completion.

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 initiate a release pipeline that deploys the same artifact across environments. Option B is wrong because a continuous integration (CI) trigger automatically starts a build when code is committed, which would rebuild the artifact for each environment rather than reusing the same artifact. Option C is wrong because a scheduled trigger runs the release pipeline at predefined times, which does not guarantee that the same build artifact is used across environments and may deploy outdated or inconsistent artifacts.

Practice this question →

164

MCQhard

Refer to the exhibit. A developer creates a pull request from a branch called 'feature/update'. The workflow runs on the pull_request event. What will the output of this workflow be?

A.The workflow will not run because the branch is not 'main'.

B.The workflow will run and output 'Running PR tests'.

C.The workflow will run but output nothing because the condition fails.

D.The workflow will fail due to a syntax error in the conditional expression.

AnswerB

The workflow is configured with the `pull_request` event, so it runs when a PR is opened or updated. The `if` condition `github.event_name == 'pull_request'` is true for this event, so the echo step executes and outputs 'Running PR tests'.

Why this answer

The workflow is triggered on the `pull_request` event, which fires for any pull request regardless of the source branch name. The condition `github.event_name == 'pull_request'` evaluates to `true` because the event is indeed a pull_request. Therefore, the `if` condition passes, and the step runs, outputting 'Running PR tests'.

Exam trap

The trap here is that candidates may assume a workflow only runs on the default branch or that branch names like 'feature/update' are excluded, but GitHub Actions `pull_request` events fire for any source branch unless explicitly filtered with `branches` or `paths`.

How to eliminate wrong answers

Option A is wrong because the workflow is configured to run on the `pull_request` event, not only on pushes to `main`; the branch name does not prevent the workflow from executing. Option C is wrong because the condition `github.event_name == 'pull_request'` is satisfied, so the step does execute and produces output. Option D is wrong because the conditional expression `github.event_name == 'pull_request'` is syntactically valid YAML and GitHub Actions expression syntax.

Practice this question →

165

MCQhard

You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?

A.Add a manual validation task in the Deploy stage.

B.Define an environment with required approvers and reference it in the Deploy stage.

C.Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

D.Configure branch policies on the main branch.

AnswerB

Defining an environment with required approvers and referencing that environment in the Deploy stage adds a pre-deployment approval gate that must be completed before the stage runs, giving you a first-class, audit-ready mechanism for human sign-off on production deployments.

Why this answer

Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.

Exam trap

The trap here is that candidates confuse manual validation tasks (Option A) with environment-based approvals, not realizing that environment approvals are the native, recommended way to enforce stage-level approval gates in YAML pipelines.

Why the other options are wrong

Manual validation tasks require a custom script and do not integrate with Azure AD groups for approvals.

This condition controls stage execution based on branch, not approvals.

Branch policies are for pull requests, not pipeline stages.

Practice this question →

166

MCQeasy

You are configuring a YAML build pipeline for a .NET Core application. Which task should you use to restore NuGet packages?

A.NuGetCommand task

B.DotNetCoreCLI task with 'restore' command

C.PowerShell task with dotnet restore

D.NuGetAuthenticate task

AnswerB

The DotNetCoreCLI task with the 'restore' command is the correct and officially recommended way to restore NuGet packages for .NET Core and .NET Standard projects. It invokes `dotnet restore`, automatically discovers project files, honors NuGet.config and authenticated feeds, and provides rich pipeline logging and error handling without requiring manual command invocation.

Why this answer

The DotNetCoreCLI task with the 'restore' command is the recommended approach for restoring NuGet packages in a YAML build pipeline for a .NET Core application. It directly invokes 'dotnet restore', which is the native .NET CLI command that handles package restoration efficiently and integrates seamlessly with the .NET SDK, ensuring compatibility with project files and dependency resolution.

Exam trap

The trap here is that candidates often choose the NuGetCommand task (A) because they associate 'NuGet' with package restoration, not realizing that .NET Core projects require the DotNetCoreCLI task for proper SDK integration and that the legacy task is deprecated for modern .NET workflows.

Why the other options are wrong

NuGetCommand is for classic NuGet scenarios; for .NET Core, DotNetCoreCLI is preferred.

While possible, using the dedicated DotNetCoreCLI task is the standard approach.

NuGetAuthenticate is for authentication, not restoring packages.

Practice this question →

167

Multi-Selecteasy

You are designing a build pipeline for a .NET Core application. The pipeline must run on a self-hosted agent in a private network without internet access. Which TWO actions are required to ensure the build can download NuGet packages?

Select 2 answers

A.Disable the NuGet restore step in the pipeline.

B.Install the NuGet tool on the self-hosted agent machine.

C.Use a Microsoft-hosted agent instead.

D.Configure the self-hosted agent to access Azure Artifacts or an internal NuGet feed.

E.Use the NuGet Authenticate task to authenticate with Azure Artifacts.

AnswersB, D

The NuGet tool (NuGet.exe) or the dotnet CLI is the client executable that actually executes restore, pack, and push commands in classic build tasks like the NuGetCommand task. On a self-hosted agent, this tool is not guaranteed to be installed, so explicitly installing it ensures the agent can perform the required NuGet operations for the pipeline. For .NET Core projects, the dotnet CLI can handle restore via the SDK, but if the pipeline uses the legacy NuGet tasks, NuGet.exe must be present and accessible on the agent's PATH. Installing the NuGet tool directly addresses the missing executable that the build pipeline relies on to interact with package feeds.

Why this answer

Option B is correct because a self-hosted agent in an isolated network must have the NuGet client tooling installed locally, since the pipeline's NuGet restore tasks (e.g., NuGetCommand@2 or DotNetCoreCLI restore) rely on a NuGet executable or the .NET SDK's built-in restore capability being present on the agent machine to resolve and download packages. Option D is correct because with no internet access, the agent cannot reach nuget.org, so the pipeline must point NuGet at a reachable package source such as Azure Artifacts or an internal NuGet feed configured via NuGet.config or a service connection, allowing packages to be downloaded from inside the private network. Option A is wrong because disabling NuGet restore would prevent package download entirely, defeating the build's dependency resolution.

Option C is wrong because switching to a Microsoft-hosted agent contradicts the requirement to run on a self-hosted agent in a private network and would not have access to internal feeds. Option E is wrong because NuGet Authenticate only supplies credentials for Azure Artifacts; authentication alone does not provide network reachability or a configured internal feed, so it is not sufficient (and not required) to enable package download in an offline network.

Exam trap

The trap is picking 'NuGet Authenticate' as a required action — it is helpful but not strictly required if the feed is already reachable and authenticated, and the question asks for the two actions that are actually necessary.

Practice this question →

168

MCQmedium

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets used in workflows are not exposed in logs. What should you do?

A.Encrypt the secret with a password before using it.

B.Use the 'echo' command to output the secret and then delete the log.

C.Store the secret in GitHub Secrets and reference it as ${{ secrets.SECRET_NAME }}.

D.Disable logging on the self-hosted runner.

AnswerC

Storing the secret in GitHub Secrets and referencing it as ${{ secrets.SECRET_NAME }} is the correct approach because GitHub Actions automatically masks the secret's value in all logs, and the secret is only injected into the workflow at runtime without being visible in the workflow definition.

Why this answer

GitHub Secrets are encrypted environment variables that are automatically masked in workflow logs. When you reference a secret using the `${{ secrets.SECRET_NAME }}` syntax, GitHub Actions ensures the value is never printed in plain text, even if the workflow attempts to echo it. This is the built-in, secure method for handling sensitive data in CI/CD pipelines.

Exam trap

The trap here is that candidates may think disabling logging or manually encrypting secrets is sufficient, but GitHub Actions already provides automatic log masking via GitHub Secrets, making those workarounds unnecessary and insecure.

How to eliminate wrong answers

Option A is wrong because encrypting a secret with a password before using it does not prevent the encrypted value or the password from being exposed in logs; the encryption key would also need to be stored securely, and the decrypted value could still leak. Option B is wrong because using the 'echo' command to output a secret and then deleting the log is unreliable — the secret is already written to the log before deletion, and log retention policies or caching may preserve it. Option D is wrong because disabling logging on a self-hosted runner does not prevent secrets from being exposed in other log outputs (e.g., runner diagnostics, system logs) and violates the principle of least privilege; GitHub Secrets masking works regardless of runner type.

Practice this question →

169

MCQmedium

Your team is adopting Infrastructure as Code (IaC) using Bicep. You need to validate the Bicep file syntax and run pre-deployment checks as part of the build pipeline. Which task should you use?

A.Azure Resource Group Deployment task

B.Terraform task

C.PowerShell task with Invoke-RestMethod

D.Azure CLI task with 'az bicep build'

AnswerD

The Azure CLI task with 'az bicep build' is the correct choice because this command compiles a Bicep file into an ARM template and reports any syntax errors during the build process. It serves as the official, built-in mechanism for validating Bicep syntax in a pipeline.

Why this answer

The `az bicep build` command compiles a Bicep file into an ARM template and performs syntax validation, making it the correct choice for validating Bicep syntax and running pre-deployment checks in a build pipeline. This task ensures that the Bicep code is syntactically correct before any deployment attempt, aligning with Infrastructure as Code (IaC) best practices.

Exam trap

The trap here is that candidates often confuse build-time syntax validation with deployment-time validation, leading them to choose the Azure Resource Group Deployment task (Option A) because it can deploy Bicep files, but it does not perform isolated syntax checks in the build phase.

How to eliminate wrong answers

Option A is wrong because the Azure Resource Group Deployment task is used to deploy ARM templates (or Bicep files via compilation) to a resource group, not to validate syntax or run pre-deployment checks independently; it executes deployment logic, not build-time validation. Option B is wrong because the Terraform task is designed for Terraform configurations, not Bicep files, and would require converting Bicep to Terraform or using a separate tool, which is unnecessary and incorrect for this scenario. Option C is wrong because a PowerShell task with Invoke-RestMethod would require manually calling the Azure REST API or a custom validation endpoint, which is overly complex and not the standard or efficient method for Bicep syntax validation; it lacks built-in Bicep support.

Practice this question →

170

MCQhard

Your organization uses GitHub Flow for source control with a monorepo containing multiple microservices. Each microservice has its own build and test workflow. You need to design a CI/CD strategy that builds and tests only the services affected by a pull request to reduce build times and resource usage. You also need to ensure that all pull requests to the main branch pass required checks before merging. What should you implement?

A.Use a single workflow that builds and tests all microservices on every push to any branch.

B.Set up a webhook that triggers builds manually per service based on pull request comments.

C.Create a single workflow that uses a matrix strategy to build and test each microservice, and run it on every pull request.

D.Use separate workflows for each microservice with path filters (on: pull_request paths:) so that only workflows with changed files are triggered.

AnswerD

Creating separate workflow files per microservice and using `on: pull_request: paths:` means each workflow activates only when a push or PR changes files under its configured path. This scopes builds and tests to the specific services affected by a change, reducing CI runtime and cost while still producing required status checks for the PR.

Why this answer

Path filters on the `on: pull_request` trigger allow each microservice workflow to run only when files under its directory change, which is the standard GitHub Actions pattern for monorepo selective CI. This directly reduces build time and resource consumption while still satisfying required status checks configured on the main branch. Separate workflows also give per-service check granularity, so branch protection rules can require only the relevant checks.

Exam trap

AZ-400 often tests whether candidates confuse matrix strategies (which run all combinations) with path-filtered triggers (which conditionally skip workflows) — matrix parallelism is not the same as selective execution.

How to eliminate wrong answers

Option A is wrong because building and testing every microservice on every push defeats the entire purpose of reducing build times and wastes CI minutes on unaffected services. Option B is wrong because manually triggering builds via PR comments is not automated, is error-prone, and cannot serve as a reliable required status check for branch protection. Option C is wrong because a matrix strategy still executes every microservice's build and test jobs on every pull request — it parallelizes but does not filter by changed paths, so no reduction in total work occurs.

Practice this question →

171

MCQmedium

You are designing a build pipeline that uses a combination of tasks. The pipeline must compile code, run unit tests, and then publish code coverage results. The tasks are: Visual Studio Build, Visual Studio Test, and Publish Code Coverage Results. Which task should be performed first?

A.Visual Studio Build

B.Visual Studio Test

C.Publish Code Coverage Results

AnswerA

The Visual Studio Build task invokes MSBuild to compile the solution and must be the first pipeline action because it produces the binary artifacts (e.g., test assemblies, application DLLs, and PDBs) that every downstream task consumes. Both the VSTest task and the Publish Code Coverage Results task depend on this compiled output—VSTest cannot discover or execute tests without assemblies to load, and coverage data is only generated when those tests run. Additionally, MSBuild can perform tasks like restoring NuGet packages and copying build outputs, ensuring that the workspace is in a consistent state before testing begins. Therefore, placing it anywhere other than first would create an immediate hard failure with 'file not found' or 'no test source files' errors.

Why this answer

The correct order of tasks is: first Visual Studio Build to compile code, then Visual Studio Test to run unit tests, and finally Publish Code Coverage Results. Since the question asks for the first task in the sequence, the correct answer is Visual Studio Build (Option A).

Exam trap

Some candidates may place 'Publish Code Coverage Results' before 'Visual Studio Test', but coverage results are generated during tests, so they must come after.

Practice this question →

172

Multi-Selecteasy

Which TWO practices help improve the security of container images in a CI/CD pipeline? (Choose two.)

Select 2 answers

A.Run containers with root privileges to avoid permission issues.

B.Store container images in a public registry for easy access.

C.Sign container images to verify their integrity.

D.Use the 'latest' tag for base images to always get the newest patches.

E.Scan container images for vulnerabilities during the build.

AnswersC, E

Signing images with a trusted key produces a cryptographic digest that the pipeline and runtime verify before deployment. This detects tampering or substitution between build and deploy, satisfying the integrity requirement rather than merely detecting known vulnerabilities.

Why this answer

Option C is correct because signing container images (e.g., with Docker Content Trust/Notary or Sigstore Cosign) creates a cryptographic signature that lets the pipeline and runtime verify image integrity and provenance, preventing tampered or spoofed images from being deployed. Option E is correct because integrating an image vulnerability scanner (such as Trivy, Clair, or Grype) into the build stage detects known CVEs in OS packages and dependencies early, allowing the pipeline to fail or block promotion of vulnerable images. Option A is wrong because running containers as root increases the attack surface and violates least-privilege; non-root users or user namespaces should be used instead.

Option B is wrong because public registries expose images to unauthorized pulls and tampering; private, access-controlled registries are preferred. Option D is wrong because the mutable 'latest' tag is non-deterministic and can silently pull unvetted or breaking changes; pinned, immutable tags or digests should be used.

Exam trap

Candidates often confuse the 'latest' tag with a security best practice, but it undermines reproducibility and security by introducing uncontrolled updates. Also, some may think running with root privileges avoids permission issues, but it increases attack surface. Signing and scanning are the verifiable security controls.

Practice this question →

173

MCQhard

During a release pipeline, you notice that the deployment to staging fails intermittently due to a timeout waiting for the health check endpoint to return 200. The health check typically passes within 30 seconds, but occasionally takes up to 2 minutes. You need to make the deployment more reliable without affecting the overall release time. What should you do?

A.Remove the health check from the pipeline and rely on monitoring.

B.Add a retry task that runs the health check again after a failure.

C.Increase the health check timeout in the pipeline task to 3 minutes.

D.Reduce the health check timeout to 10 seconds to fail fast and trigger a rollback.

AnswerC

Increasing the health check timeout to 3 minutes directly addresses the intermittent startup delay by allowing the deployment to wait longer for the application to become healthy, reducing false-negative failures. The current timeout is too tight for the observed warm-up behavior, so this change accommodates the normal variation without compromising the overall release gate, while still failing if the service genuinely cannot become ready within the allowed window.

Why this answer

Increasing the health check timeout to 3 minutes accommodates the occasional 2-minute delay without failing the deployment. Since the health check typically passes within 30 seconds but can take up to 2 minutes, a 3-minute timeout ensures the pipeline waits long enough for the endpoint to return HTTP 200, making the deployment more reliable without adding extra retry cycles or changing the overall release time.

Exam trap

The trap here is that candidates often choose retry logic (Option B) thinking it handles intermittent failures, but retries increase total release time, whereas simply increasing the timeout (Option C) waits once for the expected duration without extra cycles.

How to eliminate wrong answers

Option A is wrong because removing the health check eliminates validation that the application is running correctly after deployment, which can lead to undetected failures in staging. Option B is wrong because adding a retry task would increase the overall release time by re-running the health check after each failure, contradicting the requirement to not affect overall release time. Option D is wrong because reducing the timeout to 10 seconds would cause frequent false failures, triggering unnecessary rollbacks and making the deployment less reliable.

Practice this question →

174

MCQhard

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

A.Recreate deployment

B.Blue-green deployment

C.Canary deployment

D.Rolling update

AnswerC

Canary deployment routes a small percentage of live traffic to the new version, monitors error rates and metrics, then progressively increases exposure or rolls back. This satisfies the stem's gradual traffic shifting with error monitoring, unlike blue-green, which switches all traffic at once.

Why this answer

Canary deployment is the correct choice because it gradually shifts a small percentage of traffic to the new version while monitoring for errors, allowing you to detect issues early and roll back quickly without impacting all users. In AKS, this can be implemented using a service mesh like Istio or a progressive delivery tool like Flagger, which manages traffic splitting via VirtualService and DestinationRule configurations. This minimizes downtime by ensuring the majority of users remain on the stable version until the new version is verified.

Exam trap

The trap here is that candidates often confuse canary deployment with rolling update, but rolling update does not support traffic splitting or error-monitoring-based rollback—it simply replaces pods without the ability to route a controlled percentage of traffic to the new version for validation.

How to eliminate wrong answers

Option A is wrong because Recreate deployment terminates all existing pods before creating new ones, causing full downtime during the update, which contradicts the requirement to minimize downtime. Option B is wrong because Blue-green deployment switches traffic entirely from the old version to the new version in one step, which does not gradually shift traffic or allow incremental monitoring; it also requires double the infrastructure. Option D is wrong because Rolling update replaces pods incrementally but does not provide fine-grained traffic splitting or canary-style monitoring—it updates pods in place without the ability to route a specific percentage of traffic to the new version for error detection.

Practice this question →

175

Multi-Selectmedium

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Select 2 answers

A.Continuous deployment trigger after a build completes.

B.Source version trigger.

C.Manual trigger via the 'Create release' button.

D.Pull request trigger.

E.Scheduled release trigger.

AnswersA, E

A continuous deployment trigger automatically creates a release as soon as an associated build artifact is produced by a successful build. This is a native, valid release pipeline trigger in Azure DevOps, enabling automated deployment pipelines.

Why this answer

Azure DevOps release pipelines can be triggered in multiple ways. A continuous deployment trigger (A) automatically creates a release whenever a build artifact is successfully produced. A scheduled release trigger (E) creates a release at a defined time (e.g., nightly).

Manual release creation via the 'Create release' button (C) is a manual action, not an automated configured trigger. Pull request triggers (D) are valid only for build pipelines, not release pipelines. 'Source version trigger' (B) is not a standard release trigger type. Therefore, the two valid trigger types are A and E.

Exam trap

The trap here is that candidates confuse manual release creation (an action) with a configured trigger (an automated event), and they may incorrectly assume that pull request triggers apply to release pipelines when they are only valid for build pipelines.

Practice this question →

176

MCQmedium

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Each microservice has its own build pipeline that produces a container image. You need a single release pipeline that can deploy multiple microservices in a coordinated manner, but you want to avoid rebuilding the deployment pipeline for each microservice. The deployment should use Helm charts. What should you do?

A.Create a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.

B.Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.

C.Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.

D.Create a single multi-stage YAML pipeline that builds and deploys all microservices together.

AnswerC

A single release pipeline consuming multiple build artifacts, one per microservice, preserves independent artifact versioning while centralizing deployment coordination in one auditable process. Using a Helm chart per microservice allows each service to be templated and configured independently, while shared release stages, approval gates, and rollback steps can orchestrate the full deployment consistently across environments.

Why this answer

A single release pipeline can consume multiple build artifacts (one per microservice) and deploy each with its own Helm chart, using stages to coordinate the rollout. This avoids rebuilding the pipeline for each microservice while still allowing coordinated deployment. Azure Pipelines supports multiple artifact sources in a single release definition, and Helm tasks can be parameterized per stage.

Exam trap

AZ-400 often tests the misconception that a single release pipeline cannot consume multiple build artifacts, leading candidates to choose separate pipelines or a monolithic build.

How to eliminate wrong answers

Option A is wrong because creating separate release pipelines per microservice and chaining them with completion triggers does not provide a single coordinated pipeline and increases maintenance overhead. Option B is wrong because a single build pipeline producing all images couples the build processes and violates the requirement that each microservice has its own build pipeline. Option D is wrong because a single multi-stage YAML pipeline that builds and deploys all microservices together does not consume separate build artifacts and would rebuild everything on each change, contradicting the goal of avoiding pipeline rebuilds.

Practice this question →

177

MCQmedium

You have a YAML pipeline with multiple jobs that need to run in parallel. However, one job depends on artifacts produced by a previous job. How should you configure the dependency?

A.Set dependsOn on the dependent job and use PublishBuildArtifacts and DownloadBuildArtifacts tasks.

B.Use the 'dependsOn' keyword only, artifacts are automatically shared.

C.Set the 'condition' to 'eq(variables['Agent.JobStatus'], 'Succeeded')' on the dependent job.

D.Use the 'pool' keyword to ensure both jobs run on the same agent.

AnswerA

To share artifacts between jobs in Azure Pipelines, you need both an execution dependency and an explicit artifact transfer. The `dependsOn` keyword on the dependent job ensures it runs only after the dependency job completes, but files are not automatically shared; instead, you must use the `PublishBuildArtifacts` task in the source job to publish the files and the `DownloadBuildArtifacts` task in the dependent job to retrieve them.

Why this answer

In Azure DevOps YAML pipelines, job dependencies are explicitly declared using the `dependsOn` keyword, and artifacts must be published and downloaded using `PublishBuildArtifacts` and `DownloadBuildArtifacts` tasks (or the `publish` and `download` pipeline decorators). Without explicit artifact sharing, outputs from one job are not automatically available to another job, even if `dependsOn` is set.

Exam trap

The trap here is that candidates assume `dependsOn` alone handles artifact sharing, but Azure DevOps requires explicit publish/download tasks because jobs may run on different agents with no shared file system.

Why the other options are wrong

Artifacts must be explicitly published and downloaded.

Condition controls execution but does not handle artifact sharing.

Same agent is not guaranteed and doesn't handle dependencies.

Practice this question →

178

Multi-Selectmedium

Your team is adopting Azure Pipelines for a new project. You need to ensure that only authorized users can approve releases to production. Which two methods can you use to implement approval checks?

Select 2 answers

A.Configure pre-deployment approvals on the Production environment.

B.Use Deployment Gates with a manual approval gate.

C.Set the 'Required approvers' field on the environment to a specific user or group.

D.Add a Manual Intervention task in the release pipeline.

E.Add an Approval Check to the agent pool.

AnswersA, C

In Azure Pipelines, pre-deployment approvals on an environment require designated approvers to manually approve before any release deployment to that environment, providing a controlled go/no-go checkpoint. This is the standard mechanism for enforcing manual sign-off on production deployments, unlike automated gates.

Why this answer

Pre-deployment approvals on the Production environment (Option A) allow you to require one or more users or groups to approve a release before it is deployed to that environment. Similarly, setting the 'Required approvers' field on the environment (Option C) specifies the users or groups that must approve the deployment, which is another native Azure Pipelines approval mechanism. Both enforce authorization at the environment level, ensuring only designated approvers can promote a release to production.

Exam trap

The trap here is confusing 'Deployment Gates' (which are automated health evaluation checks) with 'Approval Checks' (which are manual sign-offs), leading candidates to incorrectly select Option B as a valid method for approval checks.

Practice this question →

179

Multi-Selecthard

You are designing a release pipeline that must deploy to Azure App Service across multiple regions. Which two practices should you implement to minimize downtime during deployments? (Choose 2)

Select 2 answers

A.Use Azure App Service deployment slots and perform a swap

B.Stop the web app before deploying, then start it after

C.Implement a rolling deployment strategy across regions

D.Deploy to all regions simultaneously

E.Use a single deployment slot for all regions

AnswersA, C

Use Azure App Service deployment slots and perform a swap: This is correct because deployment slots are live environments with their own hostnames, allowing you to stage a new build, run smoke tests, and then swap it into production instantly. The swap ensures zero downtime because the roles are atomically exchanged and Azure warms up the target slot before completing the operation.

Why this answer

Azure App Service deployment slots allow you to deploy a new version of your application to a staging slot, perform validation, and then swap it into production with zero downtime. The swap operation warms up the target slot and smoothly transitions traffic, ensuring no requests are dropped during the update. Additionally, implementing a rolling deployment strategy across regions reduces the blast radius and allows you to gradually shift traffic, further minimizing downtime during multi-region updates.

Exam trap

The trap here is that candidates often confuse 'minimizing downtime' with 'eliminating all risk' and may incorrectly choose to stop the app (Option B) or deploy simultaneously (Option D), not realizing that deployment slots and rolling updates are the standard Azure patterns for zero-downtime deployments.

Why the other options are wrong

Stopping the app causes downtime.

Simultaneous deployment can cause full outage if something goes wrong.

A single slot doesn't allow zero-downtime swap.

Practice this question →

180

MCQeasy

You need to automatically run a pipeline when a new tag is pushed to the repository. Which trigger configuration should you use?

A.Tags trigger

B.Schedule trigger

C.PR trigger

D.CI trigger with branch filters

AnswerA

A tags trigger filters pipeline execution to tag push events, satisfying the requirement to run automatically when a new tag appears. Unlike branch triggers, which respond to commits on branches, tag triggers match refs/tags patterns, so pushes to branches never fire the pipeline. This precisely targets the tag-push constraint in the stem.

Why this answer

Tags trigger allows running pipelines when a tag is pushed or updated. Option B (Schedule trigger) is incorrect because it runs on a predefined schedule, not on tag events. Option C (PR trigger) is incorrect because it triggers on pull request actions, not on tags.

Option D (CI trigger with branch filters) is incorrect because CI trigger monitors branches, not tags; even with branch filters it does not respond to tags.

Practice this question →

181

Multi-Selecthard

Which THREE steps should you take to implement a secure CI/CD pipeline that uses secrets from Azure Key Vault?

Select 3 answers

A.Use the Azure Key Vault task to download secrets as variables

B.Use secret variables in the pipeline that reference Key Vault secrets

C.Store secrets as plain text variables in the pipeline library

D.Hardcode secrets in the YAML file and use variables to mask them

E.Grant the build agent managed identity access to the Key Vault

AnswersA, B, E

The Azure Key Vault task authenticates to the vault and downloads the specified secrets as pipeline variables at runtime, ensuring that secret values are never stored in the pipeline definition or source control. This approach keeps secrets out of the YAML and only exposes them to tasks that need them, and the values are automatically masked if used in logs.

Why this answer

The Azure Key Vault task in Azure Pipelines can download secrets as pipeline variables at runtime, allowing the pipeline to securely reference them without exposing the secret values in logs or configuration. This task authenticates to Key Vault using a service connection or managed identity, ensuring secrets are never stored in the pipeline definition.

Exam trap

The trap here is that candidates often confuse 'masking' secrets in logs (Option D) with true secret isolation, mistakenly thinking that masking alone provides sufficient security, whereas Azure Key Vault integration ensures secrets are never stored in the pipeline definition or source control.

Practice this question →

182

MCQhard

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

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

B.The workflow run fails with an error about secret exposure

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

D.The secret value is masked with asterisks in the log output

AnswerD

When a configured secret appears in the workflow log, GitHub Actions automatically scans the output and replaces every occurrence of the secret's value with `***` to prevent exposure. This masking occurs at the log-upload stage, so even indirect leakage via environment variables or command outputs is redacted in the displayed logs.

Why this answer

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

Exam trap

The trap here is that candidates may confuse GitHub Actions' automatic log masking with a workflow failure or pre-execution redaction, but the key is that masking happens at runtime in the log output without stopping the workflow.

How to eliminate wrong answers

Option A is wrong because secrets are not replaced with an empty string; they are masked with asterisks (`***`) to preserve log readability while hiding the value. Option B is wrong because the workflow does not fail due to secret exposure; GitHub Actions does not automatically fail a run when a secret is logged—it only masks the output. Option C is wrong because the secret is not redacted before the step runs; it is available for use, and the step does not fail if it tries to use the secret—the masking occurs in the log output after execution.

Practice this question →

183

MCQhard

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

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

B.Store the API key as a secret variable in the pipeline library or variable group

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

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

AnswerB

Secret variables stored in the pipeline library or a variable group are encrypted at rest with Azure Key Vault-backed encryption and are masked in all pipeline logs and output. This is the recommended approach for handling sensitive values like API keys because it centralizes secure storage and prevents accidental leakage.

Why this answer

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

Exam trap

The trap here is that candidates may think retrieving secrets from Key Vault is always secure, but failing to mark the output as secret (Option A) or using non-secret variable templates (Option C) will expose the value in logs, which is a common oversight.

How to eliminate wrong answers

Option A is wrong because not marking the output as secret means the retrieved value will be visible in plain text in logs, defeating the purpose of using Key Vault. Option C is wrong because setting 'isSecret: false' explicitly marks the variable as non-secret, so it will be displayed in logs and is not encrypted. Option D is wrong because plain text variables are stored in clear text and are not masked in logs, making them vulnerable to exposure.

Practice this question →

184

MCQhard

Refer to the exhibit. This is a deployment job definition in a multi-stage YAML pipeline. The deployment fails because the Kubernetes service connection 'aks-prod' cannot be found. What is the most likely cause?

A.The approval for production environment is blocking the deployment.

B.The agent pool does not have access to the AKS cluster.

C.The service connection 'aks-prod' does not exist in the Azure DevOps project.

D.The namespace 'prod' does not exist in the AKS cluster.

AnswerC

The YAML deployment job references `aks-prod` via the `azureSubscription` or `connectionRef` field, and Azure DevOps must resolve this to an existing service connection in the project before any Kubernetes interaction occurs. If no service connection named `aks-prod` exists, the pipeline fails with a 'not found' error during the configuration phase, confirming this as the root cause.

Why this answer

The error message explicitly states that the Kubernetes service connection 'aks-prod' cannot be found. In Azure DevOps, a service connection is a stored credential set that must exist in the project before it can be referenced in a YAML pipeline. If the connection name is misspelled, deleted, or never created, the pipeline will fail at the deployment job stage regardless of other configurations.

Exam trap

The trap here is that candidates may confuse a missing service connection with runtime issues like namespace existence or agent permissions, but the error message is explicit about the connection not being found in the Azure DevOps project, not about a failure to connect to the cluster.

How to eliminate wrong answers

Option A is wrong because approval gates block the pipeline run from proceeding to the deployment stage, but they do not produce a 'service connection not found' error; they produce a pending approval status. Option B is wrong because agent pool access to the AKS cluster is managed via the service connection's credentials (e.g., kubeconfig or service principal), not directly by the agent pool; the error is about the connection object itself, not runtime access. Option D is wrong because a missing namespace in AKS would cause a Kubernetes API error (e.g., 'namespace not found') during the deployment step, not a failure to locate the service connection definition in Azure DevOps.

Practice this question →

185

Multi-Selectmedium

Which TWO benefits does using deployment groups provide in Azure Pipelines? (Choose two.)

Select 2 answers

A.You can deploy to a specific set of target servers (e.g., all web servers in a farm).

B.They enable rolling deployments with health validation.

C.You can assign multiple deployment groups to a single agent.

D.Each target server must have its own agent.

E.Deployment groups can only be used with classic release pipelines.

AnswersA, B

Deployment groups allow you to define a logical set of target machines that share the same deployment role, such as all web servers in a farm. This enables precise, scoped deployments to specific servers within an environment, rather than deploying to an entire pool arbitrarily.

Why this answer

Deployment groups in Azure Pipelines allow you to define a logical set of target machines (e.g., all web servers in a farm) and deploy to them collectively. This enables targeted, multi-machine deployments without needing to manage individual agents per environment. Option B is correct because deployment groups support rolling deployments with built-in health validation, where the pipeline can monitor application health after each batch of updates and automatically roll back on failure.

Exam trap

The trap here is that candidates often confuse deployment groups with environment-level approvals or think they are exclusive to classic pipelines, but deployment groups are a flexible agent-based targeting mechanism that works across both classic and YAML pipelines.

Practice this question →

186

MCQeasy

Your organization uses Azure DevOps. You have a classic release pipeline that deploys to multiple stages: Dev, QA, and Prod. Each stage has a pre-deployment approval gate. Recently, the QA team complained that they are not receiving approval notifications. You have verified that the approval configuration is correct and the approvers are members of the 'QA Approvers' group. The release pipeline is set to send email notifications to the approvers. However, the QA approvers report they do not receive any emails when a release is pending their approval. What should you check first?

A.Ask the QA team to check their spam folder.

B.Verify that the organization-level notification settings allow email notifications for approvals.

C.Add a 'Send email' task in the pipeline before the approval gate.

D.Check the 'Release Pipeline' logs for a warning about email delivery failure.

AnswerB

Verify that the organization-level notification settings allow email notifications for approvals, specifically the 'Release approval pending' subscription. In Azure DevOps, this subscription is a default system subscription that may be disabled or scoped to specific roles, and if it is turned off, approvers will not receive any approval notification emails regardless of personal notification preferences.

Why this answer

In Azure DevOps, email notifications for approvals are governed by organization-level (and sometimes project-level) notification settings, not just the pipeline's own configuration. If the organization has disabled or restricted the 'Approval pending' notification, approvers will not receive emails even though the pipeline is configured to send them. Verifying organization notification settings is therefore the correct first check.

Exam trap

AZ-400 often tests whether candidates know that Azure DevOps notification behavior is controlled at the organization and user levels, not just the pipeline — candidates pick pipeline-level fixes (adding email tasks or checking logs) when the real cause is a global notification setting.

How to eliminate wrong answers

Option A is wrong because asking users to check spam is a low-value first step — while spam filtering can occur, the question states the configuration is correct and the issue affects a whole group, which points to a systemic setting rather than individual mail filtering. Option C is wrong because adding a 'Send email' task before the approval gate does not address the approval notification mechanism and would be a workaround, not a diagnosis; it also cannot send to approvers dynamically as the built-in approval notification does. Option D is wrong because release pipeline logs do not typically surface email delivery failures for approval notifications — those are handled by the notification service, and the logs would not show a warning about email delivery.

Practice this question →

187

MCQmedium

Your organization is adopting GitHub Actions for CI/CD. You need to ensure that only approved actions from your enterprise can be used in workflows. What should you configure?

A.Use a third-party tool to scan workflows for disallowed actions after each commit.

B.Set the enterprise policy to 'Allow all actions' and rely on code review.

C.Configure repository permissions to restrict actions to only those created by your organization.

D.Set the enterprise policy to 'Allow only specific actions' and add approved actions.

AnswerD

Setting the enterprise policy to 'Allow only specific actions' and adding approved actions is the correct approach because it enforces centrally across every repository in the enterprise. This proactive policy ensures that only vetted, approved actions from the allowlist can be used, preventing disallowed actions from ever running in the CI/CD pipeline.

Why this answer

GitHub Enterprise allows administrators to restrict which actions can be used in workflows by setting the enterprise policy to 'Allow only specific actions' and then explicitly approving a curated list of actions. This ensures that only trusted, pre-approved actions (e.g., from verified publishers or your own organization) can be referenced, preventing the execution of unapproved or malicious actions. This policy is enforced at the enterprise level and applies to all repositories within the enterprise, providing centralized control over CI/CD supply chain security.

Exam trap

The trap here is that candidates often confuse repository-level permissions (which do not have a 'restrict by creator' option) with enterprise-level policies, leading them to select Option C, which sounds plausible but is not a valid configuration in GitHub.

How to eliminate wrong answers

Option A is wrong because using a third-party tool to scan workflows after each commit is reactive and does not prevent the execution of disallowed actions at runtime; it also adds unnecessary complexity and latency. Option B is wrong because setting the enterprise policy to 'Allow all actions' and relying solely on code review is insecure and does not enforce any technical restriction, leaving the environment vulnerable to unapproved or malicious actions being merged and executed. Option C is wrong because configuring repository permissions to restrict actions to only those created by your organization is not a valid GitHub setting; GitHub does not have a built-in repository-level permission that filters actions by creator, and this approach would not cover actions from other trusted publishers or verified creators.

Practice this question →

188

MCQmedium

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

A.Set up a release pipeline that uses the same build artifact and requires manual approval.

B.Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.

C.Use a build trigger on the staging branch to deploy after each commit, ignoring test results.

D.Define the pipeline with a single stage and use a condition to skip test on failure.

AnswerB

Separating build, test, and deploy into distinct stages with dependsOn ensures strict sequential execution: build completes, tests pass, then deploy runs. Publishing the artifact in the build stage and downloading it in the deploy stage preserves the exact compiled output, making the pipeline reliable and providing automatic gatekeeping based on test success.

Why this answer

Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.

Exam trap

The trap here is that candidates may confuse release pipelines with multi-stage YAML pipelines, thinking manual approval is required for deployment control, but the question specifically requires using the exact same bits and conditional stage execution, which is directly achieved with 'dependsOn' and artifact publishing/downloading.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with manual approval, which does not inherently ensure that the deployment uses the exact same bits from the build; it could use a different artifact version if not properly configured, and manual approval is not required for the scenario. Option C is wrong because using a build trigger on the staging branch and ignoring test results violates the requirement that the deployment stage only runs if tests succeed; it would deploy regardless of test outcomes. Option D is wrong because defining a single stage with a condition to skip tests on failure does not enforce that the deployment uses the same bits from the build; it also does not provide the multi-stage separation needed for the build, test, and deploy phases.

Practice this question →

189

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 →

190

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 automatically at defined times, independent of code changes. This satisfies the question's requirement for a valid release trigger, enabling recurring deployments such as nightly or maintenance-window releases without manual intervention.

Why this answer

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

Option D (Work item state change) is not a supported release trigger in Azure Pipelines. Option E (Pull request) is a build/CI trigger (PR triggers on branches), not a release trigger.

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 →

191

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 →

192

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 →

193

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

In Azure Pipelines, artifact names must be unique within a pipeline run. When two jobs (Build and Test) each run a PublishBuildArtifacts task with the same artifact name 'drop', the second publish conflicts with the first, causing the 'Publish Artifact' step to fail. The fix is to use distinct artifact names per job or use a single job to publish.

Exam trap

The trap is assuming the failure is environmental (size, permissions, naming rules) when the exhibit actually shows two jobs publishing the same artifact name — a classic Azure DevOps uniqueness constraint.

How to eliminate wrong answers

Option A is wrong because 'drop' is a valid artifact name; Azure DevOps allows alphanumeric names and common characters, so invalid characters are not the issue. Option B is wrong because artifact size limits (e.g., 2 GB per file for Azure Pipelines) are far larger than typical build outputs and would produce a different, size-specific error. Option D is wrong because the pipeline's build service account has publish permissions by default; a permissions failure would show an authorization error, not a naming conflict.

Practice this question →

194

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 →

195

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 →

196

MCQeasy

You are configuring a build pipeline in Azure Pipelines that compiles a .NET application. You need to ensure that the pipeline uses a specific version of the .NET SDK, which is installed on the agents. The agents are Microsoft-hosted. What should you add to your YAML pipeline?

A.A variable named 'DotNetVersion' set to the desired version and referenced in the build task.

B.The UseDotNet@2 task with the desired version specified.

C.A task that runs 'dotnet --version' to verify the SDK version.

D.A script that downloads and installs the .NET SDK from the official website.

AnswerB

The UseDotNet@2 task installs or selects the specified .NET SDK version on the agent. This ensures that subsequent tasks, such as the build, use the correct SDK. It is the recommended way to pin the .NET SDK version in Azure Pipelines.

Why this answer

The UseDotNet@2 task is designed to install or select a specific .NET SDK version on the agent. This ensures that the build uses the correct SDK. Other options do not effectively control the SDK version used by the build.

Exam trap

The trap here is assuming that a script to check the version or a variable will influence which SDK is used; only the UseDotNet@2 task actually sets the SDK for subsequent tasks.

Practice this question →

197

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 →

198

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 →

199

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 →

200

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 →

201

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 →

202

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 →

203

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 →

204

MCQeasy

Refer to the exhibit. You run the Azure CLI command to trigger a pipeline run. The pipeline fails because tests were skipped but should have run. What is the most likely issue?

A.The JSON value for skipTests must be a boolean without quotes.

B.The pipeline name is incorrect.

C.The command uses a flag '--variables-parameters' which is not a valid Azure DevOps CLI option.

D.The branch 'feature/new-feature' does not exist.

AnswerA

The Azure DevOps CLI `az pipelines run` accepts variable values as JSON strings via `--variables`, and quoted booleans are passed as strings. However, the actual failure is that `--variables-parameters` is an invalid flag, so the command never parses this JSON to begin with.

Why this answer

The Azure DevOps CLI `az pipelines run` supports `--variables` and `--parameters` but not `--variables-parameters`. If that invalid flag were used, the command would fail before any pipeline run is triggered. The symptom says the pipeline ran and skipped tests, which is typically caused by passing `skipTests` as a string value (e.g., `"false"`) rather than a boolean `false`.

In Azure DevOps, pipeline variables are strings, so a value of `'false'` is interpreted as a non-empty string and evaluated as `true` in conditional logic. For runtime parameters of type boolean, the correct syntax is `--parameters '{"skipTests":false}'` (value without quotes).

Exam trap

Candidates may incorrectly blame an invalid CLI flag when the actual issue is with how a runtime parameter value is passed. Remember: `--variables` are strings; `--parameters` accepts JSON and requires boolean values without quotes.

How to eliminate wrong answers

Option A is wrong because in Azure CLI, JSON values passed via `--variables` are interpreted as strings; the `skipTests` value being `"true"` (a quoted string) is acceptable and does not cause tests to be skipped—the issue is the flag itself. Option B is wrong because if the pipeline name were incorrect, the CLI would return a 'pipeline not found' error, not a failure due to skipped tests. Option D is wrong because if the branch did not exist, the pipeline run would fail with a 'branch not found' error, not a test-skipping issue.

Practice this question →

205

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 →

206

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

In Azure DevOps, agent pool security is controlled through the pool's permissions. By setting permissions on the agent pool, you can restrict which projects, pipelines, or users are allowed to use the agents, ensuring only authorized pipelines can run on them. This is the direct, built-in mechanism for securing a self-hosted agent pool.

Exam trap

AZ-400 often tests the confusion between agent registration tokens (used to join an agent to a pool) and pool permissions (used to control which pipelines can use the pool).

How to eliminate wrong answers

Option B is wrong because agent tokens are used during agent registration to authenticate the agent to the pool, not to authorize which pipelines can use the pool. Option C is wrong because variable groups store variables and secrets for pipelines; they have no role in controlling agent pool access. Option D is wrong because 'agent queues' is not a distinct Azure DevOps security feature — queues are associated with pools, and access is governed by pool permissions, not by configuring queues.

Practice this question →

207

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

The AzureWebApp@1 task deploys the built artefact to the Web App's configured runtime; if the app's stack is DOTNETCORE|6.0 but the artefact targets an incompatible framework, the task rejects it. The mismatch between configured stack and application is the cause.

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 →

208

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 →

209

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 AzureKeyVault task retrieves the code-signing certificate from Key Vault into the pipeline agent, making it available to the signing step. This satisfies the regulatory requirement that the certificate stays in Key Vault rather than being stored insecurely in the repository.

Why this answer

Option A is correct because the AzureKeyVault task (AzureKeyVault@2) is the supported pipeline task for retrieving secrets, including a code-signing certificate, from an Azure Key Vault so the certificate can be used during the build. Option B is correct because after the assembly is built, a script or command-line step must invoke a signing tool such as signtool.exe with the certificate to apply the code-signing signature to the .NET Core assembly. Option C is correct because the Azure Pipelines service principal (or the identity running the pipeline) must be granted access to the Key Vault, typically via an access policy or Azure RBAC role such as Key Vault Secrets User, otherwise the AzureKeyVault task cannot retrieve the certificate.

Option D is not correct because storing the certificate in a secure file in the build artifact does not satisfy the requirement to use a certificate stored in Azure Key Vault and can expose the private key in the artifact. Option E is not correct because packaging before signing would leave the package unsigned; signing must occur on the assembly before it is packaged so the signature is included in the final artifact.

Exam trap

AZ-400 often tests whether candidates confuse 'storing the certificate in a secure file' (a legacy, non-compliant pattern) with the modern Key Vault task approach, and whether they understand signing must occur post-build but pre-packaging.

Practice this question →

210

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

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

Exam trap

AZ-400 often tests the confusion between reusable workflows and composite actions, where candidates mistakenly believe a composite action can be called like a workflow or that a standard workflow can be reused without the workflow_call trigger.

How to eliminate wrong answers

Option A is wrong because a standard workflow with triggers like 'on: push' or 'on: pull_request' cannot be directly invoked by other workflows; it only runs on its own events. Option B is wrong because a composite action encapsulates a series of steps within a single job and cannot define multiple jobs or use its own runner, limiting its reusability for full build and test workflows. Option C is wrong because a custom action (JavaScript or Docker) is a single task, not a workflow; it cannot contain jobs or be called as a workflow, and referencing it in multiple workflows still requires duplicating the job structure.

Practice this question →

211

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

Token replacement keeps the same config file across branches while substituting environment-specific values at deploy time, and variable groups hold secrets so they are masked in logs. App Service configuration supplies runtime settings, satisfying environment-specificity, secret protection and local development parity.

Why this answer

The correct strategy is to store environment-specific settings in Azure App Service configuration (which can be set per slot/environment) and use Azure Pipelines variable groups for secrets, ensuring they are not exposed in logs. Token replacement in the config file during deployment allows the same config file to be used across environments while injecting environment-specific values. This supports local development because developers can use local settings or user secrets without committing sensitive data.

Exam trap

AZ-400 often tests the misconception that storing secrets in config files or pipeline variables without proper masking is acceptable, or that a single config file with overrides is sufficient; candidates must recognize the need for secure secret storage and environment-specific configuration.

How to eliminate wrong answers

Option A is wrong because storing secrets in a config file in each branch exposes them in the repository and pipeline logs, violating security best practices. Option B is wrong because using a single config file with all settings committed to the repository still exposes secrets and does not provide environment-specific separation; sticky settings alone do not secure secrets. Option D is wrong because using the same config file and overriding with pipeline variables based on branch name can work for non-sensitive values but does not address secure storage of secrets and may still expose them if not handled properly; it also lacks a clear mechanism for local development.

Practice this question →

212

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 →

213

MCQeasy

You are creating a YAML pipeline in Azure Pipelines that must run three jobs: 'Build', 'Test', and 'Deploy'. The 'Test' job must run only after the 'Build' job completes successfully, and the 'Deploy' job must run only after the 'Test' job completes successfully. You need to configure the dependencies between jobs. What should you use?

A.condition

B.dependsOn

C.continueOnError

D.stages

AnswerB

The 'dependsOn' keyword in Azure Pipelines YAML defines the order of job execution. By specifying 'dependsOn: Build' in the Test job and 'dependsOn: Test' in the Deploy job, you ensure that each job runs only after its dependency completes successfully. This is the correct way to model sequential job dependencies.

Why this answer

To enforce sequential job execution where each job runs only after the previous one succeeds, you must use the 'dependsOn' keyword. This explicitly defines the dependency graph, ensuring that the Test job waits for Build and the Deploy job waits for Test, and that a failure in a dependency prevents dependent jobs from running.

Exam trap

The trap here is confusing 'condition' with 'dependsOn'; 'condition' controls whether a job runs but does not create a dependency, so jobs would still run in parallel unless 'dependsOn' is also specified.

Practice this question →

214

Drag & Dropmedium

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

Drag or tap steps into the slots.

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 →

215

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 →

216

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 →

217

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 →

218

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 →

219

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 →

220

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

In Azure Pipelines, when a variable is defined in the pipeline YAML and the 'Settable at queue time' option is not enabled, the queue-time value is ignored and the pipeline definition's default value is used. Since the default is 'Debug' and overrides are not allowed, the build runs with BuildConfiguration=Debug (A). The developer's attempt to set 'Release' at queue time has no effect.

Exam trap

AZ-400 often tests variable precedence and the 'Settable at queue time' setting, tricking candidates into assuming queue-time values always override pipeline defaults.

How to eliminate wrong answers

Option B is wrong because the queue-time value 'Release' is discarded when the variable is not marked as settable at queue time — the pipeline definition value takes precedence. Option C is wrong because the variable is defined with a default of 'Debug', so it is never null. Option D is wrong because supplying a queue-time value for a non-overridable variable does not cause a build failure; Azure Pipelines silently ignores the override and proceeds with the default.

Practice this question →

221

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 →

222

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 →

223

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 stores restored NuGet packages between runs, keyed on the hash of `packages.lock.json`, so a cache hit skips the 15-minute dependency restoration entirely. Keying on the lock file invalidates the cache precisely when dependencies change, satisfying the requirement to speed up subsequent builds without serving stale packages.

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 →

224

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 →

225

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 →