Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 526–600 | Page 8/11

526

MCQeasy

You need to ensure that only authorized users can access the Azure DevOps organization. Which identity provider should you configure for single sign-on (SSO)?

A.Microsoft Entra ID

B.Google Workspace

C.Microsoft account (MSA)

D.GitHub ID

AnswerA

Microsoft Entra ID (formerly Azure AD) is the native identity provider for Azure DevOps, enabling enterprise-grade SSO, conditional access, and multi-factor authentication. It is the only supported option for centrally managing user permissions and access control across an Azure DevOps organization, making it the correct choice.

Why this answer

Microsoft Entra ID (formerly Azure AD) is the required identity provider for configuring single sign-on (SSO) for Azure DevOps organizations. Azure DevOps relies on Entra ID to authenticate users and enforce conditional access policies, ensuring only authorized identities from your tenant can sign in. This integration also supports SAML-based SSO and OAuth 2.0 flows, making it the native and only supported IdP for Azure DevOps SSO.

Exam trap

The trap here is that candidates may confuse personal Microsoft accounts (MSA) or external identity providers like Google Workspace as valid SSO options, but Azure DevOps SSO exclusively requires a Microsoft Entra ID tenant for organizational access control.

How to eliminate wrong answers

Option B (Google Workspace) is wrong because Azure DevOps does not support Google Workspace as a direct identity provider for SSO; it can only be used as an external identity source if federated through Microsoft Entra ID. Option C (Microsoft account, MSA) is wrong because MSAs are personal accounts and cannot be used for organizational SSO; Azure DevOps requires a tenant-backed identity for centralized access control and policy enforcement. Option D (GitHub ID) is wrong because GitHub IDs are used for GitHub authentication, not for Azure DevOps; while Azure DevOps and GitHub can be linked, SSO for the Azure DevOps organization itself must be configured via Microsoft Entra ID.

Full explanation →

527

MCQmedium

A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?

A.Copy the latest version of the code to a new Git repository and start fresh

B.Use the Git-TF tool to clone the TFVC repository

C.Use the git-tfs tool to clone the TFVC repository with changesets

D.Export TFVC as a Git bundle and import with --no-metadata

AnswerC

git-tfs is the standard community-maintained bridge that clones a TFVC repository by replaying each TFVC changeset into a corresponding Git commit, preserving the original author, timestamp, commit message, branch structure, and merge topology. It handles the TFVC-to-Git ID mapping and can also fetch shelvesets, making it the preferred tool for a full-fidelity migration. Because it reconstructs the entire commit graph rather than just copying files, it maintains the historical context needed for auditing, bisecting, and code review — which is exactly what the team needs when moving from TFVC to Git.

Why this answer

Git-tfs is a specialized bridge tool that converts TFVC changesets into Git commits, preserving the full history, author information, and branch structure during migration. Unlike Git-TF, which is deprecated and lacks support for newer TFVC features, git-tfs handles complex scenarios like merges and shelvesets, making it the recommended approach for preserving history when moving from TFVC to Git.

Exam trap

The trap here is that candidates confuse Git-TF with git-tfs, assuming both are equivalent, but Git-TF is deprecated and lacks branch support, while git-tfs is the actively maintained tool for full history preservation.

How to eliminate wrong answers

Option A is wrong because copying only the latest version discards all historical changesets, defeating the purpose of preserving history and losing audit trail and rollback capability. Option B is wrong because Git-TF (Git-TF) is a deprecated tool that does not support TFVC branches or shelvesets, and its last update was in 2015, making it unsuitable for modern TFVC repositories. Option D is wrong because TFVC does not natively support Git bundle export; the `--no-metadata` flag is irrelevant as TFVC changesets cannot be directly converted to Git bundles without a bridge tool like git-tfs.

Full explanation →

528

MCQeasy

You are designing a process for incident management. When a critical bug is reported, you need to automatically create a work item in Azure Boards and notify the on-call engineer via Microsoft Teams. Which Azure DevOps feature should you use?

A.Create a release pipeline that triggers on work item creation.

B.Set up a service hook that sends a message to Teams when a bug is created.

C.Configure a work item notification in Azure DevOps to email the on-call engineer.

D.Use a work item template to pre-populate the bug form.

AnswerB

Azure DevOps service hooks can subscribe to events such as 'work item created' and send an HTTP POST to a Teams connector or webhook. This immediately posts a message to a Teams channel when a bug is created, meeting the incident management requirement.

Why this answer

Service hooks are used to notify external systems (like Microsoft Teams) when an event occurs in Azure DevOps, such as a work item being created. They do not create the work item itself; they react to its creation. To automatically create the work item when a critical bug is reported, you would use a separate mechanism such as the Azure Boards REST API or an external integration.

Among the provided options, B is the correct feature for the Teams notification, but the explanation should clarify that the automated creation is handled outside the service hook.

Exam trap

The trap here is that candidates confuse 'work item notifications' (email-based) with 'service hooks' (webhook-based), assuming any notification feature can send to Teams, but only service hooks support direct integration with external chat systems like Teams or Slack.

How to eliminate wrong answers

Option A is wrong because a release pipeline triggers on code commits or build artifacts, not on work item creation, and is designed for deployment automation, not incident notification. Option C is wrong because work item notifications in Azure DevOps are limited to email alerts and cannot send messages to Microsoft Teams; they also require manual configuration per user and do not support dynamic on-call routing. Option D is wrong because a work item template only pre-populates fields in the bug form, it does not automate creation or notification; it is a static template, not a reactive automation mechanism.

Full explanation →

529

MCQmedium

Your team uses Azure Pipelines to build a .NET application. You notice that the build takes 15 minutes because of dependency restoration. You want to cache the NuGet packages to speed up subsequent builds. Which task should you add to your pipeline?

A.DownloadBuildArtifacts task

B.NuGet restore task with the 'noCache' option set to false

C.DotNetCoreCLI task with the 'restore' command

D.Cache task with a key based on the package lock file

AnswerD

The Cache task can cache NuGet packages based on the lock file hash, speeding up subsequent restores.

Why this answer

The Cache task (D) is the correct choice because it allows you to cache the NuGet packages folder (typically `~/.nuget/packages`) based on a key derived from the package lock file (e.g., `packages.lock.json`). This ensures that when the lock file hasn't changed, the cached packages are restored from the pipeline cache instead of being downloaded from the NuGet feed, significantly reducing build time. The key is computed from the lock file's content hash, so any change in dependencies automatically invalidates the cache.

Exam trap

The trap here is that candidates often confuse the NuGet local HTTP cache (controlled by the 'noCache' option) with the pipeline-level Cache task. The 'noCache' option only disables the HTTP cache on the local agent, but that cache persists across builds on that agent. It does not provide a distributed cache across different agents.

The pipeline Cache task caches files in Azure DevOps and restores them on any agent, which is why it's the correct approach for speeding up builds across runs.

How to eliminate wrong answers

Option A is wrong because the DownloadBuildArtifacts task is used to download build artifacts from a previous pipeline run, not to cache NuGet packages for dependency restoration. Option B is wrong because the NuGet restore task's 'noCache' option controls whether NuGet uses its local HTTP cache, not the pipeline-level cache; setting it to false does not introduce pipeline caching. Option C is wrong because the DotNetCoreCLI task with the 'restore' command performs a standard restore without any built-in caching mechanism; it would still download packages from the feed each time unless combined with a separate Cache task.

Full explanation →

530

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 →

531

Multi-Selecteasy

A company runs a critical microservices application on Azure Kubernetes Service (AKS). They need to implement distributed tracing across services using Application Insights. Which three actions should be performed?

Select 3 answers

A.Deploy the Application Insights agent as a DaemonSet on each AKS node

B.Use OpenTelemetry SDK with Application Insights exporter

C.Instrument each microservice with the Application Insights SDK

D.Set the same instrumentation key for all microservices

E.Enable Azure Monitor Container Insights on the AKS cluster

AnswersB, C, D

OpenTelemetry SDKs instrument application code to generate standardized distributed traces with context propagation, and the Application Insights exporter sends that telemetry to Azure Monitor, allowing end-to-end correlation and analysis across microservices.

Why this answer

Distributed tracing requires every microservice to emit trace data. This can be achieved by instrumenting each service with the Application Insights SDK (option C) or using OpenTelemetry SDK with the Application Insights exporter (option B). To ensure all spans from different services are correlated into a single distributed trace, all services must use the same instrumentation key so telemetry lands in the same Application Insights resource (option D).

Option A is incorrect because the Application Insights agent is not deployed as a DaemonSet for this purpose, and option E is incorrect because Container Insights is for infrastructure monitoring, not application-level distributed tracing.

Exam trap

The trap here is confusing infrastructure monitoring (Container Insights) with application-level distributed tracing, leading candidates to select options that collect metrics but fail to provide the cross-service correlation needed for distributed tracing.

Full explanation →

532

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 →

533

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 →

534

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 →

535

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 →

536

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 →

537

MCQmedium

Your team uses GitHub Actions for CI/CD. You need to enforce that all pull requests to the main branch pass a required status check that runs a security scan. The security scan is a GitHub Action that runs on pull_request events. However, the status check is not appearing as required in the branch protection rules. What should you do?

A.Add 'types: [opened, synchronize]' to the pull_request trigger.

B.Change the trigger from 'pull_request' to 'pull_request_target'.

C.Use a GitHub App instead of the default GITHUB_TOKEN for the action.

D.Ensure the workflow has a name that matches the status check name in the branch protection rule.

AnswerD

The status check name is based on the workflow name and job name. If the workflow name is different, the check won't match.

Why this answer

GitHub branch protection rules require the status check name to exactly match the workflow name (or the job name within the workflow) as it appears in the GitHub Actions UI. If the names do not match, the check will not appear as an option in the required status checks list. The security scan action runs on pull_request events, so the status check is generated, but the mismatch prevents it from being selectable as a required check.

Exam trap

The trap here is that candidates often focus on event triggers or authentication tokens, overlooking the simple but critical requirement that the status check name must exactly match the workflow or job name in the branch protection rule.

How to eliminate wrong answers

Option A is wrong because adding 'types: [opened, synchronize]' is the default behavior for pull_request triggers and does not affect the appearance of the status check in branch protection rules; the issue is a naming mismatch, not the event type. Option B is wrong because changing the trigger to 'pull_request_target' alters the security context (runs in the base branch context) but does not resolve the naming mismatch; it could introduce security risks if not carefully managed. Option C is wrong because using a GitHub App instead of GITHUB_TOKEN changes authentication but does not affect how the status check name is registered; the check name is derived from the workflow or job name, not the token used.

Full explanation →

538

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 →

539

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 →

540

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

Metrics-based gates are a key part of gated deployment.

Why this answer

Deployment gates in Azure Pipelines allow you to define pre-deployment or post-deployment conditions that evaluate external metrics (e.g., error rate from Azure Monitor, Application Insights, or other monitoring systems) before allowing the release to proceed to the next stage. This is a core mechanism for implementing a gated deployment strategy, as it automatically pauses the pipeline until the specified health criteria are met, ensuring that only healthy releases progress. Option E is correct because manual approval checks act as a human-driven gate, requiring explicit sign-off before a deployment proceeds to production, which is a common pattern in gated deployments to add oversight.

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 →

541

MCQhard

You are designing a release pipeline for a critical application. The pipeline must automatically roll back to the previous version if the deployment to staging fails health checks. Which deployment strategy should you implement?

A.Canary deployment with manual promotion.

B.Blue-green deployment with manual swap.

C.Recreate deployment by redeploying the same version.

D.Rolling update with health checks and automatic rollback.

AnswerD

Health checks trigger automatic rollback on failure.

Why this answer

A rolling update with health checks and automatic rollback is the only strategy that fully automates the deployment, validates health after each batch of pods is updated, and automatically reverts to the previous version if health checks fail. This meets the requirement for an automated rollback on staging health check failure without manual intervention.

Exam trap

The trap here is that candidates often confuse 'canary' or 'blue-green' with automatic rollback, but those strategies typically require manual promotion or swap, whereas rolling update with health checks and automatic rollback is the only option that fully automates the rollback process.

How to eliminate wrong answers

Option A is wrong because canary deployment with manual promotion requires a human to approve the promotion to full rollout, which violates the 'automatically roll back' requirement. Option B is wrong because blue-green deployment with manual swap requires a manual switch of traffic to the new environment, and while it can support rollback by swapping back, the manual step breaks the automatic rollback requirement. Option C is wrong because recreate deployment simply destroys all existing pods and creates new ones; it does not support health checks during deployment and cannot automatically roll back to a previous version if the new version fails.

Full explanation →

542

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 →

543

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 →

544

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 →

545

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 →

546

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 →

547

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

Post-deployment happens after deployment, not before.

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

Decorators are for injecting steps, not for approvals.

Full explanation →

548

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 →

549

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 →

550

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 →

551

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 →

552

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 →

553

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 →

554

Multi-Selecthard

Your GitHub organization has multiple repositories that share common CI/CD workflows. You want to centralize these workflows to reduce duplication. Which TWO approaches are valid?

Select 2 answers

A.Create reusable workflows in a central repository and use the 'uses' keyword in each repository's workflow to reference them.

B.Store the workflows in a central repository and use Git submodules to include them in each repository.

C.Create a template repository containing the workflows and use it as a template for new repositories.

D.Use branch protection rules to enforce that all workflows must be reviewed by a central team.

E.Publish the workflows as a GitHub Actions workflow library and install it in each repository.

AnswersA, C

Reusable workflows allow centralized maintenance.

Why this answer

GitHub Actions supports reusable workflows that can be stored in a central repository and referenced from other repositories using the 'uses' keyword with the syntax 'owner/repo/.github/workflows/workflow.yml@ref'. This allows teams to define common CI/CD logic once and invoke it across multiple repositories, reducing duplication and simplifying maintenance.

Exam trap

The trap here is that candidates may confuse Git submodules or template repositories as valid methods for sharing live, updatable workflows, when in fact only reusable workflows (Option A) and template repositories (Option C, for initial setup) are officially supported approaches for centralizing CI/CD workflows in GitHub Actions.

Full explanation →

555

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 →

556

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 →

557

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 →

558

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 →

559

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 →

560

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 →

561

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 →

562

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 →

563

Multi-Selectmedium

Your team uses Azure Pipelines to build a .NET application. You need to implement a secure build pipeline that meets the following requirements: - Secrets must be injected at build time without being exposed in logs or YAML files. - The build must use Microsoft-hosted agents. - All builds must be auditable. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Enable 'Allow scripts to access the OAuth token' on the agent job and use the token in scripts.

B.Use a variable group linked to Azure Key Vault to store secrets, and reference the variable group in the pipeline.

C.Store secrets as plain-text environment variables in the pipeline YAML file.

D.Use the 'Replace Tokens' task to substitute secrets from pipeline variables into configuration files.

E.Deploy a self-hosted agent on-premises to keep secrets within the corporate network.

AnswersB, D

A variable group linked to Azure Key Vault securely stores secrets outside the pipeline definition and injects them at runtime as masked variables. This approach avoids hardcoding secrets in YAML, leverages Key Vault's access policies and audit logs, and simplifies secret rotation by updating the vault without editing the pipeline.

Why this answer

To securely inject secrets without exposing them in logs or YAML, use a variable group linked to Azure Key Vault (B) to store secrets, and then use a token replacement task like Replace Tokens (D) to inject those secret variables into configuration files during the build. This avoids putting secrets in YAML, masks them in logs, and is auditable via Azure Key Vault and Azure DevOps audit logs. Option A, while the token is masked, is for Azure DevOps API access, not secret injection, and enabling it increases exposure risk.

Exam trap

The trap is confusing the OAuth token (System.AccessToken) with secret management. Although the OAuth token is masked, it is not a secret injection mechanism; it provides API access only. The correct approach combines Key Vault variable groups with token replacement tasks.

Full explanation →

564

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

It directly enforces the requirement for at least one approval before merging. 'Require a pull request before merging' must be enabled, and within that, 'Required approvals' should be set to 1. Option A (status checks) verifies CI passes, not approvals. Option B restricts who can push to branches, which is unrelated to approval requirements.

Option D (linear history) enforces a linear commit history but does not mandate approvals.

Full explanation →

565

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 →

566

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

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

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

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

Full explanation →

567

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 template references a parameter 'adminPassword' that is not defined in the parameters section. It must be declared as a parameter to be provided during deployment.

Full explanation →

568

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 →

569

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 →

570

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

Enforces at least two approvals.

Why this answer

The 'Require a minimum number of reviewers' policy enforces that a pull request must be approved by at least two reviewers before it can be completed. Option C is correct because the 'Check for linked work items' policy ensures that every pull request is associated with a work item, which satisfies the requirement that all work items must be linked to a pull request before merging.

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 →

571

Multi-Selecthard

Which TWO are best practices for securing Azure Pipelines? (Choose two.)

Select 2 answers

A.Use variable groups linked to Azure Key Vault for secrets.

B.Scope service connections to specific resource groups with 'Contributor' role.

C.Grant 'Administrator' role to all service connections for ease of management.

D.Store all pipeline variables in the YAML file as plain text.

E.Disable pipeline logging for all jobs.

AnswersA, B

Key Vault integration securely stores and retrieves secrets.

Why this answer

Variable groups linked to Azure Key Vault allow you to securely store and manage secrets (e.g., API keys, passwords) outside of pipeline definitions. Azure Pipelines retrieves these secrets at runtime via the Azure Key Vault REST API, ensuring they are never exposed in logs or YAML files. This follows the principle of least privilege and secrets management best practices.

Exam trap

The trap is thinking that scoping service connections to specific resource groups with 'Contributor' role is too permissive. While 'Contributor' is broader than a custom role, Microsoft recommends it for resource group-scoped connections because it provides the minimum permissions needed for most Azure DevOps tasks without overcomplicating management. The real risk is using overly broad scopes like subscriptions or 'Owner' roles, not 'Contributor' on specific resource groups.

Full explanation →

572

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 →

573

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 →

574

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 →

575

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 →

576

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 →

577

MCQhard

Your Azure DevOps organization has multiple projects. You need to ensure that only approved extension versions are installed across all projects. What is the most efficient way to enforce this?

A.Restrict extension usage to specific pipelines via YAML.

B.Use the Azure DevOps extension management settings to mark approved extensions and block others.

C.Create an Azure Policy that audits extension installations.

D.Uninstall all extensions and only install them per project as needed.

AnswerB

Organization administrators can use the built-in Extension management settings in the Azure DevOps admin UI to enable or disable specific extensions and control who can install them. Marking approved extensions and blocking others is the native governance mechanism for curating the extension catalog across all projects, making this the correct answer.

Why this answer

Azure DevOps provides extension management settings at the organization level where administrators can mark specific extensions as approved and block all others. This is the most efficient way to enforce approved extension versions across all projects. Option A is wrong because extensions cannot be restricted to specific pipelines via YAML; YAML can only reference tasks from installed extensions.

Option C is wrong because Azure Policy does not manage Azure DevOps extensions; it manages Azure resources. Option D is wrong because uninstalling extensions per project is inefficient and does not enforce approved versions globally.

Full explanation →

578

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 →

579

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 →

580

MCQeasy

Your team uses GitHub and wants to automatically detect exposed credentials in code. Which GitHub feature should you enable?

A.Dependabot alerts

B.GitHub Copilot

C.Code scanning

D.Secret scanning

AnswerD

Secret scanning automatically scans repositories for known patterns of secrets such as Expo access tokens, GitHub tokens, AWS keys, and connection strings, and alerts owners when a secret is detected. It can also block pushes containing secrets, making it the correct feature for detecting Expo secrets.

Why this answer

Secret scanning is the correct answer because it is the GitHub feature specifically designed to automatically detect exposed credentials, such as API keys, tokens, and passwords, in code repositories. It scans for known patterns of secrets and can alert both the repository owner and the partner service (e.g., AWS, Azure) to revoke the compromised credential. This directly addresses the requirement to automatically detect exposed credentials in code.

Exam trap

The trap here is that candidates often confuse Code scanning (which finds code vulnerabilities) with Secret scanning (which finds credentials), but Azure and GitHub treat them as separate features with distinct purposes and detection mechanisms.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts focus on vulnerable dependencies and outdated packages, not on detecting exposed credentials or secrets in code. Option B is wrong because GitHub Copilot is an AI-powered code completion tool that suggests code snippets, not a security scanning feature for detecting credentials. Option C is wrong because Code scanning (powered by CodeQL) identifies code quality issues and security vulnerabilities like SQL injection or cross-site scripting, but it does not natively scan for hardcoded secrets or credentials; secret scanning is a separate, dedicated feature.

Full explanation →

581

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 swap swaps all settings, so if staging settings are not suited for production, the site can become unresponsive.

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 →

582

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 →

583

MCQmedium

Refer to the exhibit. You run an ARM template deployment and get the error shown. What is the most likely cause?

A.The template references a resource that already exists and conflicts with the deployment.

B.The deployment name already exists in the resource group.

C.The resource group location does not match the template location.

D.The template has a syntax error in the JSON.

AnswerA

During resource provisioning, Azure Resource Manager attempts to create the resource defined in the template. If a resource of the same name already exists in the target resource group and the deployment is not able to reconcile it as an idempotent update, ARM returns an 'InvalidTemplateDeployment' error with an inner error, such as the user 'adminuser' already exists. This indicates the template itself is valid and passed parsing; the failure occurs at the resource creation step because the named resource conflicts with an existing object in the environment.

Why this answer

The error details show a Conflict with message 'User 'adminuser' already exists in this resource group.' This indicates the template tries to create a resource that already exists, causing a conflict.

Full explanation →

584

MCQmedium

You work for a multinational company that uses Azure Repos. The compliance team requires that all code changes include a work item reference in the commit message. What is the most effective way to enforce this?

A.Create a script in the build pipeline that checks the commit message

B.Configure a client-side commit hook that validates the commit message

C.Set a branch policy that requires a linked work item for pull requests

D.Use a custom build task to automatically add the work item ID to the commit message

AnswerC

Branch policies enforce the requirement server-side before merge.

Why this answer

A branch policy in Azure Repos that requires linked work items for pull requests enforces the compliance requirement at the server side, ensuring that every pull request merge includes a work item reference. This policy is enforced before the merge completes, making it a reliable and auditable method that cannot be bypassed by individual developers. It directly integrates with Azure Boards to validate the link, providing a centralized enforcement mechanism.

Exam trap

The trap here is that candidates often confuse client-side hooks (Option B) with server-side enforcement, not realizing that client-side hooks are optional and can be easily bypassed, whereas branch policies in Azure Repos provide mandatory, centralized enforcement that cannot be overridden by individual developers.

How to eliminate wrong answers

Option A is wrong because a build pipeline script that checks the commit message runs after the code is already pushed, meaning it can only fail the build but cannot prevent non-compliant commits from entering the repository; it also adds overhead and can be bypassed if the build is skipped. Option B is wrong because a client-side commit hook is only enforced locally on the developer's machine and can be easily disabled or bypassed by the developer, providing no centralized or reliable enforcement for the team. Option D is wrong because a custom build task that automatically adds a work item ID to the commit message does not enforce the requirement; it modifies the commit after the fact, which is not a valid approach for commit messages (which are immutable once created), and it does not ensure that the developer actually references a work item.

Full explanation →

585

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 →

586

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 →

587

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

Setting a unique Correlation ID in pipeline variables and passing it as a span attribute to OpenTelemetry allows end-to-end traceability by linking pipeline events with application telemetry. Option A is incorrect because Application Insights can ingest pipeline telemetry, but that alone does not correlate with application telemetry; you need a shared correlation ID. Option B is wrong because storing pipeline logs in Log Analytics and querying with metrics does not provide real-time correlation at the span level.

Option C is incorrect because deployment gates based on application metrics do not create correlation; they only block deployments based on conditions.

Full explanation →

588

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 →

589

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 →

590

MCQeasy

Your organization uses Azure DevOps and GitHub. You need to ensure that secrets such as API keys are not exposed in pipeline logs. What should you do?

A.Store the API key in a plain text variable and reference it as $(apiKey)

B.Store the API key in Azure Key Vault and use a variable group linked to the vault

C.Store the API key in a secret variable

D.Use the Logging Command to suppress output

AnswerB, C

Azure Key Vault integration is a valid way to store secrets, but it requires creating a variable group, linking it to the vault, and configuring a service connection with appropriate Key Vault access policies. This approach works but is heavier-weight than a simple secret variable and still requires the pipeline to reference the secret explicitly, so it is not the most direct secure option.

Why this answer

Both secret variables and variable groups linked to Azure Key Vault are masked in pipeline logs. Azure Pipelines automatically masks secret variables, and variables from Key Vault variable groups are also treated as secrets. Therefore, both B and C prevent exposure.

The question asks 'what should you do?' without requiring a single best method, so both B and C should be considered correct.

Full explanation →

591

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 →

592

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 →

593

MCQeasy

Your team is using GitHub Enterprise and wants to ensure that every pull request includes a link to a work item in Azure Boards. Which GitHub Apps or Azure DevOps Services integration should you configure?

A.GitHub-Azure Boards integration

B.Azure Repos branch policy

C.Azure DevOps OAuth app

D.Azure Pipelines GitHub App

AnswerA

The GitHub-Azure Boards integration creates a bi-directional link between GitHub commits, pull requests, and issues and Azure Boards work items, and it allows you to enforce work item linking in GitHub PRs by adding a required check or branch protection rule that verifies every PR references a work item.

Why this answer

The GitHub-Azure Boards integration is the correct choice because it connects GitHub repositories to Azure Boards, automatically linking commits and pull requests to work items when they mention an Azure Boards ID (e.g., 'AB#1234'). However, it does not enforce that every PR must include such a link. To enforce this, you would need an additional validation tool or branch protection rule, but among the given options, this is the only integration that provides the linking capability.

Exam trap

The trap here is that candidates might confuse the GitHub-Azure Boards integration with Azure Repos branch policies, assuming any branch policy can enforce work item linking, but branch policies only apply within Azure Repos, not GitHub Enterprise.

How to eliminate wrong answers

Option B is wrong because Azure Repos branch policies are used to enforce rules like required reviewers or status checks within Azure Repos, not GitHub Enterprise, and they cannot enforce work item linking across GitHub and Azure Boards. Option C is wrong because the Azure DevOps OAuth app provides authentication for API access but does not enforce or validate work item links in pull requests. Option D is wrong because the Azure Pipelines GitHub App integrates CI/CD pipelines with GitHub but does not manage work item linking or enforce pull request content requirements.

Full explanation →

594

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 →

595

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

This provides granular control over allowed actions.

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 →

596

Multi-Selecthard

Which THREE options are valid strategies to reduce build times in Azure Pipelines? (Choose three.)

Select 3 answers

A.Enable incremental builds by using the 'Clean: false' option.

B.Use a self-hosted agent with a local cache of dependencies.

C.Break the pipeline into multiple stages running sequentially.

D.Increase the number of parallel jobs in the pipeline.

E.Use the 'Cache' task to cache folders like node_modules or .m2.

AnswersA, B, E

Setting 'Clean: false' preserves outputs from the previous build so the incremental compiler can skip unchanged projects and only recompile modified code, dramatically shortening build time for large solutions by avoiding full rebuilds.

Why this answer

Setting 'Clean: false' enables incremental builds by retaining the workspace from the previous run. This means only changed files are rebuilt, significantly reducing build time by avoiding a full clean checkout and rebuild of unchanged code.

Exam trap

The trap here is that candidates confuse parallelism (multiple jobs) with build acceleration for a single pipeline, or assume sequential stages reduce time when they actually add overhead.

Full explanation →

597

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 steps to the numbered slots on the right, or tap a step then tap a slot.

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 →

598

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 →

599

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 →

600

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

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

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

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

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 526–600