Courseiva

CCNA Build Release Pipelines Questions

75 of 414 questions · Page 3/6 · Build Release Pipelines topic · Answers revealed

Practice these questionsExam hubAll questions
151
MCQeasy

You are designing a release pipeline for a .NET application. The pipeline must deploy to multiple environments (Dev, Test, Prod) with manual approval at each stage. Which release trigger should you configure for the production stage?

A.Pull request trigger from the main branch.
B.Continuous deployment trigger after a successful build.
C.Manual trigger with pre-deployment approvals.
D.Scheduled trigger set to run nightly.
AnswerC

A manual trigger requires a user to explicitly initiate the release, and adding pre-deployment approvals ensures that a designated approver must authorize the deployment before it proceeds. This combination gives full human control over when the release starts and enforces a review step, which directly supports the design requirement.

Why this answer

The requirement specifies manual approval at each stage, and for the production stage, a manual trigger with pre-deployment approvals ensures that deployments only occur after explicit human authorization. This aligns with the need for controlled, gated releases to production, preventing automatic or scheduled deployments that bypass approval.

Exam trap

The trap here is that candidates confuse build triggers (like PR or continuous integration) with release triggers, mistakenly applying build automation concepts to production deployment stages where manual approval is required.

How to eliminate wrong answers

Option A is wrong because a pull request trigger from the main branch is used for build validation or testing, not for release deployment triggers; it would initiate a build or test run on PR creation, not a production deployment with approvals. Option B is wrong because continuous deployment trigger after a successful build would automatically deploy to production without manual approval, violating the requirement for manual approval at each stage. Option D is wrong because a scheduled trigger set to run nightly would deploy automatically on a fixed schedule, bypassing the required manual approval and pre-deployment gates for production.

Practice this question →
152
MCQmedium

Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?

A.Add a PowerShell task that wraps the NuGet restore in a retry loop
B.Increase the number of parallel jobs to average out failures
C.Use a deployment group to deploy the build to a staging environment
D.Configure a build retention policy to automatically retry failed builds
AnswerA

Wrapping the NuGet restore in a PowerShell task enables you to implement a retry loop that checks exit codes and repeats the restore operation on transient failures (e.g., HTTP timeouts or package source throttling), while allowing the build to fail after a defined number of attempts. This directly addresses the intermittent nature of the failure without requiring changes to the pipeline's parallelism or deployment topology.

Why this answer

Adding a PowerShell task that wraps the NuGet restore command in a retry loop directly addresses transient network failures by reattempting the download. This approach is lightweight, customizable (e.g., using `Start-Sleep` between retries), and does not require changing pipeline architecture or relying on external infrastructure.

Exam trap

The trap here is that candidates confuse build-level retry mechanisms (like retention policies or parallel jobs) with step-level retry logic, assuming Azure Pipelines automatically handles transient failures when it does not.

How to eliminate wrong answers

Option B is wrong because increasing parallel jobs does not retry a failed step; it only runs more builds concurrently, which may increase load on the network and exacerbate failures. Option C is wrong because deployment groups are used for deploying to target environments, not for handling transient build-time failures like NuGet restore errors. Option D is wrong because build retention policies control how long artifacts are kept, not how failed builds are retried; Azure Pipelines does not automatically retry builds based on retention settings.

Practice this question →
153
Matchingmedium

Match each Azure Pipeline concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Compute resource to run jobs

Logical boundary for pipeline phases

Sequence of steps on a single agent

Atomic build or deployment action

Why these pairings

The correct matches are: A: Pipeline → 'A collection of stages that defines the CI/CD process' (correct); B: Stage → 'A logical boundary in the pipeline used to group jobs' (correct); C: Job → 'A unit of work that runs on an agent' (correct); D: Task → 'A single operation to perform in a job' (correct). E is incorrect because Pipeline is not a logical boundary; that definition belongs to Stage. F is incorrect because Stage is not a collection of stages; that definition belongs to Pipeline.

The most common confusion is swapping the definitions of Pipeline and Stage.

Practice this question →
154
MCQeasy

You are creating a release pipeline that uses Azure Pipelines to deploy to multiple virtual machines. You need to ensure that the deployment runs on each machine in parallel. Which deployment strategy should you use?

A.Blue-green deployment
B.Canary deployment
C.Rolling deployment
D.Run once deployment with parallel execution
AnswerD

Run once deployment with parallel execution is correct because it configures the deployment job to run on all targets in the deployment group at the same time, executing the tasks concurrently across every machine. This approach directly fulfills the requirement of running the job on all targets simultaneously, ensuring consistent and synchronized deployment.

Why this answer

The requirement is to deploy to multiple virtual machines in parallel, which is achieved by configuring a 'run once' deployment strategy with parallel execution in Azure Pipelines. This strategy uses the deployment group's parallel execution settings to run the deployment job simultaneously on all target machines, ensuring each machine receives the deployment at the same time.

Exam trap

The trap here is that candidates often confuse 'rolling deployment' with parallel execution, but rolling is inherently sequential (batched), while the question explicitly requires parallel execution across all machines, which is only achieved by the 'run once' strategy with parallel execution enabled.

How to eliminate wrong answers

Option A is wrong because blue-green deployment is a strategy that maintains two identical environments (blue and green) and switches traffic between them, not a method for parallel deployment to multiple VMs within the same environment. Option B is wrong because canary deployment gradually rolls out changes to a subset of users or servers before expanding, which is inherently sequential and not parallel across all machines. Option C is wrong because rolling deployment updates machines one by one or in batches (e.g., 20% at a time) to minimize downtime, which is sequential, not parallel.

Practice this question →
155
Multi-Selectmedium

Which TWO are valid strategies for managing secrets in a GitHub Actions workflow?

Select 2 answers
A.Use OpenID Connect to authenticate to Azure without storing any credentials.
B.Hardcode the secret in the YAML file.
C.Set the secret as an environment variable in the runner's shell profile.
D.Base64-encode the secret and include it directly in the workflow file.
E.Store the secret as an encrypted GitHub secret and reference it using ${{ secrets.SECRET_NAME }}.
AnswersA, E

OpenID Connect (OIDC) allows GitHub Actions workflows to request short-lived tokens from Azure AD by exchanging a signed JWT from GitHub's OIDC provider, eliminating the need to store static credentials like client secrets or service principal passwords. This is a valid strategy because it reduces secret exposure and enables automatic credential rotation.

Why this answer

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token directly with Azure without storing any long-lived credentials as secrets. This eliminates the need to manage and rotate client secrets or service principal passwords, reducing the risk of credential leakage. The workflow uses the `azure/login` action with `client-id`, `tenant-id`, and `subscription-id` parameters, and Azure trusts the OIDC token issued by GitHub.

Alternatively, storing the secret as an encrypted GitHub secret is also a valid strategy: GitHub encrypts secrets at rest and injects them into the workflow runtime only when referenced via `${{ secrets.SECRET_NAME }}`. This prevents hardcoding secrets in the YAML and keeps them out of logs, though it still requires managing the secret value and rotation.

Exam trap

The trap here is that candidates often confuse Base64 encoding with encryption, mistakenly believing it provides security, or they think environment variables on the runner are isolated per job, when in fact they can leak across steps or be read by other processes on the same runner.

Practice this question →
156
MCQmedium

Your team uses Azure Repos for source control. You need to enforce that all builds must pass unit tests before code can be merged into the main branch. Which branch policy should you configure?

A.Add a build validation policy that triggers the CI pipeline and requires it to succeed.
B.Require a linked work item.
C.Require a minimum number of reviewers.
D.Require comment resolution.
AnswerA

A build validation policy in Azure Repos branch policies attaches an automated pipeline to the PR as a required gate. When a PR is created or updated, Azure Pipelines runs the specified CI pipeline and posts a status back to the PR; the merge is blocked unless the policy reports a successful pipeline run. This directly enforces build integrity at the merge point, making it the correct way to ensure that code compiles and tests pass before it enters the target branch.

Why this answer

Azure Repos branch policies allow you to add a build validation policy that triggers a CI pipeline (e.g., a YAML or classic build pipeline) and requires it to succeed before a pull request can be completed. This ensures that all code merged into the main branch has passed unit tests, enforcing quality gates directly in the PR workflow.

Exam trap

The trap here is that candidates may confuse build validation policies with other branch policies like required reviewers or work item linking, thinking they indirectly enforce quality, but only build validation directly enforces that unit tests pass before merge.

How to eliminate wrong answers

Option B is wrong because requiring a linked work item ensures traceability to a work item (e.g., a user story or bug), but it does not enforce that builds pass unit tests. Option C is wrong because requiring a minimum number of reviewers enforces code review but does not validate build or test success. Option D is wrong because requiring comment resolution ensures that PR comments are addressed, but it does not enforce any build or test validation.

Practice this question →
157
MCQmedium

Your organization uses Azure Pipelines and requires that all builds be run on Microsoft-hosted agents to reduce maintenance overhead. However, you need to ensure that the build agent has a specific version of Node.js installed that is not available on the standard Microsoft-hosted agents. What should you do?

A.Use a container job that runs a custom Docker image with the required Node.js version.
B.Deploy a self-hosted agent with the required Node.js version.
C.Use a script task to install the specific Node.js version at the start of the pipeline.
D.Request Microsoft to add the Node.js version to their hosted agents.
AnswerA, C

Container jobs are supported on Microsoft-hosted agents that have Docker capability (e.g., ubuntu-latest). Using a custom Docker image with the required Node.js version is a valid approach because the container runs on the agent and can be configured with any tools.

Why this answer

Azure Pipelines supports container jobs on Microsoft-hosted agents with Docker (e.g., ubuntu-latest, windows-2019 with Docker enabled). By using a custom Docker image that includes the required Node.js version, you can run builds in a container while still using a Microsoft-hosted agent. Option C is also correct because you can use a script task at the start of the pipeline to install the specific Node.js version dynamically; Microsoft-hosted agents allow runtime installation of software via scripts.

Options B and D are incorrect: B would require a self-hosted agent, violating the Microsoft-hosted agent requirement; D is not practical and not a guaranteed solution.

Exam trap

The trap is that candidates often assume container jobs are not compatible with Microsoft-hosted agents, but many Microsoft-hosted agents (e.g., ubuntu-latest) have Docker installed and can run container jobs. Additionally, some might think installing Node.js via script is not allowed, but it is a supported practice.

How to eliminate wrong answers

Option A is wrong because container jobs require a self-hosted agent or a specific agent pool that supports Docker, and the question explicitly mandates using Microsoft-hosted agents, which do not support custom container jobs by default. Option B is wrong because deploying a self-hosted agent contradicts the requirement to reduce maintenance overhead by using Microsoft-hosted agents. Option D is wrong because Microsoft does not accept requests to add specific Node.js versions to their hosted agent images; they only update images periodically based on broad community demand.

Practice this question →
158
MCQhard

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

A.The build output is not copied to the staging directory
B.The projects pattern '**/*.csproj' does not match any files
C.The task 'PublishBuildArtifacts@1' is misspelled
D.The artifact name 'drop' is invalid
AnswerA

The PublishBuildArtifacts task publishes files from a staging directory (e.g., $(Build.ArtifactStagingDirectory)). If your build tasks only compile but never copy the compiled output (DLLs, EXEs) to that staging path, Azure DevOps uploads an empty folder, so the artifact contains no files despite the build succeeding.

Why this answer

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

Exam trap

The trap here is that candidates often focus on file matching patterns or task names, but the core issue is the missing copy step to the staging directory, which is a fundamental pipeline design concept.

How to eliminate wrong answers

Option B is wrong because if the projects pattern '**/*.csproj' does not match any files, the build itself would fail or produce no output, but the artifact would still be empty only if no files were copied to staging; this pattern mismatch would cause a build error, not an empty artifact. Option C is wrong because the task 'PublishBuildArtifacts@1' is correctly spelled and is a valid task identifier; a misspelling would cause a task not found error, not an empty artifact. Option D is wrong because the artifact name 'drop' is a valid and commonly used default name; an invalid name would cause a validation error, not an empty artifact.

Practice this question →
159
MCQhard

You are designing a build pipeline that uses Microsoft-hosted agents. The pipeline must build a .NET Framework 4.8 application and run on a Windows agent. Due to compliance, the build must use a specific version of Visual Studio that is not pre-installed on the Microsoft-hosted agents. What should you do?

A.Use a self-hosted agent that has the required version of Visual Studio installed.
B.Build the application inside a Docker container that includes the required Visual Studio version.
C.Specify the 'vsVersion' parameter in the MSBuild task to target the required version.
D.Use the 'Visual Studio Test Platform Installer' task to install the required version at build time.
AnswerA, B

Microsoft-hosted agents provide only a fixed set of pre-installed Visual Studio versions, so if the required version is absent, the build cannot run on them. A self-hosted agent can be explicitly provisioned with the exact Visual Studio version needed, and registered with an agent pool so pipeline jobs are matched to it via capabilities.

Why this answer

To use a specific version of Visual Studio not pre-installed on Microsoft-hosted agents, you can either use a self-hosted agent with that version installed, or run the build in a Docker container that includes the required Visual Studio/Build Tools version. Microsoft-hosted agents have Docker installed and can run Windows containers, so option B is viable. Options C and D do not install a full Visual Studio version.

Practice this question →
160
MCQeasy

Your build pipeline uses a self-hosted agent that runs on a Windows machine. The pipeline fails with the error: 'The task 'DotNetCoreCLI' is not supported on this agent.' What is the most likely cause?

A.The agent's execution policy is restricted.
B.The agent does not have the required capabilities (e.g., .NET Core SDK installed).
C.The agent is not authorized to run the pipeline.
D.The agent cannot connect to the internet to download the task.
AnswerB

Each task in an Azure DevOps pipeline declares required capabilities such as a specific SDK, tool, or platform version. When a self-hosted agent lacks a declared capability, such as the .NET Core SDK, the agent cannot execute the task and reports that the task is not supported, because the agent's available capabilities do not match the task's demands.

Why this answer

The error 'The task 'DotNetCoreCLI' is not supported on this agent' indicates that the agent lacks the required capabilities to execute the task. In Azure Pipelines, self-hosted agents must have the necessary software (e.g., .NET Core SDK) installed and declared as capabilities for the task to be considered supported. Option B correctly identifies this missing capability as the root cause.

Exam trap

The trap here is that candidates confuse a missing capability (which causes a 'not supported' error) with an authorization or connectivity issue, leading them to pick options C or D, when the real problem is the agent's software prerequisites.

How to eliminate wrong answers

Option A is wrong because the execution policy (e.g., PowerShell execution policy) affects script execution, not the agent's ability to support a specific task like DotNetCoreCLI. Option C is wrong because authorization issues (e.g., agent pool permissions) would result in a different error, such as 'Agent is not authorized' or 'Access denied', not a task support error. Option D is wrong because the DotNetCoreCLI task is a built-in task that does not require internet download; it runs locally on the agent, and connectivity issues would cause a different error (e.g., 'Unable to download task') or a timeout.

Practice this question →
161
MCQhard

A company uses Azure Pipelines with YAML-based pipelines stored in a Git repository. The pipeline triggers on every push to the main branch, but the team wants to reduce unnecessary builds when only documentation files are changed. What is the best way to achieve this?

A.Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.
B.Configure branch policy to require a pull request for documentation changes.
C.Add a 'condition' to the pipeline that checks if changed files are documentation.
D.Disable CI trigger and rely on scheduled builds.
AnswerA

Path filters in the trigger section use `trigger.paths.exclude` to prevent pipeline execution when only files under `docs/*` or matching `*.md` are changed; any other changed file will still trigger the pipeline, making this the correct, event-driven way to avoid documentation commits.

Why this answer

Path filters in the trigger section allow you to specify include and exclude patterns. By using exclude patterns for 'docs/*' and '*.md', the pipeline will not trigger when only documentation files are changed. Option B is incorrect because branch policies do not affect the pipeline trigger; they govern pull request requirements.

Option C is incorrect because conditions are evaluated at runtime, whereas we want to avoid triggering the pipeline altogether. Option D is incorrect because disabling CI trigger would require manual or scheduled builds, which is less efficient than using path filters.

Practice this question →
162
MCQmedium

You have a YAML pipeline that builds a Java project using Maven. The pipeline uses a private artifact feed in Azure Artifacts. You need to authenticate to the feed from the pipeline. Which authentication method should you use?

A.Use the 'PipAuthenticate' task with a pip.conf file.
B.Use the 'npmAuthenticate' task with a .npmrc file.
C.Use the 'MavenAuthenticate' task with a settings.xml file.
D.Use the 'NuGetAuthenticate' task with a nuget.config file.
AnswerC

The MavenAuthenticate task is the correct choice because it directly configures Maven's settings.xml with the appropriate credentials for Azure Artifacts. This enables the Java project to authenticate when downloading dependencies or publishing artifacts to a Maven feed, which is exactly what this pipeline requires.

Why this answer

The 'MavenAuthenticate' task is specifically designed to authenticate Maven builds against Azure Artifacts feeds. It injects credentials into a settings.xml file, which Maven uses to resolve dependencies from the private feed. This task handles the OAuth token exchange required for Azure DevOps authentication.

Exam trap

The trap here is that candidates may confuse the authentication task with the package type (e.g., choosing 'npmAuthenticate' for a Java project because they think 'npm' is generic), but Azure Artifacts requires a task specific to the client tool (Maven) and its configuration file (settings.xml).

How to eliminate wrong answers

Option A is wrong because 'PipAuthenticate' is for Python package feeds (PyPI), not Maven; it uses a pip.conf file for authentication. Option B is wrong because 'npmAuthenticate' is for npm package feeds and uses a .npmrc file, which is irrelevant to Maven builds. Option D is wrong because 'NuGetAuthenticate' is for NuGet package feeds and uses a nuget.config file, which does not apply to Maven's settings.xml-based authentication.

Practice this question →
163
Multi-Selecteasy

Which TWO are valid types of triggers for a YAML pipeline in Azure Pipelines? (Choose two.)

Select 2 answers
A.Push trigger
B.Scheduled trigger
C.Release trigger
D.PR trigger
E.Pipeline trigger
AnswersA, B

Correct. Push triggers are defined using the `trigger:` keyword and are the most common CI trigger.

Why this answer

A is correct because a push trigger in a YAML pipeline automatically starts a pipeline run when a push is made to a specified branch or tag. B is correct because scheduled triggers are also valid in YAML pipelines, allowing you to run a pipeline on a schedule defined using cron syntax. D (PR trigger) is also a valid YAML trigger, but the question asks for exactly two valid types; the intended correct pair is push and scheduled triggers.

Options C and E are not standard YAML trigger types in Azure Pipelines; release triggers are used in classic releases, and pipeline triggers are for triggering a pipeline from another pipeline, which is not a direct trigger type defined in the YAML file.

Exam trap

The trap is that candidates might think scheduled triggers cannot be configured in YAML (they can, using the `schedules:` keyword), or they might include PR triggers (which are valid but not one of the two expected correct answers in this question).

Practice this question →
164
Multi-Selectmedium

Which TWO tools can be used to manage feature flags in Azure DevOps pipelines?

Select 2 answers
A.Azure Policy.
B.LaunchDarkly.
C.Azure App Configuration.
D.Azure Monitor.
E.Azure Key Vault.
AnswersB, C

LaunchDarkly is a widely adopted third-party feature management platform that supports feature flags, gradual rollouts, A/B testing, and real-time targeting across applications. It integrates with Azure DevOps for release pipelines, making it a valid tool for managing feature flags in Azure-hosted applications.

Why this answer

LaunchDarkly is a third-party feature management platform that integrates with Azure DevOps pipelines to control feature flag rollouts, targeting, and experimentation. It allows teams to toggle features on/off without redeploying code, making it a valid tool for managing feature flags in pipeline-driven deployments.

Exam trap

The trap here is that candidates may confuse Azure App Configuration's feature flag capability with Azure Policy or Azure Monitor, assuming any Azure service with 'configuration' or 'monitoring' in its name can manage feature flags, but only App Configuration and third-party tools like LaunchDarkly are designed for this purpose.

Practice this question →
165
Multi-Selecthard

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Select 3 answers
A.DotNetCoreCLI@2 with command 'build'
B.NuGetCommand@2 with command 'install'
C.DotNetCoreCLI@2 with command 'restore'
D.DotNetCoreCLI@2 with command 'push'
E.DotNetCoreCLI@2 with command 'pack'
AnswersA, C, E

DotNetCoreCLI@2 with command 'build' compiles the source code and produces assembly outputs, forming the foundational step in any .NET pipeline. It validates that code compiles successfully and generates the binary artifacts that subsequent tasks such as testing or packing will consume.

Why this answer

The DotNetCoreCLI@2 task with the 'build' command compiles the .NET application source code into intermediate language (IL) assemblies. This is a mandatory step after restoring dependencies and before packing the project into a NuGet package. Without a successful build, the subsequent pack and push operations would fail.

Exam trap

The trap here is that candidates often confuse the 'push' command as part of the build stage, but in Azure Pipelines, pushing to a feed is typically done in a separate stage or job to separate build artifacts from deployment actions.

Practice this question →
166
Multi-Selectmedium

Which THREE are valid ways to trigger a pipeline in Azure Pipelines using GitHub integration? (Choose three.)

Select 3 answers
A.GitHub App webhooks
B.Polling GitHub on a schedule
C.GitHub pull request events
D.GitHub branch push events
E.Azure Pipelines schedule trigger
AnswersA, C, D

Azure Pipelines uses a GitHub App to receive webhooks from GitHub; when the app is installed on a repository, GitHub sends an HTTP POST to Azure Pipelines for events such as push or pull request, automatically triggering the pipeline without any polling.

Why this answer

GitHub App webhooks are the primary integration mechanism for Azure Pipelines with GitHub. When you configure a GitHub App connection in Azure Pipelines, it registers webhooks that listen for specific GitHub events (like push and pull request) and automatically triggers pipeline runs in real-time without polling.

Exam trap

The trap here is that candidates may confuse general pipeline triggers (like scheduled triggers) with GitHub-specific integration triggers, or assume that polling is a fallback method when webhooks fail, but Azure Pipelines does not support polling for GitHub repositories.

Practice this question →
167
Matchingmedium

Match each Azure Monitor feature to its use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Application performance monitoring and diagnostics

Query and analyze log data from various sources

Visualize performance metrics from Azure resources

Proactive notifications based on conditions

Why these pairings

The correct matches are Log Analytics for log collection and querying, Application Insights for live web application monitoring, and Azure Monitor Metrics for numeric performance data. The distractors swap the definitions of Log Analytics and Application Insights.

Practice this question →
168
MCQmedium

You are designing a release pipeline for a containerized application deployed to Azure Kubernetes Service (AKS). You want to implement a strategy where the new version is deployed to a small subset of pods first, and if healthy, gradually rolled out to all pods. Which Kubernetes deployment strategy should you use?

A.Canary deployment
B.Rolling update
C.Blue-green deployment
D.Recreate deployment
AnswerA

Canary deployment is the correct choice because it deploys the new containerized app version to a small subset of users or servers first, then gradually shifts traffic based on health checks and metrics. This allows you to validate the new version in production with minimal risk, automatically rolling back if errors or performance degradation are detected, before exposing it to the full user base.

Why this answer

A canary deployment is the correct strategy because it allows you to route a small percentage of traffic (e.g., 5%) to the new version of the application running on a subset of pods in AKS. If the canary is healthy (e.g., passes liveness and readiness probes), you can gradually increase the traffic percentage until 100% of pods run the new version, providing controlled rollout and rollback capabilities.

Exam trap

The trap here is confusing a rolling update with a canary deployment; while both are gradual, a rolling update does not provide traffic splitting or controlled subset exposure, which is the key requirement for a canary strategy.

How to eliminate wrong answers

Option B (Rolling update) is wrong because it replaces pods incrementally without the ability to route a controlled subset of traffic to the new version; it updates all pods over time but does not support fine-grained traffic splitting or canary analysis. Option C (Blue-green deployment) is wrong because it involves running two full environments (blue and green) and switching all traffic at once via a service selector update, not a gradual subset rollout. Option D (Recreate deployment) is wrong because it terminates all existing pods before creating new ones, causing downtime and no gradual rollout.

Practice this question →
169
MCQhard

You have the YAML pipeline exhibit above. The pipeline fails with: 'The pipeline is not valid. Could not find the template file shared-templates/build-steps.yml.' What is the most likely cause?

A.The checkout step for 'shared-templates' must be before the template reference, which it is.
B.The template file is missing from the shared-templates repository.
C.The template path is incorrect because it should be relative to the repository root; the repository name is 'myorg/shared-templates', so the path should be 'build-steps.yml'.
D.The ref 'refs/heads/main' does not exist in the shared-templates repository.
AnswerC

The path 'shared-templates/build-steps.yml' suggests that the template is in a subfolder, but the repository root is already 'shared-templates'.

Why this answer

When referencing a template from another repository in Azure Pipelines, the `repository` property specifies the repository name (e.g., `myorg/shared-templates`), and the template path must be relative to the root of that repository. The error indicates the pipeline cannot find the file, meaning the path `shared-templates/build-steps.yml` is incorrect; it should be just `build-steps.yml` since the repository name is already declared in the `repository` field. The path should not include the repository name again.

Exam trap

The trap here is that candidates often assume the template path must include the repository name or folder structure, when in fact the path is relative to the root of the repository specified in the `repository` field, leading to a common mistake of over-specifying the path.

How to eliminate wrong answers

Option A is wrong because the checkout step for 'shared-templates' is not required before the template reference; Azure Pipelines automatically fetches the referenced repository when the template is resolved, so the order of checkout steps does not affect template resolution. Option B is wrong because the error message specifically says 'Could not find the template file', which implies the file exists but the path is incorrect; if the file were missing, the error would be different (e.g., 'File not found' or a similar message). Option D is wrong because the error message does not mention a ref issue; if the ref 'refs/heads/main' did not exist, the error would indicate a failure to resolve the branch or commit, not a missing template file.

Practice this question →
170
MCQmedium

You have a release pipeline that deploys to multiple stages (Dev, QA, Prod). You want to automatically deploy to Dev and QA after a successful build, but require a manual approval for Prod. Which deployment strategy should you use?

A.Set pre-deployment approvals on the Dev and QA stages.
B.Set pre-deployment approvals on the Prod stage.
C.Use a post-deployment approval on the QA stage.
D.Disable the automatic trigger for all stages.
AnswerB

Pre-deployment approvals on the Prod stage create a manual authorization checkpoint before the production deployment begins. This satisfies the requirement for a human approval step prior to releasing to production while still allowing dev and QA deployments to run automatically, matching the specified workflow.

Why this answer

Pre-deployment approvals control whether a release can start deploying to a stage. By setting a pre-deployment approval on the Prod stage only, Dev and QA will deploy automatically (since they have no approval requirement), while Prod requires manual sign-off before deployment begins. This matches the requirement exactly.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals, leading candidates to think a post-deployment approval on QA can gate Prod, when in fact only pre-deployment approvals on the target stage (Prod) can prevent its deployment from starting.

Why the other options are wrong

A

That would require approval for Dev and QA, not Prod.

C

Post-deployment approvals occur after deployment, not before.

D

That would stop all automatic deployments.

Practice this question →
171
MCQhard

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

A.Blue-green deployment
B.Canary deployment
C.Red/Black deployment
D.Rolling deployment across regions
AnswerA

Blue-green deployment uses two identical environments (blue and green) with only one serving production traffic at a time, and a router instantly switches between them. This is a single-region or same-site technique that does not provide cross-region failover or disaster recovery, so it does not meet the cross-region requirement.

Why this answer

This strategy is a blue-green deployment because it uses two complete environments (primary and secondary regions). The new version is deployed to the secondary (green) environment first, then Traffic Manager priority routing switches all traffic from the primary (blue) to the secondary (green). The primary is then updated while idle.

This is the classic blue-green pattern applied across regions, not a rolling deployment.

Exam trap

The trap is that candidates may confuse this with rolling deployment because updates happen in stages. However, rolling deployment updates instances incrementally and gradually shifts traffic, whereas blue-green deployment performs an immediate all-or-nothing traffic switch between two pre-deployed environments. Traffic Manager priority routing is a failover/blue-green switch, not a gradual rolling shift.

How to eliminate wrong answers

Option A is wrong because blue-green deployment involves maintaining two identical environments (blue and green) and switching traffic between them instantly, not sequentially updating one region while the other serves traffic. Option B is wrong because canary deployment routes a small percentage of traffic to a new version to validate it before a full rollout, not a full region switch with priority routing. Option C is wrong because red/black deployment is another term for blue-green deployment, where the old version (red) is replaced entirely by the new version (black) after validation, not a rolling update across regions.

Practice this question →
172
MCQhard

You have a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The build stage runs successfully, but the deploy stage fails with an error: 'Error: failed to get credentials: context deadline exceeded'. You verify that the AKS cluster is running and that the service connection is valid. What is the most likely cause?

A.The Azure service connection has expired.
B.The service principal used by the pipeline does not have RBAC permissions on the cluster.
C.The container registry is not accessible from the build agent.
D.The build agent's IP address is not allowed by the AKS cluster's network policies.
AnswerD

If the build agent's public IP address is not included in the AKS cluster's authorized IP ranges (a feature of the API server access profile), the API server will silently drop packets, causing the pipeline to hang until the connection times out. This matches the symptom precisely, making it the correct cause among the given options.

Why this answer

The error 'context deadline exceeded' when running `az aks get-credentials` indicates a network timeout, not an authentication or permission failure. Since the AKS cluster is running and the service connection is valid, the most likely cause is that the build agent's IP address is blocked by AKS network policies (e.g., authorized IP ranges or a firewall), preventing the agent from reaching the cluster's API server within the default timeout.

Exam trap

The trap here is that candidates confuse network-level connectivity errors (timeout) with authentication or authorization errors, leading them to incorrectly select options about expired service connections or RBAC permissions.

How to eliminate wrong answers

Option A is wrong because the error 'context deadline exceeded' is a network timeout, not an authentication error; an expired service connection would produce a different error (e.g., '401 Unauthorized' or 'credentials not found'). Option B is wrong because insufficient RBAC permissions would result in a '403 Forbidden' error when attempting to access cluster resources, not a timeout. Option C is wrong because the build stage (which builds and pushes the container image) already succeeded, proving the container registry is accessible from the build agent.

Practice this question →
173
MCQeasy

You are implementing a CI pipeline for a Node.js application. The pipeline must run linting, unit tests, and build the application. Which YAML structure is most appropriate?

A.Define three separate stages: lint, test, build.
B.Define one job with parallel steps using 'parallel' keyword.
C.Define multiple jobs without dependencies.
D.Define one job with multiple steps: lint, test, build.
AnswerD

A single job with multiple sequential steps is the simplest and fastest CI approach for a Node.js application, as it runs in one workspace with no inter-job communication overhead. Each step executes in order, automatically stopping the pipeline on the first failure, and step outputs are directly available to subsequent steps.

Why this answer

A CI pipeline for a Node.js application typically runs linting, unit tests, and build sequentially within a single job using multiple steps. This ensures that each step executes in order, sharing the same workspace and environment, which is efficient for a simple CI workflow. Defining separate stages (Option A) or multiple jobs (Option C) adds unnecessary overhead and complexity for tasks that are inherently sequential and do not require independent environments.

Exam trap

The trap here is that candidates often confuse the need for separate stages or jobs with the concept of modularity, not realizing that for a simple sequential CI workflow, a single job with multiple steps is the most efficient and appropriate structure.

How to eliminate wrong answers

Option A is wrong because defining three separate stages (lint, test, build) introduces unnecessary pipeline orchestration overhead and potential delays due to stage-level artifact passing, which is not needed for a simple CI workflow where all steps can run sequentially in the same job. Option B is wrong because the 'parallel' keyword in Azure DevOps YAML runs steps concurrently, which would cause linting, tests, and build to execute simultaneously, leading to race conditions and potential failures (e.g., build starting before linting completes). Option C is wrong because defining multiple jobs without dependencies allows them to run in parallel by default, which again breaks the required sequential order (lint → test → build) and may cause build to run before linting or tests pass.

Practice this question →
174
MCQhard

Your Azure Pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that the image is scanned for vulnerabilities before being pushed. Which task should you add to the pipeline?

A.Azure CLI task to run 'az acr scan'
B.Docker task with the 'push' action
C.Container scanning task from Microsoft Defender for Cloud
D.PublishBuildArtifacts task
AnswerC

The Container scanning task from Microsoft Defender for Cloud is a dedicated Azure DevOps task that integrates with Microsoft Defender for Cloud to scan container images for vulnerabilities, including OS packages and language-specific dependencies. It can be configured to run after a successful push to Azure Container Registry, providing actionable security findings and can fail the pipeline if critical vulnerabilities are detected.

Why this answer

Microsoft Defender for Cloud provides a dedicated container scanning task that integrates directly into Azure Pipelines to scan Docker images for vulnerabilities before they are pushed to ACR. This task leverages the same vulnerability assessment engine used by Microsoft Defender for Cloud to identify CVEs in OS packages and application dependencies, ensuring only compliant images are pushed.

Exam trap

The trap here is that candidates may confuse the Azure CLI task with a hypothetical 'az acr scan' command, or assume the Docker push action inherently includes security scanning, when in fact Microsoft Defender for Cloud provides a dedicated task for that purpose.

How to eliminate wrong answers

Option A is wrong because 'az acr scan' is not a valid Azure CLI command; ACR uses the 'az acr task' or 'az acr run' commands for scanning, but vulnerability scanning is performed by Defender for Cloud, not a direct CLI command. Option B is wrong because the Docker task with the 'push' action only pushes the image to ACR without any built-in vulnerability scanning; it does not invoke any security assessment. Option D is wrong because the PublishBuildArtifacts task publishes build artifacts to Azure Pipelines or a file share, and has no capability to scan container images for vulnerabilities.

Practice this question →
175
MCQmedium

Your team uses GitFlow with Azure Repos. You need to ensure that every commit to the 'main' branch is built and deployed to production automatically. Which trigger should you configure in your YAML pipeline?

A.Trigger: none
B.trigger: branches: include: - main
C.schedules: - cron: "0 0 * * *" branches: include: - main
D.pr: branches: include: - main
AnswerB

This YAML defines a continuous integration trigger on the `main` branch, causing Azure Pipelines to automatically queue a new run whenever a commit is pushed to `main`. Because GitFlow's main branch is the integration branch for releases and hotfixes, this ensures every commit that lands on main is validated by the pipeline.

Why this answer

A branch-specific trigger defined with `trigger: branches: include: - main` will automatically run the pipeline on every commit to the 'main' branch. Option A is wrong because `trigger: none` disables CI triggers entirely, so the pipeline will not start on any commits. Option C is wrong because a scheduled trigger (`schedules:`) runs the pipeline at specific times, not in response to commits.

Option D is wrong because a PR trigger (`pr:`) runs the pipeline when a pull request is created or updated, not on direct commits to 'main'.

Practice this question →
176
MCQhard

Your release pipeline deploys to Azure App Service using deployment slots. You need to ensure that traffic is gradually shifted to the new slot over 30 minutes, and if performance issues occur, it should automatically roll back. Which deployment strategy should you implement?

A.Use the 'Deploy to Azure App Service' task with the 'Deploy to Slot' option and configure auto-swap with monitoring.
B.Use two separate deployment slots (blue/green) and manually swap after validation.
C.Use a canary deployment with multiple slots and manual approval gate.
D.Use an A/B testing deployment by deploying to two different App Services and routing traffic via Traffic Manager.
AnswerA

Correct: Deployment slots support gradual traffic shift and auto-rollback via monitoring.

Why this answer

The 'Deploy to Azure App Service' task with 'Deploy to Slot' and auto-swap with monitoring enables a gradual traffic shift over a specified duration (e.g., 30 minutes) using Azure's swap-with-preview and auto-rollback capabilities. When performance issues are detected via Application Insights or health checks, the swap is automatically aborted, rolling back to the previous slot. This meets the requirement for gradual shifting and automatic rollback without manual intervention.

Exam trap

The trap here is that candidates confuse 'canary deployment' (which often requires manual approval or external traffic routing) with Azure's built-in auto-swap with monitoring, which provides automatic gradual shifting and rollback without additional components.

How to eliminate wrong answers

Option B is wrong because manually swapping after validation does not provide gradual traffic shifting over 30 minutes; it is an instant swap, not a gradual rollout. Option C is wrong because a canary deployment with multiple slots and a manual approval gate requires human decision to proceed or roll back, not automatic rollback based on performance issues. Option D is wrong because using two separate App Services with Traffic Manager is not a slot-based deployment; it introduces additional cost and complexity, and Traffic Manager does not natively support automatic rollback based on application performance metrics.

Practice this question →
177
MCQhard

Your organization has a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline uses environment approvals for the production stage. You need to ensure that the container image deployed to production is the same as the one that passed all previous stages. Which strategy should you implement?

A.Publish the container image as a pipeline artifact and reference it from each stage.
B.Use the same image tag in all stages, updating the tag as needed.
C.Enable immutable tags on the container registry to prevent overwrites.
D.Rebuild the container image in each stage to ensure freshness.
AnswerA

Pipeline artifacts are immutable and can be passed between stages as dependencies, ensuring that the container image built once at the initial stage is exactly the same binary consumed by subsequent stages. This prevents any drift or accidental variation from rebuilding or republishing the image, which is crucial for reproducible deployments.

Why this answer

Publishing the container image as a pipeline artifact ensures that the exact same image (by digest, not just tag) is available to all stages. By referencing the artifact in each stage, you guarantee that the image deployed to production is identical to the one that passed testing, avoiding any risk of tag mutation or rebuild inconsistencies.

Exam trap

The trap here is that candidates often confuse tag-based strategies (like using the same tag or immutable tags) with the artifact-based approach, failing to realize that only publishing the image as a pipeline artifact guarantees the exact same image digest is used across all stages.

How to eliminate wrong answers

Option B is wrong because using the same image tag across stages is unreliable; tags can be overwritten or point to different images over time, breaking the guarantee of image consistency. Option C is wrong because enabling immutable tags only prevents tag deletion or overwrite in the registry, but does not ensure that the same image is used across stages—stages could still pull different images if tags are reused or if the pipeline rebuilds. Option D is wrong because rebuilding the container image in each stage introduces variability (e.g., different base image updates, build timestamps) and defeats the purpose of promoting a verified artifact through the pipeline.

Practice this question →
178
Multi-Selectmedium

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Select 3 answers
A.Red-black deployment.
B.Rolling deployment.
C.Blue-green deployment.
D.Canary deployment.
E.Linear deployment.
AnswersB, C, D

Rolling deployment replaces instances incrementally, typically across batches or availability zones, ensuring that some capacity remains available during the update. It minimizes downtime and supports progressive exposure, with automated health checks deciding whether to continue or roll back.

Why this answer

Rolling deployment is a valid strategy in Azure DevOps release pipelines, where instances of the previous version are gradually replaced with the new version, typically by updating a subset of instances (e.g., in a virtual machine scale set or Kubernetes cluster) while the rest continue serving traffic. Blue-green deployment is also valid, maintaining two identical environments and switching all traffic from the blue (old) to the green (new) environment after validation, often implemented using deployment slots or Kubernetes namespaces. Canary deployment is a third valid strategy, where a small percentage of traffic is routed to the new version initially, gradually increasing it while monitoring health, commonly implemented with deployment slots or progressive exposure in Kubernetes.

Red-black, while sometimes used as a synonym for blue-green, is not a distinct deployment strategy recognized in Azure DevOps documentation, and linear deployment is not a recognized industry-standard pattern.

Exam trap

The trap is that candidates may confuse 'red-black' with 'blue-green' because of similar color-based naming, but 'red-black' is not a formally defined strategy in Azure DevOps, and 'linear deployment' is not a recognized pattern. However, note that red-black is essentially the same as blue-green in many contexts, so this trap is misleading; the key differentiator is that Azure DevOps does not use this terminology or provide specific support for it.

Practice this question →
179
MCQeasy

Your release pipeline includes a 'Deploy to App Service' task for a Linux web app. The deployment fails with 'Error: Failed to deploy web package to App Service'. What should you check first?

A.Verify that the deployment slot is correctly configured.
B.Check the Kudu console for errors.
C.Ensure the web.config file is present.
D.Review the App Service diagnostic logs.
AnswerD

App Service diagnostic logs are the authoritative source for troubleshooting deployment failures, as they capture detailed information about the deployment process, container startup, and runtime exceptions. Reviewing these logs is the correct first step to identify the underlying error and resolve the issue.

Why this answer

App Service diagnostic logs provide the most comprehensive and direct source of error details when a deployment fails. The 'Deploy to App Service' task uses Kudu (for Windows) or Oryx (for Linux) to process the deployment; reviewing the diagnostic logs (e.g., via the Azure portal under 'App Service logs' or the 'Log stream') will surface the exact failure reason, such as a missing startup command, incorrect runtime stack, or permission issues.

Exam trap

The trap here is that candidates mistakenly associate 'Kudu console' (Option B) with all App Service debugging, but Kudu is not available on Linux web apps, making diagnostic logs the correct first check.

How to eliminate wrong answers

Option A is wrong because deployment slot configuration is unrelated to the core deployment failure; slots are used for staging and swapping, not for diagnosing why a web package failed to deploy. Option B is wrong because the Kudu console is not available for Linux web apps (Kudu is Windows-only; Linux apps use Oryx and SSH-based debugging). Option C is wrong because web.config is an IIS-specific configuration file and is not used by Linux web apps, which rely on startup commands or app settings.

Practice this question →
180
MCQeasy

You need to run unit tests in your build pipeline and publish the test results to Azure Pipelines. Which task should you use?

A.DotNetCoreCLI task with test command
B.Npm task
C.Publish Test Results task
D.Visual Studio Test task
AnswerD

The Visual Studio Test task runs unit tests using the VSTest console and can produce a TRX file, but it does not directly publish the results to the pipeline. After execution, you still need a 'Publish Test Results' task to upload the TRX file so that the test results appear in the Azure DevOps UI.

Why this answer

To run unit tests and publish the results in Azure Pipelines, use the Visual Studio Test task. It executes the tests and automatically publishes the test results to the pipeline, providing rich reporting and pass/fail analysis. The Publish Test Results task is only used when you already have test result files (e.g., JUnit, TRX) from a previous step and need to import them; it does not run any tests itself.

The DotNetCoreCLI test command can also run and publish results, but the Visual Studio Test task is the standard framework-agnostic choice.

Exam trap

The trap is that candidates might think the Publish Test Results task is required for all test reporting, but in fact the Visual Studio Test task already includes built-in publishing. You only need a separate Publish Test Results task when using custom test runners that do not publish natively.

How to eliminate wrong answers

Option A is wrong because the DotNetCoreCLI task with the test command runs .NET Core tests but does not inherently publish results to Azure Pipelines; you must add a separate Publish Test Results task. Option B is wrong because the Npm task is for running npm scripts (e.g., test), but it does not publish test results to Azure Pipelines; it only runs the command. Option D is wrong because the Visual Studio Test task runs tests and can publish results, but it is specific to Visual Studio test frameworks (e.g., MSTest, xUnit) and not a generic solution for all unit test types; the question asks for a task to publish results, and the Publish Test Results task is the dedicated, framework-agnostic choice.

Practice this question →
181
MCQhard

Your pipeline has the following YAML trigger configuration: trigger: paths: include: - src/app/** A developer pushes changes to a file in 'src/app/config.json' on a branch named 'release/v1'. Which statement is true about the build trigger?

A.The build will be triggered but only if no other builds are running.
B.The build will be triggered.
C.The build will not be triggered because the path filter is too restrictive.
D.The build will not be triggered because the branch is not 'main'.
AnswerB

The pipeline's trigger configuration matches the pushed branch via the 'release/*' wildcard and the modified files satisfy the include path filter, so the build is correctly triggered as soon as the change is pushed.

Why this answer

The provided YAML trigger includes a path filter that matches 'src/app/**'. The push to 'src/app/config.json' matches that include pattern, so the build triggers. No branch filter is specified, so the trigger applies to all branches including 'release/v1'.

Therefore, option B is correct.

Exam trap

Candidates often think that path filters implicitly restrict branches, but without an explicit branch filter, the trigger applies to all branches.

How to eliminate wrong answers

Option A is wrong because there is no concurrency limit or batch setting in the trigger configuration that would cause the build to wait for other builds; the trigger fires immediately on matching changes. Option C is wrong because the path filter 'src/app/*' is not too restrictive; it explicitly includes the file 'src/app/config.json', so the change matches the filter. Option D is wrong because the trigger does not specify a branch filter; without a branch filter, the trigger applies to all branches, including 'release/v1'.

Practice this question →
182
Multi-Selectmedium

A development team is configuring a YAML-based pipeline in Azure Pipelines. The pipeline must meet the following requirements: - Build only the main branch. - Run integration tests after a successful build. - Deploy to a staging environment only if tests pass. - Handle failures gracefully by sending a notification to the team. You need to define the pipeline structure. Which TWO configurations should you include?

Select 2 answers
A.Use a `deployment: Staging` job with `displayName: Deploy to staging`.
B.Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.
C.Set `trigger: main` at the pipeline root.
D.Add `condition: succeeded()` to the build job.
E.Define the trigger in the `resources` section using `pipelines`.
AnswersB, C

The `dependsOn: Test` and `condition: succeeded('Test')` pair explicitly creates a stage dependency, ensuring the Deploy stage only executes if the Test stage completed with a success status. Without this condition, the default stage behavior would run stages sequentially only if previous stages succeeded, but this explicit syntax makes the gate unambiguous and allows for complex dependency graphs. This directly satisfies the requirement to deploy only after passing tests, as the condition checks the status of the Test stage before the Deploy stage starts.

Why this answer

It defines a 'Deploy' stage that depends on the 'Test' stage and uses `condition: succeeded('Test')` to ensure deployment only occurs after tests pass. This satisfies the requirement to deploy to staging only if tests succeed. Option C is correct because `trigger: main` at the pipeline root configures the pipeline to build only the main branch, meeting the first requirement.

Exam trap

The trap here is that candidates may confuse the `deployment` job keyword (which defines a deployment job but does not enforce stage dependencies) with the stage-level `dependsOn` and `condition` needed to gate deployment on test success, or they may mistakenly place the branch trigger in the `resources` section instead of the root `trigger`.

Practice this question →
183
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 →
184
MCQhard

Your release pipeline deploys to Azure App Service using slots. You need to ensure that after swapping, the warmup request is sent to the production slot before traffic is fully routed. What should you configure?

A.Enable auto swap for the deployment slot and configure a custom warmup path.
B.Add a health check to the App Service.
C.Perform a manual swap and then send a warmup request via a script.
D.Configure slot-specific app settings to enable warmup.
AnswerA

Enabling auto swap with a custom warmup path ensures the Azure App Service performs a request against the staging slot's specified path before the swap completes, loading application caches and verifying readiness so end users never hit uninitialized code during the swap operation.

Why this answer

Enabling auto swap with a custom warmup path sends a warmup request to the target slot before the swap completes, ensuring the production slot is warmed up. Option B is incorrect because a health check is used for monitoring instance health, not for warmup before swap. Option C is incorrect because a manual swap does not include automatic warmup; you would need to implement custom logic.

Option D is incorrect because slot-specific app settings are sticky and not swapped; they do not enable warmup.

Practice this question →
185
Multi-Selectmedium

Your organization uses Azure Pipelines to deploy a web application to multiple Azure App Service instances across regions. You need to implement a deployment strategy that allows rolling back to the previous version quickly if issues are detected. Which TWO strategies should you recommend?

Select 2 answers
A.Use a rolling update with incremental deployment.
B.Implement a canary deployment with traffic splitting.
C.Store previous deployment artifacts in Azure Blob Storage.
D.Use blue-green deployment with a traffic manager endpoint.
E.Deploy to a staging slot and then swap with production.
AnswersD, E

Blue-green allows switching traffic back to the previous environment.

Why this answer

The correct answers are D and E. Blue-green deployment with a traffic manager endpoint allows you to quickly route traffic back to the previous version if issues are detected. Deploying to a staging slot and then swapping with production (slot swap) enables instant rollback by swapping back to the previous slot.

Option A (rolling update) does not provide instant rollback because it requires redeployment. Option B (canary deployment) is designed for gradual traffic shifting, not immediate rollback. Option C (storing artifacts) is a good practice but does not itself constitute a deployment strategy for rollback.

Practice this question →
186
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 →
187
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 →
188
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

Approvals are set on environments.

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 →
189
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 →
190
MCQhard

Refer to the exhibit. You have a YAML pipeline with the variables shown. What will be the value of $(Build.BuildNumber) on the first run?

A.1.0.0.0
B.20250101.1
C.1.0.0
D.1.0.1
AnswerB

20250101.1 is correct because Azure Pipelines automatically sets Build.BuildNumber to $(Date:yyyyMMdd).$(Rev:r) when no custom format is specified. On January 1, 2025, the first build of the day gets the revision 1, producing 20250101.1, and each subsequent build increments the revision.

Why this answer

The pipeline does not define a custom build number format, so Azure DevOps defaults to the date-based format 'yyyyMMdd.revision'. On the first run of the day, the revision starts at 1, resulting in a Build.BuildNumber like '20250101.1'. The counter expression (not shown in the exhibit) is a separate variable and does not affect Build.BuildNumber.

Therefore, the correct answer is B.

Practice this question →
191
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 →
192
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

Require linked work items. This branch policy enforces that pull requests or commits to the main branch have at least one associated work item, ensuring traceability. Option B, Limit merge types, restricts which merge strategies can be used (e.g., squash, rebase), but does not enforce work item linking.

Option C, Require a minimum number of reviewers, ensures code review but not work item association. Option D, Check for comment resolution, requires that all comments on pull requests are resolved before merging, which is unrelated to work items.

Practice this question →
193
MCQhard

Refer to the exhibit. You deploy this ARM template using Azure Pipelines. The deployment succeeds, but the storage account is created with a name that is not what you expected. What is the most likely reason?

A.The uniqueString function returns a hash based on the resource group ID, resulting in a non-meaningful name.
B.The storage account name parameter is of type 'string' but the default value is an object.
C.The location parameter uses resourceGroup().location which is not a valid function.
D.The apiVersion '2022-09-01' is too new and causes a naming conflict.
AnswerA

The uniqueString function in ARM templates computes a deterministic hash from the supplied inputs, such as the resource group ID, which makes the resulting name technically unique but not human-readable or descriptive. For storage accounts, which require globally unique names, this often leads to seemingly random strings that fail to convey the resource's purpose unless combined with a meaningful prefix.

Why this answer

The uniqueString(resourceGroup().id) function generates a deterministic hash based on the resource group ID, resulting in a storage account name that is a hash rather than a human-readable name. Option B is incorrect because the parameter type 'string' can accept a default value that is a string, even if it looks like an object. Option C is incorrect because resourceGroup().location is a valid function that returns the location of the resource group.

Option D is incorrect because the apiVersion '2022-09-01' is valid and does not cause naming conflicts; naming conflicts arise from the hash function, not the API version.

Practice this question →
194
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 →
195
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 →
196
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

Adding a Docker task to build and push the image to ACR, and a Kubernetes task to deploy to AKS, minimally changes the existing pipelines. Option A is incorrect because building the Docker image via a script in the release pipeline is less integrated and does not leverage the build pipeline's Docker capabilities. Option C is incorrect because creating new pipelines from scratch is unnecessary and introduces more changes.

Option D is incorrect because self-hosted agents are not required to build and push to ACR or deploy to AKS.

Practice this question →
197
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 →
198
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 starts the release pipeline after a build completes, using the same artifact.

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 →
199
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 →
200
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

A

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

C

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

D

Branch policies are for pull requests, not pipeline stages.

Practice this question →
201
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

A

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

C

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

D

NuGetAuthenticate is for authentication, not restoring packages.

Practice this question →
202
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

To restore NuGet packages on a self-hosted agent without internet access, the NuGet tool must be installed on the agent machine (B) and the agent must be configured to access an internal NuGet feed, such as Azure Artifacts or a local feed (D). Disabling the NuGet restore step (A) would prevent packages from being downloaded. Using a Microsoft-hosted agent (C) would require internet access, which violates the private network constraint.

The NuGet Authenticate task (E) is not required because authentication can be handled through feed configuration or integrated authentication.

Practice this question →
203
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 →
204
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 →
205
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

GitHub Actions path filters (on: pull_request paths:) allow you to trigger workflows only when changes occur in specific directories. This ensures that only the microservices affected by a pull request are built and tested, reducing build times and resource usage. Option A is incorrect because building all services on every push is wasteful.

Option B is incorrect because manual triggering via webhook comments defeats automation and is not scalable. Option C is incorrect because a matrix strategy, while useful for parallel builds, still triggers on every pull request and would build all services, not just the changed ones.

Practice this question →
206
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 →
207
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 container images cryptographically verifies the publisher's identity and guarantees the image has not been tampered with, ensuring that only trusted images are deployed. This helps prevent supply-chain attacks.

Why this answer

Signing container images (Option C) ensures their integrity and authenticity by allowing the CI/CD pipeline to verify that the image has not been tampered with since it was signed, typically using tools like Docker Content Trust (DCT) or Notary. Scanning container images for vulnerabilities (Option E) during the build identifies known security issues in the image layers and dependencies, allowing teams to remediate before deployment. Both practices are essential for supply chain security.

The other options are incorrect: running as root increases risk, public registries expose images, and 'latest' tags cause unpredictable updates.

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 →
208
MCQeasy

Your company uses GitHub Actions for CI/CD. The development team wants to automatically create a new GitHub release with release notes whenever a pull request is merged to the main branch. The release notes should include a list of all merged pull requests since the last release. You need to implement this automation. What should you do?

A.Add a workflow triggered on push to main that uses the 'softprops/action-gh-release' action to create a release with auto-generated release notes.
B.Configure a branch protection rule to require a release note file in each pull request.
C.Use a workflow that runs on pull request merge and creates a Git tag, then rely on GitHub to create a release from the tag.
D.Add a step to the existing CI workflow that runs 'gh release create' with a changelog.
AnswerA

This is correct because the workflow, triggered on every push to main, uses the 'softprops/action-gh-release' action with 'generate_release_notes: true' (or the action's default behavior) to automatically create a GitHub Release. The action compares against the previous tag and auto-assembles release notes from merged pull requests, providing a fully automated, hands-off release process.

Why this answer

The 'softprops/action-gh-release' action can create a release and, when configured with `generate_release_notes: true`, generates release notes from merged PRs. Option B is incorrect because requiring a release note file via branch protection does not create a GitHub release. Option C is incorrect because GitHub does not automatically create releases from tags; a release must be created explicitly.

Option D is incorrect because `gh release create` alone does not automatically generate release notes from merged PRs; it requires a manually constructed changelog.

Practice this question →
209
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 →
210
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

Correct: Canary releases a small subset of new version and gradually increases traffic with monitoring.

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 →
211
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 →
212
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 use Helm charts to deploy each microservice in stages. This allows coordinated deployment without duplicating the pipeline logic. Option A is incorrect because creating separate release pipelines for each microservice and triggering them sequentially lacks a single orchestration point and can lead to coordination failures.

Option B is incorrect because creating a single build pipeline that produces all container images couples the builds and prevents independent microservice development. Option D is incorrect because a single multi-stage YAML pipeline that builds and deploys all microservices together also couples the build and deploy stages, and does not allow each microservice to have its own independent build pipeline.

Practice this question →
213
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

B

Artifacts must be explicitly published and downloaded.

C

Condition controls execution but does not handle artifact sharing.

D

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

Practice this question →
214
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 →
215
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

B

Stopping the app causes downtime.

D

Simultaneous deployment can cause full outage if something goes wrong.

E

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

Practice this question →
216
Multi-Selecthard

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure the pipeline uses the latest version of Docker and that the build is cached for faster subsequent runs. Which two tasks should you include? (Choose two.)

Select 2 answers
A.DockerInstaller@0
B.Docker@2 with arguments: --cache-from
C.DockerCompose@0
D.HelmDeploy@0
AnswersA, B

Why this answer

(DockerInstaller@0) is correct because it ensures the pipeline uses the latest version of Docker by installing or upgrading the Docker engine on the build agent. Option B (Docker@2 with --cache-from) is correct because it enables layer caching by pulling the previously built image from ACR as a cache source, which speeds up subsequent builds by reusing unchanged layers.

Exam trap

The trap here is that candidates often confuse DockerCompose@0 (used for orchestrating multiple containers) with Docker@2 (used for building and pushing single images), or assume HelmDeploy@0 is relevant because it involves containers, but it is strictly for Kubernetes deployments.

Why the other options are wrong

C

Docker Compose is not needed for a single image build.

D

Helm is for package management, not Docker build.

Practice this question →
217
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

Tags trigger runs the pipeline when tags are pushed.

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 →
218
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 →
219
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 →
220
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 →
221
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 →
222
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 →
223
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

The correct first step. Even if the pipeline's approval configuration is correct and the approvers are in the correct group, the organization-level notification settings in Azure DevOps can override individual pipeline settings. If email notifications for approvals are disabled at the organization level, no emails will be sent regardless of the pipeline configuration.

Therefore, checking the organization-level notification settings should be the first troubleshooting step. Option A is not the first step because while spam filters could cause missed emails, the issue is more likely a system-level configuration problem. Option C is incorrect because Azure DevOps automatically sends approval notifications; adding a manual 'Send email' task is unnecessary and not a standard fix.

Option D is incorrect because checking release pipeline logs might reveal delivery failures, but the most efficient first step is to verify the notification settings at the organization level.

Practice this question →
224
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 →
225
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 →
← PreviousPage 3 of 6 · 414 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Build Release Pipelines questions.

Start 20-question session