Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 451–525

696 questions total · 10pages · All types, answers revealed

Take a mock examExam hub
Page 6

Page 7 of 10

Page 8
451
MCQmedium

Your Azure DevOps organization contains multiple teams. You need to ensure that code reviews require approval from a member of the security team before merging to the main branch. What is the best way to implement this?

A.Add a validation step in Azure Pipelines
B.Enable Microsoft Defender for Cloud
C.Deploy Microsoft Sentinel
D.Configure branch policies in Azure Repos
AnswerD

In Azure Repos, branch policies on the main branch can require a minimum number of reviewers and specific approvers for pull requests. Configuring such policies enforces that designated team members must approve changes before merging, directly satisfying the requirement.

Why this answer

Configuring branch policies in Azure Repos (option D) is the correct approach because branch policies allow you to require specific reviewers—such as members of the security team—for pull requests targeting the main branch. This ensures that every merge to main must be approved by the security team. Option A is incorrect: Azure Pipelines is designed for continuous integration and delivery (CI/CD), not for enforcing code review requirements.

Option B is incorrect: Microsoft Defender for Cloud focuses on cloud security posture management and threat protection, not on code review policies. Option C is incorrect: Microsoft Sentinel is a security information and event management (SIEM) tool for security analytics and threat intelligence, not for managing branch-level review policies.

Full explanation →
452
MCQmedium

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

A.The pipeline does not run because the PR trigger requires a pull request.
B.The pipeline runs once for the CI trigger.
C.The pipeline runs twice: once for the CI trigger and once for the PR trigger.
D.The pipeline runs once for the PR trigger only.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
453
MCQhard

Refer to the exhibit. An engineer tries to add a custom script extension to a VMSS but gets a ResourceNotFound error. What is the most likely cause?

A.The script URL is inaccessible due to network restrictions.
B.The CustomScript extension is not supported on this VMSS SKU.
C.The VMSS does not exist in the specified resource group.
D.The VMSS is in a different region than the resource group.
AnswerC

The ResourceNotFound error is produced by the Azure Resource Manager control plane when the referenced VMSS resource cannot be found in the specified subscription and resource group. When deploying an extension via the ARM route /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachineScaleSets/{vmssName}/extensions/{name}, ARM first resolves the parent VMSS resource by name and type. If the VMSS name is mistyped, the resource group is incorrect, or the VMSS has not been created, ARM immediately returns ResourceNotFound for the parent resource.

Full explanation →
454
MCQmedium

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

A.Use a stage template.
B.Define the steps as variables and reference them.
C.Create a YAML template and reference it from each stage.
D.Create a separate job and call it from each stage.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
455
MCQmedium

Your team uses a monorepo in Azure Repos with multiple feature branches. You notice that merge conflicts frequently occur because developers are working on the same files. You want to reduce conflicts and improve collaboration. Which branching strategy should you recommend?

A.Use release branches for each deployment and cherry-pick commits from main.
B.Use trunk-based development with feature flags to merge small, frequent changes.
C.Use a single main branch and require all changes to be committed directly.
D.Use GitFlow with separate develop and release branches.
AnswerB

Trunk-based development with feature flags enables developers to merge small, frequent changes directly into the trunk behind a flag, keeping branches short-lived and integration burden low, which minimizes merge conflicts and supports continuous integration and delivery.

Why this answer

Trunk-based development with feature flags is the correct approach because it encourages developers to merge small, frequent changes into the main branch, reducing the surface area for conflicts. Feature flags allow incomplete features to be hidden in production, enabling continuous integration without requiring long-lived feature branches. This strategy directly addresses the problem of frequent merge conflicts by minimizing divergence between branches.

Exam trap

The trap here is that candidates often choose GitFlow (Option D) because it is a well-known structured model, but they fail to recognize that its long-lived feature branches directly cause the merge conflicts described in the scenario.

How to eliminate wrong answers

Option A is wrong because using release branches with cherry-picking from main does not reduce merge conflicts; it introduces additional complexity and potential for missed commits, and it does not address the root cause of developers working on the same files simultaneously. Option C is wrong because requiring all changes to be committed directly to a single main branch without any branching strategy or feature flags would lead to even more conflicts and instability, as developers would be forced to coordinate manually without isolation. Option D is wrong because GitFlow with separate develop and release branches encourages long-lived feature branches, which exacerbates merge conflicts when multiple developers work on the same files; it is designed for scheduled releases, not for reducing conflict frequency.

Full explanation →
456
MCQmedium

You are configuring a release pipeline in Azure Pipelines that deploys a web app to Azure App Service. The pipeline uses a stage with a deployment job. You need to ensure that the deployment uses a specific deployment slot named 'staging' and then swaps it with the production slot after successful deployment. Which task should you use?

A.AzureRmWebAppDeployment@4 with the 'DeployToSlotOrASE' option enabled and the 'SlotName' set to 'staging'.
B.Use AzureRmWebAppDeployment@4 to deploy to the 'staging' slot, followed by AzureAppServiceManage@0 to swap the 'staging' slot with production.
C.AzureRmWebAppDeployment@4 with the 'SwapSlot' input set to 'staging'.
D.AzureAppServiceManage@0 with the 'Action' set to 'Swap Slots' and the 'SourceSlot' set to 'staging'.
AnswerB

This combination first deploys the app to the staging slot using AzureRmWebAppDeployment@4 with the SlotName set to 'staging'. Then, AzureAppServiceManage@0 with the Swap Slots action swaps the staging slot with the production slot. This meets the requirement of deploying to a specific slot and then swapping. It is a common pattern for zero-downtime deployments.

Why this answer

The correct approach is to use two tasks: first, deploy to the staging slot using AzureRmWebAppDeployment@4 with the slot name specified; second, use AzureAppServiceManage@0 to swap the staging slot with production. This ensures the new version is deployed to staging, tested if desired, and then swapped into production. The other options either miss the deployment step or the swap step.

Exam trap

The trap here is assuming that the deployment task can also perform a slot swap, when in fact a separate task is required.

Full explanation →
457
MCQhard

Your organization uses Azure Boards and requires that all changes to work items in the 'Security' area path be audited. Which solution ensures that any modification to a work item triggers an audit event in Microsoft Sentinel?

A.Configure Azure DevOps Audit Streaming to send logs to Microsoft Sentinel
B.Enable Microsoft Purview to scan Azure DevOps and detect changes
C.Export Azure DevOps audit logs to CSV and import to Sentinel daily
D.Create a service hook in Azure DevOps that calls a logic app to create incidents in Sentinel
AnswerA

This is the native Azure DevOps integration that continuously streams audit events (such as project, pipeline, and permission changes) to your Log Analytics workspace for Microsoft Sentinel. It provides real-time, automatic ingestion with no custom code, enabling immediate security monitoring and alerting, which directly satisfies the requirement.

Why this answer

Azure DevOps Audit Streaming is the correct solution because it natively streams audit events (including work item modifications) to Microsoft Sentinel via the Azure Event Hubs or Log Analytics workspace integration. This ensures real-time, continuous auditing without manual intervention, meeting the requirement for all changes in the 'Security' area path to trigger audit events in Sentinel.

Exam trap

The trap here is that candidates may confuse service hooks (which are event-driven but require custom logic) with native audit streaming, or assume that manual CSV exports are sufficient for real-time auditing, missing the requirement for automated, continuous audit event ingestion into Sentinel.

How to eliminate wrong answers

Option B is wrong because Microsoft Purview is a data governance and cataloging service, not an audit log streaming solution; it cannot detect or forward Azure DevOps work item modifications to Sentinel. Option C is wrong because exporting audit logs to CSV and importing them daily introduces latency and manual effort, failing to provide real-time or automated audit event triggering in Sentinel. Option D is wrong because service hooks in Azure DevOps can trigger external actions (e.g., Logic Apps) but do not directly stream audit events to Sentinel; they would require custom development and do not leverage the native audit log pipeline, making them less reliable and scalable than Audit Streaming.

Full explanation →
458
MCQhard

You have a multi-stage YAML pipeline that deploys to multiple environments. You want to enforce that a manual approval is required before deploying to the production environment, but not for other environments. How should you configure the pipeline?

A.Create an environment named 'Production', add an approval check, and reference the environment in the deployment job.
B.Set a pipeline-level approval check that applies to all stages.
C.Add an approval gate on the 'Production' stage in the pipeline settings.
D.Configure branch policy on the main branch to require approval for all changes.
AnswerA

In Azure Pipelines, manual approval checks are attached to environments, not to stages or the pipeline as a whole. By defining a 'Production' environment, adding an approval check to it, and referencing that environment in the deployment job's `environment:` keyword, you create a pre-deployment gate that prompts a designated approver before the job executes, yielding controlled, auditable production deployments.

Why this answer

Azure Pipelines allows you to add an approval check on a specific environment. By creating an environment named 'Production' and attaching an approval check to it, any deployment job that references that environment will require manual approval before proceeding. This ensures that only the production deployment is gated, while other environments deploy automatically.

Exam trap

The trap here is that candidates confuse environment-level approval checks with stage-level gates or pipeline-level settings, thinking they can add an approval directly on a stage in the pipeline settings UI, which is not supported.

How to eliminate wrong answers

Option B is wrong because a pipeline-level approval check applies to all stages in the pipeline, which would force manual approval for non-production environments as well, violating the requirement. Option C is wrong because there is no such thing as an 'approval gate on a stage' in Azure Pipelines; approvals are configured on environments or as pre-deployment gates, not directly on stages. Option D is wrong because branch policies control code changes to the repository, not deployment approvals; they cannot enforce manual approval for a specific deployment environment.

Full explanation →
459
MCQhard

Your organization is adopting GitHub Copilot for developers. Which security measure should you implement to ensure that no proprietary code is inadvertently shared with the AI model?

A.Use a separate network segment for development
B.Configure content exclusions in the GitHub Copilot settings
C.Disable GitHub Copilot for all users
D.Enable audit logging for Copilot usage
AnswerB

By configuring content exclusions, organizations can define specific repositories or files that Copilot will not access or use as context for generating suggestions, thereby preventing sensitive code from being transmitted to GitHub's AI service. This is a targeted control that directly mitigates data exfiltration risks while allowing developers to continue using Copilot for non-excluded code.

Why this answer

GitHub Copilot's content exclusions allow administrators to specify files or repositories that should not be sent to the AI model for code completion suggestions. This prevents proprietary or sensitive code from being transmitted to GitHub's servers, ensuring compliance with security policies. Other options like network segmentation or audit logging do not directly block code from being shared with the AI.

Exam trap

The trap here is that candidates often confuse security controls like network segmentation or audit logging with data loss prevention mechanisms, failing to recognize that content exclusions are the specific Copilot feature designed to prevent code from being sent to the AI model.

How to eliminate wrong answers

Option A is wrong because using a separate network segment for development does not prevent Copilot from sending code to the AI model; it only isolates network traffic, which does not address data exfiltration at the application layer. Option C is wrong because disabling Copilot for all users is an overreaction that eliminates productivity benefits without addressing the need for selective protection; content exclusions provide a targeted solution. Option D is wrong because enabling audit logging for Copilot usage only records events after they occur, it does not prevent proprietary code from being shared with the AI model in the first place.

Full explanation →
460
Multi-Selectmedium

Which TWO actions should you take to implement a gated deployment strategy in Azure Pipelines?

Select 2 answers
A.Use deployment gates to evaluate metrics like error rate before allowing the next stage.
B.Configure a dashboard to monitor application health.
C.Use a multi-stage YAML pipeline.
D.Configure a rollback strategy if deployment fails.
E.Add manual approval checks before deployment to production.
AnswersA, E

Deployment gates query external metrics such as error rate or incident counts before releasing a stage, automatically blocking promotion when thresholds are breached. This satisfies the gated deployment requirement by enforcing automated, metric-based verification rather than relying solely on human judgement.

Why this answer

Option A is correct because deployment gates in Azure Pipelines are precisely the mechanism that queries external sources—such as Azure Monitor alerts, REST APIs, or work items—to evaluate metrics like error rate and automatically decide whether the stage may proceed, which is the core of a gated deployment. Option E is correct because manual approval checks (approvals and checks configured on an environment or service connection) pause the pipeline before production deployment so a human can verify readiness, which is a standard gating control in a gated release strategy. Option B is not correct because a dashboard is a monitoring and visualization tool; it reports health but does not itself gate or block a pipeline stage.

Option C is not correct because a multi-stage YAML pipeline is just the structural definition of stages and does not by itself implement gating logic. Option D is not correct because a rollback strategy is a recovery measure after a failed deployment, not a gate that controls whether deployment proceeds.

Exam trap

The trap here is that candidates often confuse monitoring (dashboard) or pipeline structure (multi-stage YAML) with the actual gating mechanism, forgetting that gates require explicit evaluation of health metrics or approvals to block or allow the release.

Full explanation →
461
Multi-Selectmedium

Your team uses GitHub Discussions for Q&A. You notice that many questions go unanswered. Which two actions can improve response rates? (Choose two.)

Select 2 answers
A.Limit the number of discussion categories to one.
B.Automatically close discussions that are unanswered for 7 days.
C.Create a template for new discussions to guide users.
D.Assign a team of maintainers to monitor unanswered discussions.
E.Convert unanswered discussions to issues.
AnswersC, D

GitHub Discussions supports issue forms-style templates that enforce structured problem statements—such as expected behavior, reproduction steps, and screenshots—which reduces vague posts, surfaces necessary context upfront, and lets maintainers answer more efficiently, directly improving Q&A quality.

Why this answer

Option C is correct because creating a discussion template guides users to provide complete, structured information (such as version, environment, and steps to reproduce), which makes questions easier to understand and answer, thereby improving response rates. Option D is correct because assigning a team of maintainers to monitor unanswered discussions ensures there is clear ownership and accountability for responding, directly reducing the number of questions that go unanswered. Option A is not appropriate because limiting discussions to a single category reduces organization and makes it harder for the right experts to find relevant questions.

Option B is not appropriate because auto-closing unanswered discussions after 7 days would suppress legitimate questions rather than encourage answers. Option E is not appropriate because converting unanswered discussions to issues does not by itself increase response rates and may simply move the problem elsewhere.

Exam trap

The trap here is that candidates confuse 'closing' or 'converting' discussions with 'managing' them, but the correct approach is to improve the quality of the initial post (via templates) and ensure active monitoring (via assigned maintainers), not to remove or repurpose unanswered content.

Full explanation →
462
MCQmedium

You are designing a build pipeline for a Node.js application. The pipeline must run unit tests and publish code coverage results to Azure Pipelines. Which task should you use to ensure coverage results are available in the pipeline summary?

A.PublishTestResults@2
B.VSTest@2
C.CopyFiles@2
D.PublishCodeCoverageResults@1
AnswerD

PublishCodeCoverageResults@1 is the correct task because it directly consumes coverage report files in Cobertura or JaCoCo format and renders an interactive coverage summary in the Azure DevOps pipeline UI, including per-file and line-level percentages. It is language-agnostic, so it works for Node.js applications as long as the test runner (e.g., Jest with the Istanbul/Cobertura reporter) produces the required XML artifact. Unlike tasks that merely copy files or publish test outcomes, this task parses the coverage data and exposes it for direct visibility and monitoring within the pipeline.

Why this answer

The PublishCodeCoverageResults@1 task is specifically designed to publish code coverage results (e.g., Cobertura, JaCoCo, or .coverage formats) to Azure Pipelines, making them visible in the pipeline summary and the Tests tab. This task consumes coverage data files generated by a previous test run and integrates them into the pipeline's reporting UI.

Exam trap

The trap here is that candidates confuse PublishTestResults@2 (which publishes test outcomes) with PublishCodeCoverageResults@1 (which publishes coverage metrics), assuming a single task handles both, when in fact Azure Pipelines requires separate tasks for test results and code coverage.

How to eliminate wrong answers

Option A is wrong because PublishTestResults@2 publishes test pass/fail results (e.g., JUnit, NUnit, VSTest) to the Tests tab, not code coverage data; it does not make coverage percentages or file-level coverage available in the pipeline summary. Option B is wrong because VSTest@2 is a Visual Studio test runner task that executes tests and can optionally publish test results, but it does not natively publish code coverage results to the pipeline summary; coverage data would require a separate task. Option C is wrong because CopyFiles@2 is a file copy task used to copy files from source to destination (e.g., for artifact staging) and has no capability to parse or publish coverage results.

Full explanation →
463
MCQmedium

Your team uses Azure DevOps for CI/CD. You need to ensure that every build publishes telemetry to Application Insights, including build duration, test pass rate, and deployment frequency. Which approach should you use?

A.Call the Azure DevOps REST API from a custom script in the pipeline to capture telemetry.
B.Run the Azure DevOps CLI command 'az devops telemetry publish' in a build task.
C.Use the built-in 'Pipeline Telemetry' dashboard in Azure DevOps.
D.Use the Azure DevOps Analytics OData endpoint to query pipeline telemetry and send to Application Insights via a release task.
AnswerD

The Analytics Service exposes pipeline run, test, and work item data as OData entities, allowing you to run rich queries. You can then use a release pipeline task (e.g., a PowerShell script) to call the OData endpoint, transform the results, and send them to Application Insights using its TrackEvent or TrackMetric APIs for custom monitoring and alerting. This is the recommended integration path.

Why this answer

The Azure DevOps Analytics OData endpoint provides a standardized, queryable interface to pipeline telemetry data (build duration, test pass rate, deployment frequency). By using a release task to query this endpoint and forward the data to Application Insights, you can instrument your CI/CD pipeline to send custom telemetry without relying on manual scripting or unsupported commands. This approach aligns with the 'Implement an instrumentation strategy' domain by leveraging Azure DevOps Analytics and Application Insights integration.

Exam trap

The trap here is that candidates may assume Azure DevOps has a built-in 'telemetry publish' command or dashboard that directly sends data to Application Insights, but in reality, you must use the Analytics OData endpoint as an intermediary to extract and forward pipeline telemetry.

How to eliminate wrong answers

Option A is wrong because calling the Azure DevOps REST API from a custom script requires manual parsing of pipeline execution data and lacks a built-in mechanism to directly push telemetry to Application Insights, making it error-prone and less maintainable. Option B is wrong because the Azure DevOps CLI command 'az devops telemetry publish' does not exist; the CLI does not support a telemetry publish command for pipeline data. Option C is wrong because the built-in 'Pipeline Telemetry' dashboard in Azure DevOps only displays telemetry within Azure DevOps itself and does not export data to Application Insights for external monitoring or alerting.

Full explanation →
464
MCQeasy

You have a multi-stage YAML pipeline that builds and deploys a Node.js application. You want to ensure that the build stage runs only when changes are made to the 'src' folder. Which trigger configuration should you use?

A.Trigger with 'batch' set to true
B.Trigger with 'branches' filter
C.Trigger with 'paths' filter
D.Disable CI trigger and use a scheduled trigger
AnswerC

Using a 'paths' filter in the CI trigger allows you to specify include or exclude patterns for file paths, so the pipeline only triggers when changes under the target folder (e.g., /frontend) are detected. This is the exact mechanism to scope triggers to a specific folder or set of files, making it the correct solution.

Why this answer

Azure Pipelines supports path-based triggers that allow you to specify which file paths should trigger a pipeline run. By configuring a trigger with a 'paths' filter that includes only the 'src' folder, the build stage will only execute when changes are detected within that specific directory, ignoring changes elsewhere in the repository.

Exam trap

The trap here is that candidates often confuse path filters with branch filters or batch settings, mistakenly thinking that branch filters or batching can restrict triggers to specific folders, when in fact only path filters provide that capability.

How to eliminate wrong answers

Option A is wrong because setting 'batch' to true controls whether multiple pending CI builds are batched into a single run, not which paths trigger the pipeline. Option B is wrong because a 'branches' filter restricts triggers to specific branches (e.g., main or feature branches), not to specific folders or file paths. Option D is wrong because disabling the CI trigger and using a scheduled trigger would run the pipeline on a fixed schedule regardless of any code changes, which does not achieve the goal of triggering only on changes to the 'src' folder.

Full explanation →
465
MCQmedium

Your organization uses Azure Repos and has multiple Git repositories that share common code. You want to enable code reuse across these repositories without duplicating code. Which strategy should you use?

A.Use Git subtrees to merge the shared code into each repository
B.Publish the shared code as a NuGet package
C.Reference the shared repository as a Git submodule
D.Add the shared repository as an upstream source in Azure Artifacts
AnswerC

A Git submodule references a specific commit from the shared repository, allowing the parent repository to track that exact version without copying the code; this keeps a single canonical source, enables atomic checkout, and lets you update the shared code deliberately by moving the submodule pointer—making it the correct choice for sharing source across multiple Git repos.

Why this answer

Git submodules allow you to include a specific commit of a shared repository as a subdirectory within multiple parent repositories, enabling code reuse without duplication. When the shared code is updated, you can pull the latest commit into each parent repository, maintaining a clear link between the parent and the shared codebase. This is the native Git mechanism for referencing external repositories while preserving version control history.

Exam trap

The trap here is confusing package management (NuGet, Azure Artifacts) with source control strategies, leading candidates to choose options that distribute compiled artifacts rather than shared source code.

How to eliminate wrong answers

Option A is wrong because Git subtrees merge the entire history of the shared repository into the parent repository, duplicating the code and history, which defeats the goal of avoiding duplication. Option B is wrong because publishing shared code as a NuGet package is a binary distribution mechanism for .NET libraries, not a source control strategy for sharing live Git repository code across multiple repos. Option D is wrong because adding a shared repository as an upstream source in Azure Artifacts is used for package management (e.g., NuGet, npm), not for direct source code sharing via Git.

Full explanation →
466
Multi-Selecthard

Which THREE of the following are valid methods to securely store and use secrets in Azure DevOps pipelines?

Select 3 answers
A.Azure Key Vault task in the pipeline
B.Variable Group linked to Azure Key Vault
C.Azure App Configuration with Key Vault references
D.Storing secrets in a pipeline YAML file with encryption
E.Pipeline variables marked as 'secret'
AnswersA, B, E

The Azure Key Vault task fetches secrets from Azure Key Vault at pipeline runtime, dynamically injecting them as pipeline variables without exposing them in source control or build logs. It supports versioning and access policies, making it a secure, auditable method for handling credentials during execution.

Why this answer

The Azure Key Vault task in a pipeline allows you to fetch secrets directly from an Azure Key Vault instance during pipeline execution. This task retrieves secret values as pipeline variables, ensuring they are never exposed in logs or YAML files, and it supports both Azure Resource Manager and service principal authentication for secure access.

Exam trap

The trap here is that candidates may think Azure App Configuration with Key Vault references is a direct pipeline secret storage method, but it is designed for application configuration at runtime, not for pipeline variable management, and it requires additional configuration to resolve references during pipeline execution.

Full explanation →
467
MCQmedium

You have a release pipeline that deploys to multiple stages. You want to ensure that a manual approval is required before deploying to the production stage. Which approach should you use?

A.Add a pre-deployment approval on the production stage.
B.Add a post-deployment approval on the staging stage.
C.Configure a deployment gate with a manual intervention task.
D.Use a pipeline decorator to inject approval step.
AnswerA

A pre-deployment approval on the production stage is the correct approach because it prevents the pipeline from starting the production deployment until a designated user or group explicitly approves the release, providing a manual control point before any changes reach the live environment.

Why this answer

Pre-deployment approvals in Azure Pipelines allow you to require manual sign-off before a release proceeds to a specific stage. By adding a pre-deployment approval on the production stage, the pipeline will pause and wait for designated approvers to approve the deployment, ensuring that no code reaches production without explicit authorization.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which occur after a stage completes) with pre-deployment approvals (which occur before a stage starts), or they mistakenly think a manual intervention task inside a deployment gate can replace the native stage-level approval feature.

Why the other options are wrong

B

Post-deployment happens after deployment, not before.

C

Gates evaluate conditions, but manual approval is simpler and more direct.

D

Decorators are for injecting steps, not for approvals.

Full explanation →
468
MCQeasy

Your team uses Azure Repos Git and wants to enforce a policy that all pushes to the main branch must pass a build validation pipeline. The pipeline runs unit tests and code analysis. You need to configure this in the branch policy. Which setting should you enable?

A.Require comment resolution
B.Linked work items
C.Limit merge types
D.Build validation
AnswerD

Build validation automatically triggers a configured build pipeline on each push to a pull request and blocks completion until the build succeeds. It acts as a continuous integration gate that catches compilation errors, test failures, and other issues, thereby enforcing a successful build on every code change.

Why this answer

The Build validation policy in Azure Repos Git enforces that a specified pipeline must succeed before a pull request can be merged into the target branch. This directly meets the requirement to run unit tests and code analysis on all pushes to the main branch, blocking merges if the build fails.

Exam trap

The trap here is that candidates may confuse Build validation with other PR policies like Require comment resolution or Linked work items, mistakenly thinking those options also enforce automated checks, when in fact only Build validation triggers a pipeline execution.

How to eliminate wrong answers

Option A is wrong because Require comment resolution ensures all PR comments are resolved before merging, but it does not trigger or validate any build pipeline. Option B is wrong because Linked work items requires that a PR be associated with a work item, which enforces traceability but does not run any automated validation. Option C is wrong because Limit merge types restricts the merge strategies (e.g., squash, rebase) available for a PR, but it does not execute any build or test pipeline.

Full explanation →
469
Multi-Selectmedium

Your organization is adopting GitHub Advanced Security. Which THREE features should you enable to improve security?

Select 3 answers
A.GitHub Pages
B.Branch protection rules
C.Secret scanning
D.Dependabot alerts and security updates
E.Code scanning (CodeQL)
AnswersC, D, E

Secret scanning detects credentials.

Why this answer

Secret scanning (Option C) is a GitHub Advanced Security feature that automatically detects exposed secrets (e.g., API keys, tokens, private keys) in repositories by matching against known patterns and partner-defined signatures. It helps prevent credential leaks from reaching production or being exploited, directly improving the security posture of your codebase.

Exam trap

The trap here is that candidates may confuse standard GitHub features (like branch protection rules) with GitHub Advanced Security features, or assume that any security-related setting (e.g., GitHub Pages with HTTPS) qualifies as an Advanced Security improvement, when only secret scanning, Dependabot alerts/updates, and code scanning (CodeQL) are the three core Advanced Security capabilities tested on the AZ-400.

Full explanation →
470
MCQeasy

You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?

A.Use commit messages with work item IDs
B.Deploy a custom Git hook on the server
C.Configure a branch policy to require linked work items
D.Use the 'Require status checks' policy
AnswerC

Configuring a branch policy to require linked work items is the native, server-enforced solution: when a pull request is created, the policy checks that at least one work item is linked, and the merge is blocked until that requirement is satisfied. This directly ensures every commit merged into the branch is traceable to a work item, and it is the only option that is both enforced and work-item-specific.

Why this answer

Azure Repos branch policies include a setting to 'Require linked work items', which enforces that every pull request (and by extension, every commit merged through that PR) is associated with a work item in Azure Boards. This policy is enforced server-side at merge time, ensuring no commit can be merged without a linked work item, regardless of how the commit message is formatted.

Exam trap

The trap here is that candidates confuse a voluntary convention (commit message IDs) with an enforced policy, or they incorrectly assume that custom Git hooks are available in Azure Repos as they are in self-hosted Git servers.

How to eliminate wrong answers

Option A is wrong because commit messages with work item IDs are a convention, not an enforcement mechanism; they can be omitted or faked, and Azure Repos does not natively validate commit message content to block commits. Option B is wrong because custom Git hooks on the server are not supported in Azure Repos (which uses a managed Git service); hooks would need to be implemented via Azure DevOps service hooks or policies, not arbitrary server-side scripts. Option D is wrong because 'Require status checks' policy validates external CI/CD pipeline results (e.g., build validation), not work item association; it does not inspect commit-to-work-item links.

Full explanation →
471
Multi-Selecthard

Your team uses Azure Pipelines to build a Java application. The build must produce a JAR file and publish it as a pipeline artifact. Which THREE steps should be included in the build pipeline?

Select 3 answers
A.Use a Maven or Gradle task to compile and package the application.
B.Use the DotNetCoreCLI task to build the application.
C.Use the Publish Build Artifacts task to upload the staging directory.
D.Use the Copy Files task to copy the JAR to $(Build.ArtifactStagingDirectory).
E.Use the NuGetCommand task to pack the JAR.
AnswersA, C, D

The Maven/Gradle task is the correct Java build step: it invokes the project's build tool (e.g., `mvn clean package` or `gradle build`), compiles the Java sources, runs tests, and packages the output into a deployable JAR (or WAR). Without this task, no Java artifact exists to publish.

Why this answer

A Maven or Gradle task is the standard way to compile and package a Java application into a JAR file. These tasks invoke the build tool's lifecycle (e.g., `mvn package` or `gradle build`) to produce the artifact, which is a prerequisite for publishing.

Exam trap

The trap here is that candidates may confuse the DotNetCoreCLI or NuGetCommand tasks with Java tooling, or assume any packaging task works for any language, but Azure Pipelines tasks are language-specific and must match the build toolchain.

Full explanation →
472
MCQhard

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). Each microservice has its own pipeline that builds a Docker image and deploys it to a shared AKS cluster. The deployment must support rolling updates with zero downtime. You need to ensure that if a deployment fails (e.g., health check fails), the pipeline automatically rolls back to the previous version. Which deployment strategy should you implement in the pipeline?

A.Use a canary deployment strategy with a pipeline task that gradually shifts traffic to the new version and monitors error rates. If errors exceed a threshold, the task stops the canary.
B.Use a rolling update strategy with the 'kubectl apply' command, and include a post-deployment step that checks the rollout status. If the rollout fails, run 'kubectl rollout undo' to roll back.
C.Use the 'KubernetesManifest' task with the 'rollout status' option, which automatically rolls back if the rollout status indicates failure.
D.Use a blue-green deployment strategy with two separate AKS clusters. Deploy the new version to the green cluster, run health checks, and then update the load balancer to point to green. If health checks fail, keep pointing to blue.
AnswerB

The default Kubernetes rolling update strategy, triggered by `kubectl apply`, replaces pods incrementally and waits for readiness probes before continuing, which minimizes downtime. Adding a post-deployment step that checks `kubectl rollout status` allows the pipeline to detect a stuck or failed rollout (e.g., crashlooping pods or failed readiness checks). If that status check returns a failure, running `kubectl rollout undo` reverts the Deployment to its previous ReplicaSet, restoring the last known-good configuration without custom scripting.

Why this answer

It directly implements the required behavior: using `kubectl apply` for a rolling update (which inherently supports zero-downtime by gradually replacing pods), followed by a post-deployment step that checks the rollout status. If the rollout fails (e.g., due to health check failures), the pipeline runs `kubectl rollout undo` to automatically revert to the previous version, ensuring rollback on failure.

Exam trap

The trap here is that candidates confuse 'monitoring and reporting failure' (Option C) with 'automatically executing a rollback'—the KubernetesManifest task's rollout status option only checks and reports, it does not perform the undo action; you must explicitly add a separate rollback step.

How to eliminate wrong answers

Option A is wrong because a canary deployment shifts traffic gradually and monitors error rates, but it does not inherently perform a rollback of the Kubernetes Deployment object; it typically requires additional manual or custom logic to revert the Deployment revision. Option C is wrong because the 'KubernetesManifest' task with 'rollout status' only monitors the rollout and reports failure—it does not automatically execute a rollback; you must explicitly add a rollback step. Option D is wrong because blue-green with two separate AKS clusters is overcomplicated and not a single-pipeline rolling update; it also does not automatically roll back the Deployment—it only switches traffic back, leaving the failed Deployment still active.

Full explanation →
473
MCQmedium

A company uses Azure DevOps for CI/CD. The security team requires that all pipeline runs must use a specific service connection (ServiceConnection-Prod) that has been approved for production deployments. However, developers are accidentally using unapproved connections. You need to enforce that only the approved service connection can be used in any pipeline that deploys to the production environment. What should you do?

A.Define a required template for all pipelines that includes the service connection, and instruct developers to use it.
B.Set up a manual approval gate on the production environment stage in the pipeline.
C.Configure a branch policy on the main branch to require a successful build before merging.
D.Create an Azure Pipeline decorator that validates the service connection used in each task and fails the pipeline if it is not the approved one.
AnswerD

A pipeline decorator is an extension-based mechanism that injects a custom task into every pipeline run at the specified point (pre-job, post-job, or around a task). By defining a post-task decorator, you can read the inputs of each executed task—such as the `connectedServiceName` or `azureSubscription` input—and compare the referenced service connection to the organization's approved list. If the connection is not approved, the decorator can set the task result to `Failed` and stop the pipeline, providing a hard enforcement that ordinary YAML conventions cannot achieve. This works for any pipeline that uses the task, regardless of whether the author referenced a shared template.

Why this answer

Azure Pipeline decorators inject custom validation logic at runtime, allowing you to inspect each task's service connection and fail the pipeline if it does not match the approved one. This enforces the security requirement centrally without relying on developer compliance or manual gates.

Exam trap

The trap here is that candidates confuse process-based controls (templates, approvals, branch policies) with runtime enforcement, overlooking that only a decorator can programmatically validate and block unauthorized service connections at execution time.

How to eliminate wrong answers

Option A is wrong because a required template is a guideline that developers can bypass or modify, not an enforceable control. Option B is wrong because a manual approval gate only pauses the pipeline for human approval; it does not validate which service connection was used in the tasks. Option C is wrong because a branch policy on the main branch ensures code quality before merging but does not inspect or restrict the service connection used during pipeline execution.

Full explanation →
474
MCQeasy

Your team uses Azure Boards with a Kanban board. You want to limit the number of work items in the 'In Progress' column to prevent bottlenecks. What should you configure?

A.Column limits on the Kanban board
B.Branch policies
C.Backlog level settings
D.Work item rules
AnswerA

Column limits on the Kanban board cap the number of work items allowed in each column at a time, enforcing WIP limits and exposing bottlenecks so the team can swarm and balance flow. This is the correct mechanism for preventing overloading a stage in the process.

Why this answer

Column limits on the Kanban board directly enforce work-in-progress (WIP) constraints by capping the number of work items allowed in a specific column, such as 'In Progress'. This prevents bottlenecks by signaling the team to complete existing work before pulling new items, aligning with Lean and Kanban principles. Azure Boards supports this configuration through the board settings, where you can set a maximum limit per column.

Exam trap

The trap here is confusing process configuration (column limits) with code governance (branch policies) or automation (work item rules), leading candidates to select options that manage code or workflows rather than direct board constraints.

How to eliminate wrong answers

Option B is wrong because branch policies are used to enforce code quality and review requirements on pull requests in Azure Repos, not to limit work items on a Kanban board. Option C is wrong because backlog level settings define the hierarchy of work item types (e.g., Epics, Features, User Stories) and their visibility, but do not control column-level WIP limits. Option D is wrong because work item rules automate field updates or state transitions based on conditions (e.g., when a field changes), but they cannot enforce a numeric cap on items in a column.

Full explanation →
475
MCQmedium

Your company uses Azure DevOps and must enforce that all pipelines use approved agent pools. The security team wants to prevent the use of the default agent pool. What should you do?

A.Use pipeline settings to require authorization for the default pool
B.Set agent pool permissions to deny the default pool for all projects
C.Remove the default agent pool from the organization
D.Disable the default agent pool in project settings
AnswerB

Setting agent pool permissions to deny the 'Use' permission for the default pool across all projects explicitly prevents any pipeline in those projects from queuing jobs on that pool, making it the correct way to enforce the restriction.

Why this answer

Setting agent pool permissions to deny the default pool for all projects explicitly blocks its use across the organization. This enforces the security policy by preventing any pipeline from selecting the default agent pool, while still allowing administrators to manage the pool if needed. In Azure DevOps, agent pool permissions control which users, teams, or projects can use a pool, and setting 'Deny' overrides any inherited 'Allow' permissions.

Exam trap

The trap here is that candidates often confuse 'requiring authorization' (which still allows use after approval) with 'denying permissions' (which blocks use entirely), or they mistakenly think the default agent pool can be removed or disabled like a custom pool.

How to eliminate wrong answers

Option A is wrong because requiring authorization for the default pool only adds an approval step before pipelines can use it, but does not prevent its use entirely—pipelines could still be approved to run on the default pool, violating the security policy. Option C is wrong because removing the default agent pool from the organization is not possible; Azure DevOps requires at least one agent pool, and the default pool is a system pool that cannot be deleted. Option D is wrong because disabling the default pool in project settings is not a valid action; Azure DevOps does not provide a 'disable' toggle for agent pools at the project level—you can only manage permissions or remove agents from the pool.

Full explanation →
476
Multi-Selecteasy

Which TWO actions should you take to proactively protect your repository from accidentally committing secrets? (Choose two.)

Select 2 answers
A.Enable branch protection rules
B.Use pre-commit hooks with tools like detect-secrets
C.Enable push protection in secret scanning
D.Use signed commits
E.Configure secret scanning alerts
AnswersB, C

Pre-commit hooks run locally before a commit is finalized, allowing tools like detect-secrets to scan staged files and reject the commit if a potential secret is found. This shifts security left, stopping credentials from ever entering the Git history, which is a proactive measure because it prevents secret exposure before the commit is created.

Why this answer

Pre-commit hooks, such as those using the detect-secrets tool, scan staged changes before a commit is finalized. This prevents secrets from ever entering the repository history, providing a proactive, client-side guard. Option C is correct because push protection in secret scanning blocks pushes that contain known secret patterns at the server side, preventing the secret from being stored in the remote repository.

Exam trap

The trap here is confusing reactive security measures (like alerts or branch policies) with proactive, blocking controls (like pre-commit hooks and push protection) that prevent secrets from being stored in the first place.

Full explanation →
477
Multi-Selecteasy

Which TWO actions are recommended practices for improving communication within a DevOps team?

Select 2 answers
A.Create a shared team charter with communication norms.
B.Hold daily stand-up meetings.
C.Use separate documentation repositories for each team.
D.Send monthly status reports via email.
E.Remove team chat channels to reduce noise.
AnswersA, B

A shared team charter defines agreed-upon communication channels, response-time expectations, and escalation paths, reducing ambiguity and ensuring consistent, effective collaboration across the DevOps team. It establishes the shared norms needed for smooth information flow and alignment.

Why this answer

A shared team charter with communication norms establishes explicit expectations for how the team interacts, reducing ambiguity and fostering a culture of transparency and accountability. Daily stand-up meetings promote regular, synchronous communication, enabling quick updates, identification of blockers, and alignment on priorities. Both practices align with DevOps principles of collaboration and shared ownership.

In contrast, separate documentation repositories, monthly email reports, and removing chat channels hinder real-time collaboration and transparency.

Exam trap

The trap here is that candidates may dismiss daily stand-ups as 'agile-only' or think monthly reports are sufficient, but the AZ-400 exam emphasizes that DevOps teams need frequent, synchronous communication (like stand-ups) and a shared charter to align on norms, not just asynchronous reports or channel removal.

Full explanation →
478
MCQmedium

Your Azure DevOps pipeline deploys a web app to Azure App Service using a YAML pipeline. The deployment fails intermittently with the error 'Conflict' when updating deployment slots. What is the most likely cause?

A.Another deployment or swap operation is already in progress on the slot.
B.The service connection is using expired credentials.
C.The slot name is misspelled in the pipeline configuration.
D.The web app is locked by a file handle from a previous deployment.
AnswerA

Azure App Service serializes deployment and swap operations per slot, returning an HTTP 409 Conflict when a second operation is attempted concurrently. This error indicates that a previous deployment or swap has not yet completed, so you must wait for it to finish or cancel it before retrying.

Why this answer

The 'Conflict' error during an Azure App Service deployment slot update indicates that the slot is currently locked by another operation, such as an ongoing deployment or a swap. Azure App Service enforces mutual exclusion on slot operations to prevent race conditions, so if a previous deployment or swap has not completed, the new request is rejected with HTTP 409 Conflict.

Exam trap

The trap here is that candidates may confuse a 'Conflict' error with authentication or configuration issues, but Azure specifically returns HTTP 409 only when a resource-level lock prevents the operation, not for credential or naming problems.

How to eliminate wrong answers

Option B is wrong because expired credentials would cause an authentication failure (e.g., HTTP 401 Unauthorized or 403 Forbidden), not a Conflict error. Option C is wrong because a misspelled slot name would result in a 'ResourceNotFound' or HTTP 404 error, as the slot does not exist. Option D is wrong because file handle locks from a previous deployment are an on-premises IIS concept; Azure App Service isolates deployments via slot infrastructure and does not expose file handles that cause HTTP Conflict errors.

Full explanation →
479
MCQeasy

Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?

A.on: workflow_run: workflows: ["Build"] types: [completed]
B.on: issue_comment: types: [created]
C.on: pull_request: types: [labeled] branches: [main]
D.on: pull_request_target: types: [opened, synchronize] branches: [main]
AnswerC

This is correct because the `pull_request` event supports the `labeled` activity type, and the `branches: [main]` filter scopes it to pull requests targeting the main branch. When a label is added to such a PR, this workflow triggers exactly as intended; note it uses the workflow file from the base branch context for security.

Why this answer

The `pull_request` trigger with `types: [labeled]` is the correct event to detect label additions. However, it triggers for any label, not just 'safe-to-deploy'. To ensure the workflow runs only when that exact label is applied, you must combine this trigger with a job-level conditional, e.g., `if: github.event.label.name == 'safe-to-deploy'`.

The answer option C is still the correct trigger, but the explanation must clarify this additional required condition.

Exam trap

The trap here is that candidates may confuse `pull_request` with `pull_request_target` or think that `issue_comment` can detect label changes, but only the `labeled` activity type on `pull_request` directly responds to label additions.

How to eliminate wrong answers

Option A is wrong because `workflow_run` triggers on the completion of another workflow, not on pull request labeling; it would run after a 'Build' workflow finishes, regardless of labels. Option B is wrong because `issue_comment` triggers on comments in issues or pull requests, not on label additions; it would fire when a comment is created, not when a label is applied. Option D is wrong because `pull_request_target` with `types: [opened, synchronize]` triggers on PR creation or new commits, not on labeling; it also runs with a different security context (base repo secrets) and does not respond to label events.

Full explanation →
480
MCQmedium

A company's Azure DevOps project uses a custom agent pool with self-hosted agents. The security team discovers that pipeline runs can access secrets stored in Azure Key Vault, but the team wants to ensure that secrets are only accessible to approved pipelines. Which configuration should the team implement?

A.Use a library variable group linked to Key Vault and configure pipeline permissions with branch control.
B.Store secrets directly in pipeline variables and use 'Make secrets available to all pipelines' setting.
C.Assign pipeline-level permissions to the Key Vault using Azure RBAC.
D.Limit the number of agents in the custom agent pool.
AnswerA

A library variable group linked to Azure Key Vault centralizes secret storage, and configuring pipeline permissions with branch controls and approval checks ensures only approved pipelines on specific branches can retrieve those secrets. This provides granular, auditable, and policy-driven secret governance, making it the correct security approach.

Why this answer

The correct configuration is to create a library variable group linked to Azure Key Vault and then use pipeline permissions to grant access only to approved pipelines. This restricts secret access at the pipeline level. Branch-specific restrictions are not available on variable groups; to limit access by branch, the pipeline YAML must conditionally include the variable group (e.g., using an `if` expression based on the source branch) or separate pipelines must be used.

Exam trap

The real trap is confusing Azure RBAC on the Key Vault with Azure DevOps pipeline permissions. RBAC controls access to the key vault itself, while pipeline permissions control which pipelines can read the variable group. Note that variable groups do not support approval checks or branch filters; those are features of other protected resources.

How to eliminate wrong answers

Option B is wrong because storing secrets directly in pipeline variables and enabling 'Make secrets available to all pipelines' would expose secrets to every pipeline in the project, violating the requirement to restrict access to approved pipelines only. Option C is wrong because assigning pipeline-level permissions to Key Vault using Azure RBAC is not a supported configuration; Key Vault access is managed via access policies or RBAC at the vault level for service principals or managed identities, not at the pipeline level. Option D is wrong because limiting the number of agents in the custom agent pool does not control which pipelines can access secrets; it only affects concurrency and resource availability, not secret authorization.

Full explanation →
481
MCQmedium

A company uses Azure DevOps for CI/CD. They have multiple pipelines that deploy to different environments. They want to ensure that secrets like API keys are not exposed in pipeline logs. What is the best approach?

A.Use Azure App Configuration with Key Vault references
B.Create a Variable Group linked to Azure Key Vault
C.Use Azure Kubernetes Service secrets
D.Use pipeline variables marked as 'secret'
AnswerB

Creating a Variable Group linked to Azure Key Vault is the recommended approach because the Variable Group stores only references to secret names in Key Vault, not the secret values themselves. At pipeline runtime, Azure Pipelines fetches the actual secret values from Key Vault using a service connection, ensuring secrets never reside in pipeline definitions, logs, or the Azure DevOps database. This also provides centralized access control via Key Vault permissions, supports secret rotation, and integrates natively with pipeline consumers.

Why this answer

Variable Groups linked to Azure Key Vault allow you to securely store secrets in Key Vault and reference them in pipelines without exposing the actual values in logs or output. Option A is incorrect: Azure App Configuration with Key Vault references is designed for application configuration, not for managing pipeline secrets directly. Option C is incorrect: Azure Kubernetes Service (AKS) secrets are specific to Kubernetes workloads and not intended for general pipeline secret management.

Option D is incorrect: Pipeline variables marked as 'secret' are masked in logs, but they are still stored in Azure DevOps and lack the centralized security and auditing capabilities of Key Vault.

Full explanation →
482
MCQmedium

Your team uses GitHub Flow and wants to enforce that all pull requests require at least one approval before merging to the main branch. Which branch protection rule should you configure?

A.Require status checks to pass before merging
B.Restrict who can push to matching branches
C.Require a pull request before merging with at least 1 approval
D.Require linear history
AnswerC

This branch protection policy forces all changes to go through a pull request and, when 'Require approvals' is set to 1, prevents merging until at least one eligible reviewer has explicitly approved. It directly creates the desired human review gate before any code is integrated.

Why this answer

GitHub branch protection's 'Require a pull request before merging' setting, with 'Require approvals' set to at least 1, enforces that changes to main go through a PR with a reviewer sign-off. This directly matches the requirement for at least one approval before merge. Status checks, push restrictions, and linear history address different concerns and do not enforce human approval.

Exam trap

The trap is confusing 'require status checks' (automated CI gate) with 'require pull request approvals' (human review gate) — the question asks specifically for approval, so only the PR-with-approval rule satisfies it.

How to eliminate wrong answers

Option A is wrong because requiring status checks enforces CI passing, not human approval — it does not guarantee a reviewer signs off. Option B is wrong because restricting who can push limits who can write to the branch but does not require a pull request or approval. Option D is wrong because requiring linear history only enforces a merge strategy (no merge commits), not review approval.

Full explanation →
483
MCQeasy

A team uses Azure Pipelines to build a .NET Core application. The build pipeline runs successfully, but the release pipeline fails when deploying to Azure App Service with the error: 'ERROR_FILE_IN_USE'. What is the most likely cause?

A.The deployment slot is not configured correctly.
B.The 'Take App Offline' setting is not enabled in the deployment task.
C.The Azure App Service plan is not scaled appropriately.
D.The build configuration is set to Release instead of Debug.
AnswerB

The 'Take App Offline' setting instructs the Web App to place an app_offline.htm file in the site root, which gracefully shuts down the app and releases any locks on its assemblies and files. Without this, the running process holds the DLLs, causing 'file in use' errors when the pipeline tries to overwrite them.

Why this answer

The 'ERROR_FILE_IN_USE' error occurs when the deployment process tries to overwrite files that are currently locked by the running application. Enabling the 'Take App Offline' setting in the Azure App Service deploy task places an app_offline.htm file in the wwwroot directory, which gracefully shuts down the application and releases all file locks before the new binaries are copied. Without this setting, the running process holds locks on the DLLs, causing the deployment to fail.

Exam trap

The trap here is that candidates often confuse 'ERROR_FILE_IN_USE' with a slot configuration or scaling issue, but the root cause is always the running process holding file locks, which is directly resolved by the 'Take App Offline' setting in the deployment task.

How to eliminate wrong answers

Option A is wrong because an incorrectly configured deployment slot would cause routing or swapping issues, not a file-lock error during deployment. Option C is wrong because scaling the App Service plan affects performance and resource allocation, not the ability to overwrite locked files. Option D is wrong because the build configuration (Release vs.

Debug) affects optimization and debugging symbols, not file-locking behavior during deployment.

Full explanation →
484
MCQmedium

You are designing a release pipeline that must deploy to multiple environments in sequence: Dev, Test, and Prod. Each environment requires manual approval before deployment. You want to minimize the number of approvals while ensuring that Prod is never deployed without approval. What should you do?

A.Use a single approval for all environments by adding an approval to the pipeline.
B.Add a pre-deployment approval only to the Prod environment.
C.Add a post-deployment approval to the Test environment.
D.Add a pre-deployment approval to each environment.
AnswerB

Adding a pre-deployment approval only to Prod ensures that Prod deployments require manual approval, while Dev and Test can deploy automatically. This minimizes the number of approvals to just one per release, satisfying the requirement that Prod is never deployed without approval. It balances control and efficiency.

Why this answer

Configuring a pre-deployment approval only on the Prod environment ensures that Prod deployments are gated by manual approval, while Dev and Test deploy automatically. This reduces the total number of approvals to one per release, meeting the requirement to minimize approvals and protect Prod. It is the most efficient approach for sequential environments.

Exam trap

The trap here is thinking that approvals must be applied to every environment to be safe, which unnecessarily increases manual steps.

Full explanation →
485
Multi-Selectmedium

Which two of the following are valid strategies to implement conditional deployment in a YAML pipeline? (Choose 2)

Select 2 answers
A.Use the 'condition' property on a stage
B.Use template expressions with parameters
C.Configure stage filters in the triggers section
D.Use dependency conditions like 'succeededOrFailed'
E.Add a PowerShell script to check environment
AnswersA, B

The 'condition' property on a stage in Azure Pipelines evaluates expressions at runtime, such as `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, and is the native, declarative way to control whether a stage executes during a pipeline run, making it ideal for conditional deployment strategies.

Why this answer

Both 'condition' property and template expressions with parameters are valid strategies for conditional deployment in YAML pipelines. The 'condition' property (e.g., `eq(variables['Build.SourceBranch'], 'refs/heads/main')`) controls at runtime whether a stage, job, or step runs, based on variables or expressions. Template expressions with parameters (e.g., `${{ if eq(parameters['environment'], 'prod') }}`) allow you to conditionally include or exclude parts of the pipeline at compile time, making them a powerful tool for conditional deployment based on parameters.

Exam trap

The trap here is that candidates confuse dependency conditions (like `succeededOrFailed`) with custom conditional logic, not realizing that dependency conditions are predefined and not a general-purpose strategy for implementing conditional deployment based on arbitrary criteria like branch names or variables.

Why the other options are wrong

C

Stage filters are for triggers, not conditions within a pipeline.

D

Dependency conditions are built-in for run order, not for custom conditional logic.

E

While possible, it's not a pipeline-native strategy; the question asks for valid strategies in YAML.

Full explanation →
486
MCQhard

Refer to the exhibit. A release pipeline deploys this ARM template. The deployment fails with error: 'The template parameters 'adminPassword' is not a valid input.' What is the most likely cause?

A.The VM size is not available in the specified location.
B.The parameter 'adminPassword' is not defined in the parameters section of the template.
C.The resource group location is invalid.
D.The parameter 'adminPassword' is misspelled in the template.
AnswerB

In Azure Resource Manager (ARM) templates, any parameter referenced within the resources section must first be declared in the parameters section of the template. This template's osProfile block references an 'adminPassword' value, but no corresponding parameter definition exists, so the ARM template validation engine rejects the template with a 'parameter not defined' error before any deployment attempt. The remedy is to add a declaration such as "adminPassword": { "type": "securestring" } to the parameters section, ensuring the reference resolves correctly.

Why this answer

The error 'The template parameters 'adminPassword' is not a valid input' occurs when the ARM template does not declare a parameter named 'adminPassword' in its parameters section. Even if the parameter is referenced elsewhere, it must be explicitly defined in the parameters block to be accepted. Therefore, the most likely cause is that the parameter is missing from the template's parameters definition.

Exam trap

AZ-400 often tests the distinction between parameter declaration and usage, so candidates may overlook that a parameter must be explicitly defined in the parameters section even if it is referenced in the resources section.

How to eliminate wrong answers

Option A is wrong because VM size availability would produce a different error, such as 'The requested VM size is not available in the location'. Option C is wrong because an invalid resource group location would cause an error about the location not being valid, not about a parameter. Option D is wrong because a misspelling would typically result in an error about an undefined parameter or variable, but the error specifically states the parameter is not a valid input, which indicates it is not defined at all.

Full explanation →
487
MCQeasy

Your team manages a large monorepo in Azure Repos containing multiple projects. Developers frequently complain that cloning the entire repository takes too long and that they only need a subset of the code. The team uses Git LFS for large binary files. The repository currently has 50,000 commits and is 5 GB in size. You want to improve clone performance without sacrificing the ability to contribute to any part of the repo. What should you do?

A.Configure sparse checkout so developers can clone only the directories they need.
B.Instruct developers to use a shallow clone with depth 1 to reduce clone time.
C.Move all large binary files to Git LFS to reduce repository size.
D.Split the monorepo into multiple repositories and use submodules to aggregate them.
AnswerB

A shallow clone with `depth 1` retrieves only the latest commit from each branch, omitting the entire commit history and all historical tree and blob objects that are not reachable from that tip. This can shrink the clone payload from many gigabytes to just the snapshot of the latest revision, dramatically cutting clone time. Developers who need older history can later run `git fetch --unshallow` or `git fetch --depth=N` to incrementally download additional commits, and the clone remains a normal repository capable of receiving changes to any part of the monorepo.

Why this answer

Using a shallow clone with depth 1 significantly reduces clone time by fetching only the latest commit history instead of all 50,000 commits. This minimizes the data transferred over the network, which is the primary cause of slow clones. Developers can later deepen the clone if they need more history.

Sparse checkout alone does not reduce the data transferred during clone; it only limits what appears in the working directory. Git LFS is already being used for large binaries, so that is not the issue. Splitting the monorepo would require significant restructuring and may complicate cross-project contributions.

Exam trap

The trap is that candidates may think sparse checkout alone speeds up cloning, but it only affects the working directory after all objects are downloaded. Shallow clone directly reduces the amount of history and data transferred, which is the key factor in clone time.

How to eliminate wrong answers

Option B is wrong because a shallow clone with depth 1 reduces the commit history but still downloads the full working tree for all projects, which is 5 GB; it does not solve the problem of needing only a subset of code. Option C is wrong because the team already uses Git LFS for large binary files, so moving files to LFS again would not further reduce repository size or improve clone performance. Option D is wrong because splitting the monorepo into multiple repositories with submodules introduces significant overhead in managing cross-repo dependencies, breaks the monorepo workflow, and does not guarantee faster clones for developers who still need multiple submodules.

Full explanation →
488
Multi-Selectmedium

Which TWO actions should you take to ensure that only approved pipelines can deploy to production in Azure DevOps? (Choose two.)

Select 2 answers
A.Disable parallel jobs for the project.
B.Configure a pipeline approval gate on the production environment.
C.Set branch policies to require a pull request before merging to the main branch.
D.Limit the number of pipelines that can deploy from the main branch.
E.Use a single agent pool for all pipelines.
AnswersB, C

Configuring an approval gate on the production environment adds a pre-deployment check that requires designated approvers to manually review and approve the deployment before it proceeds. This directly satisfies the need for an explicit approval process, and in Azure Pipelines it can be set as an environment check.

Why this answer

Configuring a pipeline approval gate on the production environment ensures that every deployment to production requires explicit approval from designated reviewers, preventing unauthorized or unapproved pipelines from deploying. Option C is correct because setting branch policies to require a pull request before merging to the main branch enforces code review and validation, ensuring that only approved changes reach the main branch, which is typically the source for production deployments.

Exam trap

The trap here is that candidates often confuse branch policies (which control code merging) with deployment controls (which control release execution), leading them to incorrectly select options like limiting pipeline counts or disabling parallel jobs instead of recognizing that approval gates and branch policies are the two distinct mechanisms for securing production deployments.

Full explanation →
489
Multi-Selectmedium

Your team uses Azure DevOps and wants to enforce that all work items must be linked to a pull request before merging. Additionally, the pull request must be approved by at least two reviewers. Which two branch policies should you enable?

Select 2 answers
A.Automatically update work items
B.Require a minimum number of reviewers
C.Check for linked work items
D.Build validation
E.Comment resolution
AnswersB, C

Require a minimum number of reviewers enforces the approval threshold by blocking completion until the specified count of approvers signs off, satisfying the two-reviewer constraint. Configure it on the target branch's policy settings, setting the minimum to two. It does not address work item linking, so the separate "Check for linked work items" policy is also needed.

Why this answer

Option B (Require a minimum number of reviewers) is correct because this branch policy lets you set the required reviewer count, so configuring it to two enforces that a pull request must be approved by at least two reviewers before it can complete. Option C (Check for linked work items) is correct because this policy blocks pull request completion unless at least one work item is linked, directly enforcing that all work items be associated with a pull request before merging. Option A (Automatically update work items) only changes the state of linked work items after a merge and does not require any link to exist, so it does not enforce the linking requirement.

Option D (Build validation) triggers a build pipeline to validate the merge but has nothing to do with reviewer counts or work item links. Option E (Comment resolution) only requires that active pull request comments be resolved and does not enforce reviewer approvals or work item linkage.

Exam trap

The trap here is that candidates often confuse 'Automatically update work items' with 'Check for linked work items,' but the former only updates status after merge, while the latter enforces the link before merge.

Full explanation →
490
Multi-Selectmedium

You are designing a process for your Azure DevOps project to improve traceability between work items and code changes. You need to ensure that developers can easily navigate from a work item to related commits and pull requests. Which two actions should you perform? (Choose two.)

Select 2 answers
A.Enable the 'Link work items to commits' setting in the repository options.
B.Configure branch policies to require linked work items on pull requests.
C.Use the Azure DevOps CLI to manually link work items to commits after each push.
D.Create a custom work item query that lists all commits without linked work items.
E.Instruct developers to include work item IDs in commit messages using the #ID syntax.
AnswersB, E

Enforcing linked work items on pull requests via branch policies ensures that every pull request has at least one work item linked. This creates a link between the pull request and the work item, allowing easy navigation from the work item to the pull request. It improves traceability by making the association mandatory.

Why this answer

Including work item IDs in commit messages using #ID automatically links commits to work items. Enforcing linked work items on pull requests via branch policies ensures that pull requests are also linked. Together, these actions provide bidirectional traceability, allowing navigation from work items to commits and pull requests.

The other options are either non-existent, manual, or misapply features.

Exam trap

The trap here is assuming that a repository setting exists to automatically link work items to commits, when the linking actually depends on commit message syntax.

Full explanation →
491
MCQeasy

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

A.pull_request: branches: [main]
B.pull_request: types: [closed] branches: [main]
C.push: branches: [main]
D.release: types: [published]
AnswerC

This push trigger activates on any push to the main branch, including direct pushes, force pushes, or pushes from branch creation, not just pushes resulting from a pull request merge. It does not distinguish between a merge commit and a direct push, so it would trigger on all commits pushed to main, violating the requirement to only respond to PR merges.

Why this answer

In GitHub Actions, merging a pull request into `main` results in a `push` event to `main`. The `push` trigger with `branches: [main]` therefore correctly fires whenever a PR is merged. `pull_request: types: [closed]` fires on any PR closure, whether merged or not, so it would deploy even when a PR is closed without merging. To use `pull_request` for merges, you would need an additional `if: github.event.pull_request.merged == true` check, but the question asks for the event trigger alone.

Exam trap

The trap is that `pull_request: types: [closed]` is not the same as 'merged'. A merge to a branch is a push event, not a pull_request event. Candidates may incorrectly choose the `pull_request` trigger, but the correct trigger for a merge is `push`.

How to eliminate wrong answers

Option A is wrong because `pull_request: branches: [main]` triggers on any pull request activity (e.g., opened, synchronized, reopened) targeting main, not just when it is merged, leading to premature or repeated deployments. Option C is wrong because `push: branches: [main]` triggers on any push to main, including direct commits or pushes that are not pull request merges, which bypasses the intended merge-only deployment policy. Option D is wrong because `release: types: [published]` triggers only when a GitHub Release is published, which is a separate manual or automated process unrelated to pull request merges.

Full explanation →
492
MCQmedium

You are designing a build pipeline that produces an artifact. You need to ensure that the artifact is only published if the build succeeds. The pipeline includes multiple jobs: Build, Test, and Publish. Which condition should you use on the Publish job to achieve this?

A.condition: always()
B.condition: failed()
C.condition: succeeded()
D.condition: eq(variables['Build.Status'], 'Succeeded')
AnswerC

The succeeded() condition returns true only if all previous jobs in the dependency chain have succeeded. By setting this condition on the Publish job, it will only run if the Build and Test jobs succeed. This ensures the artifact is published only on successful builds.

Why this answer

The succeeded() condition ensures that the Publish job runs only if all previous jobs in the dependency chain have succeeded. This is the standard way to gate a job on the success of prior jobs. Other conditions either run unconditionally, on failure, or use invalid variables.

Exam trap

The trap here is using a variable like Build.Status, which does not exist for job status; the correct approach is to use the succeeded() function.

Full explanation →
493
MCQmedium

Your organization uses Azure DevOps Services. The development team uses feature branches and pull requests to merge changes into the main branch. You need to implement a policy that ensures every pull request has at least two approvals from the 'Senior Developers' group, and the build must succeed before merging. Additionally, any comment on the pull request must be resolved before merging. The policy should apply to the main branch only. You have already created the 'Senior Developers' group in Azure DevOps. What should you do?

A.Configure the team's settings to require approvals for all pull requests.
B.Add a branch policy on the main branch that requires a minimum of two reviewers from 'Senior Developers', a successful build, and that all comments are resolved.
C.Set up a build validation policy on the main branch that runs the pipeline and fails if comments are unresolved.
D.Configure the repository's pull request settings to require approvals and comment resolution.
AnswerB

A branch policy on main enforces these requirements at code push/PR validation time, and can restrict reviewer approvals to members of the Senior Developers group. The required number of reviewers, build validation, and comment resolution are all configurable checks in Azure DevOps branch policies.

Why this answer

Azure DevOps branch policies allow you to enforce specific requirements on pull requests targeting a branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers from a specific group (e.g., 'Senior Developers'), a successful build, and that all comments are resolved before merging. This directly meets all the stated requirements.

Exam trap

The trap here is that candidates often confuse repository-level settings (which are global) with branch-specific policies, leading them to choose options that cannot enforce group-based reviewer requirements or comment resolution on a single branch.

How to eliminate wrong answers

Option A is wrong because team settings for pull request approvals apply globally to all branches and cannot enforce a minimum number of reviewers from a specific group or require comment resolution. Option C is wrong because build validation policies only run a pipeline and check for build success; they cannot evaluate whether comments are resolved, as comment resolution is a separate policy setting. Option D is wrong because repository pull request settings are not branch-specific and cannot enforce a minimum number of reviewers from a specific group or require comment resolution; those are branch policy features.

Full explanation →
494
MCQmedium

Your organization uses GitHub Copilot for pull request summaries. A developer notices that the AI-generated summary is inaccurate. Which step should the developer take to improve the quality of future summaries?

A.Disable Copilot for pull requests
B.Provide a detailed pull request description
C.Edit the description after generation
D.Ignore the inaccuracy
AnswerB

A detailed pull request description provides structured context—such as motivation, scope, and testing—that Copilot uses alongside the diff to generate summaries; richer, clearer input directly improves the relevance and factual accuracy of the AI-generated output.

Why this answer

Providing a detailed pull request description gives GitHub Copilot more context and structured input, which directly improves the accuracy of AI-generated summaries. Copilot's PR summary feature relies on the diff and any existing description to infer intent; a richer description reduces ambiguity and enhances the quality of the generated output.

Exam trap

The trap here is that candidates may confuse reactive fixes (editing after generation) with proactive improvements (providing better input), leading them to choose option C instead of recognizing that the quality of AI-generated output is fundamentally driven by the quality of the input context.

How to eliminate wrong answers

Option A is wrong because disabling Copilot for pull requests eliminates the feature entirely rather than improving its accuracy, and it does not address the root cause of inaccurate summaries. Option C is wrong because editing the description after generation only fixes the current inaccuracy but does not improve the quality of future summaries, as Copilot does not learn from post-generation edits. Option D is wrong because ignoring the inaccuracy fails to provide any corrective feedback or additional context, leaving the underlying issue unresolved and likely to recur.

Full explanation →
495
MCQmedium

You are designing a build pipeline for a Java application hosted in Azure Repos. The pipeline needs to run unit tests, package the application as a JAR file, and publish the build artifact. Which task should you use to publish the JAR file as a pipeline artifact?

A.Publish Build Artifacts task
B.Copy Files task
C.Archive Files task
D.Publish Pipeline Artifact task
AnswerD

Publish Pipeline Artifact uploads files, directories, or archives to Azure Pipelines' pipeline artifact storage, making them downloadable and consumable by later stages in the same pipeline. It is the modern, YAML-native artifact-publishing task, and by default subsequent stages automatically download published pipeline artifacts into the Pipeline.Workspace directory. This is the correct task when the goal is to pass build outputs from a Java build stage to later deployment or test stages.

Why this answer

The Publish Pipeline Artifact task (D) is the correct choice because it is the modern, recommended way to publish artifacts from a pipeline in Azure DevOps. It stores the JAR file as a pipeline artifact, making it available for subsequent stages or releases, and it supports both file and folder paths directly without requiring an intermediate staging directory.

Exam trap

The trap here is that candidates often confuse the legacy Publish Build Artifacts task (A) with the modern Publish Pipeline Artifact task (D), not realizing that the latter is the recommended approach in current Azure DevOps pipelines and offers better performance and integration.

How to eliminate wrong answers

Option A is wrong because the Publish Build Artifacts task is a legacy task that publishes artifacts to Azure Pipelines, but it requires an explicit staging directory and is less efficient than the newer Publish Pipeline Artifact task. Option B is wrong because the Copy Files task only copies files from source to a target folder within the agent's workspace; it does not publish anything as a pipeline artifact. Option C is wrong because the Archive Files task compresses files into a ZIP or other archive format but does not publish the archive as a pipeline artifact; it only creates the archive file locally.

Full explanation →
496
Multi-Selectmedium

A development team uses Git for source control. They want to enforce a branching strategy where all feature work is done in short-lived branches that are merged to main via pull requests. The team also requires that every commit on main builds successfully. Which TWO practices should the team implement?

Select 2 answers
A.Configure a branch policy on main that requires a successful build before merging.
B.Use squash merge when completing pull requests to main.
C.Require at least one approver on all pull requests targeting main.
D.Create feature branches from main and keep them long-lived for stability.
E.Allow developers to commit directly to main for urgent fixes.
AnswersA, C

Establishing a branch policy on main that requires a successful build before merging ensures that every pull request targeting main must pass a defined build pipeline as a mandatory gate. Azure DevOps blocks the merge until the build succeeds, preventing broken code from integrating into main and enforcing continuous integration at the point of merge.

Why this answer

Option A configures a branch policy on main that requires a successful build before merging, directly ensuring every commit on main has passed a build. Option C requires at least one approver on all pull requests targeting main, which enforces the code review process as part of the pull request workflow, a key practice for maintaining a healthy branching strategy with short-lived feature branches. Together, these two practices enforce both the build-success requirement and the pull-request-based workflow.

Exam trap

The trap here is that candidates often confuse squash merge (which simplifies history) with a practice that ensures build success, or they mistakenly think allowing direct commits for urgent fixes is acceptable when the requirement explicitly demands every commit on main builds successfully.

Full explanation →
497
MCQhard

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. You need to require manual approval before deploying to prod. The approver should be able to review the changes and approve or reject. Which feature should you use?

A.Pre-deployment conditions.
B.Environment checks.
C.Approval gates.
D.Manual intervention task.
AnswerA

Pre-deployment conditions in Azure Pipelines include artifact filters, schedule times, and pre-deployment approvals, but the approval itself is a separate gate that must be explicitly configured. Merely having pre-deployment conditions does not implement a manual approval workflow by default; it only defines when and under what circumstances the deployment is triggered.

Why this answer

In Azure DevOps release pipelines, to require manual approval before deploying to a specific stage, you configure the pre-deployment conditions of that stage, specifically assigning pre-deployment approvers. These approvers can review the changes and then approve or reject the deployment. This satisfies the requirement directly.

Exam trap

Candidates may mistake 'Approval gates' for a valid feature, but Azure DevOps only supports 'approvals' and 'gates' as separate features. Manual approval is achieved via pre-deployment approvers under 'Pre-deployment conditions', not via gates, which are automated checks.

How to eliminate wrong answers

Option A is wrong because pre-deployment conditions include triggers, gates, and approvals, but the specific feature that enables manual approval by a reviewer is the 'Approvals' section within pre-deployment conditions, not the conditions themselves. Option B is wrong because environment checks are automated evaluations (e.g., querying Azure Monitor or REST endpoints) that run before or after deployment; they do not provide a manual approval workflow. Option D is wrong because the Manual Intervention task is a pipeline agent job step that pauses the pipeline and waits for a manual input, but it runs inside the deployment job on the agent, not as a pre-deployment gate, and it does not integrate with the release pipeline's approval history or notification system.

Full explanation →
498
MCQmedium

Your Azure Pipelines build uses a self-hosted agent that runs on a Windows VM. The build fails with the error 'Access to the path 'C:\agent\_work\1\s\bin' is denied.' What is the most likely cause?

A.The agent service account does not have write permissions on the working directory
B.The agent is not configured to use the correct agent pool
C.The build is trying to overwrite a file that is locked by another process
D.The source code checkout failed due to incorrect credentials
AnswerA

The agent service account is the OS-level account under which the self-hosted agent process runs. When a pipeline job starts, the agent creates a working directory under its _work folder (e.g., _work/1/s) to clone the source and perform build outputs. If that account lacks write permissions (NTFS Modify or POSIX write/execute) on the working directory, any file creation or modification fails with an access-denied error—even though the agent itself successfully connected and started the job. To resolve this, grant the service account full control (Windows) or write+execute (Unix) on the entire _work directory.

Why this answer

The error 'Access to the path ... is denied' indicates a permissions issue. Self-hosted agents run under a specific Windows service account (e.g., Network Service, Local System, or a custom domain account). If that account lacks write permissions on the working directory (e.g., `C:\agent\_work\1\s\bin`), the agent cannot create or modify files during the build, causing the failure.

This is the most common cause when using self-hosted agents on Windows VMs.

Exam trap

The trap here is that candidates may confuse a permissions error with a file-locking error (Option C), but Azure Pipelines specifically uses distinct error messages for each scenario, and 'access denied' always points to NTFS permissions, not file locks.

How to eliminate wrong answers

Option B is wrong because an incorrect agent pool configuration would prevent the build from being assigned to the agent at all, resulting in a 'no agent found' or 'agent offline' error, not a file access denied error. Option C is wrong because a file locked by another process would produce a specific error like 'The process cannot access the file because it is being used by another process', not a generic 'access denied' error. Option D is wrong because source code checkout failures due to incorrect credentials would manifest as authentication errors (e.g., 'Authentication failed', 'Repository not found'), not as a local file path access denied error.

Full explanation →
499
MCQhard

Your release pipeline deploys a .NET Core web app to Azure App Service using a slot swap strategy. The pipeline runs acceptance tests on the staging slot before swapping. After a recent change, the acceptance tests pass but the production site becomes unresponsive after the swap. What is the most likely cause?

A.The staging slot had different app settings that were swapped into production, causing the site to fail.
B.The acceptance tests are not comprehensive enough and missed a regression.
C.The acceptance tests should have been run after the swap.
D.The slot swap was not 'warm-up' and caused downtime.
AnswerA

Slot swaps exchange app settings marked as swappable, so staging-specific values (connection strings, endpoints) migrate into production and break it, while acceptance tests still pass because they ran against staging's own configuration. The unresponsiveness stems from production receiving staging's incompatible settings during the swap, not from code or warm-up failures.

Why this answer

The most likely cause is that the staging slot had different app settings (e.g., connection strings, environment variables, or feature flags) that were swapped into production. During a slot swap, Azure App Service automatically moves all slot-specific configuration (app settings, connection strings, and other deployment slot settings) to the target slot. If the staging slot was configured with settings intended only for testing (like a staging database or debug mode), those settings would overwrite the production settings, causing the production site to become unresponsive.

This is a common pitfall because acceptance tests may pass against the staging environment but fail when the same code runs with production configuration.

Exam trap

The trap here is that candidates often assume acceptance tests are sufficient to catch all issues, or they misunderstand the slot swap mechanism—thinking it causes downtime—when the real problem is the automatic migration of non-sticky configuration settings between slots.

How to eliminate wrong answers

Option B is wrong because the acceptance tests passing on the staging slot does not guarantee that the production configuration is correct; the issue is a configuration mismatch, not a code regression. Option C is wrong because running acceptance tests after the swap would not prevent the swap from occurring and would only detect the problem after the site is already broken. Option D is wrong because Azure App Service slot swaps include automatic warm-up of the staging slot before the swap completes; the swap itself does not cause downtime unless the warm-up fails, but the scenario states the site becomes unresponsive after the swap, which points to a configuration issue, not a warm-up failure.

Full explanation →
500
Multi-Selecteasy

Which TWO features of Azure Pipelines help you manage build artifacts across stages? (Choose two.)

Select 2 answers
A.Pipeline variables
B.Release gates
C.Build tags
D.Download Pipeline Artifact task
E.Publish Pipeline Artifact task
AnswersD, E

The Download Pipeline Artifact task is correct because it downloads pipeline artifacts from a previous build or pipeline run into the current job, enabling the job to consume build outputs that were published earlier. This task is a fundamental part of managing build artifacts across stages and pipelines.

Why this answer

The Publish Pipeline Artifact task (option E) makes files available to subsequent stages by uploading them to Azure Pipelines, while the Download Pipeline Artifact task (option D) retrieves those artifacts in later stages. Together, they form the primary mechanism for passing build outputs across stages in a pipeline.

Exam trap

The trap here is that candidates confuse pipeline variables (which pass simple values) with artifact tasks (which pass files), or mistakenly think release gates or build tags have a role in artifact management across stages.

Full explanation →
501
Multi-Selecthard

Which TWO of the following are valid strategies to reduce the build time of a container image in Azure Pipelines?

Select 2 answers
A.Combine multiple RUN commands into a single RUN instruction to reduce layers.
B.Build multiple images in parallel using matrix strategy.
C.Use Docker layer caching with a registry cache.
D.Disable security scanning for the image.
E.Use a larger build agent with more CPU cores.
AnswersC, E

Using Docker layer caching with a registry cache is a valid strategy because it reuses previously built and stored layers from a container registry (e.g., ACR) instead of rebuilding unchanged steps. This dramatically accelerates builds, particularly in CI/CD pipelines with frequent commits or shared base layers, as only the modified layers are rebuilt and the rest are pulled from cache.

Why this answer

The correct strategies to reduce build time for a container image in Azure Pipelines are using Docker layer caching with a registry cache (C) and using a larger build agent with more CPU cores (E). Layer caching avoids rebuilding unchanged layers, while a larger agent provides more parallelism for CPU-bound build steps. Combining RUN commands (A) can hurt cache efficiency and is not a reliable way to reduce build time.

Building multiple images in parallel (B) reduces overall pipeline time when you have multiple images, but it does not reduce the build time of a single image. Disabling security scanning (D) is not a valid practice.

Exam trap

The trap is that candidates often assume combining RUN commands (Option A) always reduces build time, but it can harm cache efficiency. Another is assuming that parallelizing multiple images (B) affects the build time of a single image; it does not.

Full explanation →
502
Multi-Selectmedium

Which TWO options are valid ways to communicate build status from Azure Pipelines to external stakeholders?

Select 2 answers
A.Create a work item in Azure Boards for each build.
B.Export pipeline logs to Power BI for reporting.
C.Configure a Service Hook to post to a Slack channel.
D.Set up an email notification for specific events.
E.Use a release pipeline to send SMS via Twilio.
AnswersC, D

Azure DevOps Service Hooks can be configured to trigger an HTTP POST to a Slack incoming webhook when build events such as build.completed occur, which delivers a real-time status message to a Slack channel. This is a documented, first-class integration pattern that enables automatic build status notifications to your team.

Why this answer

Service Hooks in Azure Pipelines allow integration with external services like Slack by triggering HTTP POST requests containing build status payloads. Additionally, Azure Pipelines provides built-in email notifications for specific events, such as build completion or failure, which can be configured to send status updates to stakeholders. Both are standard, officially supported features.

Options like using a release pipeline to call Twilio are possible but are not standard built-in methods, so they are not considered 'valid ways' in this context.

Exam trap

The trap here is that candidates may think any integration is valid if it's technically possible (like using a release pipeline to call Twilio), but the question asks for 'valid ways' meaning standard, built-in, or officially supported methods within Azure Pipelines.

Full explanation →
503
MCQhard

You are designing an instrumentation strategy for a microservices application deployed to Azure Kubernetes Service (AKS) using Azure Pipelines. The application emits custom metrics using OpenTelemetry. You need to ensure that all pipeline-related events (build, release, and test results) are correlated with application telemetry to enable end-to-end traceability. What should you do?

A.Configure Application Insights to ingest pipeline telemetry via a custom exporter.
B.Store pipeline logs in an Azure Log Analytics workspace and query them together with application metrics.
C.Use Azure Pipelines' Checks feature to enforce deployment gates based on application metrics.
D.Set a unique Correlation ID in the pipeline variables and pass it to the application's OpenTelemetry instrumentation as a span attribute.
AnswerD

Setting a unique Correlation ID in pipeline variables and passing it into the application's OpenTelemetry instrumentation as a span attribute creates a shared context for all telemetry emitted during that pipeline run. This allows you to query Application Insights for every span and log associated with a specific build/deployment, enabling end-to-end traceability from pipeline to application.

Why this answer

To correlate pipeline events with application telemetry, you must propagate a shared identifier from the pipeline into the application's telemetry. Setting a unique Correlation ID in pipeline variables and passing it as an OpenTelemetry span attribute (D) lets Application Insights and pipeline logs join on that ID, enabling true end-to-end traceability.

Exam trap

The trap is confusing 'co-locating logs' (Option B) with 'correlating telemetry' — without a shared correlation ID propagated into spans, you cannot join pipeline events to application traces.

How to eliminate wrong answers

Option A is wrong because Application Insights does not natively ingest Azure Pipelines telemetry via a custom exporter — there is no supported pipeline-to-App-Insights exporter that correlates build/release events with app spans. Option B is wrong because storing pipeline logs in Log Analytics and querying them alongside app metrics provides co-location, not correlation — without a shared ID, you cannot reliably join a specific build to a specific request trace. Option C is wrong because Checks enforce deployment gates based on metrics; they do not create traceability between pipeline events and application telemetry.

Full explanation →
504
MCQhard

You have a classic release pipeline that deploys to Azure App Service. You need to implement a canary deployment strategy where 10% of traffic is routed to the new version for 30 minutes before full rollout. What should you use?

A.Configure multiple deployment slots and use Traffic Manager to distribute traffic.
B.Use the 'Azure App Service deploy' task with the 'Deploy to Slot' option, then manually adjust routing rules.
C.Deploy to a staging slot and then use Azure CLI to update routing rules after deployment.
D.Use slot swap with 'Swap with preview' and set traffic percentage in the swap settings.
AnswerC

Using Azure CLI to update routing rules after deploying to a staging slot is a manual, scripted step that lacks the automatic warm-up, validation, and controlled traffic shifting provided by swap with preview. This approach also doesn't integrate with release pipeline gates or provide a clear path to roll back if issues are detected during the canary phase.

Why this answer

Canary deployment on Azure App Service is achieved by deploying to a deployment slot and then configuring routing rules to send a percentage of traffic to that slot. In a classic release pipeline, you can use the Azure App Service deploy task to deploy to a slot, followed by an Azure CLI task to set the traffic percentage (e.g., az webapp traffic-routing set). The 'Swap with preview' feature is for multi-phase swap validation, not for setting traffic percentages.

Exam trap

Candidates confuse Traffic Manager (DNS-level) and slot-based routing, but also mistakenly assume 'Swap with preview' supports traffic percentage. The correct tool is slot routing rules, not swap-based traffic shifting.

How to eliminate wrong answers

Option A is wrong because Traffic Manager is a DNS-based traffic routing service that operates at the domain level, not at the slot level within a single App Service; it cannot route a percentage of traffic between deployment slots of the same app. Option B is wrong because the 'Azure App Service deploy' task with 'Deploy to Slot' deploys to a slot but does not automatically adjust routing rules; manual adjustment of routing rules is not a built-in feature of the task and would require additional scripting. Option C is wrong because deploying to a staging slot and then using Azure CLI to update routing rules is possible but less integrated; the 'Swap with preview' feature provides a more streamlined, built-in approach with traffic percentage control during the swap process.

Full explanation →
505
MCQmedium

Your team uses Azure Pipelines with GitHub for source control. You need to ensure that whenever a pull request is created against the main branch, a validation build runs automatically. Which YAML trigger should you configure in the pipeline?

A.pr: branches: include: - main
B.pr: main
C.trigger: branches: exclude: - main
D.trigger: main
AnswerA

This is the correct YAML for a pull request trigger that runs the pipeline when a PR targets the `main` branch. The `pr` keyword specifically enables pull request validation for GitHub repos, and the `branches: include` list tells Azure Pipelines which target branches should trigger a run. Without this configuration, PRs to `main` would rely on the default policy and might not run automatically.

Why this answer

The correct syntax for a pull request trigger in Azure Pipelines YAML. The `pr` trigger requires a `branches` node with `include` or `exclude`, and the verbose form `pr: branches: include: - main` is fully valid. Option B, `pr: main`, is not valid YAML syntax for Azure Pipelines; the shorthand `pr: main` is not recognized and will cause the pipeline to ignore the trigger.

Options C and D use the `trigger` keyword, which is for CI builds on push, not for PR validation.

Exam trap

The trap is that some documentation or online examples might incorrectly suggest the shorthand `pr: main` is valid, but Azure Pipelines requires the explicit `pr: branches: include:` structure. Candidates may choose the seemingly simpler format and fail.

How to eliminate wrong answers

Option A is wrong because while it uses the `pr` trigger, the syntax `pr: branches: include: - main` is invalid; the correct shorthand for a single branch is `pr: main`. Option C is wrong because `trigger: branches: exclude: - main` configures a CI trigger that excludes the main branch, meaning it would run on pushes to other branches but not on pull requests, which does not meet the requirement. Option D is wrong because `trigger: main` is a CI trigger that runs on pushes to the main branch, not on pull request creation, so it would not trigger a validation build for PRs.

Full explanation →
506
MCQhard

Your organization uses GitHub for source control and GitHub Actions for CI/CD. You need to implement a branching strategy where every commit to the main branch triggers a build and deployment to a staging environment, but only after a successful pull request review. Which GitHub Actions trigger should you use?

A.pull_request_target with branches: [main] and types: [closed]
B.push with branches: [main]
C.pull_request with branches: [main]
D.workflow_dispatch
AnswerB

The push trigger on main fires for every commit pushed directly to the branch, including fast-forward merges and direct pushes, without requiring a pull request, so it cannot enforce branch protection review policies. This means unreviewed changes can trigger the workflow, unlike pull_request_target which only fires on the closed event after a PR is merged.

Why this answer

The `push` trigger with `branches: [main]` runs on every commit pushed to main. When branch protection requires pull request reviews, commits only reach main through a reviewed and merged PR, so this satisfies the 'only after successful pull request review' condition. In contrast, `pull_request_target` with `types: [closed]` triggers for any closed PR, including those not merged, and does not map one-to-one to commits on main.

To use a PR event, you would need an additional condition like `if: github.event.pull_request.merged == true`, which is not mentioned.

Exam trap

The trap is confusing pull_request closed with merge. A PR can be closed without merging, so types: [closed] does not guarantee a successful review and merge. The correct event for new commits on a branch is `push`.

How to eliminate wrong answers

Option B is wrong because a `push` trigger on `main` would run the workflow on every commit to main, including direct pushes that bypass pull request review, which violates the requirement for a successful review before deployment. Option C is wrong because `pull_request` triggers on pull request creation or updates (e.g., opened, synchronized), not specifically after the PR is closed/merged; it would run during the review process, not after approval. Option D is wrong because `workflow_dispatch` is a manual trigger that requires someone to manually run the workflow, which does not automate the deployment after a pull request merge.

Full explanation →
507
MCQhard

Refer to the exhibit. You deploy this Bicep template to create an Azure App Service with a custom container. The deployment succeeds, but the container fails to start with an error 'Container didn't respond to HTTP pings'. What is the most likely missing configuration?

A.The template is missing the 'healthCheckPath' property in siteConfig.
B.The container image is not publicly accessible.
C.The WEBSITES_ENABLE_APP_SERVICE_STORAGE should be set to 'true'.
D.The template is missing the app setting 'WEBSITES_PORT'.
AnswerA

The template omits the healthCheckPath property in siteConfig, which is required for App Service to route /health requests to the container's endpoint and remove unhealthy instances from the load balancer. Without this property, the container's custom health endpoint is never probed, so the deployment fails validation if the container requires a specific path.

Why this answer

The error 'Container didn't respond to HTTP pings' indicates that Azure App Service's built-in health check mechanism is failing to reach the container. By default, App Service pings the root path ('/') on the container's exposed port. If the container's application does not respond on that path, the health check fails.

Adding the 'healthCheckPath' property in siteConfig allows you to specify a custom endpoint (e.g., '/health') that the container can respond to, resolving the issue.

Exam trap

The trap here is that candidates often confuse the health check path with the container port setting (WEBSITES_PORT), assuming the ping failure is due to a port mismatch rather than the HTTP endpoint not being reachable on the default path.

How to eliminate wrong answers

Option B is wrong because the container image not being publicly accessible would cause a deployment failure (e.g., 'ImagePullBackOff'), not a post-startup HTTP ping failure. Option C is wrong because WEBSITES_ENABLE_APP_SERVICE_STORAGE controls persistent file storage for Windows containers, not HTTP health check behavior; it is irrelevant to the ping failure. Option D is wrong because WEBSITES_PORT defines the internal port the container listens on, but if the container is already listening on the default port (e.g., 80 or 8080) and the ping fails, the issue is the response path, not the port.

Full explanation →
508
MCQhard

Your team is adopting Infrastructure as Code (IaC) using Bicep. You have a multi-stage YAML pipeline that deploys Azure resources to dev, test, and prod environments. You need to ensure that the Bicep files are validated and deployed consistently, and that any changes to the infrastructure are approved for production. You also want to use the latest version of the Azure CLI task. What is the recommended approach?

A.Use the Azure Resource Manager Template Deployment task with the 'templateLocation' parameter pointing to the compiled ARM JSON.
B.Create three separate pipelines for each environment, each using the ARM Template Deployment task.
C.Use the AzureCLI task with inline script to run 'az deployment group validate' and 'az deployment group create'. Add environments with approval gates for production.
D.Use a PowerShell task with the 'New-AzResourceGroupDeployment' cmdlet.
AnswerC

The Azure CLI task natively supports Bicep files, so you can run 'az deployment group validate' to catch template errors before deploying, then 'az deployment group create' to apply the resource definitions. Adding environments with approval gates for production lets you control promotions and gain auditability, all within one pipeline and without any precompilation step.

Why this answer

It uses the AzureCLI task with the 'az deployment group validate' and 'az deployment group create' commands, which natively support Bicep files. This approach integrates with multi-stage YAML pipelines and allows adding approval gates for production environments. Option A is incorrect because the Azure Resource Manager Template Deployment task requires a compiled ARM JSON file, adding an unnecessary compilation step and not leveraging Bicep's native capabilities.

Option B is incorrect because creating separate pipelines for each environment duplicates effort and does not take advantage of the multi-stage YAML pipeline structure with environment approvals. Option D is incorrect because using a PowerShell task with 'New-AzResourceGroupDeployment' cmdlet lacks native Bicep support and may require manual compilation.

Full explanation →
509
MCQhard

Your organization uses GitHub Actions and needs to enforce that only approved actions from the GitHub Marketplace can be used in workflows. Developers have been using custom actions from third-party repositories. What is the most effective way to control which actions are allowed?

A.Create a manual approval process for each new action.
B.Set the organization to disallow all third-party actions.
C.Configure the organization to allow only actions created by GitHub.
D.Use the 'Allow actions created by GitHub and verified partners' policy and add specific actions to the allow list.
AnswerD

A repository or organisation action policy restricts execution to GitHub-authored and verified-creator actions, then an allow list permits specific third-party actions. This directly blocks unapproved marketplace actions while retaining sanctioned ones, satisfying the requirement to control which actions workflows may use.

Why this answer

The 'Allow actions created by GitHub and verified partners' policy, combined with an explicit allow list, provides granular control over which actions can run in workflows. This approach blocks unverified third-party actions by default while permitting specific approved actions from the Marketplace, directly addressing the need to enforce only approved actions without unnecessarily restricting all third-party actions.

Exam trap

The trap here is that candidates often choose Option B (disallow all third-party actions) thinking it is the most secure, but the question specifically requires allowing approved actions from the Marketplace, which includes verified partners, making the granular allow-list approach in Option D the correct balance of security and flexibility.

How to eliminate wrong answers

Option A is wrong because a manual approval process for each new action is not a native GitHub Actions policy; it would require custom scripting or external tooling, is not scalable, and does not prevent unapproved actions from being used in workflows until after the fact. Option B is wrong because disallowing all third-party actions would also block verified partners and any custom actions that might be necessary, which is overly restrictive and not aligned with the requirement to allow approved actions from the Marketplace. Option C is wrong because allowing only actions created by GitHub excludes verified partner actions and any custom actions that could be safely allowed, which is too restrictive and does not match the need to control which actions are allowed while still permitting some third-party actions.

Full explanation →
510
Drag & Dropmedium

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct order to set up a self-hosted Azure DevOps agent on a Windows VM is: create a Personal Access Token (PAT) first, then download the agent package, then run config.cmd to configure and register the agent with Azure DevOps, and finally start the agent as a service. Option A reflects this sequence correctly. Other options either place download before PAT creation or start the agent before configuration, which would fail.

Full explanation →
511
MCQhard

Your company uses GitHub Advanced Security. You need to ensure that all code in the main branch is free of high-severity secrets before deployment. What is the most efficient way to enforce this?

A.Require manual review of all pull requests for secrets
B.Enable secret scanning push protection
C.Configure Dependabot to flag secrets in dependencies
D.Enable code scanning alerts for secrets
AnswerB

Secret scanning push protection uses a pre-receive hook to detect supported secret patterns (e.g., GitHub tokens, AWS access keys) in commits before they are pushed, blocking the push and preventing the secret from ever reaching the remote repository. This makes it an effective, automated control for keeping secrets out of git history—even before a PR is opened.

Why this answer

Secret scanning push protection (option B) is the most efficient way to enforce that no high-severity secrets reach the main branch because it blocks the push at the Git level before the commit is accepted. This prevents secrets from ever entering the repository, eliminating the need for post-hoc detection or manual review. Other options either rely on reactive detection or do not address secrets in code.

Exam trap

The trap here is that candidates may confuse 'secret scanning alerts' (which detect secrets after they are committed) with 'push protection' (which blocks secrets before they are committed), leading them to choose option D instead of B.

How to eliminate wrong answers

Option A is wrong because requiring manual review of all pull requests for secrets is inefficient, error-prone, and does not scale; it relies on human vigilance rather than automated enforcement. Option C is wrong because Dependabot is designed to manage dependency vulnerabilities, not to detect or block secrets in source code; it has no capability to scan for secrets. Option D is wrong because code scanning alerts for secrets are reactive — they detect secrets after they have already been committed, which does not prevent them from reaching the main branch.

Full explanation →
512
MCQhard

A company uses Microsoft Defender for Cloud to assess the security posture of Azure Pipelines agents. They notice that self-hosted agents are flagged as having high-severity vulnerabilities. What is the recommended action to remediate these findings while minimizing downtime?

A.Disable Microsoft Defender for Cloud for the agent pool.
B.Uninstall the self-hosted agents and use only Microsoft-hosted agents.
C.Apply the security updates recommended by Microsoft Defender for Cloud to the agent VMs.
D.Replace all self-hosted agents with Microsoft-hosted agents.
AnswerC

Applying the security updates recommended by Microsoft Defender for Cloud directly remediates the identified vulnerabilities on the agent VMs by patching the operating system and installed software. This eliminates known exploit paths, reduces the attack surface, and aligns the environment with security best practices.

Why this answer

Microsoft Defender for Cloud identifies vulnerabilities on the VMs hosting self-hosted Azure Pipelines agents and provides specific security update recommendations. Applying these updates directly remediates the high-severity findings without requiring agent replacement or disabling security monitoring, thus minimizing downtime by patching in-place.

Exam trap

The trap here is that candidates may assume replacing agents with Microsoft-hosted agents is the only secure option, but the question specifically asks for remediation while minimizing downtime, and patching the existing VMs is the least disruptive and most direct action.

How to eliminate wrong answers

Option A is wrong because disabling Microsoft Defender for Cloud for the agent pool would stop vulnerability assessments and security monitoring, leaving the agents exposed and violating security compliance requirements. Option B is wrong because uninstalling self-hosted agents and using only Microsoft-hosted agents is an unnecessary and disruptive migration that does not address the root cause of the vulnerabilities on the existing infrastructure. Option D is wrong because replacing all self-hosted agents with Microsoft-hosted agents is an overreaction that ignores the ability to patch the underlying VMs, and it introduces migration overhead and potential downtime that can be avoided by applying the recommended updates.

Full explanation →
513
MCQhard

Your YAML pipeline uses a self-hosted agent pool. You need to ensure that only the pipeline can trigger builds on that pool, preventing other projects from using it. What should you do?

A.Set the agent pool to 'Disabled' for other projects
B.Configure pipeline permissions in the agent pool security settings
C.Use a deployment group instead of an agent pool
D.Create a separate agent pool for each project
AnswerB

Configuring pipeline permissions in the agent pool security settings is the correct approach because Azure DevOps agent pools support role-based access control (Reader, User, Administrator) and you can grant or deny the 'Use' permission to specific pipelines or groups. This allows you to restrict which pipelines can consume the agents in the pool.

Why this answer

Azure DevOps agent pool security settings allow you to restrict which pipelines or projects can use a specific agent pool. By configuring pipeline permissions, you can grant the 'Use' permission only to the intended pipeline, preventing other projects from triggering builds on that pool. This ensures exclusive access without disabling the pool for all other uses.

Exam trap

The trap here is that candidates often confuse disabling the pool for other projects (Option A) with permission-based restrictions, not realizing that disabling removes all access, including the intended pipeline's ability to use it.

Why the other options are wrong

A

Disabling the pool prevents all usage, including the intended pipeline.

C

Deployment groups are for targeting specific servers, not for access control.

D

That would work but is not necessary; you can secure a single pool with permissions.

Full explanation →
514
Multi-Selecteasy

You are configuring a continuous integration (CI) trigger for your YAML pipeline. The trigger should run the pipeline when changes are pushed to the 'main' branch or any release branch matching 'release/*'. Which TWO trigger configurations are valid? (Choose two.)

Select 2 answers
A.trigger: branches: exclude: - main
B.trigger: branches: include: - main
C.branches: include: - main
D.trigger: branches: main
E.trigger: branches: include: - release/*
AnswersB, E

This is correct: the trigger block with branches/include and a main entry tells Azure Pipelines to start the CI pipeline only when changes are pushed to main, using the required YAML syntax where branches filters are lists under include or exclude.

Why this answer

The `trigger` section with `branches: include: - main` explicitly specifies that the pipeline should run on pushes to the `main` branch. Option E is correct because `trigger: branches: include: - release/*` uses the wildcard pattern `release/*` to include all branches matching that pattern, such as `release/v1.0` or `release/2.0`. Both configurations are valid YAML trigger definitions for Azure Pipelines.

Exam trap

The trap here is that candidates often forget the `trigger:` keyword (as in Option C) or misuse `exclude` when `include` is needed (as in Option A), and they may also incorrectly assume a simple list syntax like `branches: main` is valid without the `include` keyword.

Full explanation →
515
Matchingmedium

Match each Azure Artifacts feed type to its description.

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

Concepts
Matches

Accessible to all projects in the organization

Accessible only within a specific project

Caches packages from external sources like NuGet.org

Filters packages by release status (e.g., prerelease)

Why these pairings

In Azure Artifacts, project-scoped feeds are limited to a specific project, organization-scoped feeds are available to the entire org, and public feeds allow anonymous access. Common confusions arise from swapping the scope of project and org feeds, or misstating public feed authentication requirements.

Full explanation →
516
MCQmedium

A company uses Azure Pipelines to deploy microservices to Azure Kubernetes Service (AKS). They want to implement a canary deployment strategy. What should they use?

A.Use Kubernetes native deployment strategies with multiple replica sets and traffic splitting
B.Use Azure Front Door to route traffic between clusters
C.Use deployment slots in Azure App Service
D.Use Azure Container Instances as a staging environment
AnswerA

Kubernetes natively supports canary deployments by running multiple replica sets of the same microservice and gradually shifting traffic between them using a service mesh (e.g., Istio, Linkerd) or ingress controllers with traffic-splitting rules. This allows incremental rollout with fine-grained control and automatic rollback, making it the correct strategy for canary releases within an AKS cluster.

Why this answer

Kubernetes natively supports canary deployments by running multiple replica sets of the same application and using a service mesh or ingress controller (e.g., Istio, NGINX Ingress) to split traffic between the stable and canary versions. Azure Pipelines can orchestrate this by updating the canary deployment and adjusting traffic weights gradually, enabling controlled rollouts and rollbacks without external routing services.

Exam trap

The trap here is that candidates confuse Azure Front Door’s global traffic routing with Kubernetes-native traffic splitting, assuming a PaaS-level service can replace the granular, service-mesh-based canary logic required within a single AKS cluster.

How to eliminate wrong answers

Option B is wrong because Azure Front Door is a global load balancer and application delivery network that routes traffic between entire clusters or regions, not between microservice versions within the same AKS cluster; it cannot perform fine-grained canary traffic splitting at the pod or replica set level. Option C is wrong because deployment slots are a feature of Azure App Service, not AKS; they apply to web apps running on Windows or Linux App Service plans, not to containerized microservices orchestrated by Kubernetes. Option D is wrong because Azure Container Instances (ACI) is a serverless container runtime for running individual containers, not a staging environment for canary deployments; it lacks the orchestration, service discovery, and traffic management capabilities needed to split traffic between versions of a microservice.

Full explanation →
517
MCQmedium

A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?

A.Use trunk-based development with short-lived feature branches that merge directly to main.
B.Use a forking workflow where each developer forks the repository and creates pull requests.
C.Use Git Flow with feature, develop, release, and main branches.
D.Use GitHub Flow with feature branches and pull requests directly to main.
AnswerC

Git Flow's dedicated release branch lets the team stabilise a release candidate while develop continues accepting feature work, and main plus hotfix branches handle urgent production fixes. This matches the stem's feature, hotfix, and stabilisation requirements.

Why this answer

Git Flow is the correct choice because it explicitly supports feature development, release stabilization, and hotfix releases through its structured branch hierarchy. The release branch allows the team to stabilize a release candidate before merging to main, while hotfix branches can be created from main for urgent fixes. This aligns perfectly with the requirement for both feature development and hotfix releases with release candidate stabilization.

Exam trap

The trap here is that candidates often confuse GitHub Flow (option D) with Git Flow, but GitHub Flow lacks the dedicated release and hotfix branches needed for the described release stabilization and hotfix requirements.

How to eliminate wrong answers

Option A is wrong because trunk-based development with short-lived feature branches merging directly to main does not provide a dedicated release branch for stabilizing a release candidate before final deployment, nor does it inherently support hotfix releases without disrupting ongoing development. Option B is wrong because a forking workflow is designed for open-source collaboration where contributors do not have direct write access, not for managing a structured branch strategy with release and hotfix branches within a single team's repository. Option D is wrong because GitHub Flow uses feature branches and pull requests directly to main, which lacks a separate release branch for stabilization and a dedicated hotfix workflow, making it unsuitable for scenarios requiring release candidate stabilization.

Full explanation →
518
MCQmedium

You are implementing a CI pipeline for a Node.js application. The pipeline must run unit tests and generate code coverage reports. You want to publish the coverage results to Azure DevOps and enforce a minimum coverage threshold of 80%. Which tasks should you use?

A.Use the Publish Test Results task to publish coverage data.
B.Use the Publish Build Artifacts task with coverage files.
C.Use the Copy Files task to copy coverage files and then the Publish Build Artifacts task.
D.Use the Publish Code Coverage Results task and configure the threshold in the task settings.
AnswerD

The Publish Code Coverage Results task is the correct solution because it natively consumes coverage files (e.g., Cobertura, JaCoCo) and publishes them to the pipeline summary. It also has threshold settings to enforce minimum coverage percentages, which can fail the build if the thresholds are not met, satisfying both reporting and quality gate requirements.

Why this answer

The Publish Code Coverage Results task is specifically designed to publish code coverage data (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps and supports configuring a minimum coverage threshold directly in its settings. This meets both requirements: publishing results and enforcing the 80% threshold. Other tasks like Publish Test Results or Publish Build Artifacts do not natively handle coverage threshold enforcement.

Exam trap

The trap here is that candidates confuse 'publishing test results' with 'publishing code coverage results,' assuming the Publish Test Results task can handle coverage data, when in fact coverage requires a dedicated task with threshold enforcement.

How to eliminate wrong answers

Option A is wrong because the Publish Test Results task publishes test execution results (e.g., JUnit XML), not code coverage data, and cannot enforce coverage thresholds. Option B is wrong because the Publish Build Artifacts task only uploads raw files as build artifacts without any analysis or threshold enforcement for coverage. Option C is wrong because while Copy Files and Publish Build Artifacts can move coverage files, they lack the built-in capability to parse coverage reports and fail the pipeline if the threshold is not met.

Full explanation →
519
MCQeasy

You need to deploy a web app to Azure App Service using Azure Pipelines. The deployment slot should be 'staging' first, and after smoke tests, swap to production. Which deployment strategy should you use?

A.Slot swap
B.Canary deployment
C.Rolling update
D.Blue-green deployment
AnswerD

Blue-green deployment maintains two fully separate environments (blue and green) with the new version deployed to the idle environment before switching traffic via a load balancer or DNS; although conceptually similar, App Service slots provide this capability within a single app as a swap, so slot swap is the precise Azure-native implementation, not a distinct blue-green setup.

Why this answer

Blue-green deployment is a release strategy that uses two identical environments (blue and green). The new version is deployed to the staging slot (green), smoke tests are run, and traffic is switched to the staging slot by swapping it with the production slot (blue). Slot swap is the Azure App Service mechanism used to implement blue-green deployment, but the strategy itself is blue-green.

Exam trap

The trap is that 'slot swap' is an Azure-specific implementation mechanism, not the deployment strategy. Candidates may answer 'slot swap' because they recognize the step, but the question asks for the strategy, which is blue-green.

How to eliminate wrong answers

Option B is wrong because canary deployment routes a small percentage of traffic to the new version gradually, which is not the same as a full slot swap after smoke tests; Azure App Service does not natively support canary routing without additional traffic manager or feature flags. Option C is wrong because rolling update replaces instances one by one, which is not how Azure App Service deployment slots work; slots are swapped atomically, not instance-by-instance. Option D is wrong because blue-green deployment is the general pattern, but the question asks for the specific deployment strategy to use in Azure Pipelines with App Service slots, and the correct Azure-specific term is 'slot swap'.

Full explanation →
520
MCQhard

Refer to the exhibit. A developer runs 'git log --oneline --graph --decorate' and sees the output. Which Git workflow does this history most closely represent?

A.GitLab Flow
B.Trunk-based development
C.GitHub Flow
D.Git Flow
AnswerD

Git Flow explicitly uses feature branches cut from a development branch and merges them with `--no-ff` (no fast-forward) merge commits to preserve the feature branch context. This produces a non-linear history with multiple merge points and a visible branch structure, precisely matching the exhibit. That characteristic merge-commit topology is the definitive signature of Git Flow.

Why this answer

The output of `git log --oneline --graph --decorate` shows multiple long-lived branches (e.g., `develop`, `feature/*`, `release/*`, `hotfix/*`) with periodic merges back to `develop` and `main`. This branching structure with dedicated branches for features, releases, and hotfixes is the hallmark of Git Flow, which uses a strict branching model to manage releases and maintenance in parallel.

Exam trap

The trap here is that candidates see a graph with multiple branches and assume it represents GitHub Flow or trunk-based development, but the presence of both `develop` and `release` branches specifically indicates Git Flow, not simpler workflows.

How to eliminate wrong answers

Option A is wrong because GitLab Flow typically uses environment branches (e.g., `staging`, `production`) and feature branches that merge directly into `main`, not the multi-tiered `develop`/`release`/`hotfix` structure shown. Option B is wrong because trunk-based development keeps branches extremely short-lived (hours to a day) and merges directly to a single trunk (e.g., `main`), without long-lived `develop` or `release` branches. Option C is wrong because GitHub Flow uses a single `main` branch with short-lived feature branches that are merged via pull requests, lacking the `develop`, `release`, and `hotfix` branches visible in the graph.

Full explanation →
521
MCQeasy

You need to configure a release pipeline that deploys to Azure App Service. The deployment should use the 'slot swap' strategy to minimize downtime. Which deployment slot should you initially deploy to?

A.Production slot
B.Warmup slot
C.Staging slot
D.All slots simultaneously
AnswerC

Deploying to a Staging slot is the correct approach because it lets you validate the build and perform pre-production checks without impacting live traffic. Once verified, you perform a swap between the Staging and Production slots, which is an atomic operation that keeps the app continuously available and enables quick rollback by swapping again if needed.

Why this answer

The slot swap strategy in Azure App Service deploys to a non-production slot (typically 'staging') first, allowing validation before swapping with the production slot. This eliminates downtime by warming up the staging slot and then routing traffic to it via a zero-downtime swap operation. Deploying directly to production would cause downtime or require manual traffic management.

Exam trap

The trap here is that candidates may think 'Warmup slot' is a real Azure slot name due to the term 'warmup' being used in Azure App Service settings (like application initialization), but Azure only provides 'production' and 'staging' as default slots, and custom slots must be explicitly created.

How to eliminate wrong answers

Option A is wrong because deploying directly to the Production slot would cause downtime during the deployment process, as the app would be restarted or updated in-place, defeating the purpose of a slot swap strategy. Option B is wrong because 'Warmup slot' is not a standard Azure App Service slot name; Azure uses 'staging' as the default non-production slot, and warmup is a process (e.g., application initialization) not a slot. Option D is wrong because deploying to all slots simultaneously would overwrite production and staging at the same time, eliminating the ability to validate changes before swapping and potentially causing downtime or failed rollbacks.

Full explanation →
522
MCQmedium

Your team uses Azure DevOps and wants to automate the creation of work items when a build pipeline fails. The work item should be assigned to the last person who committed a change in the failed build. Which approach should you use?

A.Create a release pipeline that triggers on build failure and creates a work item.
B.Add the 'Create work item on failure' task to the build pipeline.
C.Configure a Service Hook to create a work item on build failure.
D.Use a PowerShell script in the pipeline to call Azure DevOps REST API.
AnswerB

The built-in 'Create work item on failure' task runs on build failure and automatically creates a work item, such as a bug, with the ability to assign it to the last committer. It is the intended, simplest solution because it requires no custom code, external service hooks, or additional Azure DevOps REST API calls.

Why this answer

The 'Create work item on failure' task in Azure DevOps build pipelines automatically creates a bug work item and assigns it to the last committer of the failed build. Option A is incorrect because release pipelines are meant for deployment, not build-time tasks. Option C is incorrect because while Service Hooks can trigger on build failure, they require additional custom logic to assign the work item to the last committer, making it less straightforward.

Option D is incorrect because using a PowerShell script to call the REST API is more complex and error-prone compared to the built-in task.

Full explanation →
523
MCQeasy

Your team uses Azure Pipelines to deploy to multiple environments. The compliance team requires that all deployments to the production environment are approved by a security officer. Which feature should you use?

A.Configure approvals and checks on the production environment in Azure Pipelines.
B.Create a branch policy that requires approval for pull requests.
C.Use a service connection with a managed identity that requires approval.
D.Store the production credentials in a variable group with approval required.
AnswerA

Approvals and checks in Azure Pipelines environments allow you to require manual sign-off and/or automated gates (e.g., Azure Monitor alerts) before any deployment job targeting that environment runs. This is the native mechanism to gate deployments to production, providing control and auditability without affecting source control or artifact release processes.

Why this answer

Approvals and checks in Azure Pipelines allow you to require manual approval before a deployment to a specific environment, such as production. By configuring an approval on the production environment, you ensure that a designated security officer must approve the deployment before it proceeds, meeting the compliance team's requirement.

Exam trap

The trap here is confusing environment-level approvals (which gate the deployment itself) with branch policies or secret management features, which address different compliance concerns like code review or credential access.

How to eliminate wrong answers

Option B is wrong because a branch policy that requires approval for pull requests controls code merging into a branch, not deployment approvals to an environment. Option C is wrong because a service connection with a managed identity handles authentication but does not enforce manual approval gates for deployments. Option D is wrong because storing production credentials in a variable group with approval required controls access to secrets, not the deployment approval process itself.

Full explanation →
524
MCQmedium

Your team uses Git for source control. A developer accidentally committed a large binary file (500 MB) to the main branch. The push succeeded but other team members are now complaining about slow fetch times. What is the most efficient way to remove the file from the repository history?

A.Use 'git filter-repo' to remove the file from history
B.Add the file to .gitignore and push again
C.Use 'git revert' to undo the commit
D.Use BFG Repo-Cleaner
AnswerA

git filter-repo is the official Git tool for history rewriting; it removes the file from every commit in the repository, thereby eliminating the sensitive data from all historical versions. It rewrites commit hashes and requires force-pushing to update remote references, but it is the recommended and safest approach for this task.

Why this answer

'git filter-repo' is the recommended modern tool for permanently removing large files from Git history. It rewrites the repository's commit graph, eliminating the file from all commits, which reduces repository size and resolves slow fetch times for team members. Unlike BFG Repo-Cleaner, 'git filter-repo' is actively maintained and integrates natively with Git, making it the most efficient and reliable choice for this task.

Exam trap

The trap here is that candidates often confuse 'git revert' (which only adds a new commit to undo changes) with history-rewriting tools like 'git filter-repo' or BFG, not realizing that only history rewriting permanently removes a file from all commits and reduces repository size.

How to eliminate wrong answers

Option B is wrong because adding the file to .gitignore only prevents future tracking of the file; it does not remove the file from existing commits, so the large binary file remains in the repository history and continues to bloat fetch times. Option C is wrong because 'git revert' creates a new commit that undoes the changes of the original commit, but the large binary file remains in the commit history, so the repository size is not reduced and slow fetch times persist. Option D is wrong because BFG Repo-Cleaner is a valid tool for removing large files from history, but it is less efficient than 'git filter-repo' for this specific scenario; BFG is a Java-based tool that requires additional setup and is not as tightly integrated with Git's internals, making 'git filter-repo' the preferred choice in modern Git workflows.

Full explanation →
525
MCQhard

You are a DevOps engineer for a large e-commerce company. The company uses Azure DevOps for CI/CD and Application Insights for monitoring. The application is a .NET Core 6 microservice running on Azure Kubernetes Service (AKS) with a Redis cache and Azure SQL Database. Recently, the operations team noticed that the application's response time has degraded significantly during peak traffic hours. Application Insights shows an increase in server-side dependency call duration to Redis and SQL, but no increase in exceptions. The team suspects a connection pooling issue. You have been asked to diagnose and fix the problem. Which approach should you take first?

A.Increase the number of AKS nodes to handle peak traffic and reduce resource contention.
B.Review the application code to ensure that Redis and SQL connections are properly opened and closed using 'using' statements.
C.Run a load test against the application to reproduce the issue and monitor system counters.
D.Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.
AnswerD

This approach uses telemetry to isolate the dependency (Redis vs SQL) that is causing the delay by comparing p50/p95/p99 call durations, and then lets you tune connection pool max sizes based on measured concurrency and latency, directly addressing the root cause.

Why this answer

The first step in diagnosing a connection pooling issue is to analyze the dependency performance data in Application Insights. The 'Dependency' blade provides detailed percentiles (e.g., P50, P95, P99) for Redis and SQL call durations, allowing you to pinpoint which dependency is the bottleneck. Once identified, you can adjust the connection pool size (e.g., Max Pool Size in SQL connection string or Redis multiplexer settings) to match the peak concurrency demands without overwhelming the database or cache.

Exam trap

The trap here is that candidates assume the issue is a code bug (Option B) or infrastructure scaling (Option A), but the question explicitly states no exceptions and a connection pooling suspicion, so the correct first diagnostic step is to analyze existing telemetry to confirm the bottleneck before making changes.

How to eliminate wrong answers

Option A is wrong because increasing AKS nodes addresses compute resource contention, not connection pooling issues; the problem is at the dependency layer (Redis/SQL), not node CPU/memory. Option B is wrong because while proper disposal of connections is important, the team already suspects a connection pooling issue (not leaked connections), and the code likely already uses 'using' statements in .NET Core 6; the fix is to tune pool sizes, not to fix leaks. Option C is wrong because running a load test to reproduce the issue is a valid step, but it should come after analyzing existing telemetry; Application Insights already has the data needed to identify the bottleneck, making a load test premature and potentially disruptive.

Full explanation →
Page 6

Page 7 of 10

Page 8

All pages

12345678910

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Design and implement source controlConfigure processes and communicationsDevelop a security and compliance planImplement an instrumentation strategyDesign and implement build and release pipelinesDesign and implement a source control strategy
See all domains with question counts →