Knowledge + Practice

CCNA Design and implement build and release pipelines Questions

75 of 414 questions · Page 1/6 · Design and implement build and release pipelines · Answers revealed

Practice these questions Domain overview All questions

1

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in logs. A developer reports that a secret value appeared in the workflow run log. What is the most likely reason?

A.The workflow was triggered via repository_dispatch.

B.The secret was printed using a script that bypassed automatic masking.

C.The secret name was used in the log output.

D.The workflow used 'debug' log level.

AnswerB

Correct: When a script or action writes a secret value to stdout in a format that GitHub's log redaction does not recognize—for example, by printing it in base64, with escaped characters, or through an intermediate environment variable that is not pre-registered as a secret—the automatic masking may fail and expose the value. GitHub masks secrets that appear verbatim in the log, but only if the exact string is seen; any transformation bypasses that protection.

Why this answer

GitHub Actions automatically masks secrets in log output, but this masking can be bypassed if the secret is printed via a script that outputs it directly (e.g., using `echo` with a variable that contains the secret value, or printing it in a manipulated form). The most likely reason the secret appeared is that the developer used a script that directly printed the secret value, bypassing the automatic masking. Option A is incorrect because the trigger type (repository_dispatch) does not affect logging.

Option C is incorrect because secret names are not masked; only their values are masked. Option D is incorrect because the 'debug' log level does not disable masking; masking applies to all log levels.

Practice this question →

2

MCQeasy

You are using Azure Pipelines to deploy a function app. You need to automatically roll back the deployment if the post-deployment smoke tests fail. What should you do?

A.Add a stage that runs only when the previous stage fails, executing a rollback script.

B.Configure the pipeline to retry the deployment on failure.

C.Use a pre-deployment approval gate to validate the build before deployment.

D.Set up a manual validation gate that requires operations to initiate a rollback.

AnswerA

In Azure Pipelines, you can define a conditional stage using the `condition: failed()` expression on the deployment stage. This stage runs only when the preceding stage fails, allowing you to execute a rollback script that reverts the function app to its previous healthy version. This approach automates the rollback process, ensuring immediate recovery without manual intervention.

Why this answer

Azure Pipelines supports conditional stage execution using expressions like `eq(variables['Build.Reason'], 'IndividualCI')` or `failed()`. By adding a stage that runs only when the previous deployment stage fails (e.g., `condition: failed()`), you can execute a rollback script that reverts the function app to its previous stable version. This ensures automatic rollback upon smoke test failure without manual intervention.

Exam trap

The trap here is that candidates confuse automatic rollback with retry logic or manual gates, failing to recognize that Azure Pipelines' conditional stage execution (`failed()`) is the native mechanism to trigger a rollback stage automatically when smoke tests fail.

How to eliminate wrong answers

Option B is wrong because retrying the deployment on failure does not roll back; it simply re-attempts the same failing deployment, which will likely fail again if the underlying issue persists. Option C is wrong because a pre-deployment approval gate validates the build before deployment, not after; it cannot detect or respond to post-deployment smoke test failures. Option D is wrong because a manual validation gate requires human approval to proceed, but it does not automatically trigger a rollback; it pauses the pipeline and relies on an operator to manually initiate rollback, which contradicts the requirement for automatic rollback.

Practice this question →

3

Multi-Selecthard

You are designing a build pipeline for a .NET Core application. You need to ensure that the pipeline restores NuGet packages from both an Azure Artifacts feed and the public NuGet gallery. The pipeline must fail if a package is not found in either source. Which two actions must you take? (Select two.)

Select 1 answer

A.Create a NuGet.config file that includes both feeds as package sources and reference it in the restore task.

B.Set the 'NoWarn' property to NU1603 to ignore warnings about missing packages.

C.Use the 'dotnet restore' task with the '--no-cache' flag.

D.Set the 'CheckConsistency' flag to true in the restore task.

E.Configure the Azure Artifacts feed to use the public NuGet gallery as an upstream source.

AnswersA

Correct. A NuGet.config file explicitly defines the package sources, and referencing it in the restore task ensures the pipeline searches both feeds and fails if a package is not found in either.

Why this answer

Creating a NuGet.config file that includes both the Azure Artifacts feed and the public NuGet gallery as package sources, and referencing it in the restore task, ensures the pipeline consults both sources. Option D is incorrect because the 'CheckConsistency' flag is not related to failing on missing packages; the restore task already fails by default if a package cannot be resolved from any configured source. Options B, C, and E do not fulfill the requirement to fail on missing packages from both sources.

Exam trap

The trap here is that candidates often confuse upstream sources (which provide automatic fallback) with explicit source configuration and error handling, leading them to select Option E instead of understanding that upstream sources prevent failures rather than enforce them.

Why the other options are wrong

B

This would suppress warnings, not cause failure on missing packages.

C

This bypasses cache but does not enforce failure on missing packages.

E

This is a feed configuration, not a pipeline setting, and does not cause failure if a package is missing.

Practice this question →

4

MCQhard

Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?

A.Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.

B.Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.

C.Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.

D.Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.

AnswerC

The correct approach defines one workflow with three jobs: build/test, deploy to staging, and deploy to production; the production job references an environment configured with required reviewers, which automatically pauses the job until approval is granted. This gives a native audit trail and allows environment-specific secrets to be used safely.

Why this answer

Correct answer is C. A single GitHub Actions workflow can have multiple jobs: build and test, deploy to staging, and deploy to production. The production deployment job should use a GitHub Environment configured with required reviewers, enabling manual approval.

Option A is incorrect because two separate workflows make it harder to share build artifacts and do not inherently use environment-based approvals for staging vs production. Option B is incorrect because GitHub Issues are not used for manual approvals; approvals are configured via GitHub Environments. Option D is incorrect because it uses Azure Pipelines, not GitHub Actions, which violates the requirement to use official Azure actions in GitHub Actions.

Practice this question →

5

Multi-Selecthard

Your build pipeline uses a YAML template that references variables from a variable group. The variable group is linked to a library. You need to ensure that sensitive variables are not exposed in logs. Which THREE actions should you take?

Select 3 answers

A.Set the variable group to 'Allow access to all pipelines'.

B.Store the secrets in Azure Key Vault and reference them in the variable group.

C.Use 'Write-Host' to output the variable values for debugging.

D.Mark the variables as 'secret' in the variable group.

E.Configure permissions on the library to restrict which pipelines can use the variable group.

AnswersB, D, E

Storing secrets in Azure Key Vault and referencing them via a variable group is the recommended secure approach, as Azure DevOps retrieves these values at runtime and automatically masks them in logs. It enables centralized secret rotation, access policies, and auditing without storing sensitive data in the pipeline definition itself.

Why this answer

To keep sensitive variables out of pipeline logs, you should store secrets in Azure Key Vault and reference them in a variable group (B), mark variables as secret in the variable group (D), and configure permissions on the library to restrict which pipelines can use the variable group (E). Key Vault integration and secret marking ensure that values are masked automatically, while restricting access limits the risk of unauthorized pipelines that could expose secrets.

Exam trap

Candidates may incorrectly think that allowing access to all pipelines is harmless or that explicitly writing secret values to logs with Write-Host is safe. In reality, both actions can expose sensitive data. Restricting library permissions is a key security measure to prevent unauthorized pipeline access.

Practice this question →

6

MCQmedium

You have an Azure Pipelines YAML file with the following trigger configuration: ```yaml trigger: branches: include: - main paths: include: - /src/* ``` The team reports that the pipeline does not trigger when changes are pushed to the main branch that modify files outside the /src folder. What is the most likely reason?

A.The path filter restricts the trigger to only changes in /src/.

B.The trigger syntax is incorrect; 'branch' should be 'branches'.

C.The script step is missing a display name.

D.The pool vmImage is not specified correctly.

AnswerA

The path filter in the trigger uses the 'paths' keyword with an 'include' clause, which restricts the pipeline to run only when changes are made to files under the /src/ directory. Any commits affecting other paths, such as the root or documentation, will not trigger the pipeline, making this statement correct.

Why this answer

The most likely reason is that a path filter is configured in the trigger, restricting the pipeline to only trigger on changes under /src/. The other options are incorrect because they either refer to minor syntax issues or irrelevant details.

Exam trap

The trap is that candidates may overlook the path filter's restrictive behavior and instead focus on minor syntax details like 'branch' vs 'branches', missing that the core issue is the include pattern limiting triggers to only the /src folder. Without seeing the exhibit, it's essential to recognize that path filters are the most likely cause.

How to eliminate wrong answers

Option B is wrong because 'branch' is actually a valid property in the trigger block (though 'branches' is also accepted as an alias), and the syntax shown is correct for specifying branch filters; the issue is not with the branch property but with the path filter. Option C is wrong because a missing display name on a script step does not affect pipeline triggering; it only affects the UI label in pipeline runs. Option D is wrong because the pool vmImage specification (e.g., 'ubuntu-latest') is syntactically correct and does not impact trigger behavior; it only defines the build agent environment.

Practice this question →

7

MCQmedium

You are designing a build pipeline for a Python application that uses Anaconda environments. The pipeline must create a Conda environment, install dependencies, and run tests. The pipeline should also cache the Conda environment to speed up subsequent builds. Which configuration should you use?

A.Use the 'UsePythonVersion' task with a version spec, and add a script to create the Conda environment.

B.Use a Docker container with Anaconda pre-installed and run the pipeline inside the container.

C.Use the 'CondaEnvironment' task to create the environment, and use the 'Cache' task to cache the Conda packages folder.

D.Use a script to run 'conda create' and 'conda install', and manually cache the environment by specifying a path.

AnswerC

The 'CondaEnvironment' task is specifically designed to create a Conda environment from a YAML file or package specification, ensuring the environment is set up correctly and integrated with the pipeline. Pairing it with the 'Cache' task to cache the Conda packages folder (typically 'pkgs') reduces re-download overhead and speeds up subsequent runs.

Why this answer

The 'CondaEnvironment' task is purpose-built for creating and updating Conda environments from an environment.yml file, and combining it with the 'Cache' task to cache the Conda packages folder (typically `$(Pipeline.Workspace)/conda_pkgs`) significantly reduces build time by avoiding re-downloading packages on subsequent runs. This approach aligns with Azure DevOps best practices for dependency caching and Conda environment management.

Exam trap

The trap here is that candidates often assume manual scripting (Option D) is more flexible or that Docker (Option B) is always the best isolation strategy, but they overlook the purpose-built 'CondaEnvironment' task and its seamless integration with the 'Cache' task for efficient, maintainable pipelines.

How to eliminate wrong answers

Option A is wrong because the 'UsePythonVersion' task is designed for standard Python installations (e.g., from the Microsoft-hosted agent's Python versions), not for managing Conda environments; it cannot create or activate Conda environments, and it lacks caching capabilities. Option B is wrong because using a Docker container with Anaconda pre-installed adds unnecessary complexity and overhead (e.g., image build/pull time, volume mounts) and does not natively integrate with Azure DevOps caching tasks for Conda packages; it also bypasses the simplicity of the built-in CondaEnvironment task. Option D is wrong because manually scripting 'conda create' and 'conda install' is error-prone (e.g., missing environment activation, inconsistent environment names) and manually caching by specifying a path requires extra boilerplate code to handle cache keys and restore logic, whereas the CondaEnvironment task and Cache task provide a standardized, tested solution.

Practice this question →

8

MCQhard

Your organization requires that all code changes must be built and tested before merging to the main branch. You plan to use branch policies in Azure Repos. Which policy enforcement will ensure that a pull request cannot be completed unless the build succeeds?

A.Require a linked work item in the pull request.

B.Require a minimum number of reviewers.

C.Add a build validation policy that triggers a build on each PR update.

D.Reset code reviewer votes when new changes are pushed.

AnswerC

Adding a build validation policy queues a build on every pull request update and blocks completion unless the build succeeds. This directly enforces that all code changes are built successfully before merging, preventing broken code from entering the target branch.

Why this answer

Azure Repos branch policies include a 'Build validation' policy that triggers a specified build pipeline on each pull request (PR) update. The policy enforces that the PR cannot be completed unless the build succeeds, directly meeting the requirement that all code changes must be built and tested before merging to the main branch.

Exam trap

The trap here is that candidates may confuse a 'build validation' policy with other branch policies like 'Require a linked work item' or 'Minimum number of reviewers', thinking any policy that adds a check will enforce build success, but only build validation directly triggers and gates on a build pipeline result.

How to eliminate wrong answers

Option A is wrong because requiring a linked work item ensures traceability but does not enforce any build or test execution. Option B is wrong because requiring a minimum number of reviewers enforces peer review but does not trigger or validate a build. Option D is wrong because resetting code reviewer votes when new changes are pushed ensures re-review but does not enforce build success before merge.

Practice this question →

9

MCQhard

Your organization uses Azure Pipelines to build a large monolithic application. The build takes over 60 minutes. Management wants to reduce the build time to under 30 minutes. The application has multiple independent modules that could be built in parallel. What is the most effective strategy to reduce build time?

A.Reduce the number of unit tests run during the build.

B.Upgrade the build agent to a larger VM size with more CPU and memory.

C.Move the build to a self-hosted agent in the same network as the source code repository.

D.Refactor the build pipeline to use multiple parallel jobs, each building a separate module.

AnswerD

A monorepo with independent modules can be split into multiple parallel jobs, each building a separate module on its own agent; this leverages true concurrency to reduce overall wall-clock time, provided you correctly manage inter-module dependencies and publish artifacts for downstream consumption.

Why this answer

The build time is dominated by sequential compilation of independent modules. By refactoring the pipeline to use multiple parallel jobs, each building a separate module, Azure Pipelines can leverage its built-in parallelism to reduce wall-clock time significantly. This directly addresses the root cause—lack of concurrency—without sacrificing code quality or infrastructure cost.

Exam trap

The trap here is that candidates often choose 'upgrade the build agent' (Option B) because they assume more CPU/RAM will linearly speed up compilation, but for a build with many independent modules, the real bottleneck is sequential execution; adding parallelism yields the greatest reduction. Hardware upgrades may help somewhat but do not remove the sequential dependency.

How to eliminate wrong answers

Option A is wrong because reducing unit tests may compromise code quality and does not address the core issue of sequential module compilation; tests typically run after compilation and are not the primary bottleneck in a 60-minute build. Option B is wrong because upgrading to a larger VM size provides only linear CPU/memory improvements, which cannot reduce build time by half if the build is I/O-bound or constrained by sequential dependencies; parallel execution is far more effective. Option C is wrong because moving to a self-hosted agent in the same network as the source repository reduces network latency but does not change the sequential build process; the bottleneck is compilation time, not network transfer.

Practice this question →

10

Multi-Selecteasy

Which TWO tasks can be used to run unit tests in an Azure Pipeline?

Select 2 answers

A.DotNetCoreCLI@2

B.VSTest@2

C.NuGetCommand@2

D.PublishBuildArtifacts@1

E.CopyFiles@2

AnswersA, B

DotNetCoreCLI@2 runs the `dotnet test` command, which discovers and executes unit tests in .NET Core and .NET 5+ projects using the dotnet test runner, supporting VSTest and xUnit/NUnit/MSTest adapters via the `command: test` and `arguments` inputs.

Why this answer

The DotNetCoreCLI@2 task can run unit tests for .NET Core and .NET 5+ projects by invoking the 'dotnet test' command, which discovers and executes tests in the specified project files. The VSTest@2 task runs unit tests using the Visual Studio Test Runner, supporting a wide range of test frameworks (MSTest, xUnit, NUnit) and can run tests from assemblies or test containers. Both tasks are designed specifically for executing unit tests within an Azure Pipeline, making them the correct choices.

Exam trap

The trap here is that candidates may confuse tasks that are part of the build process (like NuGetCommand or CopyFiles) with tasks that actually execute tests, or assume that any task with 'Test' in its name (like VSTest) is the only correct option, overlooking DotNetCoreCLI@2 which also runs tests via 'dotnet test'.

Practice this question →

11

MCQhard

Your company uses GitHub Actions to build and deploy a Python application. The workflow includes a job that runs on a self-hosted runner. You need to ensure that sensitive environment variables are not exposed in the workflow logs. What is the best approach?

A.Use a custom action to read secrets from a file.

B.Use GitHub environment secrets and mark the secret as sensitive to ensure it is masked in logs.

C.Store secrets in GitHub repository secrets and reference them in the workflow.

D.Define the variables directly in the workflow YAML.

AnswerC

Secrets are automatically masked, but this is the standard approach, not necessarily the 'best' for additional security.

Why this answer

GitHub repository secrets and environment secrets are both automatically masked in workflow logs when referenced via ${{ secrets.NAME }}. The best practice is to store sensitive variables in GitHub secrets and reference them in the workflow, rather than defining them directly in YAML or reading from a file. Option C correctly describes this approach.

Exam trap

A common mistake is thinking you need to manually mark secrets as 'sensitive' or that repository secrets are not masked. In fact, all GitHub secrets are masked automatically.

How to eliminate wrong answers

Option A is wrong because reading secrets from a file bypasses GitHub's built-in secret masking and logging controls, potentially exposing the secret if the file content is printed or logged. Option C is wrong because while GitHub repository secrets are masked when referenced directly in workflows, the option does not specify marking them as sensitive or using environment-level scoping, which is the best practice for controlling access and ensuring masking. Option D is wrong because defining variables directly in the workflow YAML exposes them in plaintext in the repository and logs, completely defeating security requirements.

Practice this question →

12

MCQeasy

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to ensure that only pull requests from specific branches trigger a build pipeline. Which trigger configuration should you use?

A.pr: paths: include: - main - develop

B.pr: branches: only: - main

C.trigger: branches: include: - main - develop

D.pr: branches: include: - main - develop

AnswerD

This is the correct YAML syntax for filtering PR triggers by target branch. The `pr` keyword enables PR validation, and `branches: include` specifies that only PRs targeting `main` or `develop` should be built, ensuring the pipeline runs only for those branches.

Why this answer

The `pr` trigger in Azure Pipelines controls which pull requests trigger a pipeline. By using `branches` with `include`, you specify that only PRs targeting the `main` and `develop` branches should trigger the build. This directly meets the requirement to restrict PR triggers to specific branches.

Exam trap

The trap here is confusing `pr` triggers (for pull requests) with `trigger` triggers (for CI builds on commits), leading candidates to select option C which targets commits instead of PRs.

How to eliminate wrong answers

Option A is wrong because `paths` filters changes by file paths, not branches; it would still trigger on PRs to any branch if the specified paths are modified. Option B is wrong because `only` is not a valid keyword under `pr.branches`; the correct syntax uses `include` and `exclude`. Option C is wrong because `trigger` controls CI triggers for commits, not pull request triggers; it would run builds on direct pushes to `main` and `develop`, not on PRs.

Practice this question →

13

MCQeasy

You need to enforce that all builds in Azure Pipelines use a specific version of the .NET SDK. What is the best approach?

A.Add a UseDotNet task to the pipeline that specifies the required SDK version.

B.Set a pipeline variable DotNetVersion and use it in the DotNetCoreCLI task.

C.Install the SDK manually on the build agent using a script.

D.Include a global.json file in the repository and rely on the build agent to respect it.

AnswerA

Correct: The UseDotNet task can download and install a specified .NET SDK version, enforcing it for the build.

Why this answer

The UseDotNet task in Azure Pipelines can be configured to download and install a specific version of the .NET SDK, ensuring that all builds use exactly that version, regardless of what is pre-installed on the agent. Option B is incorrect because setting a pipeline variable DotNetVersion and using it in the DotNetCoreCLI task does not enforce the SDK version; the DotNetCoreCLI task uses the SDK already available on the agent, unless explicitly redirected, and the variable alone does not install or enforce a specific SDK. Option C is incorrect because installing the SDK manually via a script is not a reliable or repeatable approach; it depends on the agent's state and does not automatically enforce the version across different agents or pipeline runs.

Option D is incorrect because including a global.json file in the repository does not guarantee that the required SDK version is installed on the agent; the build agent may not respect global.json if the specified SDK is not present, and there is no enforcement mechanism without additional steps.

Practice this question →

14

MCQhard

Your team uses Azure Pipelines with a YAML-based build pipeline. The pipeline builds a .NET application and runs unit tests. Recently, the unit tests are failing intermittently due to flaky tests. You need to ensure that the pipeline fails only if the same test fails in two consecutive runs. Which feature should you configure?

A.Implement a GitHub Actions workflow with 're-run' trigger.

B.Use the 'Re-run failed stages' option in the pipeline run.

C.Enable 'Automatically rerun failed jobs' in the pipeline settings.

D.Configure the 'retry failed tests' setting in the pipeline's test tab.

AnswerD

The 'retry failed tests' setting in the pipeline's Test tab is the correct way to handle flaky tests: it automatically re-executes only the failed test cases (not entire jobs or stages) a configurable number of times during the same run. If a retried test passes, it is reported as 'Passed on retry' in the Test tab, giving you visibility into which tests are flaky while keeping the overall run green.

Why this answer

The correct feature is the 'Retry failed tests' setting in the pipeline's test tab. This allows you to configure the number of times a failed test is automatically retried. If the test passes on retry, the pipeline is marked as succeeded with warnings, effectively requiring two consecutive failures for the pipeline to fail.

Option A is incorrect because GitHub Actions workflows are not relevant to Azure Pipelines. Option B is for rerunning failed stages, not individual tests. Option C reruns failed jobs, not tests.

Practice this question →

15

MCQhard

You are designing a build pipeline that must be triggered only when changes are made to specific folders in the repository. The pipeline should ignore documentation changes. Which trigger configuration should you use?

A.Configure a scheduled trigger to run the pipeline daily.

B.Configure a branch trigger with an include filter for the main branch.

C.Configure a path trigger with include paths for source code and exclude paths for docs.

D.Configure a tag trigger with a pattern that matches release tags.

AnswerC

A path trigger uses include/exclude patterns on file paths to decide whether a push starts the pipeline. By including paths to source code folders and excluding paths to docs, the pipeline runs only when actual code changes, precisely matching the trigger requirement while ignoring doc-only commits.

Why this answer

Azure Pipelines path triggers allow you to specify include and exclude filters on file paths. By including only source code folders and excluding the docs folder, the pipeline will only run when relevant code changes are made, ignoring documentation updates.

Exam trap

The trap here is that candidates often confuse branch triggers with path triggers, thinking that filtering by branch alone can ignore documentation changes, but branch filters only control which branches trigger the pipeline, not which files within those branches.

How to eliminate wrong answers

Option A is wrong because a scheduled trigger runs the pipeline at specified times regardless of any changes, so it would not respond to specific folder changes. Option B is wrong because a branch trigger with an include filter for the main branch only restricts which branch triggers the pipeline, not which paths within that branch; it would still trigger on any change to the main branch, including documentation. Option D is wrong because a tag trigger is designed to run the pipeline when a Git tag matching a pattern is pushed, not for monitoring changes to specific folders.

Practice this question →

16

MCQhard

You have a YAML pipeline that deploys to multiple environments. The pipeline uses environment approvals. You need to ensure that the pipeline waits for manual approval before deploying to the production environment. The production environment is named 'Production'. Which configuration should you add to the deployment job?

A.Add 'environment: Production' to the deployment job and configure approvals on the environment in the Azure DevOps portal

B.Add 'approvals: Production' to the deployment job

C.Add 'checks: Production' to the deployment job

D.Add 'dependsOn: ProductionApproval' and use a separate stage for approval

AnswerA

In Azure DevOps, attaching a deployment job to an environment named 'Production' and configuring approvals on that environment in the portal is the correct, native mechanism. The environment acts as a gate that pauses the pipeline before deployment, waiting for the designated approvers to approve or reject the release, with full audit trail and notifications.

Why this answer

Environment approvals in Azure DevOps are configured on the environment resource itself, not in the pipeline YAML. By adding 'environment: Production' to the deployment job, the pipeline references the environment, and the manual approval gate is enforced by the approvals configured on that environment in the Azure DevOps portal. This ensures the pipeline waits for approval before proceeding to the production deployment job.

Exam trap

The trap here is that candidates often assume approvals can be defined directly in the YAML pipeline (like a task or a key), but Azure DevOps requires approvals to be configured on the environment resource in the portal, not in the pipeline code.

Why the other options are wrong

B

'approvals' is not a valid keyword in YAML pipeline syntax.

C

'checks' is not a valid keyword; checks are configured on environments.

D

While you can create a separate stage for approval, it's not the standard way; environment approvals are built-in.

Practice this question →

17

MCQhard

You have the YAML pipeline shown in the exhibit. What will be the output of the script in the Deploy stage?

A.The Deploy stage will be skipped

B.Deploying to prod

C.Deploying to dev

D.The script will fail because variable is not defined

AnswerB

The Deploy stage defines the variable 'environment' with the value 'prod' in its stage-level variables block. This stage-scoped variable overrides any same-named variable from the pipeline or global scope, so when the script executes 'echo Deploying to $(environment)', it outputs 'Deploying to prod'.

Why this answer

The YAML pipeline defines a variable `environment` at the stage level with the value `prod`. The script in the Deploy stage references `$(environment)`, which resolves to `prod`, so the output is `Deploying to prod`. Stage-level variables override any pipeline-level or default variables for that stage.

Exam trap

The trap here is that candidates may assume the variable `environment` is undefined or defaults to `dev` from a pipeline-level variable, but they overlook that the stage-level definition explicitly sets it to `prod`, which overrides any broader scope.

How to eliminate wrong answers

Option A is wrong because the Deploy stage is not skipped; it runs normally with the stage-level variable `environment` set to `prod`. Option C is wrong because the variable `environment` is explicitly set to `prod` in the stage, not `dev`; if no stage-level variable were defined, it might default to `dev` from a pipeline-level variable, but here the stage-level value takes precedence. Option D is wrong because the variable `environment` is defined at the stage level, so it is available to the script; the script will not fail due to an undefined variable.

Practice this question →

18

MCQhard

You are implementing a multi-stage YAML pipeline in Azure Pipelines for a microservices application. You need to ensure that the 'deploy' stage only runs if the 'build' stage succeeds and that the 'test' stage runs in parallel with 'build' for different services. How should you structure the pipeline?

A.Define stages 'build', 'test', 'deploy' with 'dependsOn: []' on 'test' and 'dependsOn: build' on 'deploy'

B.Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy' but use 'condition: always()' on test

C.Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy'

D.Define stages 'build', 'test', 'deploy' with no dependsOn; by default they run sequentially

AnswerA

test runs in parallel with build because it has no dependencies; deploy runs after build.

Why this answer

Setting `dependsOn: []` on the 'test' stage removes any implicit dependency, allowing it to run in parallel with the 'build' stage (since stages without explicit dependencies default to running sequentially after the previous stage). The 'deploy' stage with `dependsOn: build` ensures it only runs after the 'build' stage succeeds, as Azure Pipelines stages by default only run if all dependencies succeed. This structure meets the requirement: 'test' runs in parallel with 'build' for different services, and 'deploy' depends on 'build' success.

Exam trap

The trap here is that candidates assume stages always run sequentially by default and overlook the `dependsOn: []` syntax to break the implicit dependency chain, leading them to choose options that enforce sequential execution or incorrect conditions.

How to eliminate wrong answers

Option B is wrong because `condition: always()` on the 'test' stage would cause it to run even if the 'build' stage fails, which violates the requirement that 'deploy' only runs if 'build' succeeds (though 'test' could still run, the condition is unnecessary and could lead to unwanted behavior). Option C is wrong because it makes 'test' depend on 'build' (sequential, not parallel) and 'deploy' depend on 'test', forcing a linear order that does not allow 'test' to run in parallel with 'build'. Option D is wrong because by default stages run sequentially in the order they are defined, so 'build' would run first, then 'test', then 'deploy', which does not achieve parallel execution of 'test' with 'build'.

Practice this question →

19

MCQeasy

You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

A.trigger: branches: include: - main

B.pr: branches: include: - main

C.resources: repositories: - repository: self trigger: branches: include: - main

D.schedules: - cron: "0 0 * * *" branches: include: - main

AnswerA

This is the standard YAML syntax in Azure Pipelines to trigger a pipeline on a push to the main branch in GitHub. It uses the `trigger` keyword with branch filters under `branches.include`, causing the pipeline to run automatically when commits are pushed to that branch.

Why this answer

The `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

Exam trap

The trap here is that candidates often confuse the `trigger` (CI push trigger) with the `pr` (pull request trigger), or incorrectly assume that a resource-level trigger is required for the self repository, when the root-level `trigger` is the correct and simplest configuration for push-based CI on the same repository.

Why the other options are wrong

B

This triggers on pull request creation, not on push.

C

This is for triggering from another repository, not the self repo.

D

This is a scheduled trigger, not on push.

Practice this question →

20

Multi-Selecthard

Which THREE steps should you take to implement a blue-green deployment strategy for an Azure App Service using Azure Pipelines? (Choose three.)

Select 3 answers

A.Create a deployment slot named 'staging' for the App Service.

B.Enable 'Auto swap' on the staging slot.

C.Deploy the new version to the staging slot.

D.Delete the production slot after swapping.

E.Route 100% of traffic to the staging slot.

AnswersA, B, C

Create a deployment slot named 'staging' for the App Service: This creates a separate live app slot that acts as the 'green' environment, allowing you to deploy and validate a new build without affecting the 'blue' production slot. The staging slot gets its own hostname and app settings, and you can later swap it with the production slot to promote the new version.

Why this answer

In a blue-green deployment for Azure App Service using Azure Pipelines, the three key steps are: create a staging deployment slot (A), enable 'Auto swap' on the staging slot (B), and deploy the new version to the staging slot (C). Auto-swap ensures that after the new version is deployed and validated, the staging slot automatically swaps with the production slot, enabling zero-downtime updates. Option D (deleting the production slot after swapping) is incorrect because the production slot continues to hold the previous version for potential rollback.

Option E (routing 100% of traffic to the staging slot) is incorrect because traffic routing is handled by the swap operation, not by manually directing traffic.

Practice this question →

21

MCQmedium

Your team uses GitHub Actions to build and deploy a Node.js application to Azure App Service. The deployment succeeds, but the app crashes after startup with an error indicating a missing module. The build artifact includes the node_modules folder. What is the most likely cause?

A.The .gitignore file excludes node_modules from the artifact.

B.The Node.js version on the runner differs from the App Service runtime, causing native module incompatibility.

C.The workflow YAML has an indentation error that causes the deploy step to fail silently.

D.The build step does not run npm ci, so the package-lock.json is ignored.

AnswerB

The runner and Azure App Service runtime must use the same Node.js major version (or at least a compatible ABI) for native modules such as bcrypt or sharp. If the workflow builds with a different Node.js version than the App Service runtime, those native addons are compiled against incompatible V8/N-API binaries and fail to load at startup, producing a 'module not found' or similar crash.

Why this answer

The most likely cause is that the Node.js version on the GitHub Actions runner differs from the version on Azure App Service, leading to native module incompatibility. Native modules (e.g., those using node-gyp) are compiled against the specific Node.js ABI (Application Binary Interface) of the build environment. If the runtime version differs, the compiled .node binaries will fail to load, resulting in a 'missing module' error even though the node_modules folder is present in the artifact.

Exam trap

The trap here is that candidates assume a missing module error always means the file wasn't included in the artifact, but in this scenario the node_modules folder is present, so the real issue is ABI incompatibility between the build and runtime Node.js versions.

How to eliminate wrong answers

Option A is wrong because the .gitignore file does not affect the build artifact; GitHub Actions artifacts are created from the workspace after the build step, and the workflow explicitly includes node_modules in the artifact. Option C is wrong because an indentation error in the YAML would cause the workflow to fail at parse time, not silently skip the deploy step; the deployment succeeded, so the YAML is valid. Option D is wrong because npm ci is used for deterministic installs based on package-lock.json, but the error is about a missing module at runtime, not about the install process; the artifact includes node_modules, so npm ci was likely run or the modules were otherwise included.

Practice this question →

22

MCQhard

Your organization uses Azure Pipelines to manage infrastructure as code with Terraform. The pipeline runs terraform plan and apply. You need to ensure that the state file is stored securely and can be locked to prevent concurrent modifications. What should you configure?

A.Store the state file in a Git repository with LFS.

B.Use the Terraform Cloud backend with remote operations.

C.Store the state file in Azure Pipelines secure files.

D.Use an Azure Storage account as the backend with a container for the state file.

AnswerB, D

Terraform Cloud does provide state locking and remote operations, but it is a third-party SaaS that requires managing an external subscription and credentials outside Azure; for an Azure-centric pipeline, an Azure Storage-backed backend is the native, integrated choice.

Why this answer

Both Azure Storage backend (D) and Terraform Cloud backend (B) satisfy the requirement of secure state storage and locking. Azure Storage uses blob leases; Terraform Cloud uses its own locking mechanism. The original explanation only justifies D but does not explain why B is incorrect, and it cannot be considered incorrect as written.

Exam trap

The trap here is that candidates may confuse secure file storage (Option C) with state file storage, not realizing that state files require dynamic locking and frequent updates, which secure files do not support.

How to eliminate wrong answers

Option A is wrong because storing the state file in a Git repository with LFS does not provide native locking mechanisms and can lead to merge conflicts or corruption when multiple pipelines attempt to update the state simultaneously. Option B is wrong because Terraform Cloud with remote operations is a paid service and introduces an external dependency, whereas the requirement specifies using Azure Pipelines and Azure-native services. Option C is wrong because Azure Pipelines secure files are designed for storing secrets or configuration files, not for dynamic state files that require read/write locking and frequent updates during pipeline execution.

Practice this question →

23

MCQmedium

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. Which security practice should you implement?

A.Use GitHub Actions secrets and ensure they are marked as masked

B.Store secrets in a YAML file within the repository

C.Pass secrets as environment variables in the workflow

D.Use a third-party secret management service and fetch secrets at runtime

AnswerA

Use GitHub Actions secrets and ensure they are marked as masked. This is correct because secrets are automatically masked in logs when referenced via ${{ secrets.NAME }}.

Why this answer

GitHub Actions automatically masks secret values in build logs when referenced via the secrets context, such as ${{ secrets.SECRET_NAME }}. Option B is wrong because storing secrets in a repository YAML file exposes them to anyone with repo access. Option C is wrong not because environment variables are unsecurely logged, but because it is not the recommended practice; secrets should be referenced directly through the secrets context to avoid risk of unintended exposure (e.g., if the value is modified or used outside GitHub's masking).

Option D, while a valid security practice, does not directly address preventing log exposure unless the fetched secrets are also masked.

Exam trap

The trap is that even when using GitHub Actions secrets, if you output them to logs using echo or similar commands without proper masking, they can still be exposed. However, if you use the built-in secret syntax (${{ secrets.NAME }}), GitHub automatically masks them.

Practice this question →

24

Multi-Selecthard

Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?

Select 3 answers

A.Use variable groups scoped to environments to override variables per stage.

B.Use environment-level approvals to gate production deployments.

C.Use stage-level approvals to gate each stage.

D.Use conditions on stages to filter based on branch.

E.Use YAML templates to define each environment's deployment steps.

AnswersA, B, D

In Azure Pipelines, variable groups can be linked to an environment, allowing environment-specific variable values to be automatically injected into deployment jobs that target that environment. This enables per-stage overrides without duplicating pipeline code, because each stage can reference a different environment and thus consume its linked variable group, making it a valid and recommended practice.

Why this answer

Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code.

For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch.

To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.

Exam trap

The trap here is that candidates often confuse stage-level approvals (which do not exist) with environment-level approvals, and they mistakenly think YAML templates should be used to define separate deployment steps per environment instead of parameterizing a single template.

Practice this question →

25

MCQhard

You configured a multi-stage YAML pipeline with a deployment job that uses a deployment strategy like 'runOnce' or 'rolling'. You need to ensure that the deployment target is marked as 'succeeded' only after the deployment job completes successfully, and that any previous deployment to the same environment is preserved for rollback. Which setting must you configure?

A.Set the environment's 'retain' property to 1 or more

B.Set the deployment job's 'continueOnError' to true

C.Use the 'deployment' job with 'strategy: rolling'

D.Set the 'deploymentStrategy' to 'blueGreen'

AnswerA

Setting the environment's 'retain' property to 1 or more instructs Azure Pipelines to keep the specified number of previous deployments for that environment. This retained deployment history enables rollback to a prior version, as the pipeline can redeploy the previous artifact without needing to recreate it.

Why this answer

Setting the environment's 'retain' property to 1 or more ensures that the previous deployment (e.g., the last successful run) is preserved as a 'retained' revision in the environment. This allows you to redeploy that specific revision for rollback purposes. The deployment job marks the environment target as 'succeeded' only after the job completes successfully, and retaining previous revisions prevents them from being automatically cleaned up.

Exam trap

The trap here is that candidates often confuse deployment strategies (rolling, blue-green) with revision retention, assuming that a strategy like 'rolling' or 'blueGreen' inherently preserves previous deployments for rollback, when in fact retention is a separate environment-level setting.

Why the other options are wrong

B

This would continue on failure, not preserve previous deployments.

C

This defines the update strategy but does not control retention of history.

D

Blue-green is a deployment strategy, but retention is still controlled by environment settings.

Practice this question →

26

MCQmedium

Your team uses GitHub Actions to build a Python application. The workflow includes a step to run unit tests with pytest. The tests pass locally but fail in CI with 'ModuleNotFoundError: No module named 'myapp''. The repository structure has the application code in a subdirectory 'src/'. What is the most likely fix?

A.Set the working directory of the test step to 'src/'.

B.Add a step to install dependencies with 'pip install -r requirements.txt'.

C.Set the environment variable PYTHONPATH to 'src/' before running tests.

D.Add a step to run 'pip install -e .' from the repository root.

AnswerC

Setting PYTHONPATH to 'src/' before running tests adds the 'src' directory to Python's module search path, allowing the test runner to import the local package modules directly. This is a standard and effective fix for a src-layout project where the package has not been installed, directly resolving the ModuleNotFoundError.

Why this answer

The Python interpreter cannot find the 'myapp' module when tests run in CI, even though the code is present in the 'src/' subdirectory. Setting PYTHONPATH to 'src/' tells Python to include that directory in the module search path, allowing 'import myapp' to resolve correctly without moving or copying files. This is the most direct fix for a missing module path issue in a CI environment where the working directory is not automatically set to the source folder.

Exam trap

The trap here is that candidates often confuse changing the working directory (Option A) with modifying the module search path, not realizing that Python's import resolution depends on sys.path, not the current working directory.

How to eliminate wrong answers

Option A is wrong because setting the working directory to 'src/' would only change where the test step runs, but it does not add 'src/' to Python's module search path; the tests would still fail if they import 'myapp' from a parent directory. Option B is wrong because installing dependencies with 'pip install -r requirements.txt' addresses missing third-party packages, not the inability to find the local 'myapp' module. Option D is wrong because 'pip install -e .' installs the package in editable mode from the repository root, but if the setup.py or pyproject.toml is not configured to include the 'src/' layout, it may not make 'myapp' importable; even if it did, it is an over-engineered solution compared to simply setting PYTHONPATH.

Practice this question →

27

MCQmedium

Your team uses Azure Pipelines to build a .NET application. Recently, builds have been failing intermittently with NuGet restore errors. The pipeline uses a hosted agent. You need to ensure consistent package restoration. What should you do?

A.Use a self-hosted agent with persistent NuGet package caches.

B.Clear the NuGet cache in the pipeline using 'dotnet nuget locals all --clear' before restore.

C.Enable multi-stage Docker builds for the application.

D.Configure the pipeline to use the Dapr sidecar for package management.

AnswerA

Using a self-hosted agent with persistent NuGet package caches keeps the global-packages folder and HTTP cache across pipeline runs, so restore operations reuse already-downloaded packages instead of hitting external feeds every time. This reduces dependency on feed availability and network reliability, making builds faster and less prone to transient outages.

Why this answer

Using a self-hosted agent with persistent NuGet package caches ensures that packages are not re-downloaded on each build, avoiding intermittent network failures. Option B would clear the cache and force re-download, worsening the issue. Option C is for Docker builds, not NuGet.

Option D is unrelated to package restoration.

Practice this question →

28

MCQhard

You have a YAML pipeline that uses a multi-stage build. You want to cache the restored NuGet packages across builds to improve performance. Which caching strategy should you use?

A.Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'

B.Use the NuGetCommand@2 task with the -Cache argument.

C.Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.

D.Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.

AnswerA

The Cache@2 task is the correct built-in mechanism for caching NuGet packages in Azure Pipelines. The composite key, combining 'nuget', the agent OS, and packages.lock.json, invalidates the cache only when the OS or the lock file changes, ensuring restore artifacts are reused across runs. The path points to the packages folder (typically the global packages folder) so subsequent restore operations can use the cached packages without hitting the network.

Why this answer

The Cache@2 task is the recommended way to cache NuGet packages in Azure Pipelines. By using a cache key that includes the agent OS and the packages.lock.json file, the cache is invalidated only when the lock file changes, ensuring restored packages are reused across builds. The path points to the NuGet global packages folder, which is typically $(System.DefaultWorkingDirectory)/packages when NUGET_PACKAGES is set.

Exam trap

The trap here is that candidates may confuse the Cache@2 task's explicit key-path pairing with other NuGet-specific arguments or environment variables, assuming a simpler flag exists, when in fact Azure DevOps requires the Cache@2 task for reliable cross-build caching.

Why the other options are wrong

B

NuGetCommand does not have a -Cache argument for cross-build caching.

C

The environment variable is useful but caching must be explicitly configured.

D

--no-restore skips restore, not caching.

Practice this question →

29

MCQmedium

You have a multi-stage YAML pipeline that deploys to a Linux-based Azure App Service. The pipeline uses a 'Deploy to Azure App Service' task. You need to ensure that the deployment uses the Kudu REST API with ZIP deployment. Which value should you set for the 'packageForLinux' task input?

A.Set 'enableCustomDeployment' to true

B.Set 'packageForLinux' to true

C.Set 'useWebDeploy' to false

D.Set 'enableKuduDeploy' to true

AnswerB

Why this answer

The 'packageForLinux' input must be set to 'true' to force the 'Deploy to Azure App Service' task to use the Kudu REST API with ZIP deployment when targeting a Linux-based Azure App Service. This is required because Linux App Services do not support WebDeploy (MSDeploy) and rely on the Kudu endpoint for ZIP-based deployments.

Exam trap

The trap here is that candidates confuse the 'packageForLinux' input with a generic 'enableKudu' switch, not realizing that Kudu is the underlying mechanism for ZIP deployment on Linux and that this specific input is required to activate it.

Why the other options are wrong

A

This enables custom deployment scripts, not specifically ZIP deployment via Kudu for Linux.

C

This disables Web Deploy, but does not enable ZIP deployment for Linux.

D

There is no such input 'enableKuduDeploy' in the Azure Web App task.

Practice this question →

30

MCQeasy

You are designing a release pipeline for a mission-critical application. The pipeline must deploy to multiple environments (dev, test, prod) in sequence, with manual approval required before production deployment. Which Azure Pipelines feature should you use?

A.Pre-deployment approvals

B.Variable groups

C.Pipeline triggers

D.Deployment gates

AnswerA

Pre-deployment approvals define mandatory manual sign-off by designated approvers before a release is deployed to a stage. They act as a compliance checkpoint in the release pipeline and are distinct from automated gates, ensuring human oversight for mission-critical environments.

Why this answer

Pre-deployment approvals are the correct feature because they allow you to require manual sign-off before a release proceeds to a specific stage. In this scenario, you need a manual approval gate before production deployment, which is exactly what pre-deployment approvals enforce—the release pauses at the production stage until an authorized user approves it.

Exam trap

The trap here is that candidates often confuse pre-deployment approvals with deployment gates, thinking both are manual checks, but deployment gates are automated and based on external signals, not human approval.

How to eliminate wrong answers

Option B is wrong because variable groups store configuration values (like connection strings or secrets) and do not provide any approval or gating mechanism for deployment stages. Option C is wrong because pipeline triggers control when a pipeline starts (e.g., on code commit or schedule), not manual approval gates within a release. Option D is wrong because deployment gates are automated health checks (e.g., monitoring metrics or incident status) that evaluate conditions continuously, not manual approval steps requiring human intervention.

Practice this question →

31

MCQhard

Your team uses a monorepo in Azure Repos with multiple projects. You want to trigger a pipeline only when changes are made to a specific subfolder. Which configuration should you use?

A.Use a branch filter in the CI trigger.

B.Add a 'paths' filter to the CI trigger.

C.Configure the checkout step to only include the subfolder.

D.Use a 'file_match' condition on the job.

AnswerB

Paths filter triggers the pipeline only when files in the specified path change.

Why this answer

Azure Pipelines CI triggers support a 'paths' filter that allows you to specify include or exclude patterns for file changes. When a monorepo contains multiple projects in separate subfolders, adding a 'paths' filter to the CI trigger ensures the pipeline only runs when changes are detected within that specific subfolder, avoiding unnecessary builds for unrelated projects.

Exam trap

The trap here is that candidates confuse the checkout step's sparse checkout or path filtering with trigger-level path filtering, mistakenly believing that limiting what is downloaded also prevents the pipeline from being triggered by changes outside that path.

How to eliminate wrong answers

Option A is wrong because a branch filter in the CI trigger controls which branches trigger the pipeline, not which file paths within the repository; it cannot restrict triggers to a specific subfolder. Option C is wrong because configuring the checkout step to only include the subfolder limits what files are downloaded to the agent, but it does not prevent the pipeline from being triggered by changes outside that subfolder; the trigger still fires on any change in the repo. Option D is wrong because Azure Pipelines does not support a 'file_match' condition on a job; path-based triggering is configured at the pipeline trigger level, not as a job condition.

Practice this question →

32

MCQeasy

Your build pipeline uses a hosted agent. You notice that every build starts with a clean workspace, increasing build time. You want to improve performance by caching the Node.js 'node_modules' folder. Which task should you add to the pipeline?

A.Publish Build Artifacts task

B.Copy Files task

C.Download Build Artifacts task

D.Cache task

AnswerD

The Cache task is designed exactly for this: it captures a specified folder after a run and restores it on subsequent runs using a defined key (typically a hash of package manifests) and cache hit variables. When the key matches, it avoids expensive re-downloads or recompilation, making it the correct way to persist dependency caches on hosted agents. Its whole purpose is cross-run reuse, unlike tasks that publish, copy, or download artifacts.

Why this answer

The Cache task (option D) is correct because it allows you to cache the 'node_modules' folder between pipeline runs on hosted agents, avoiding the need to reinstall dependencies from scratch each time. By specifying a cache key (e.g., based on package-lock.json) and the path to cache, subsequent builds can restore the folder from cache, significantly reducing build time.

Exam trap

The trap here is that candidates confuse the Cache task with artifact tasks (Publish/Download Build Artifacts), assuming artifacts can be used for caching, but artifacts are designed for immutable output storage and lack the key-based restoration and automatic eviction that the Cache task provides for performance optimization.

How to eliminate wrong answers

Option A is wrong because the Publish Build Artifacts task is used to store build outputs (e.g., compiled binaries) for later use or release, not for caching intermediate folders like node_modules across builds. Option B is wrong because the Copy Files task simply copies files from source to destination within the workspace, but does not persist them across pipeline runs or provide caching functionality. Option C is wrong because the Download Build Artifacts task retrieves previously published artifacts, but artifacts are immutable and not designed for the incremental, key-based caching of node_modules that the Cache task provides.

Practice this question →

33

MCQhard

Refer to the exhibit. You are deploying this ARM template using Azure Pipelines. The pipeline passes the parameter 'environmentName' with value 'prod'. What will be the name of the virtual network?

A.vnet-default

B.vnet-prod

C.vnet-prod-vnet

D.vnet-dev

AnswerB

The ARM template variable expression uses string concatenation to join the prefix 'vnet-' with the value of the environment parameter. Because the parameter is set to (or defaults to) 'prod', the variable correctly resolves to 'vnet-prod', which is the intended name for the virtual network.

Why this answer

The ARM template uses the `concat` function to combine the string 'vnet-' with the value of the `environmentName` parameter. Since the pipeline passes 'prod' for `environmentName`, the resulting virtual network name is 'vnet-prod'. This is a standard pattern for parameterizing resource names in Azure Resource Manager templates.

Exam trap

The trap here is that candidates may assume the parameter's default value ('dev') is used instead of recognizing that the pipeline explicitly overrides it with 'prod', leading them to incorrectly select 'vnet-dev'.

How to eliminate wrong answers

Option A is wrong because 'vnet-default' would only be the result if the `environmentName` parameter had a default value of 'default' and no override was provided, but the pipeline explicitly passes 'prod'. Option C is wrong because 'vnet-prod-vnet' would require an additional concatenation or a different expression, such as `concat('vnet-', parameters('environmentName'), '-vnet')`, which is not present in the template. Option D is wrong because 'vnet-dev' would only be produced if the parameter value were 'dev', but the pipeline passes 'prod'.

Practice this question →

34

MCQmedium

A team uses Azure Pipelines to build a .NET application. The build takes 30 minutes, and developers complain that the pipeline runs slowly. The pipeline uses the 'windows-latest' agent and installs the .NET SDK in each run. Which action would MOST reduce the build time?

A.Enable pipeline caching for the .NET SDK.

B.Deploy a self-hosted agent in Azure.

C.Increase the number of parallel jobs.

D.Change the agent pool to 'ubuntu-latest'.

AnswerA

Enabling pipeline caching for the .NET SDK stores the downloaded SDK and NuGet packages in a shared cache, so subsequent pipeline runs can reuse them instead of re-downloading and re-extracting the SDK from the network. This directly reduces the repetitive setup time that dominates the pipeline's build time, especially when the project specifies a pinned SDK version.

Why this answer

Enabling pipeline caching for the .NET SDK allows the SDK to be restored from a cache instead of being downloaded and installed on every run. This eliminates the recurring overhead of SDK installation, which is a significant portion of the 30-minute build time, directly addressing the slow pipeline complaint.

Exam trap

The trap here is that candidates often confuse reducing build time with scaling resources (parallel jobs or self-hosted agents) instead of recognizing that eliminating redundant work (SDK installation) via caching directly shortens the pipeline duration.

How to eliminate wrong answers

Option B is wrong because deploying a self-hosted agent does not reduce the time spent installing the .NET SDK; it only removes agent provisioning delays, and the SDK must still be installed each run unless caching is also used. Option C is wrong because increasing parallel jobs speeds up concurrent builds but does not reduce the duration of a single build pipeline. Option D is wrong because changing to 'ubuntu-latest' would require a different .NET SDK installation and may introduce compatibility issues, but the SDK still needs to be installed each run without caching, so build time would not be significantly reduced.

Practice this question →

35

Multi-Selectmedium

Which TWO conditions must be met for a self-hosted agent to be used in an Azure Pipelines agent pool? (Choose two.)

Select 2 answers

A.The agent must be in the Default pool.

B.The agent must have network access to Azure Pipelines.

C.The agent must run on Windows Server.

D.The agent must be installed on a virtual machine.

E.The agent must be registered with the agent pool.

AnswersB, E

A self-hosted agent must have outbound network connectivity to the Azure Pipelines service over HTTPS. This connection is required to poll for queued jobs, download task definitions and source code, and report execution status back to the service; without it the agent cannot participate in pipelines.

Why this answer

A self-hosted agent must have outbound network connectivity to Azure Pipelines (specifically to the Azure DevOps service endpoints) in order to receive job assignments, download tasks, and report status. Without this network access, the agent cannot communicate with the orchestration layer and will remain offline. This is a fundamental requirement for any agent, whether hosted or self-hosted.

Exam trap

The trap here is that candidates often assume self-hosted agents must be in the Default pool or run on a specific OS, but Azure Pipelines allows any pool and any supported OS (Windows, Linux, macOS) as long as the agent is registered and has network access.

Practice this question →

36

MCQhard

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

A.Recreate deployment

B.Canary deployment

C.Blue-green deployment

D.Rolling deployment

AnswerB

Canary deployment is correct because it gradually shifts traffic to the new version, starting with a small percentage, and promotes it only if health checks and key metrics pass. If the health checks fail partway through, the rollout can be halted or rolled back, and only the small canary slice of users has been exposed to the problematic version. This satisfies the requirement for a gradual, safer release with a limited blast radius and controlled promotion.

Why this answer

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

Exam trap

The trap here is that candidates confuse canary deployment with blue-green deployment, assuming both involve a full cutover, but canary specifically requires gradual traffic shifting with health-check validation before full promotion.

How to eliminate wrong answers

Option A is wrong because a recreate deployment tears down the existing environment and deploys the new version all at once, with no gradual traffic shift or canary phase. Option C is wrong because a blue-green deployment swaps all traffic from the stable (blue) environment to the new (green) environment in one cutover, not gradually shifting traffic to a canary. Option D is wrong because a rolling deployment updates instances incrementally but does not typically use a separate canary environment with health-check gating before full traffic shift.

Practice this question →

37

MCQmedium

You have a multi-stage YAML pipeline that builds and deploys a Java application. The pipeline runs on a Microsoft-hosted agent. The build stage fails intermittently with 'OutOfMemoryError: Java heap space'. What should you do to resolve this issue?

A.Set the environment variable 'MAVEN_OPTS' to '-Xmx2048m'.

B.Use a self-hosted agent with more memory.

C.Set the environment variable 'GRADLE_OPTS' to '-Xmx2048m'.

D.Use the 'Maven@3' task with the 'jdkVersion' option set to 'jdk11'.

AnswerA

Setting MAVEN_OPTS to -Xmx2048m explicitly sets the maximum JVM heap size for the Maven process, ensuring the build has 2GB of heap available and directly addressing the OutOfMemoryError during compilation or tests. This is the standard environment variable for passing JVM arguments to Maven, and -Xmx is the primary switch to increase heap space.

Why this answer

The 'OutOfMemoryError: Java heap space' in a Maven build indicates that the JVM running Maven needs more heap memory. Setting the environment variable 'MAVEN_OPTS' to '-Xmx2048m' increases the maximum heap size for the Maven JVM process to 2048 MB, which resolves the memory issue. This is the standard and correct approach for Maven-based builds.

Exam trap

The trap here is that candidates may confuse 'MAVEN_OPTS' with 'GRADLE_OPTS' or think that increasing agent memory (Option B) will automatically increase JVM heap, but the JVM heap is independent of physical memory and must be explicitly configured.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with more memory does not directly address the JVM heap limit; the error is caused by insufficient heap allocated to the Maven process, not the agent's physical memory. Option C is wrong because 'GRADLE_OPTS' is used for Gradle builds, not Maven; setting it would have no effect on a Maven pipeline. Option D is wrong because changing the JDK version with the 'jdkVersion' option does not affect JVM heap settings; it only selects the Java Development Kit version for compilation.

Practice this question →

38

MCQmedium

You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?

A.Use a multi-stage YAML pipeline with environment per region and a manual approval on each environment.

B.Create three separate stages (one per region) and duplicate the deployment tasks in each.

C.Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.

D.Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.

AnswerA

While this approach provides a manual approval gate per region via separate environments, it still requires the pipeline author to define and manage duplicate environment objects and job logic for each region, significantly increasing YAML complexity and maintenance burden compared to a single reusable job that targets tagged deployment group agents.

Why this answer

For a phased rollout to multiple Azure App Service regions, you should create an environment per region and use a multi-stage YAML pipeline that contains deployment jobs (or stages) targeting those environments. Manual approval gates can be configured on each environment, enabling controlled progression from West US to East US to North Europe without duplicating tasks. This approach directly uses App Service slots and environments.

Deployment group jobs (Option D) are intended for targeting on-premises or VM-based agents, not App Service instances, and do not support slots. Options B and C are incorrect because they duplicate tasks or deploy in parallel rather than in the required phased sequence.

Exam trap

The trap is assuming deployment groups are the universal solution for multi-target deployment. For Azure App Service, deployment groups are not appropriate; you must use environments and deployment jobs targeting App Service resources.

Practice this question →

39

MCQhard

Your team uses Azure DevOps to deploy a Node.js web app to Azure App Service on Linux. The build pipeline runs `npm install` and `npm run build`, then publishes the `dist` folder. The release pipeline uses the 'Azure App Service deploy' task. Recently, deployments fail intermittently with 'ERR_MODULE_NOT_FOUND' for a custom module. The module is listed in `package.json` and is present in the `node_modules` folder on the build agent. What is the most likely cause?

A.The 'Azure App Service deploy' task modifies package.json during deployment.

B.The 'Azure App Service deploy' task runs npm install on the target, but it fails due to network restrictions.

C.The build artifact does not include node_modules; the app requires them at runtime.

D.The deployment slot's Kudu service fails to sync the dist folder.

AnswerC

The build artifact contains only the dist folder because the pipeline's publish step excluded node_modules, yet the Node.js app needs those dependencies at runtime to load modules. Without node_modules in the artifact, the deployed app cannot find required packages and fails to start, regardless of how the App Service deploy task behaves.

Why this answer

The most likely cause is that the build artifact does not include the `node_modules` folder. The build pipeline runs `npm install` and `npm run build`, which installs dependencies on the build agent, but only the `dist` folder is published as the artifact. At deployment time, the Azure App Service on Linux expects the `node_modules` folder to be present in the deployed artifact because it does not automatically run `npm install` for Node.js apps on Linux (unlike Windows-based App Services).

Without `node_modules`, the app cannot resolve custom modules at runtime, leading to the `ERR_MODULE_NOT_FOUND` error.

Exam trap

The trap here is that candidates often assume the Azure App Service deploy task automatically runs `npm install` on the target (like it does on Windows), but on Linux, the default behavior is to deploy the artifact as-is without dependency restoration unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because the 'Azure App Service deploy' task does not modify `package.json` during deployment; it simply transfers the artifact to the target App Service. Option B is wrong because the 'Azure App Service deploy' task does not run `npm install` on the target for Linux App Service; it relies on the artifact containing all necessary dependencies. Option D is wrong because the Kudu service (which is a Windows-based deployment engine) is not used for Azure App Service on Linux; Linux App Service uses Oryx or direct artifact deployment, and the error is not related to sync failures of the `dist` folder.

Practice this question →

40

MCQeasy

You need to integrate security scanning into your build pipeline to detect vulnerable open-source dependencies. Which Azure DevOps extension should you use?

A.WhiteSource Bolt

B.Azure Policy

C.GitHub Advanced Security

D.SonarQube

AnswerA

WhiteSource Bolt is a build-task extension in Azure DevOps that scans open-source components from package managers like npm, NuGet, and Maven against the Whitesource vulnerability database, failing the pipeline on known CVEs and generating an inline report. It fits the requirement directly because it performs security scanning during the build, whereas other options either do not target open-source dependencies or are not integrated into Azure Pipelines.

Why this answer

WhiteSource Bolt is a free Azure DevOps extension that integrates directly into build pipelines to automatically scan open-source dependencies for known vulnerabilities. It identifies vulnerable components, provides remediation guidance, and enforces security policies without requiring additional configuration or external tools, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) or SonarQube (a code quality tool) with a dedicated dependency vulnerability scanner, overlooking that WhiteSource Bolt is purpose-built for open-source security scanning in Azure Pipelines.

How to eliminate wrong answers

Option B is wrong because Azure Policy is a governance tool for enforcing compliance rules on Azure resources (e.g., tagging, location restrictions), not a dependency scanner for open-source libraries in a build pipeline. Option C is wrong because GitHub Advanced Security is a suite of security features for GitHub repositories (including code scanning and secret scanning), but it is not an Azure DevOps extension and does not integrate directly into Azure Pipelines for dependency scanning. Option D is wrong because SonarQube is a code quality and static analysis tool that focuses on code smells, bugs, and technical debt, not specifically on detecting vulnerable open-source dependencies; it requires additional plugins or configurations to perform dependency scanning.

Practice this question →

41

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. How can you prevent this from happening in the future?

A.Enable 'Secret scanning' and 'Push protection' for the repository.

B.Add the secret to the 'Secret scanning' exclusion list.

C.Instruct developers to avoid using 'echo' and use '::set-output' instead.

D.Use the 'actions/secrets' action to mask secrets automatically.

AnswerA

These features detect and block secrets in code and logs.

Why this answer

Enabling Secret scanning and Push protection for the repository helps prevent secrets from being exposed in build logs. Secret scanning can detect secrets when they are pushed or used in workflows, and Push protection blocks pushes containing secrets. Additionally, GitHub Actions automatically masks any string that matches a repository secret or organization secret if it appears in logs, but the developer accidentally printed it.

Enabling these features provides proactive detection and prevention. Option B is incorrect because adding the secret to the exclusion list would allow it to be exposed. Option C is incorrect because echoing with `::set-output` still prints the value to logs.

Option D is incorrect because the `actions/secrets` action does not exist; secrets are accessed via the `secrets` context.

Practice this question →

42

MCQeasy

The exhibit shows an Azure CLI command to run a pipeline. What does this command do?

A.Runs the pipeline on all branches with the variable.

B.Runs the pipeline and sets a secret variable.

C.Runs the pipeline named 'MyPipeline' on the 'main' branch with a variable 'myVar' set to 'value1'.

D.Creates a new pipeline named 'MyPipeline' with a variable.

AnswerC

This option correctly describes `az pipelines run --name MyPipeline --branch main --variables myVar=value1`: it triggers an existing pipeline definition named `MyPipeline`, targets the `main` branch, and injects a non-secret variable `myVar` with the value `value1` for that run.

Why this answer

The Azure CLI command `az pipelines run --name MyPipeline --branch main --variables myVar=value1` triggers an existing pipeline named 'MyPipeline' on the 'main' branch, passing a plain-text variable 'myVar' with the value 'value1'. The `--variables` parameter sets pipeline variables at runtime, but they are not automatically marked as secret; to set a secret variable, you must use the `--secret-variables` parameter instead. This matches option C exactly.

Exam trap

The trap here is that candidates confuse the `--variables` parameter with `--secret-variables`, assuming all variables passed at runtime are automatically secured, when in fact Azure CLI requires an explicit flag to treat them as secret.

How to eliminate wrong answers

Option A is wrong because the command specifies a single branch (`--branch main`), not 'all branches'; running on all branches would require omitting the `--branch` parameter or using a wildcard, which Azure CLI does not support. Option B is wrong because the `--variables` parameter sets a plain-text variable, not a secret variable; to set a secret variable, you must use the `--secret-variables` parameter (e.g., `--secret-variables mySecret=value`). Option D is wrong because `az pipelines run` triggers an existing pipeline, it does not create a new one; creating a pipeline requires the `az pipelines create` command.

Practice this question →

43

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that deployment to production only occurs after a successful deployment to a staging environment and requires approval from a senior developer. The deployment workflow is defined in a single YAML file. What is the most efficient way to achieve this?

A.Add a step that pauses the pipeline until a manual approval is received via a custom webhook.

B.Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.

C.Use a build matrix to run staging and production deployments in parallel.

D.Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.

AnswerD

Environment protection rules enforce approvals, and conditional steps ensure order.

Why this answer

GitHub Actions supports deployment environments with required reviewers. By defining separate 'staging' and 'production' environments, you can use a conditional step to deploy to staging first, and then require manual approval from a senior developer before the production deployment proceeds. This approach is built into GitHub Actions and does not require external webhooks or manual workflow triggers, making it the most efficient and secure method.

Exam trap

The trap here is that candidates may think a build matrix or manual trigger is sufficient, but they overlook the need for sequential deployment and built-in approval gating, which is exactly what GitHub Environments with required reviewers provide.

How to eliminate wrong answers

Option A is wrong because pausing a pipeline via a custom webhook is not a native GitHub Actions feature; it would require building and maintaining external infrastructure, which is inefficient and error-prone. Option B is wrong because using a workflow_dispatch trigger requires the senior developer to manually run the workflow, which bypasses the staging deployment check and does not enforce the sequential dependency (staging must succeed first). Option C is wrong because a build matrix runs jobs in parallel, but the requirement is for staging to complete before production; parallel execution would allow production deployment without staging success, violating the sequential dependency.

Practice this question →

44

MCQhard

Your release pipeline uses deployment groups to deploy to on-premises servers. You want to ensure that only one deployment runs at a time on each server. Which option should you configure?

A.Set the deployment queue to 'Deploy one at a time' with 'Exclusive lock'.

B.Configure a pre-deployment condition that checks the current deployment status.

C.Add a manual approval step before each deployment.

D.Set the deployment queue to 'Deploy all in parallel' with 'Number of parallel deployments' set to 1.

AnswerA

Exclusive lock ensures that only one deployment runs on each target at a time.

Why this answer

Setting the deployment queue to 'Deploy one at a time' with 'Exclusive lock' ensures that only one deployment runs at a time on each server in the deployment group. This lock prevents concurrent deployments to the same target, which is essential for on-premises servers that cannot handle parallel updates without conflicts.

Exam trap

The trap here is that candidates confuse 'Deploy one at a time' with a simple queue setting, but the key is the 'Exclusive lock' option, which specifically prevents concurrent deployments to the same resource, unlike parallel deployment settings that only control the number of simultaneous runs across different targets.

How to eliminate wrong answers

Option B is wrong because a pre-deployment condition that checks the current deployment status does not enforce a queue-based lock; it only evaluates a condition before starting a deployment, but multiple deployments could still start simultaneously if the condition passes. Option C is wrong because a manual approval step only pauses the pipeline for human intervention, but it does not prevent concurrent deployments to the same server once approved. Option D is wrong because setting 'Deploy all in parallel' with 'Number of parallel deployments' set to 1 still allows parallel deployments across multiple servers, not a per-server exclusive lock, and it does not prevent concurrent runs on the same server.

Practice this question →

45

MCQmedium

Your team uses a multi-stage YAML pipeline in Azure Pipelines. The pipeline includes a stage that runs integration tests against a test environment. You want to ensure that the integration tests are not affected by other pipelines that deploy to the same environment concurrently. What should you implement?

A.Set the environment's 'Exclusive lock' check to enabled.

B.Set the pipeline's 'Maximum number of parallel deployments' to 1.

C.Configure a required template check on the environment.

D.Add a manual approval check on the environment.

AnswerA

Enabling the Exclusive lock check on an environment in Azure DevOps ensures that only one pipeline run can deploy to that environment at a time; any other runs that attempt to acquire the lock are queued until the current run releases it, providing the required concurrency control without limiting deployments across unrelated environments.

Why this answer

The 'Exclusive lock' check on an environment ensures that only one pipeline deployment can use that environment at a time. When enabled, Azure Pipelines will queue any other pipeline runs that target the same environment, preventing concurrent deployments that could interfere with integration tests. This directly addresses the requirement to avoid conflicts from parallel deployments.

Exam trap

The trap here is confusing pipeline-level concurrency limits (Option B) with environment-level exclusive access, leading candidates to think limiting a single pipeline's parallelism is sufficient when multiple pipelines could still collide.

How to eliminate wrong answers

Option B is wrong because setting 'Maximum number of parallel deployments' on the pipeline limits the number of concurrent runs of that specific pipeline, but does not prevent other pipelines from deploying to the same environment simultaneously. Option C is wrong because a required template check enforces that a specific YAML template is used in the pipeline, but does not control concurrency or access to the environment. Option D is wrong because a manual approval check pauses the deployment for human approval but does not prevent concurrent deployments from other pipelines once approved; it does not provide exclusive access.

Practice this question →

46

MCQhard

Your team uses Azure Pipelines to deploy a web app to Azure App Service. The deployment uses the 'AzureWebApp@1' task with a deployment slot. You need to ensure that after a successful deployment to the staging slot, the slot swap happens automatically and the staging slot is warmed up before the swap. Which configuration should you use?

A.Use the 'Azure App Service manage' task to swap slots after deployment.

B.Set the 'Slot' parameter to 'staging' and enable 'Swap with production' in the task.

C.Use the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment.

D.Configure the deployment task to deploy to staging and then use a separate task to swap.

AnswerB

This automatically swaps after deployment with warmup.

Why this answer

The 'AzureWebApp@1' task includes a 'Swap with production' checkbox that, when enabled, automatically performs a slot swap after the deployment to the specified slot (e.g., staging) completes. This ensures the staging slot is warmed up by the deployment process before the swap, as the swap operation respects the warm-up phase of the target slot, preventing downtime and ensuring the production slot receives a fully initialized application.

Exam trap

The trap here is that candidates often think a separate swap task or CLI command is required for slot swapping, but the 'AzureWebApp@1' task's built-in 'Swap with production' option handles both deployment and warm-up automatically, making it the simplest and most reliable choice.

How to eliminate wrong answers

Option A is wrong because the 'Azure App Service manage' task is a separate task that can swap slots, but it does not inherently integrate with the deployment task to ensure automatic warm-up before swap; it requires manual sequencing and does not leverage the built-in warm-up behavior of the deployment task. Option C is wrong because using the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment adds unnecessary complexity and does not automatically handle warm-up; the CLI command performs a swap but does not guarantee the staging slot is warmed up before the swap unless additional warm-up logic is explicitly implemented. Option D is wrong because deploying to staging and then using a separate task to swap is a valid approach but lacks the automatic warm-up guarantee provided by the 'Swap with production' setting in the 'AzureWebApp@1' task; the separate swap task may swap before the staging slot is fully warmed up, leading to potential downtime or cold-start issues.

Practice this question →

47

Multi-Selecthard

Which THREE components are required to implement a self-hosted agent pool in Azure Pipelines?

Select 3 answers

A.An Azure Resource Manager service connection.

B.A YAML pipeline definition.

C.The Azure Pipelines agent software installed on the machine.

D.A virtual machine or physical server to host the agent.

E.A personal access token (PAT) with agent pool management permissions.

AnswersC, D, E

The Azure Pipelines agent software is the core executable that runs on the self-hosted machine to request work from Azure DevOps and execute pipeline jobs. Without this software installed, the machine cannot act as an agent, so it is an essential component for implementing a self-hosted agent.

Why this answer

The Azure Pipelines agent software is the core component that executes pipeline jobs on the self-hosted machine. Without installing the agent software (via the agent configuration script), the machine cannot register with Azure Pipelines or run any tasks, making it a mandatory requirement for a self-hosted agent pool.

Exam trap

The trap here is that candidates often confuse the authentication method for the agent (PAT) with the service connection used for Azure resource deployments, leading them to incorrectly select the ARM service connection as a required component.

Practice this question →

48

MCQeasy

You are creating a release pipeline that deploys to Azure App Service. You want to ensure that the deployment uses the 'Run from package' feature for faster deployments and reduced downtime. Which deployment method should you select in the 'Azure App Service deploy' task?

A.Web Deploy

B.Container

C.RunFromPackage

D.Zip Deploy

AnswerC

RunFromPackage is the correct deployment method for Azure Functions because it deploys a zip package and sets the WEBSITE_RUN_FROM_PACKAGE app setting, which makes the function app run directly from the mounted zip blob. This approach provides benefits like atomic deployment, faster startup, and avoids file lock issues, and it is the recommended deployment mechanism for Azure Functions.

Why this answer

The 'Run from package' feature deploys your app as a zip package directly to Azure App Service, bypassing the file copy and compilation steps of traditional methods. This reduces deployment time and downtime because the app runs from the package without extracting it to the wwwroot folder. Selecting 'RunFromPackage' in the Azure App Service deploy task enables this behavior by setting the WEBSITE_RUN_FROM_PACKAGE app setting to 1.

Exam trap

The trap here is that candidates confuse 'Zip Deploy' with 'Run from package' because both use zip files, but Zip Deploy extracts the package to wwwroot, while Run from package runs directly from the zip, offering faster deployments and reduced downtime.

How to eliminate wrong answers

Option A is wrong because Web Deploy (msdeploy) performs incremental file synchronization and can cause longer deployment times and potential downtime due to file locking. Option B is wrong because Container deployment is used for deploying Docker containers to App Service, not for deploying code packages with the 'Run from package' feature. Option D is wrong because Zip Deploy extracts the zip package to the wwwroot folder, which can lead to file locking and slower deployments compared to running directly from the package.

Practice this question →

49

MCQmedium

Your team uses GitHub Actions to build and deploy a static website to Azure Storage. The workflow uses the 'azure/storage-blob-upload' action to deploy to a storage account static website. Recently, deployments started failing with 'Error: Failed to get credentials'. The workflow uses OpenID Connect (OIDC) for authentication. What is the most likely cause?

A.The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.

B.The storage account firewall is blocking the GitHub Actions IP range.

C.The OIDC configuration in GitHub is missing the 'client secret' field.

D.The 'azure/storage-blob-upload' action does not support static websites.

AnswerA

OIDC only authenticates the GitHub workflow as the service principal; for the upload to succeed, that principal must also be authorized for data operations. Without the 'Storage Blob Data Contributor' role assigned on the storage account (or a containing scope), Azure returns an authorization failure even though authentication succeeded.

Why this answer

The 'azure/storage-blob-upload' action requires the service principal used for OIDC authentication to have the 'Storage Blob Data Contributor' role on the storage account to upload static website content. Without this role, the action fails to obtain credentials for blob write operations, resulting in the 'Failed to get credentials' error.

Exam trap

The trap here is that candidates often confuse authentication (OIDC token exchange) with authorization (role assignment), assuming a valid OIDC configuration automatically grants access, when in fact the service principal must have the appropriate Azure RBAC role on the target resource.

How to eliminate wrong answers

Option B is wrong because a storage account firewall blocking GitHub Actions IP ranges would cause a network connectivity error (e.g., '403 Forbidden' or timeout), not a credential retrieval failure. Option C is wrong because OIDC authentication in GitHub Actions does not use a client secret; it relies on a federated identity credential and token exchange, so a missing client secret is irrelevant. Option D is wrong because the 'azure/webapps-deploy' action fully supports deploying to Azure Storage static websites when the correct role and permissions are configured.

Practice this question →

50

Multi-Selectmedium

Your release pipeline deploys to multiple environments (dev, test, prod). You need to ensure that only authorized users can approve production deployments. Which TWO actions should you take?

Select 2 answers

A.Use a manual intervention task in the pipeline.

B.Set environment permissions to allow only specific users to create releases.

C.Configure deployment gates to check for user approval.

D.Add a 'Approval' check on the production environment.

E.Add a pre-deployment approval to the production stage.

AnswersD, E

Checks can require approval from specific users or groups.

Why this answer

The correct actions to ensure only authorized users can approve production deployments are to add an 'Approval' check on the production environment (option D) and to add a pre-deployment approval to the production stage (option E). Both methods require explicit user approval before deployment proceeds. Option A is incorrect because a manual intervention task pauses the pipeline for interactive validation but does not enforce user authorization checks; it is typically used for prompts, not approval gates.

Option B is incorrect because environment permissions control who can create releases or manage environments, not who can approve deployments to production—they manage access at a higher level. Option C is incorrect because deployment gates are automated health checks (e.g., monitoring metrics) that can block deployment based on conditions, but they do not handle user approval; approval is a separate check type.

Practice this question →

51

MCQhard

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that allows rolling back to the previous version quickly if a deployment fails. The pipeline should also support canary deployments. Which tool or feature should you use?

A.Terraform with Kubernetes provider.

B.Helm package manager with Helm deploy task.

C.Azure Pipelines Kubernetes manifest task with kubectl apply.

D.Kubectl task with rolling update strategy.

AnswerB

Correct: Helm supports rollback and canary deployments.

Why this answer

Helm is the correct choice because it provides native support for rollbacks via `helm rollback`, which can revert a release to a previous revision quickly. Additionally, Helm supports canary deployments through its upgrade strategy (e.g., `--set canary.enabled=true`) and integration with tools like Flagger or Argo Rollouts, enabling fine-grained traffic shifting. The Helm deploy task in Azure Pipelines wraps these capabilities, making it the most suitable tool for both rollback and canary requirements.

Exam trap

The trap here is that candidates often confuse `kubectl apply` (which only applies manifests) with a full release management tool, overlooking Helm's built-in rollback and canary support that are explicitly required by the question.

How to eliminate wrong answers

Option A is wrong because Terraform with Kubernetes provider is an infrastructure-as-code tool focused on provisioning and managing Kubernetes resources, not on release management or rollback strategies; it lacks native support for canary deployments or quick rollbacks of application releases. Option C is wrong because the Azure Pipelines Kubernetes manifest task with `kubectl apply` applies manifests directly but does not provide built-in rollback mechanisms or canary deployment capabilities; it relies on manual `kubectl rollout undo` commands and lacks revision history management. Option D is wrong because the `kubectl task with rolling update strategy` only supports basic rolling updates and does not natively support canary deployments or automated rollbacks; it requires custom scripting for traffic splitting and revision tracking.

Practice this question →

52

Multi-Selectmedium

Which TWO tasks can be used to deploy an Azure Web App using YAML pipelines in Azure DevOps?

Select 2 answers

A.AzureWebApp

B.CopyFilesOverSSH

C.AzureRmWebAppDeployment

D.AzureFunctionApp

E.AzureVMAppDeployment

AnswersA, C

AzureWebApp is a first-class Azure Pipelines deployment task designed specifically for Azure App Service. It supports multiple deployment methods, including ZIP deploy, Web Deploy, and container images, and can be used on both Windows and Linux agents, making it a correct choice for deploying an Azure web app.

Why this answer

The AzureWebApp task is correct because it is the dedicated Azure DevOps YAML pipeline task for deploying code to an Azure Web App (App Service). It supports deployment methods like Web Deploy (msdeploy), Kudu REST API, and ZIP deploy, making it the standard choice for web app deployments.

Exam trap

The trap here is that candidates often confuse AzureRmWebAppDeployment as a deprecated or incorrect task, but it remains a valid YAML pipeline task for Azure Web App deployments, especially when using ARM-based deployment slots.

Practice this question →

53

MCQeasy

Your team uses Azure Pipelines for CI/CD. You want to enforce that every build produces a versioned artifact that includes the Git commit ID. Which predefined variable should you use to get the commit ID in a YAML pipeline?

A.Build.Repository.Name

B.Build.BuildId

C.Build.SourceVersion

D.Build.SourceBranch

AnswerC

Build.SourceVersion contains the full commit ID (SHA) of the source that triggered the pipeline. This is the appropriate predefined variable to enforce policies, tag builds, or take actions based on the exact commit, making it the correct answer.

Why this answer

The `Build.SourceVersion` predefined variable in Azure Pipelines resolves to the commit ID (full SHA) of the commit that triggered the pipeline. This makes it the correct choice for embedding the Git commit ID into a versioned artifact. Other variables like `Build.BuildId` or `Build.SourceBranch` do not provide the commit hash.

Exam trap

The trap here is that candidates often confuse `Build.BuildId` (a pipeline run counter) with a Git commit identifier, or assume `Build.SourceBranch` contains the commit hash because it includes 'Source' in its name.

How to eliminate wrong answers

Option A is wrong because `Build.Repository.Name` returns the name of the repository (e.g., 'my-repo'), not the commit ID. Option B is wrong because `Build.BuildId` is a numeric identifier for the pipeline run, not a Git commit hash. Option D is wrong because `Build.SourceBranch` returns the branch or tag reference (e.g., 'refs/heads/main'), not the commit ID.

Practice this question →

54

MCQhard

Your release pipeline uses a multi-stage YAML with environments. You need to ensure that only one deployment runs at a time to a production environment to avoid conflicts. Which feature should you use?

A.Use a condition to check if a previous deployment is in progress.

B.Add a pre-deployment approval gate.

C.Set the 'parallel' deployment option to 1.

D.Configure an exclusive lock policy on the production environment.

AnswerD

Configuring an exclusive lock policy on the Production environment ensures that only a single pipeline run can deploy to that environment at any given time. Once a deployment job acquires the lock, any other deployment jobs targeting the same environment will be queued and wait until the lock is released.

Why this answer

An exclusive lock policy on an environment ensures that only one deployment can run at a time to that environment. When a deployment starts, it acquires a lock on the environment; subsequent deployments are queued until the lock is released. This prevents conflicts from concurrent deployments to the same production environment.

Exam trap

The trap here is that candidates often confuse 'parallel deployment' settings (which control concurrency within a single stage) with environment-level locking (which controls concurrency across multiple pipeline runs targeting the same environment).

How to eliminate wrong answers

Option A is wrong because conditions in YAML evaluate at runtime based on variables or previous job status, but they do not provide a queuing mechanism to prevent concurrent deployments; they only skip or run a stage based on a boolean expression. Option B is wrong because pre-deployment approval gates add manual or automated checks before a deployment starts, but they do not serialize deployments; multiple approvals can be granted concurrently, leading to simultaneous deployments. Option C is wrong because the 'parallel' deployment option controls the number of parallel deployment jobs within a single stage, not across stages or environments; setting it to 1 only limits parallelism within that stage, not across different pipeline runs targeting the same environment.

Practice this question →

55

MCQhard

You are designing a build pipeline that produces a NuGet package. The pipeline must conditionally sign the assembly only when the build is triggered by a tag starting with 'v' (e.g., v1.0.0). The pipeline uses a script task that signs the assembly. Which expression should you use in the condition of the script task?

A.and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v'))

B.and(succeeded(), startsWith(variables['Build.SourceBranchName'], 'v'))

C.and(succeeded(), startsWith(variables['Build.SourceVersion'], 'v'))

D.and(succeeded(), eq(variables['Build.Reason'], 'IndividualCI'))

AnswerA

The Build.SourceBranch variable holds the full Git ref, which for a tag push is exactly 'refs/tags/vX.Y.Z'. By using startsWith(..., 'refs/tags/v'), the condition first verifies that the ref is under the 'refs/tags/' namespace, ensuring it is a tag rather than a branch, and then checks that the tag name starts with 'v' to restrict to version-style tags. This accurately limits the signing step to semantic-version tags, making it the correct condition.

Why this answer

The condition uses `startsWith(variables['Build.SourceBranch'], 'refs/tags/v')` to check if the build was triggered by a tag whose full Git ref starts with `refs/tags/v`. This ensures the signing script runs only when the source branch is a tag reference matching the 'v' prefix, which is the standard way to identify version tags in Azure Pipelines. The `and(succeeded(), ...)` wrapper guarantees the previous tasks completed successfully before signing.

Exam trap

The trap here is that candidates often confuse `Build.SourceBranchName` (short name) with `Build.SourceBranch` (full ref), leading them to choose Option B, which would incorrectly match branches or other refs starting with 'v' instead of only tags.

Why the other options are wrong

B

Build.SourceBranchName for a tag is the tag name, so this would also work but is less precise; however, the official documentation recommends using Build.SourceBranch.

C

Build.SourceVersion is the commit SHA, not the tag.

D

Build.Reason checks for CI trigger, not tag.

Practice this question →

56

MCQmedium

Your team is using GitHub Actions for CI/CD. The workflow builds a container image and pushes it to Azure Container Registry (ACR). However, the workflow fails with an authentication error when pushing to ACR. What is the most likely cause?

A.The repository name in the workflow is incorrect.

B.The Dockerfile is missing a required LABEL instruction.

C.The ACR allows anonymous pull access.

D.The workflow does not include an 'azure/login' step to authenticate with Azure.

AnswerD

The azure/login action establishes Azure credentials for the job, and a subsequent docker login step (or azure/docker-login) uses those credentials to authenticate with the ACR. Without the azure/login step, the workflow has no authenticated context for Azure, so the Docker push receives an unauthorized or authentication-required response, exactly matching the reported failure.

Why this answer

GitHub Actions workflows that push container images to Azure Container Registry (ACR) must first authenticate with Azure. Without an 'azure/login' step (using Azure CLI or Azure PowerShell actions), the workflow lacks the necessary OAuth2 tokens or service principal credentials to authorize the 'docker push' command against the ACR endpoint. The authentication error occurs because the Docker client cannot obtain a valid ACR access token without prior Azure authentication.

Exam trap

The trap here is that candidates assume Docker authentication is handled automatically by the Docker client or that ACR allows anonymous pushes, when in fact Azure requires explicit Azure AD authentication via the 'azure/login' action before any registry write operations.

How to eliminate wrong answers

Option A is wrong because an incorrect repository name would cause a 'repository does not exist' or 'name unknown' error, not an authentication error (HTTP 401/403). Option B is wrong because a missing LABEL instruction in the Dockerfile does not affect authentication; it is a metadata instruction that has no impact on registry push permissions. Option C is wrong because anonymous pull access (if enabled) only allows pulling images without authentication, not pushing; pushing always requires authenticated access regardless of pull settings.

Practice this question →

57

MCQmedium

Refer to the exhibit. The pipeline YAML includes an Azure CLI script that sets an app setting on a Web App. The pipeline fails with an authentication error. What is the most likely cause?

A.The resource group name is incorrect.

B.The pipeline does not have an Azure service connection configured for authentication.

C.The DEPLOYMENT_SLOT setting name is invalid.

D.The script syntax is invalid.

AnswerB

The Azure CLI task (AzureCLI@2) requires an Azure service connection to authenticate to Azure. Without a service connection defined in the pipeline's inputs (e.g., azureSubscription), the task cannot obtain credentials, causing an authentication error before any script executes.

Why this answer

The Azure CLI script in the pipeline attempts to run `az webapp config appsettings set`, which requires authentication to Azure. Without an Azure service connection configured in the pipeline, there is no authenticated session or service principal to authorize the command, resulting in an authentication error. The service connection provides the necessary credentials (e.g., via Azure AD) for the pipeline to interact with Azure resources.

Exam trap

The trap here is that candidates may focus on the script content or resource details (like the slot name or resource group) instead of recognizing that the fundamental authentication mechanism for Azure CLI in a pipeline is the service connection, not the script itself.

How to eliminate wrong answers

Option A is wrong because an incorrect resource group name would cause a 'ResourceNotFound' or similar error, not an authentication error. Option C is wrong because an invalid DEPLOYMENT_SLOT setting name would cause a validation or runtime error when the app setting is applied, not an authentication failure. Option D is wrong because invalid script syntax would produce a syntax or parsing error before any Azure CLI command is executed, not an authentication error.

Practice this question →

58

MCQhard

You are managing a pipeline that deploys a microservices application to multiple Azure Kubernetes Service (AKS) clusters in different regions. You want to implement a progressive exposure strategy where the deployment first goes to a small cluster (canary), then to a medium cluster, and finally to all clusters. The deployment should be automated but with the ability to halt if errors occur. What should you use?

A.Use manual approval gates between stages.

B.Use deployment gates with evaluation of health metrics (e.g., error rate) before proceeding to the next stage.

C.Configure a rolling deployment strategy on each cluster.

D.Use a manual validation step in the pipeline.

AnswerB

Deployment gates automatically evaluate predefined health metrics, such as error rate, latency, or availability, before allowing the pipeline to proceed to the next stage. They continuously assess these signals and can halt or fail the deployment if thresholds are exceeded, enabling safe, automated progressive exposure across clusters without manual intervention.

Why this answer

Deployment gates in Azure Pipelines allow you to automatically evaluate health metrics (such as error rate, CPU usage, or custom metrics from Application Insights) before promoting a release to the next stage. This enables a progressive exposure strategy (canary → medium → all clusters) with automated rollback or halt if the metrics breach thresholds, without requiring manual intervention.

Exam trap

The trap here is that candidates confuse manual approval gates (Option A) with automated deployment gates (Option B), assuming any 'gate' requires human approval, when in fact deployment gates can be fully automated based on health metrics.

How to eliminate wrong answers

Option A is wrong because manual approval gates require a human to manually approve each stage, which defeats the automation requirement and introduces delay and human error risk; they do not automatically evaluate health metrics. Option C is wrong because a rolling deployment strategy is a per-cluster update mechanism (e.g., gradually replacing pods) and does not provide cross-stage gating or health-based promotion between different clusters. Option D is wrong because a manual validation step is a human-in-the-loop check, not an automated health metric evaluation, and does not support the progressive exposure logic across multiple clusters.

Practice this question →

59

MCQhard

Your team uses Azure Pipelines for CI/CD. A release pipeline fails intermittently during deployment to an Azure App Service slot. The error message indicates 'Failed to fetch access token for Azure Resource Manager service endpoint.' The service principal used has been granted Contributor role on the resource group. The issue resolves after re-creating the service connection in Azure DevOps. What is the most likely cause?

A.The service principal client secret has expired.

B.The user who created the service connection has been removed from Azure DevOps.

C.The Azure DevOps organization is behind a firewall that blocks outbound requests to Azure Resource Manager.

D.The service principal lacks the required role on the target resource group.

AnswerA

The service principal client secret has expired. Because Azure DevOps caches Azure AD tokens for a period, the pipeline may succeed on cached tokens and then fail when it must refresh them, producing the intermittent behavior seen here. Once the secret expires, any new token request to Azure AD is rejected with a 401, so the ARM deployment service connection fails. Re-creating the service connection generates a fresh client secret, which is why that is the correct remedy.

Why this answer

Service principal credentials (client secret) can expire, causing intermittent token fetch failures. Re-creating the service connection generates a new secret, temporarily resolving the issue until it expires again. Option B is wrong because the service connection is bound to the service principal, not the user who created it; removing the user does not affect the existing connection.

Option C is wrong because network restrictions would cause consistent failure, not intermittent. Option D is wrong because the service principal already has the Contributor role on the resource group.

Practice this question →

60

MCQeasy

You are setting up a build pipeline for a .NET Core application. The build should run on every pull request to the 'main' branch. Which trigger configuration should you use in the YAML pipeline?

A.trigger: pr: branches: include: - main

B.trigger: branches: include: - main

C.pr: branches: include: - main

D.pr: autoCancel: false branches: include: - '*'

AnswerC

This YAML snippet correctly configures a pull request trigger for the pipeline using the top-level `pr` key. By specifying `branches: include: main`, the pipeline will automatically run as PR validation whenever a pull request targets the `main` branch, which is exactly the desired behavior. Unlike `trigger`, which controls CI builds on branch pushes, `pr` is the dedicated mechanism for pull request validation in Azure Pipelines. This configuration is valid and requires no additional nesting or modifiers to achieve the stated goal.

Why this answer

In Azure Pipelines YAML, the `pr` trigger is used to define pull request validation triggers, separate from the `trigger` keyword which controls CI triggers on branch pushes. By specifying `pr: branches: include: - main`, the pipeline will automatically run on every pull request targeting the `main` branch, which matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse the `trigger` keyword (for CI pushes) with the `pr` keyword (for pull request validation), leading them to incorrectly nest PR settings under `trigger` or use `trigger` alone for PR scenarios.

How to eliminate wrong answers

Option A is wrong because it incorrectly nests the `pr` configuration under the `trigger` keyword; `trigger` is for CI (push) triggers, not PR triggers, and this syntax would cause a YAML parsing error or be ignored. Option B is wrong because it uses only the `trigger` keyword with a branch include, which would run the pipeline on every push to `main`, not on pull requests to `main`. Option D is wrong because it sets `autoCancel: false` (which prevents cancellation of existing PR builds when new commits are pushed) and includes all branches with `'*'`, but the requirement is specifically to trigger only on PRs to `main`, not all branches.

Practice this question →

61

Multi-Selecthard

Which THREE options are valid strategies for implementing progressive exposure in Azure Pipelines?

Select 3 answers

A.Rolling update.

B.Ring-based deployment.

C.Canary deployment.

D.Immutable infrastructure.

E.Blue-green deployment.

AnswersB, C, E

Ring-based deployment is a progressive delivery strategy that releases a new version to small, successively larger groups of users (rings), such as internal testers, then a small percentage of production users, and finally all users, allowing monitoring and rollback at each ring boundary.

Why this answer

Ring-based deployment, canary deployment, and blue-green deployment are all valid strategies for progressive exposure. Ring-based deployment gradually rolls out to increasing groups of users (rings), often using deployment gates and percentage-based rollout. Canary deployment routes a small percentage of traffic to the new version before increasing it, allowing monitoring and rollback.

Blue-green deployment runs two identical environments (blue and green) and switches traffic from the old to the new version, enabling immediate rollback. These strategies all provide controlled, incremental exposure to validate changes before full rollout.

Exam trap

The trap here is that candidates confuse rolling updates (which are about instance replacement) with progressive exposure strategies (which are about user-based or traffic-based phased rollouts), leading them to incorrectly select 'Rolling update' as a valid option.

Practice this question →

62

Multi-Selectmedium

Which TWO are valid strategies for managing secrets in Azure Pipelines?

Select 2 answers

A.Store secrets in plain text in a variable group.

B.Use a variable group linked to Azure Key Vault and mark variables as secret.

C.Store secrets in a Git repository and read them during build.

D.Embed secrets directly in the pipeline YAML file.

E.Use the Azure Key Vault task to fetch secrets and map them to pipeline variables.

AnswersB, E

A variable group linked to Azure Key Vault securely references secrets stored in Key Vault, allowing pipeline tasks to consume them as secret variables. Marking them as secret ensures they are masked in logs and not exposed, while Key Vault enforces access policies and rotation, making this a recommended, secure strategy.

Why this answer

Linking a variable group to Azure Key Vault allows secrets to be securely referenced without exposing them in plaintext; when variables are marked as secret, Azure Pipelines masks their values in logs. Alternatively, the Azure Key Vault task can fetch secrets at runtime and map them to pipeline variables for use in tasks, which also keeps secrets out of YAML and logs. Both approaches are valid strategies for secret management.

Exam trap

The trap here is that candidates may think variable groups alone are secure, but only when linked to Key Vault and marked as secret do they provide proper secret management; plain-text variable groups or YAML embedding are common missteps.

Practice this question →

63

Multi-Selectmedium

Which TWO of the following are valid strategies to securely store and use secrets in Azure Pipelines?

Select 2 answers

A.Link a variable group to Azure Key Vault and reference variables in the pipeline.

B.Use the 'AzureKeyVault' task to download secrets during the pipeline run.

C.Use the 'secret' variable type in YAML and hardcode the value.

D.Store secrets in a text file in the repository and use a script to read them.

E.Use encrypted environment variables in GitHub Actions.

AnswersA, B

This securely stores secrets in Key Vault.

Why this answer

Azure Pipelines allows you to link a variable group to Azure Key Vault, enabling secure retrieval of secrets as pipeline variables without exposing them in YAML or logs. This integration uses Azure Key Vault's access policies and managed identities to authenticate, ensuring secrets are never stored in the pipeline definition.

Exam trap

The trap here is that candidates often confuse the 'secret' variable type in YAML as a secure storage mechanism, not realizing it still requires the value to be defined in the pipeline file or library, whereas true security comes from external secret stores like Key Vault.

Practice this question →

64

MCQhard

You have the above YAML task in a pipeline. The task runs but no secrets are available in subsequent tasks. What is the most likely cause?

A.The secrets are not automatically mapped to environment variables; you must reference them using $(secretName).

B.The SecretsFilter is set to '*' which is invalid.

C.The service principal does not have 'Get' permission on the key vault.

D.The key vault name 'mykv' does not exist.

AnswerA

The Azure Key Vault task downloads secrets as pipeline variables, but it does not automatically export them to the environment of subsequent tasks. To use a secret inside a script or tool, you must reference it explicitly with the macro syntax $(secretName) or map it into the `env` section of a task. Without such explicit mapping, the secret is not visible as an environment variable, even though the task itself completed successfully.

Why this answer

By default, secrets downloaded from Azure Key Vault in a pipeline task are not automatically mapped to environment variables for subsequent tasks. You must explicitly reference them using the macro syntax `$(secretName)` or map them as environment variables with the `env` keyword. Without this explicit mapping, the secret values remain inaccessible to later tasks, even though the download task succeeds.

Exam trap

The trap here is that candidates assume downloading secrets automatically makes them available as environment variables in all subsequent tasks, but Azure DevOps requires explicit mapping via `$(secretName)` or the `env` keyword to prevent accidental leakage.

How to eliminate wrong answers

Option B is wrong because `SecretsFilter: '*'` is a valid wildcard that downloads all secrets from the key vault; it does not cause the task to fail or prevent secrets from being available. Option C is wrong because if the service principal lacked 'Get' permission on the key vault, the task itself would fail with an authorization error, not silently succeed with no secrets available. Option D is wrong because if the key vault name 'mykv' did not exist, the task would fail immediately with a 'VaultNotFound' error, not complete successfully with no secrets.

Practice this question →

65

MCQmedium

Your Azure DevOps pipeline deploys an ARM template to create a storage account. The deployment fails with 'AuthorizationFailed' error. The service principal used by the service connection has 'Contributor' role on the resource group. What is the most likely issue?

A.The 'Microsoft.Storage' resource provider is not registered for the subscription, and the service principal lacks permission to register it at subscription scope.

B.The storage account name is already taken.

C.The ARM template is using an unsupported API version.

D.The service principal does not have 'Contributor' role at the subscription scope.

AnswerA

Correct. If the Microsoft.Storage resource provider is not registered for the subscription, the deployment fails with an authorization error because the service principal cannot register it (requires subscription-level permissions).

Why this answer

The AuthorizationFailed error is likely due to the Microsoft.Storage resource provider not being registered for the subscription. The service principal has Contributor on the resource group, but registering a resource provider requires Microsoft.Register/action at the subscription scope, which the principal does not have. The service principal itself is not registered for the resource provider; resource providers are registered at the subscription level.

Exam trap

Candidates often confuse resource provider registration with RBAC permissions. Even with Contributor on the resource group, if the resource provider is not registered, the deployment can fail because the principal cannot register it at the subscription level.

How to eliminate wrong answers

Option A is wrong because the 'AuthorizationFailed' error is a permissions issue, not a resource provider registration issue; an unregistered resource provider would cause a 'RegistrationFailed' or 'MissingSubscriptionRegistration' error. Option B is wrong because a duplicate storage account name would result in a 'Conflict' or 'StorageAccountAlreadyTaken' error, not 'AuthorizationFailed'. Option C is wrong because an unsupported API version would produce a 'BadRequest' or 'InvalidTemplate' error, not an authorization failure.

Practice this question →

66

MCQhard

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

A.The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.

B.The Publish stage is missing 'dependsOn: Build'.

C.The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.

D.The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.

AnswerC

In Azure DevOps YAML pipelines, variables declared in the `variables` section are compile-time constants; they are evaluated when the pipeline is created and cannot be overridden at queue time unless defined as `runtime` parameters. Therefore, the condition referencing `publishEnabled` will always use the value from the YAML, not any queue-time value, making this the correct diagnosis.

Why this answer

In Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

Exam trap

The trap here is that candidates confuse variable evaluation timing—assuming all variables can be overridden at queue time—when in fact only parameters or explicitly settable variables can be changed, while compile-time variables are baked into the pipeline definition before runtime.

How to eliminate wrong answers

Option A is wrong because the condition syntax 'eq(variables.publishEnabled, true)' is actually correct for YAML expressions; the issue is not syntax but the variable's evaluation timing. Option B is wrong because the Publish stage does not need an explicit 'dependsOn: Build' if it already runs after the Build stage by default in a sequential multi-stage pipeline; missing dependsOn would cause a different error (e.g., stage not running at all), not the described behavior. Option D is wrong because the 'dependsOn' syntax shown in the exhibit (likely 'dependsOn: Build') is correct; the problem is not a syntax error but the variable's compile-time evaluation.

Practice this question →

67

MCQeasy

Your team uses GitHub Actions for CI/CD. You want to securely store a database connection string used in a workflow. Where should you store it?

A.GitHub Secrets.

B.Workflow environment variables.

C.Directly in the workflow YAML.

D.In a configuration file committed to repo.

AnswerA

GitHub Secrets are encrypted at rest and by default are masked in workflow logs, making them the recommended way to store sensitive values like API tokens or connection strings. They can be scoped to a repository, environment, or organization and are only exposed to workflows that explicitly reference them via ${{ secrets.NAME }}.

Why this answer

GitHub Secrets is the correct choice because it provides encrypted storage for sensitive data like database connection strings. When you store a value in GitHub Secrets, it is encrypted via libsodium before being stored, and it is only exposed to GitHub Actions workflows as an environment variable or input when explicitly referenced. This prevents the secret from being logged or leaked in the workflow output, unlike other storage methods that risk exposure.

Exam trap

The trap here is that candidates may confuse environment variables (which are plain text and visible in logs) with secrets (which are encrypted and masked), leading them to choose workflow environment variables as a simpler but insecure alternative.

How to eliminate wrong answers

Option B is wrong because workflow environment variables are stored in plain text within the workflow YAML or GitHub UI and can be printed in logs, making them insecure for secrets. Option C is wrong because directly embedding the connection string in the workflow YAML exposes it in the repository history and to anyone with read access to the repo, violating security best practices. Option D is wrong because committing a configuration file with the connection string to the repository stores it in plain text in version control, making it accessible to all users with repo access and impossible to rotate without a new commit.

Practice this question →

68

MCQhard

You are reviewing an Azure Policy definition applied to an Azure DevOps project. The project has a build pipeline that deploys to production. What is the effect of this policy on the build pipeline?

A.The policy blocks the pipeline from running if fewer than two reviewers approve.

B.The policy requires two reviewers and blocks the pipeline if not met.

C.The policy audits the pipeline but does not enforce any mandatory reviewers.

D.The policy does not apply to build pipelines because the field type is teamProjects.

AnswerC

The audit effect logs compliance without blocking.

Why this answer

Azure Policy definitions applied to Azure DevOps projects use the 'audit' effect by default for policy types that do not support 'deny' or 'enforce' on build pipelines. Since the policy in question does not specify a mandatory reviewer requirement with enforcement, it only audits the pipeline's compliance without blocking execution. Therefore, the pipeline runs regardless, and the policy logs a compliance state.

Exam trap

The trap here is that candidates assume Azure Policy can enforce pipeline-level controls like mandatory reviewers, but in Azure DevOps, Azure Policy only audits or denies resource-level configurations, not pipeline execution logic.

How to eliminate wrong answers

Option A is wrong because Azure Policy cannot block a build pipeline from running based on reviewer count; it only audits or denies resource creation, not pipeline execution. Option B is wrong because the policy does not enforce mandatory reviewers; it only audits, and Azure Policy does not have a 'require' effect for pipeline reviewers. Option D is wrong because Azure Policy applies to Azure DevOps projects via the 'Microsoft.DevOps/pipelines' resource type, and the field type 'teamProjects' is not a valid exclusion for build pipelines.

Practice this question →

69

MCQhard

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

A.Create a single pipeline that builds all projects on every commit

B.Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents

C.Use a single pipeline with a condition that checks which files changed and runs only the corresponding job

D.Create separate pipelines for each project and trigger them manually

AnswerB

Configuring path filters in the pipeline trigger limits pipeline runs to commits that touch relevant project paths, while a custom dependency detection script builds the transitive closure of affected projects and their dependents. This ensures that changes to a shared library still downstream projects to rebuild, maintaining artifact integrity while drastically reducing CI time compared to build-all approaches.

Why this answer

It uses path filters in the pipeline trigger to only run when files in the changed projects are modified, and a custom script detects dependencies between projects to also build any dependent projects. This minimizes build time while ensuring all affected projects are built. Option A builds all projects on every commit, which is inefficient.

Option C only builds changed projects but ignores dependency chains, potentially breaking the build. Option D requires manual triggers, which is not automated and defeats the purpose of CI/CD.

Practice this question →

70

MCQeasy

Refer to the exhibit. You have a YAML pipeline that deploys an ARM template. The pipeline runs successfully on the first commit to main, but subsequent commits fail with 'The resource group myResourceGroup already exists'. How should you modify the pipeline to avoid this error?

A.Change the location to a different region.

B.Add a condition to check if the resource group exists before creating it.

C.Use a different service connection for each deployment.

D.Rename the pipeline to trigger a clean build.

AnswerB

Using an Azure CLI or PowerShell task condition such as `az group exists` (which returns a boolean) before invoking the resource group creation step makes the pipeline idempotent. If the resource group already exists, the creation task is skipped, preventing the 'The resource group already exists' error while still allowing subsequent deployment tasks to run.

Why this answer

Adding a condition to check if the resource group exists before creating it avoids the error when the resource group already exists from a previous deployment. Options A, C, and D are incorrect: changing the location (A) does not prevent the existence error, using a different service connection (C) does not address resource group existence, and renaming the pipeline (D) triggers a new pipeline but does not affect resource group existence.

Practice this question →

71

MCQmedium

You have a multi-stage YAML pipeline that deploys to Azure Kubernetes Service (AKS). The pipeline uses a deployment job with a strategy of 'runOnce'. You need to ensure that if the deployment fails, the pipeline automatically redeploys the previous successful version. Which strategy should you use instead?

A.Use the 'canary' strategy with manual intervention

B.Use the 'rolling' strategy and configure 'on:failure: always'

C.Use the 'blueGreen' strategy and configure automatic swap

D.Use the 'runOnce' strategy with a rollback task

AnswerD

Correct. Adding a rollback task to the existing 'runOnce' strategy allows automatic redeployment of the previous successful version on failure, meeting the requirement without changing the strategy.

Why this answer

The requirement can be met by adding a rollback task to the existing 'runOnce' strategy. When a deployment fails, the rollback task can automatically redeploy the previous successful version. Option A requires manual intervention, which contradicts the 'automatically' requirement.

Option B uses invalid syntax ('on:failure: always')—the correct hook is 'on: failure: rollback'—and option C's automatic swap does not revert the deployment on failure.

Exam trap

Candidates often think they must change the deployment strategy to achieve rollback, but the requirement can be satisfied by adding a rollback task to the existing 'runOnce' strategy. They may also confuse 'on:failure' actions and incorrectly use 'always' instead of 'rollback'.

Why the other options are wrong

A

Canary strategy does not automatically roll back; it requires manual approval or additional steps.

C

BlueGreen strategy requires manual swap; it does not roll back automatically.

Practice this question →

72

Multi-Selectmedium

Which two actions can you use to validate that a deployment to a staging environment is successful before promoting to production? (Choose two.)

Select 2 answers

A.Configure gates on the staging environment to check health metrics.

B.Add a manual intervention task in the pipeline.

C.Set a post-deployment approval on the staging stage.

D.Use a pull request to validate the deployment.

E.Run a load test as part of the pipeline.

AnswersA, C

Gates on the staging environment evaluate pre-defined health metrics (e.g., error rate, latency, availability) after deployment completes but before promotion to production. These gates continuously query the chosen Azure Monitor or other data sources during a configurable timeout; if the metrics don't meet the threshold, the pipeline is blocked and ultimately fails, providing objective, automated validation of actual workload health.

Why this answer

Gates with health checks can monitor metrics like error rates before allowing promotion. Manual intervention with a post-deployment approval also allows a human to validate before proceeding. Both are valid methods.

Exam trap

Candidates may select 'Use a pull request' which is for code review, not deployment validation.

Why the other options are wrong

B

Manual intervention tasks are deprecated; use approvals instead.

D

Pull requests validate code changes, not deployments.

E

Load testing is a good practice but not a direct validation mechanism for promotion approval.

Practice this question →

73

MCQeasy

You are designing a build pipeline for a Python application that uses multiple third-party packages from the public PyPI repository. Your organization has security policies that require all build dependencies to be scanned for known vulnerabilities before being used. The build pipeline runs on Microsoft-hosted agents. You need to integrate vulnerability scanning into the build pipeline with minimal overhead and without storing credentials in the pipeline. What should you do?

A.Configure a service connection to a private vulnerability database and use a script to scan.

B.Write a custom script that uses pip audit to scan the requirements.txt file.

C.Use a pre-build validation step in the pipeline to manually review dependencies.

D.Add a dependency scanning task from the Azure DevOps marketplace to the build pipeline.

AnswerD

Adding a dependency scanning task from the Azure DevOps marketplace is the correct approach because it integrates directly into the pipeline, supports credential-free scanning for public packages, and automatically fails the build on detected vulnerabilities. It leverages Azure DevOps' built-in reporting, governance, and extension ecosystem, providing comprehensive coverage of both direct and transitive dependencies without custom code.

Why this answer

The correct approach is to add a dependency scanning task from the Azure DevOps marketplace to the build pipeline. These tasks, such as WhiteSource Bolt or Snyk, integrate seamlessly with Azure Pipelines, automatically scan dependencies from PyPI for known vulnerabilities, and require no credential storage in the pipeline. Option A is incorrect because connecting to a private vulnerability database adds unnecessary complexity and overhead.

Option B is incorrect because using a custom script with pip audit would require maintaining the script and potentially storing credentials for external services. Option C is incorrect because manual review is not automated and defeats the purpose of a CI/CD pipeline.

Practice this question →

74

MCQhard

You are designing a release pipeline for a critical business application that must adhere to strict compliance requirements. The pipeline must deploy to multiple environments (dev, test, staging, prod) with manual approvals required for staging and prod. Additionally, the pipeline must automatically run integration tests after deployment to dev and test, and only proceed to the next environment if tests pass. You need to implement this using Azure Pipelines YAML. What should you do?

A.Use a single multi-stage YAML pipeline with a stage per environment. Add approvals on staging and prod stages. Ensure stages run sequentially by default.

B.Create separate YAML pipelines for each environment and use pipeline completion triggers to chain them together.

C.Use a classic release pipeline with environments and pre-deployment approvals on staging and prod. Add a post-deployment task to run integration tests in dev and test environments.

D.Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.

AnswerD

Stages with conditions and approvals fulfill all requirements.

Why this answer

It uses a single multi-stage YAML pipeline with a stage per environment, adds a job after deployment to dev that runs integration tests, uses a condition on the next stage to run only if tests passed, and adds approvals on staging and prod stages. This satisfies all requirements: sequential deployment, conditional test execution, and manual approvals. Option A is incorrect because it lacks the conditional test execution; after deployment to dev, the pipeline would proceed to test regardless of test results.

Option B is incorrect because separate pipelines with completion triggers cannot enforce the required conditions (run tests and only proceed if passed) and cannot easily add approvals per environment. Option C is incorrect because it describes a classic release pipeline, which does not support YAML-based definitions and cannot easily integrate conditional test execution with stage dependencies.

Practice this question →

75

Multi-Selecthard

Your organization uses GitHub Actions for CI/CD. You need to enforce branch protection rules and ensure that all pull requests to the main branch require a successful status check from a specific workflow. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Configure a GitHub environment with required reviewers.

B.Add a workflow to the repository that runs tests and reports a conclusion status.

C.Use a repository ruleset to require status checks.

D.Set up branch policies in Azure Repos for the main branch.

E.In the repository settings, enable 'Require status checks to pass before merging' under branch protection rules.

AnswersB, E

Adding a workflow that runs tests and reports a conclusion status is the essential first step because it creates a check run (status check) whose conclusion can later be required. Without such a workflow, there is no status check for branch protection rules to enforce, so this is the correct way to enable test validation before merging.

Why this answer

A workflow that runs tests and reports a conclusion status provides the status check that branch protection rules can require. Option E is correct because enabling 'Require status checks to pass before merging' under branch protection rules in the repository settings enforces that the specific workflow's status check must succeed before a pull request can be merged into the main branch.

Exam trap

The trap here is confusing GitHub's branch protection rules with repository rulesets or Azure Repos policies, leading candidates to select options that are either for a different platform or for a different enforcement mechanism.

Practice this question →

Page 1 of 6 · 414 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Design and implement build and release pipelines questions.

Start 20-question session