Courseiva

CCNA Design and implement build and release pipelines Questions

75 of 348 questions · Page 1/5 · Design and implement build and release pipelines · Answers revealed

Practice these questionsDomain overviewAll 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 logs by replacing their values with '***', but this masking can be bypassed if a script transforms the secret (e.g., base64 encoding, splitting, or printing it in a way that changes its exact string) before outputting it. The most likely reason a secret value appeared in the log is that the script printed it in a form that bypassed the automatic masking. This is a known limitation of GitHub's secret masking.

Exam trap

AZ-400 often tests the misconception that GitHub Actions masks secrets in all cases, when in fact masking can be bypassed by transforming the secret value before printing.

How to eliminate wrong answers

Option A is wrong because triggering a workflow via repository_dispatch does not affect secret masking; secrets are still masked regardless of trigger type. Option C is wrong because using the secret name (not its value) in log output is safe — masking applies to the value, not the name. Option D is wrong because enabling debug logging does not disable secret masking; GitHub still masks secrets even in debug logs, though debug logs may reveal more context.

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

The correct approach is to create a single GitHub Actions workflow with multiple jobs: one for build and test, one for deploy to staging, and one for deploy to production that uses a GitHub Environment with required reviewers. This allows automatic deployment to staging on push to main, and manual approval for production. The official Azure actions (e.g., azure/functions-action) can be used.

Option C is the only one that meets all requirements.

Exam trap

AZ-400 often tests the use of GitHub Environments for approvals versus other approval mechanisms like GitHub Issues or Azure Pipelines approvals; candidates might choose separate workflows or Azure Pipelines, but the question specifies GitHub Actions and manual approval via GitHub Environments.

How to eliminate wrong answers

Option A is wrong because it uses two separate workflows and triggers production manually, which does not automatically promote after staging and lacks the integrated approval via GitHub Environments. Option B is wrong because it uses GitHub Issues for approval, not GitHub Environments, and does not separate jobs for clarity. Option D is wrong because it uses Azure Pipelines instead of GitHub Actions, which does not meet the requirement to use GitHub Actions and official Azure actions.

Practice this question →
4
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 →
5
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 →
6
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 →
7
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 →
8
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 →
9
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 →
10
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 →
11
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 →
12
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 →
13
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 →
14
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 →
15
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 →
16
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 →
17
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 →
18
MCQeasy

You are designing a release pipeline that deploys a web app to Azure App Service. You need to ensure that configuration secrets (e.g., database connection strings) are not stored in the pipeline YAML file. Which approach should you use?

A.Define the secrets as agent-scoped variables in the release pipeline.
B.Hardcode the secrets in the App Service configuration and reference them in the pipeline.
C.Use an Azure Key Vault variable group linked to the pipeline.
D.Store the secrets as pipeline variables and mark them as 'Secret'.
AnswerC

Linking an Azure Key Vault variable group to the release pipeline is the recommended approach because secrets are never stored in the pipeline definition or on the agent. Instead, Azure DevOps securely retrieves the latest secret values from Key Vault at runtime using the configured ARM service connection, which in turn uses a service principal or managed identity. This enables centralized secret management with fine-grained access policies, automatic rotation support, and eliminates the risk of exposing secrets in logs, version control, or build artifacts.

Why this answer

Azure Key Vault variable groups allow you to securely reference secrets stored in Azure Key Vault from within a pipeline without exposing them in the YAML file. The pipeline retrieves the secrets at runtime via a linked service connection, ensuring they never appear in source control or pipeline logs.

Exam trap

The trap is that candidates often choose Option D (secret pipeline variables) because they mask output in logs, but they fail to realize that the secret value is still stored in the pipeline definition (not in YAML, but in Azure DevOps) and can be viewed by users with access to the pipeline settings or exported via API. Key Vault variable groups provide better security through centralized secret management, permissions, and audit logging.

How to eliminate wrong answers

Option A is wrong because agent-scoped variables are not designed for secrets; they are used to scope variables to a specific agent and do not provide secure storage or access control for secrets. Option B is wrong because hardcoding secrets in App Service configuration still requires the pipeline to know the secrets to set them, and referencing them in the pipeline would expose them in the YAML or logs. Option D is wrong because marking pipeline variables as 'Secret' only masks their value in logs, but the secrets are still stored in the pipeline definition and can be exposed if the pipeline YAML is shared or stored in source control.

Practice this question →
19
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 →
20
Multi-Selecthard

You are designing a YAML pipeline in Azure Pipelines that must deploy an application to Azure Kubernetes Service (AKS). You need to ensure that the pipeline uses a Kubernetes service connection to authenticate to the AKS cluster and that the deployment is performed using a Helm chart. Which two actions should you include in the pipeline? (Choose two.)

Select 2 answers
A.Use the `HelmDeploy@0` task to deploy the Helm chart.
B.Create a Kubernetes service connection in Azure DevOps that points to the AKS cluster.
C.Use the `KubernetesManifest@0` task to deploy the application.
D.Use the `AzureResourceManagerTemplateDeployment@3` task to deploy the Helm chart.
E.Use the `Kubectl@0` task to apply the Helm chart.
AnswersA, B

The HelmDeploy task is specifically designed to deploy Helm charts to a Kubernetes cluster. It supports various commands like install, upgrade, and uninstall, and can authenticate using a Kubernetes service connection. This task is the correct choice for deploying a Helm chart in Azure Pipelines.

Why this answer

To deploy a Helm chart to AKS using Azure Pipelines, you should use the HelmDeploy task, which is designed for Helm deployments. You also need a Kubernetes service connection to authenticate to the AKS cluster. The other tasks are either for different deployment methods or not suitable for Helm charts.

Exam trap

The trap here is assuming that the KubernetesManifest task can deploy Helm charts directly, when it is intended for raw Kubernetes manifests.

Practice this question →
21
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 →
22
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 →
23
Multi-Selecteasy

You are configuring a YAML pipeline in Azure Pipelines. The pipeline must trigger only when changes are pushed to the main branch. Which setting should you configure?

Select 1 answer
A.Set the PR trigger to include main.
B.Set the pipeline to run on every push regardless of branch.
C.Use a schedule trigger with cron expression.
D.Set the trigger to include the main branch.
E.Set the trigger to none for other branches.
AnswersD

Setting the trigger to include the main branch is the standard and correct approach. In a YAML pipeline, the `trigger` section with `branches.include: [main]` defines a whitelist so that only pushes to the main branch start the pipeline. Any push to a branch not listed under `include` is implicitly ignored, giving precise control over which branches trigger CI.

Why this answer

In Azure Pipelines YAML, the `trigger` section controls which branches cause a CI pipeline to run. By setting `trigger.branches.include` to `main`, only pushes to `main` will trigger the pipeline. All other branches are automatically excluded.

There is no separate setting required to disable triggers for other branches; the include list is authoritative.

Exam trap

The trap is confusing CI triggers with PR triggers, or thinking that an include list also requires explicit exclusions. In YAML, an include list actually means only those branches are included, so no extra 'none' setting is needed.

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

A paths filter on the CI trigger restricts pipeline execution to commits touching specified subfolders, so changes elsewhere in the monorepo are ignored. This directly satisfies the requirement to trigger only for a specific subfolder without splitting the repository.

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 →
26
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 →
27
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 →
28
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 →
29
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 →
30
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 →
31
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 →
32
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

A multi-stage YAML pipeline with one environment per region and a manual approval check on each environment provides the phased rollout with approval gates while keeping stage definitions DRY through templates or repeated environment references. Environments in Azure DevOps natively support approval checks, so no duplicated approval logic is needed. This satisfies the minimize-duplication requirement.

Exam trap

AZ-400 often tests whether candidates confuse deployment groups (agent-tag-based targeting for on-prem) with environments (approval-gated deployment targets) — the manual approval requirement points to environments, not deployment groups.

How to eliminate wrong answers

Option B is wrong because duplicating deployment tasks across three separate stages increases maintenance burden and violates the minimize-duplication requirement, even though it could technically achieve phased rollout. Option C is wrong because a single stage with parallel deployment cannot enforce sequential regional rollout with approvals between regions — parallel jobs run concurrently, not in sequence. Option D is wrong because deployment groups target agents by tags for on-premises/IaaS scenarios and do not provide the environment-based approval gates or the App Service deployment slot semantics required here.

Practice this question →
33
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 →
34
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 →
35
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 →
36
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

GitHub environments hold protection rules, so the production environment's required reviewers gate the job until a senior developer approves. Staging deploys first via job ordering, satisfying both the sequencing and approval constraints within one YAML workflow.

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 →
37
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 →
38
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 →
39
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 →
40
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 →
41
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 →
42
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 →
43
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 →
44
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 →
45
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 →
46
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 →
47
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 →
48
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 →
49
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 →
50
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 →
51
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 →
52
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 →
53
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 →
54
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 →
55
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 →
56
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

To build only changed projects in a monorepo, you need to detect which files changed and then determine the affected projects and their dependents. Path filters in the pipeline trigger can limit the pipeline to run only when specific paths change, but they don't handle dependencies. A custom script can analyze the dependency graph and build only the affected projects plus their dependents, minimizing build time.

This approach is flexible and can be implemented in Azure Pipelines using scripts or tools like Nx or Lerna.

Exam trap

AZ-400 often tests the misconception that path filters alone can handle monorepo builds; candidates may forget that dependencies between projects require additional logic to ensure all affected projects are built.

How to eliminate wrong answers

Option A is wrong because building all projects on every commit wastes time and resources, especially in a large monorepo. Option C is wrong because a single pipeline with a condition that checks changed files and runs corresponding jobs can work, but it does not inherently handle dependencies between projects; you would still need to manually define dependencies or use a script. Option D is wrong because separate pipelines triggered manually do not automate the process and do not minimize build time; manual triggers are error-prone and not scalable.

Practice this question →
57
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 →
58
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 →
59
MCQeasy

You need to ensure that only specific branches can trigger a release to production in Azure Pipelines. What should you configure?

A.Add an approval gate that requires a manager to approve the release.
B.Add a deployment gate that checks the source branch.
C.Add a branch filter to the release pipeline's artifact trigger.
D.Add a branch filter to the build pipeline trigger.
AnswerC

In Azure Pipelines, a release pipeline's artifact trigger can be configured with a branch filter to specify which branches of the source repository are allowed to initiate a release. When you add a branch filter under the artifact trigger of the release pipeline, only builds from those branches (or builds that match the filter) will cause a release to be created, directly meeting the requirement to restrict which branches can trigger a release.

Why this answer

A branch filter on the release pipeline's artifact trigger allows you to specify which branches of the source artifact (e.g., a build pipeline) should automatically trigger a release. By configuring this filter to only include branches like 'main' or 'release/*', you ensure that only builds from those specific branches can initiate a release to production, providing precise control over deployment triggers.

Exam trap

The trap here is confusing branch filters on build pipeline triggers (which control when code is built) with branch filters on release pipeline artifact triggers (which control when releases are created from those builds), leading candidates to incorrectly select Option D.

How to eliminate wrong answers

Option A is wrong because an approval gate requires a manager to approve the release after it is triggered, but it does not restrict which branches can trigger the release; any branch could still initiate the release, and the gate only adds a manual approval step. Option B is wrong because a deployment gate checks conditions (like source branch) at deployment time, but it does not prevent the release from being triggered; it only evaluates whether to proceed with the deployment after the release is already created. Option D is wrong because a branch filter on the build pipeline trigger controls which branches trigger a build, not which branches trigger a release; this would affect when code is compiled, not when a release is deployed to production.

Practice this question →
60
MCQeasy

Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?

A.condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
B.condition: contains(variables['Build.SourceBranch'], 'main')
C.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
D.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
AnswerD

This condition uses eq() to perform an exact string comparison against the full source ref 'refs/heads/main'. In Azure Pipelines, Build.SourceBranch contains the full ref, so this matches only the actual main branch and excludes all others, including branches that merely contain 'main' as a substring. It is the precise, minimal condition that satisfies the requirement without adding extra behavior such as succeeded() checks.

Why this answer

The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.

Exam trap

The trap here is that candidates often choose option B (`contains`) thinking it is a simpler way to match the branch, but they overlook that `contains` does a substring match and will incorrectly trigger on branches like 'maintenance' or 'main-feature', whereas the exact ref comparison in option D is the precise and safe approach.

How to eliminate wrong answers

Option A is wrong because `ne(variables['Build.SourceBranch'], 'refs/heads/main')` runs the stage when the source branch is NOT 'main', which is the opposite of the requirement. Option B is wrong because `contains(variables['Build.SourceBranch'], 'main')` would match any branch containing 'main' in its ref path (e.g., 'refs/heads/main-feature' or 'refs/heads/notmain'), not just the exact 'main' branch. Option C is wrong because while it correctly checks for 'main', it adds `and(succeeded(), ...)` which is redundant since stages default to running only if the previous stage succeeded; this extra condition does not break the logic but is unnecessary and not the simplest correct answer.

Practice this question →
61
MCQmedium

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

A.Define an environment with approvals required for the production stage.
B.Use deployment gates in the production stage to check for manual intervention.
C.Use a classic release pipeline with pre-deployment approvals.
D.Configure a branch policy on the main branch to require approval for pull requests.
AnswerA

Defining an environment and enabling the approval check on its production stage is the correct way to require a manual sign-off before deployment. This approval is configured on the environment itself and naturally integrates with multi-stage YAML pipelines, ensuring that only authorized users can deploy to production.

Why this answer

Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Exam trap

The trap here is that candidates often confuse deployment gates (which are automated checks) with manual approvals, leading them to incorrectly select Option B, even though gates cannot provide the required manual intervention step.

How to eliminate wrong answers

Option B is wrong because deployment gates are designed for automated health checks (e.g., monitoring metrics, incident status) and do not support manual intervention; they evaluate conditions automatically, not wait for human approval. Option C is wrong because classic release pipelines with pre-deployment approvals are a legacy approach that still works, but the question asks for a strategy in the context of modern YAML-based multi-stage pipelines, where environment approvals are the recommended method. Option D is wrong because branch policies on the main branch control pull request merges and code quality, not release deployment approvals; they are unrelated to the release pipeline's manual approval requirement.

Practice this question →
62
MCQhard

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

A.Hardcode credentials in the script and encrypt the script file
B.Store credentials as pipeline variables and reference them
C.Use Azure Key Vault task to fetch secrets during deployment
D.Use environment variables on the target machines
AnswerC

The Azure Key Vault task securely retrieves secrets from Key Vault at deployment time and injects them as variables, ensuring that credentials are not stored in the pipeline or exposed in logs while centralizing access and enabling rotation.

Why this answer

The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Exam trap

The trap here is that candidates may choose Option B (pipeline variables) thinking they are secure because they can be marked as secret, but they lack the centralized management, rotation, and access control that Azure Key Vault provides, which is the recommended approach for production secrets.

How to eliminate wrong answers

Option A is wrong because hardcoding credentials in a script, even if encrypted, violates security best practices and is difficult to rotate or audit; encryption keys can be compromised. Option B is wrong because pipeline variables, even marked as secret, are stored in the pipeline definition and can be exposed in logs or export operations, and they do not provide centralized secret management. Option D is wrong because environment variables on target machines are static, not centrally managed, and can be read by any process or user on the machine, leading to credential leakage.

Practice this question →
63
MCQeasy

You are setting up a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. Each environment requires approval before deployment. What is the best way to implement this in Azure Pipelines?

A.Define pipeline stages with environment resources and pre-deployment approvals.
B.Use environment resources with 'auto' trigger and no approvals.
C.Use classic release pipelines with approval gates per environment.
D.Use a custom PowerShell script to pause and prompt for approval.
AnswerA

Defining stages with environment resources and pre-deployment approvals is the correct approach because each environment maps to a resource in Azure DevOps, and pre-deployment approvals provide a built-in, auditable manual sign-off before the deployment proceeds, making it the native and recommended YAML pipeline pattern.

Why this answer

Azure Pipelines supports multi-stage YAML pipelines where each stage can reference an environment resource. Pre-deployment approvals are configured on the environment itself, ensuring that before a stage deploys to that environment, the specified approvers must grant approval. This provides a native, auditable, and integrated approval gate without custom scripting or legacy tooling.

Exam trap

The trap here is that candidates may think classic release pipelines are still the best practice, but Microsoft has not deprecated classic releases; they are legacy and Microsoft recommends YAML pipelines with environment resources for better traceability, consistency, and integration with modern DevOps practices.

How to eliminate wrong answers

Option B is wrong because using 'auto' trigger with no approvals would automatically deploy to each environment without any manual intervention, failing the requirement for approval before deployment. Option C is wrong because classic release pipelines are a legacy approach; while they do support approval gates, the modern and recommended approach for multi-environment sequential deployments is to use YAML pipelines with environment resources and pre-deployment approvals. Option D is wrong because using a custom PowerShell script to pause and prompt for approval is brittle, non-auditable, bypasses the built-in approval workflow, and does not integrate with Azure Pipelines' environment resource tracking or deployment history.

Practice this question →
64
MCQmedium

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

A.Increase the number of parallel jobs in the organization.
B.Use more pipeline triggers.
C.Provision self-hosted agents.
D.Reduce the number of parallel jobs.
AnswerC

Self-hosted agents are owned and managed by your team, providing dedicated compute capacity that operates independently of Microsoft's hosted agent pool. By registering self-hosted agents in an agent pool that your pipelines target, you can scale out processing capacity and reduce or eliminate queue waiting times, especially for high-frequency builds.

Why this answer

Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Exam trap

The trap here is that candidates confuse 'parallel jobs' (concurrency limit) with 'agent availability' (queue wait time), assuming that buying more parallelism will speed up agent assignment when it only affects how many builds can run at once.

How to eliminate wrong answers

Option A is wrong because increasing parallel jobs only allows more builds to run concurrently once they start, but does not reduce the time a build waits in the queue for an available agent. Option B is wrong because pipeline triggers control when a build is initiated, not how quickly an agent is assigned to run it; more triggers could actually increase queue congestion. Option D is wrong because reducing parallel jobs would decrease the number of builds that can run simultaneously, likely increasing queue times further.

Practice this question →
65
MCQmedium

Your organization uses GitHub Actions for CI/CD. You want to enforce that all workflows pass required checks before a pull request can be merged. The repository is in an organization that uses GitHub Enterprise Cloud. What should you configure?

A.Add a branch protection rule that requires status checks to pass.
B.Enable 'Require approval for all workflows' in the organization settings.
C.Set the workflow to be required in the 'Require status check' settings of each pull request.
D.Create a repository ruleset that requires linear history.
AnswerA

Branch protection rules with required status checks block merging until specified GitHub Actions workflows report success. This enforces that all required checks pass before any pull request merges into the protected branch, satisfying the organisation's gating requirement.

Why this answer

Branch protection rules in GitHub Enterprise Cloud allow you to require status checks to pass before merging a pull request. By configuring a branch protection rule on the target branch (e.g., main) and selecting the specific GitHub Actions workflow status checks that must succeed, you enforce that all required CI/CD checks pass before a merge is allowed. This directly meets the requirement to enforce workflow checks on pull requests.

Exam trap

The trap here is confusing organization-level workflow approval settings (which control workflow execution) with branch-level status check requirements (which control merge permissions), leading candidates to select option B or C instead of the correct branch protection rule.

How to eliminate wrong answers

Option B is wrong because 'Require approval for all workflows' is a setting that controls whether external contributors' workflows require approval before running, not a mechanism to enforce status checks on pull requests. Option C is wrong because there is no 'Require status check' setting on individual pull requests; status checks are configured at the branch or repository level via branch protection rules or rulesets. Option D is wrong because requiring linear history enforces a linear commit history (e.g., via rebase or squash merges) but does not enforce that workflows pass checks before merging.

Practice this question →
66
Multi-Selecthard

Which THREE are valid security best practices for Azure Pipelines? (Choose three.)

Select 3 answers
A.Restrict agent pool permissions to only necessary users
B.Use Microsoft Entra ID to control access to pipelines
C.Store secrets as plain text in YAML files
D.Use variable groups with Azure Key Vault integration for secrets
E.Run build agents on domain controllers
AnswersA, B, D

Agent pool permissions determine which identities can queue jobs onto agents, so restricting them to necessary users prevents unauthorised pipeline runs and credential exposure on shared agents. This enforces least privilege at the compute boundary, a core Azure Pipelines security control.

Why this answer

Option A is correct because restricting agent pool permissions to only necessary users enforces least privilege, preventing unauthorized users from creating or modifying agents that could execute malicious pipeline jobs. Option B is correct because Microsoft Entra ID (formerly Azure AD) provides centralized identity and access control for Azure DevOps, enabling conditional access, MFA, and role-based assignments to secure pipeline access. Option D is correct because variable groups integrated with Azure Key Vault keep secrets out of YAML and pipeline definitions, retrieving them securely at runtime with proper access policies.

Option C is not a best practice because storing secrets as plain text in YAML files exposes them to anyone with repository read access and to logs or history. Option E is not a best practice because running build agents on domain controllers violates the principle of least privilege and exposes critical identity infrastructure to pipeline workloads.

Exam trap

The trap here is that candidates may think storing secrets in YAML files is acceptable if the repository is private, but Azure Pipelines explicitly warns against this because secrets can be exposed in pipeline logs, build artifacts, or through source control history.

Practice this question →
67
MCQhard

Your Azure DevOps pipeline deploys a microservice to a Kubernetes cluster using Helm. The Helm chart requires a values file that contains environment-specific configurations. You want to store the values file securely and use it during deployment. What is the recommended approach?

A.Store the values in a variable group and map them to Helm values.
B.Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.
C.Store the values file as a secure file in Azure Pipelines library.
D.Store the values file in a separate Git repository and clone it during the pipeline.
AnswerC

Secure files in the Azure Pipelines Library are encrypted at rest and can be downloaded during a pipeline run using the DownloadSecureFile task, which yields a temporary file path. This makes it the correct choice for storing a sensitive Helm values file because the original file never resides in source control and is exposed only as an encrypted library artifact.

Why this answer

Azure Pipelines provides a 'Secure files' library feature specifically designed to store files (like Helm values files, certificates, or keystores) that need to be downloaded securely during a pipeline run. The DownloadSecureFile task retrieves the file at runtime, and it can then be passed to the HelmDeploy task, keeping environment-specific configuration out of source control.

Exam trap

AZ-400 often tests the distinction between variable groups (key-value), Key Vault (secrets/certs), and Secure files (arbitrary files), so candidates who default to 'Key Vault for everything secure' pick the wrong answer for file-based configuration.

How to eliminate wrong answers

Option A is wrong because variable groups store key-value pairs, not files, and mapping them to Helm values is cumbersome and doesn't handle multi-line YAML structures well. Option B is wrong because Azure Key Vault stores secrets, keys, and certificates — not arbitrary YAML files — and the HelmDeploy task's overrideValues parameter expects inline values, not a Key Vault reference. Option D is wrong because storing the values file in a separate Git repository still exposes it to anyone with repo access and does not provide the secure, access-controlled storage that the Secure files library offers.

Practice this question →
68
MCQeasy

You have an Azure DevOps pipeline that deploys to multiple environments. You need to ensure that approvals are required before production deployment. Which pipeline configuration should you use?

A.Set the pipeline trigger to 'Manual' only
B.Add a 'Manual Intervention' task in the pipeline
C.Configure branch policies on the main branch
D.Define an environment with required approvers for the production stage
AnswerD

Defining an environment with required approvers is the correct approach because Azure Pipelines environments provide pre-deployment approval checks that pause the pipeline before the production stage runs. Each deployment to that environment must be explicitly approved by the listed users or groups, creating an auditable, enforceable gate before any production release proceeds.

Why this answer

Azure DevOps environments allow you to define required approvers for a specific stage (e.g., production). When a pipeline deploys to that environment, it pauses and waits for manual approval before proceeding, ensuring that production deployments are gated by authorized personnel.

Exam trap

The trap here is that candidates confuse branch policies (which control code merging) with deployment approvals (which control release execution), leading them to select option C instead of the environment-based approval mechanism.

How to eliminate wrong answers

Option A is wrong because setting the pipeline trigger to 'Manual' only prevents automatic pipeline runs but does not enforce approvals during the deployment process; approvals are a separate gate mechanism. Option B is wrong because the 'Manual Intervention' task is a legacy feature that pauses the pipeline for manual input, but it is not designed for multi-environment approval workflows and does not integrate with Azure DevOps environment-based approval gates. Option C is wrong because branch policies on the main branch control code quality and pull request merges, not deployment approvals; they do not gate the release pipeline after code is merged.

Practice this question →
69
Multi-Selecteasy

Which TWO strategies can you use to manage secrets in Azure Pipelines securely?

Select 2 answers
A.Use a variable group linked to Azure Key Vault.
B.Store secrets directly in the YAML pipeline file.
C.Use the 'secret' variable type in the pipeline UI.
D.Use environment variables in the build agent.
E.Print the secret in a script to verify it is correct.
AnswersA, C

A variable group linked to Azure Key Vault enables pipelines to reference secrets stored in Key Vault without never copying them into the pipeline definition. Access is governed by Azure RBAC, and secret values are dynamically retrieved at run time, keeping them out of source control and logs.

Why this answer

Options A and C are correct. Variable groups can be linked to Azure Key Vault to fetch secrets, and you can mark variables as secret in the pipeline UI to prevent them from being displayed in logs. Option B is wrong because storing secrets in YAML files exposes them in source control.

Option D is wrong because using environment variables on the build agent is not inherently secure; they can be accessed by other processes and may be logged. Option E is wrong because printing secrets in scripts exposes them in the pipeline logs, which is a security risk.

Practice this question →
70
MCQeasy

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'
B.Use the build ID as the tag and manually update 'latest'
C.Use the Git commit hash as the tag and push 'latest' separately
D.Always tag the image as 'latest' regardless of build status
AnswerA

This approach guarantees that the 'latest' tag is only moved after a fully successful build, using a condition such as `condition: succeeded()` to run a docker tag/push step. It ensures the image referenced by 'latest' is always a known-good artifact, avoiding the risk of tagging broken builds.

Why this answer

It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Exam trap

The trap here is that candidates may assume any tagging strategy that includes 'latest' is sufficient, overlooking the critical requirement that the tag must only be applied to successful builds, which is enforced by a conditional step.

How to eliminate wrong answers

Option B is wrong because manually updating the 'latest' tag introduces human error and operational overhead, and it does not automate the process to ensure only successful builds are tagged. Option C is wrong because using the Git commit hash as the tag is a valid strategy for traceability, but pushing 'latest' separately without a conditional check on build success could result in tagging a failed build as 'latest'. Option D is wrong because always tagging the image as 'latest' regardless of build status would overwrite the 'latest' tag with a broken or incomplete image, breaking downstream consumers that rely on 'latest' being a stable reference.

Practice this question →
71
MCQhard

You are configuring a multi-stage YAML pipeline in Azure Pipelines. The pipeline has stages for Build, Test, and Deploy. You need to ensure that the Deploy stage runs only if the Build and Test stages succeed, and that it uses a specific environment named 'Production' with an approval check. What should you do?

A.Add a dependsOn condition to the Deploy stage for Build and Test, and configure the environment 'Production' with an approval check.
B.Add a dependsOn condition to the Deploy stage for Build and Test, and use a manual approval task in the stage.
C.Use a condition on the Deploy stage to check the status of previous stages, and add an approval gate in the release pipeline.
D.Set the Deploy stage to run always, and use a manual intervention task before deployment.
AnswerA

Using dependsOn on the Deploy stage ensures it runs only after Build and Test succeed. Configuring the 'Production' environment with an approval check enforces manual approval before deployment. This combination meets both requirements: conditional execution and approval.

Why this answer

In YAML pipelines, stage dependencies are defined with dependsOn, and approvals are configured on environments. The Deploy stage should depend on Build and Test, and the Production environment should have an approval check. This ensures the stage runs only after successful prior stages and requires approval.

Exam trap

The trap here is confusing YAML pipeline approvals with classic release pipeline approval gates, or thinking that a manual intervention task can be used in YAML for approvals.

Practice this question →
72
Multi-Selectmedium

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Select 2 answers
A.Store secrets in environment variables on the agent machine.
B.Define secrets as pipeline secret variables and reference them as $(secretName).
C.Store secrets in a YAML file and include the file in the repository.
D.Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.
E.Use Azure Key Vault to store secrets and reference them via variable groups linked to Key Vault.
AnswersB, E

Pipeline secret variables are encrypted at rest by Azure DevOps and are masked in pipeline logs when referenced as $(secretName). Only tasks that explicitly reference the variable receive its value, and it is never exposed in the pipeline definition or logs, making this a secure method.

Why this answer

Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Exam trap

The trap here is that candidates may think masking secrets in logs (Option D) is sufficient, but masking does not protect the secret from being stored in plaintext in the pipeline definition or from being exposed in other output channels.

Practice this question →
73
Multi-Selecteasy

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

Select 3 answers
A.Schedule trigger
B.Pull request (PR) trigger
C.Continuous integration (CI) trigger
D.'on: push' trigger in YAML
E.Commit trigger
AnswersA, B, C

A schedule trigger runs the pipeline automatically at defined cron times, satisfying the requirement for a valid pipeline trigger. It is configured via the trigger's schedules block in YAML, distinct from CI, PR, or pipeline-completion triggers.

Why this answer

A is correct because Azure Pipelines supports scheduled triggers via the `schedules` block in YAML (or the Triggers UI), which runs the pipeline on a cron-based timetable. B is correct because PR triggers (`pr:` in YAML) cause the pipeline to run when a pull request is opened or updated against specified branches, typically for validation builds. C is correct because CI triggers (`trigger:` in YAML) run the pipeline automatically whenever code is pushed to the included branches, which is the standard continuous integration mechanism.

D is not a valid Azure Pipelines trigger; `on: push` is GitHub Actions syntax, not Azure Pipelines YAML. E is not a valid trigger type in Azure Pipelines; commits are picked up through CI triggers, not a separate 'commit trigger' construct.

Exam trap

Do not confuse Azure Pipelines trigger syntax with other CI systems. Azure Pipelines supports CI triggers, PR triggers, and scheduled triggers as first-class trigger types.

Practice this question →
74
MCQhard

Your pipeline builds a .NET application and runs unit tests. You notice that the pipeline takes too long because it restores NuGet packages on every run. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

A.NuGetCommand@2 with the restore command
B.CopyFiles@2
C.PowerShell@2 to manually download and cache
D.Cache@2 (CacheBeta)
AnswerD

The Cache@2 task (formerly CacheBeta) is Azure DevOps' built-in caching solution; it restores a folder from a cache key, and if there is a miss, it saves the folder after the job completes. For a .NET application, you can cache the ~/.nuget/packages directory (NuGet package cache) to speed up subsequent restores, so it is the correct answer.

Why this answer

The Cache@2 (CacheBeta) task is specifically designed to cache folders or files between pipeline runs, such as NuGet packages, to reduce restore time. By caching the NuGet packages folder (e.g., $(UserProfile)/.nuget/packages), subsequent builds can skip the full restore and reuse previously downloaded packages, significantly speeding up the pipeline.

Exam trap

The trap here is that candidates often choose NuGetCommand@2 (Option A) thinking it inherently caches packages, but it only restores from remote sources each time unless combined with a separate caching task.

How to eliminate wrong answers

Option A is wrong because NuGetCommand@2 with the restore command only restores packages from sources; it does not cache them across pipeline runs. Option B is wrong because CopyFiles@2 is used to copy files from source to destination, not to manage caching of NuGet packages. Option C is wrong because PowerShell@2 can manually download and cache packages, but it requires custom scripting and lacks the built-in cache key, restore keys, and automatic hit/miss handling that Cache@2 provides, making it error-prone and less efficient.

Practice this question →
75
MCQmedium

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

A.Immutable deployment
B.Rolling deployment
C.Blue-green deployment
D.Canary deployment
AnswerB

Rolling deployment replaces instances incrementally across regions, keeping the previous version running in unaffected instances; if a region's batch fails health checks, Azure DevOps can stop that batch while other regions continue receiving updates, thereby tolerating regional failures and meeting the requirement to keep deploying.

Why this answer

Rolling deployment updates instances gradually across regions. If a deployment to one region fails, the pipeline can continue deploying to other regions because each region is updated independently. Option A (immutable deployment) replaces all instances at once, so a failure would halt the entire deployment.

Option C (blue-green) switches all traffic to a new environment; if that environment fails, the whole deployment fails. Option D (canary) routes a small percentage of traffic to a new version and rolls back if issues occur, but it does not ensure continued deployment to other regions upon failure.

Practice this question →
Page 1 of 5 · 348 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