Knowledge + Practice

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

913 questions total · 13pages · All types, answers revealed

Take a mock exam Exam hub

Page 8 of 13

526

MCQhard

Your organization uses GitHub and wants to implement a policy that requires all pull requests to be approved by at least two members of the 'security-team' team before merging. The 'security-team' team is a child team of 'engineering'. Which branch protection rule setting should you use?

A.Enable 'Dismiss stale pull request approvals when new commits are pushed'.

B.Use the 'Require pull request reviews before merging' rule and set 'Required reviewers' to the security team.

C.Require a minimum number of reviewers and set it to 2.

D.Require code owner review and add the security team as code owners.

AnswerB

This enforces approval from two members of the specified team.

Why this answer

Option D is correct because the 'Require pull request reviews before merging' rule with 'Required reviewers' set to the team slug 'security-team' enforces approval from two members of that specific team. Option A (Require code owner review) would require a CODEOWNERS file and only enforce from listed owners. Option B (Dismiss stale reviews) is unrelated.

Option C (Restrict who can dismiss reviews) does not set the reviewer requirement.

Full explanation →

527

MCQhard

Refer to the exhibit. An Azure CLI command outputs the configuration of an Azure Web App. Your pipeline deploys to this Web App using the 'AzureWebApp@1' task. The deployment fails with an error indicating that the runtime stack is not supported. What is the most likely cause?

A.The Web App is not a Linux app.

B.The ASPNETCORE_ENVIRONMENT setting is incorrect.

C.The runtime stack (DOTNETCORE|6.0) is not compatible with the deployed application.

D.The resource group name is incorrect.

AnswerC

If the application targets a different runtime version, the deployment fails.

Why this answer

The exhibit shows 'linuxFxVersion': 'DOTNETCORE|6.0', which indicates the runtime stack. If the task expects a different stack (e.g., .NET 8), it may fail. Option A is wrong because the app setting is correct.

Option C is wrong because the resource group is correct. Option D is wrong because the kind shows Linux, which is supported.

Full explanation →

528

MCQhard

You are troubleshooting a release pipeline that deploys an ARM template to Azure. The deployment fails with the error 'The subscription '...' could not be found.' The service connection used has Contributor permissions on the subscription. The pipeline runs successfully from the Azure DevOps portal when triggered manually. What is the likely cause?

A.The service principal used by the service connection is not authorized in the subscription.

B.The service connection does not have sufficient permissions.

C.The subscription has been deleted.

D.The deployment is targeting a resource group in a different region.

AnswerA

The service principal might have been removed or the connection is misconfigured.

Why this answer

Option C is correct because the pipeline might be using a service principal that is not authorized in the subscription when running from a specific context (e.g., a different tenant or using a managed identity). Option A is wrong because manual triggers would also fail if the subscription didn't exist. Option B is wrong because Contributor role is sufficient for ARM deployments.

Option D is wrong because the issue is not about resource group location.

Full explanation →

529

Multi-Selectmedium

Which TWO are true about Azure Pipelines YAML templates? (Choose two.)

Select 2 answers

A.Templates must be stored in the same repository as the main pipeline.

B.Template expressions are evaluated at compile time.

C.Templates require parameters to be defined.

D.Templates can be nested by including other templates.

E.Templates can only define a single job.

AnswersB, D

Expressions like '${{ variables.var }}' are evaluated before runtime.

Why this answer

Option B is correct because template expressions in Azure Pipelines YAML are evaluated at compile time, before the pipeline runs. This allows the template to inject variables, conditions, and other logic into the pipeline definition statically, ensuring that the final pipeline structure is fully resolved before execution begins.

Exam trap

The trap here is that candidates often confuse compile-time evaluation with runtime evaluation, leading them to think template expressions can use runtime variables, or they mistakenly believe templates must be in the same repo or require parameters, when in fact templates are flexible and optional in their structure.

Full explanation →

530

MCQhard

Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?

A.Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.

B.Use GitHub branch protection rules to require pull request reviews from release managers on main.

C.Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.

D.Require a successful build for all branches and set the build pipeline to only run for release manager commits.

AnswerA

This allows only release managers to create pull requests into main, enforcing the desired control.

Why this answer

Option C is correct because branch policies in Azure Repos can restrict who can push or merge to a branch, and you can set different policies for main and develop. Option A is incorrect because restricting all users except release managers from creating pull requests into main is not sufficient if developers can push directly. Option B is incorrect because branch protection is a GitHub concept, not Azure Repos.

Option D is incorrect because requiring a successful build is good practice but does not restrict who can merge.

Full explanation →

531

MCQmedium

You need to implement a build retention policy that automatically deletes old builds after 30 days, but keeps the latest 5 builds regardless of age. Which configuration should you use?

A.Set 'Number of days to keep runs' to 30 and 'Number of runs to keep' to 5

B.Set 'Maximum retention policy' to 30 days and 'Number of builds to retain' to 5

C.Set 'Days to keep builds' to 30 and 'Minimum number of builds to keep' to 5

D.Set 'Number of days to keep artifacts' to 30 and 'Number of artifacts to keep' to 5

AnswerC

Deletes builds older than 30 days but keeps at least 5.

Why this answer

Option A is correct because in Azure Pipelines retention policy, you set 'Days to keep builds' to 30 and 'Minimum number of builds to keep' to 5. Option B is wrong because 'Maximum retention policy' is not a setting. Option C is wrong because 'Number of days to keep artifacts' is separate from builds.

Option D is wrong because 'Number of days to keep runs' is for GitHub Actions.

Full explanation →

532

MCQeasy

Your organization is adopting DevSecOps and wants to integrate security scanning into the CI/CD pipeline. Which tool should you use to scan container images for vulnerabilities?

A.Azure Monitor

B.GitHub Copilot

C.Microsoft Defender for Cloud

D.Azure Logic Apps

AnswerC

Defender for Cloud includes vulnerability scanning for container images.

Why this answer

Option A is correct because Microsoft Defender for Cloud can scan container images in Azure Container Registry. Option B is wrong because GitHub Copilot is an AI pair programmer. Option C is wrong because Azure Monitor is for observability.

Option D is wrong because Azure Logic Apps is for workflows.

Full explanation →

533

Multi-Selectmedium

Which THREE of the following are prerequisites for implementing a CI/CD pipeline for a .NET Core application?

Select 3 answers

A.Build agent (Microsoft-hosted or self-hosted)

B.Source control repository (e.g., Git)

C.Unit test framework

D.Docker container registry

E.Target deployment environment (e.g., App Service)

AnswersA, B, E

A build agent executes the pipeline tasks.

Why this answer

A build agent is required to execute the pipeline tasks, such as compiling code, running tests, and packaging artifacts. Microsoft-hosted agents provide a pre-configured environment with common tools, while self-hosted agents allow custom configurations and access to on-premises resources. Without a build agent, the CI/CD pipeline cannot perform any automated build or deployment steps.

Exam trap

The trap here is that candidates often mistake optional pipeline components (like unit tests or container registries) as prerequisites, when in fact only the core infrastructure (agent, source control, and target environment) is mandatory for a basic CI/CD pipeline.

Full explanation →

534

Multi-Selecthard

You are designing a release pipeline for a .NET Core application that must comply with regulatory requirements. The pipeline must sign the assembly with a code-signing certificate stored in Azure Key Vault. Which THREE actions should you perform?

Select 3 answers

A.Add a step to download the certificate from Key Vault using the AzureKeyVault task.

B.Use a script task to invoke the signing tool (e.g., signtool.exe) after the build.

C.Grant the Azure Pipelines service principal access to the Key Vault.

D.Store the certificate in a secure file in the build artifact.

E.Package the application before signing to avoid signature corruption.

AnswersA, B, C

The task retrieves the certificate securely.

Why this answer

Option A, Option C, and Option D are correct. The pipeline needs access to the certificate via a service connection, and the signing tool must run after the build. Option B is wrong because the certificate should be kept in Key Vault, not the build artifact.

Option E is wrong because signing should happen before packaging.

Full explanation →

535

MCQmedium

Your team uses Azure DevOps for CI/CD. You want to ensure that only code from the main branch is deployed to production. The release pipeline has a pre-deployment condition that requires approval. However, you notice that a release created from a feature branch was approved and deployed. What is the most likely cause?

A.The deployment queue settings were set to 'Deploy all in parallel'.

B.The pre-deployment condition did not include a branch filter on the artifact.

C.The artifact was published from a build pipeline that allowed any branch.

D.The pre-deployment condition was set to 'After release' instead of 'Before deployment'.

AnswerB

Branch filters must be configured on the artifact trigger or pre-deployment condition to restrict branches.

Why this answer

Option C is correct because if the pre-deployment condition 'Require approval from a specific number of approvers' is not configured to check the artifact branch, any branch can be approved. Option A is wrong because branch filters on the artifact are the correct way to restrict, but they must be set on the trigger, not the condition. Option B is wrong because the deployment queue settings do not affect branch filtering.

Option D is wrong because the artifact source itself does not enforce branch restrictions; that is done via filters.

Full explanation →

536

MCQmedium

A developer pushes a commit to a branch named 'releases/v1.0'. What will happen?

A.The pipeline runs but fails because the branch name contains a dot.

B.The pipeline runs only if a pull request is created.

C.The pipeline runs automatically on the push.

D.The pipeline does not run because the branch is not main.

AnswerC

The branch matches the trigger pattern.

Why this answer

Option C is correct because Azure Pipelines, by default, triggers a pipeline run automatically on any push to any branch unless a trigger filter is explicitly configured. The branch name 'releases/v1.0' is valid and does not contain any characters that would prevent a trigger; dots are allowed in branch names. The pipeline will execute the steps defined in the YAML file for that branch.

Exam trap

The trap here is that candidates may assume branch names with dots are invalid or that pipelines only run on the main branch, but Azure Pipelines treats all branches equally by default and dots are perfectly valid in Git branch names.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not restrict branch names containing dots; dots are valid characters in Git branch names and do not cause pipeline failures. Option B is wrong because a push to a branch triggers the pipeline automatically by default, regardless of whether a pull request is created; pull request triggers are a separate configuration. Option D is wrong because Azure Pipelines does not require the branch to be 'main' to run; pipelines can be configured to trigger on any branch, and by default they trigger on all branches.

Full explanation →

537

MCQeasy

You are designing a build pipeline for a Python application that uses multiple external packages from PyPI. You want to ensure that builds are reproducible and not affected by package updates. Which strategy should you use?

A.Use a Pipfile and Pipfile.lock without version pinning.

B.Use a dependency update tool like Dependabot weekly.

C.Pin exact versions in requirements.txt.

D.Use 'pip install <package>' without version specifiers.

AnswerC

Pinning exact versions ensures reproducibility.

Why this answer

Option C is correct because using a requirements.txt with pinned versions ensures exact package versions are installed. Option A is wrong because it suggests using latest, which breaks reproducibility. Option B is wrong because it only uses lock file but without version pinning.

Option D is wrong because it only updates lock file periodically, still allowing variability.

Full explanation →

538

MCQmedium

Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?

A.Define a standard workflow in .github/workflows/build.yml

B.Use a composite action to encapsulate the build steps

C.Create a custom action and reference it in multiple workflows

D.Define a reusable workflow with 'on: workflow_call'

AnswerD

Reusable workflows can be called from other workflows.

Why this answer

Option D is correct because reusable workflows are defined in a separate file with workflow_call trigger. Option A is wrong because it defines a workflow that cannot be reused. Option B is wrong because actions are different from workflows.

Option C is wrong because composite actions are for multiple steps, not entire workflows.

Full explanation →

539

MCQhard

You are reviewing a Data Collection Rule (DCR) for an Azure virtual machine. The DCR is assigned to the VM, and the Azure Monitor Agent is installed. After one hour, no performance data appears in the Log Analytics workspace. What is the most likely cause?

A.The workspace resource ID is incorrectly formatted.

B.The data flow streams property does not include 'Microsoft-Perf'.

C.The counter specifier uses the wrong format for Windows performance counters.

D.The sampling frequency of 60 seconds is too low and data is being throttled.

AnswerB

Performance counters require the 'Microsoft-Perf' stream in the data flow.

Why this answer

The most likely cause is that the data flow streams property in the DCR does not include 'Microsoft-Perf'. The Azure Monitor Agent uses DCRs to define which data to collect and where to send it. Without the 'Microsoft-Perf' stream specified in the dataFlows section, performance counters are not collected, even if the counter specifiers are correctly defined.

The workspace resource ID and counter format may be correct, but the missing stream prevents any performance data from being ingested.

Exam trap

The trap here is that candidates focus on the counter specifier format or sampling frequency, overlooking the critical data flow stream property which is the actual pipeline that enables data ingestion.

How to eliminate wrong answers

Option A is wrong because an incorrectly formatted workspace resource ID would typically cause a configuration error or a failure to connect, not a silent absence of data after one hour; the agent would log an error. Option B is wrong because it is actually the correct answer, not a wrong option. Option C is wrong because the counter specifier format (e.g., '\Processor(_Total)\% Processor Time' for Windows) is validated at DCR creation time, and an incorrect format would result in a schema validation error, not a one-hour delay with no data.

Option D is wrong because a sampling frequency of 60 seconds is standard and not too low; Azure Monitor does not throttle data based on sampling frequency, and throttling would affect all data types, not just performance counters.

Full explanation →

540

MCQmedium

Refer to the exhibit. You have this YAML pipeline in an Azure Repos repository. What is the expected behavior when a pull request is created from a feature branch to the main branch?

A.The pipeline runs twice: once on PR creation and once on merge.

B.The pipeline runs automatically on the PR to main, triggered by the pr trigger.

C.The pipeline runs when the PR is merged to main, triggered by the trigger block.

D.The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.

AnswerD

No automatic trigger for PRs to main; the pr trigger is only for develop.

Why this answer

Option D is correct because the YAML pipeline shown does not include a `pr` trigger, and the `trigger` block only applies to CI (continuous integration) builds on branch pushes, not pull requests. Without a `pr` trigger, Azure Pipelines does not automatically run on pull request creation; it must be triggered manually or via a branch policy configured in the repository settings.

Exam trap

The trap here is that candidates often assume the `trigger` block also applies to pull requests, but in Azure Pipelines, `trigger` and `pr` are separate, and omitting `pr` means no automatic PR build occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not have a `pr` trigger, so it will not run on PR creation, and the `trigger` block only triggers on merges to main, not on PR creation. Option B is wrong because the `pr` trigger is not defined in the YAML; without it, Azure Pipelines does not automatically run on PRs to main. Option C is wrong because while the `trigger` block would cause the pipeline to run on a merge to main, the question asks about behavior when a PR is created, not when it is merged.

Full explanation →

541

MCQmedium

Your organization uses Microsoft Purview Data Loss Prevention (DLP) to protect sensitive data in Azure DevOps repositories. The compliance team has identified that source code containing credit card numbers (PCI data) was accidentally committed to a public repository. You need to implement a solution that meets the following requirements: (1) Automatically scan all new commits in Azure Repos for sensitive data types like credit card numbers. (2) If sensitive data is detected, automatically block the push and notify the security team. (3) The solution must be integrated with Microsoft Purview and Azure DevOps. Option A: Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit. Option B: Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data. Option C: Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team. Option D: Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes. Which option is the most appropriate and efficient?

A.Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data

B.Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit

C.Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes

D.Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team

AnswerA

This is the native Microsoft solution that meets all requirements.

Why this answer

Option B is correct. Microsoft Purview DLP for Azure DevOps (in preview/GA) provides native scanning and blocking of sensitive data in commits. Option A is complex and not native.

Option C is for GitHub, not Azure Repos. Option D might not be native and may not integrate with Purview.

Full explanation →

542

MCQhard

Your team uses Azure Boards with a custom process. You need to ensure that when a bug is closed, it automatically triggers a new release pipeline. Which approach should you use?

A.Configure a CI trigger in the release pipeline.

B.Add a release gate that checks for closed bugs.

C.Create an Azure Function that polls work items.

D.Set up a Service Hook from Azure Boards to Azure Pipelines.

AnswerD

Service Hooks can trigger a release on work item state change.

Why this answer

Service Hooks in Azure DevOps allow you to integrate Azure Boards with Azure Pipelines by subscribing to events like 'work item updated' or 'work item state changed'. When a bug is closed (state changed to 'Closed'), a Service Hook can automatically trigger a release pipeline, enabling event-driven automation without polling or custom code. This is the correct approach because it directly connects the work item state change to pipeline execution.

Exam trap

The trap here is that candidates often confuse CI triggers (which respond to code changes) with event-driven triggers from work items, or mistakenly think release gates can initiate pipelines rather than just gate ongoing releases.

How to eliminate wrong answers

Option A is wrong because a CI trigger in a release pipeline is designed to fire on code changes (e.g., a commit or pull request merge), not on work item state changes in Azure Boards. Option B is wrong because release gates are conditions evaluated during a release (e.g., checking for approvals or quality metrics), not triggers that initiate a new release; they cannot start a pipeline based on a work item being closed. Option C is wrong because creating an Azure Function to poll work items introduces unnecessary complexity, latency, and overhead compared to the native event-driven Service Hook mechanism, which is simpler and more reliable.

Full explanation →

543

MCQhard

Your company uses Microsoft Defender for Cloud to monitor Azure DevOps environments. You receive an alert that a service principal has excessive permissions. What is the first step you should take to investigate and remediate?

A.Reduce the service principal's permissions to the minimum required.

B.Review the Microsoft Entra ID audit logs for the service principal.

C.Immediately delete the service principal.

D.Reset the service principal's credentials.

AnswerB

Audit logs provide details on permissions and usage.

Why this answer

Option B is correct because reviewing the Entra ID audit logs helps understand the scope of permissions and actions taken. Option A is wrong because resetting credentials immediately might lock out legitimate users without investigation. Option C is wrong because deleting the service principal could break dependencies.

Option D is wrong because you need to investigate before adjusting permissions.

Full explanation →

544

MCQeasy

You are reviewing an Azure Policy definition applied to an Azure DevOps organization. What is the effect of this policy?

A.It denies creation of any Azure resource

B.It allows creation of all pipelines

C.It denies creation of new pipelines

D.It audits pipeline creation without blocking

AnswerC

The policy rule denies when the type is Microsoft.DevOps/pipelines.

Why this answer

Option B is correct because the policy denies the creation of new pipelines. Option A is wrong because it allows creation. Option C is wrong because it denies all resource creation, not just pipelines.

Option D is wrong because it does not audit.

Full explanation →

545

MCQhard

You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?

A.Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.

B.Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.

C.Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.

D.Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.

AnswerB

Container Insights provides integrated log and metric collection with querying via KQL.

Why this answer

Container Insights in Azure Monitor is the best solution because it natively collects stdout/stderr logs from AKS containers and correlates them with performance metrics (CPU, memory, disk, network) in a single Log Analytics workspace. This enables the operations team to query logs across all microservices using KQL and join them with metrics for end-to-end troubleshooting, without additional infrastructure or data movement.

Exam trap

The trap here is that candidates often confuse Application Insights (designed for application-level telemetry) with Container Insights (designed for container-level logs and metrics), leading them to choose Option D, which lacks the native AKS metric correlation and Log Analytics workspace integration required for centralized querying.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is a cold storage tier with no native query capability for JSON logs; Storage Analytics provides only storage metrics, not log search or correlation with application performance metrics. Option C is wrong because streaming logs to Event Hubs and then to Azure Data Explorer adds unnecessary complexity and latency; while ADX is a powerful analytics engine, it is not the integrated, out-of-the-box solution for AKS log and metric correlation that Container Insights provides. Option D is wrong because the Application Insights agent as a DaemonSet sends logs directly to Application Insights, which is designed for application-level telemetry (traces, exceptions, requests) rather than container stdout/stderr logs and AKS node/container metrics; it lacks the native integration with AKS cluster-level metrics and Log Analytics workspace that Container Insights offers.

Full explanation →

546

MCQmedium

Your team uses GitHub and wants to prevent direct pushes to the main branch. Only pull requests with at least one approval should be allowed to merge. Which GitHub feature should you use?

A.Repository rulesets

B.Branch protection rules

C.CODEOWNERS file

D.GitHub Actions

AnswerB

Branch protection rules can require pull request reviews and block direct pushes.

Why this answer

Branch protection rules are the correct GitHub feature to enforce that direct pushes to the main branch are blocked and that only pull requests with at least one approval can merge. This is configured under the repository's Settings > Branches, where you can require pull request reviews before merging and restrict who can push directly.

Exam trap

The trap here is that candidates often confuse CODEOWNERS (which only requests reviews) with branch protection rules (which enforce mandatory reviews and block direct pushes), leading them to pick the wrong option when the question explicitly requires enforcement.

How to eliminate wrong answers

Option A is wrong because repository rulesets (a newer GitHub feature) can enforce similar restrictions but are designed for more granular, organization-wide policy management and are not the classic, straightforward solution for branch-specific push and PR approval requirements. Option C is wrong because the CODEOWNERS file defines individuals or teams that are automatically requested for review when certain files are changed, but it does not block direct pushes or enforce approval requirements. Option D is wrong because GitHub Actions is a CI/CD automation platform for workflows like testing and deployment, not a mechanism to enforce branch policies or merge requirements.

Full explanation →

547

Multi-Selectmedium

Which THREE of the following are valid techniques to reduce the volume of telemetry data sent to Application Insights while preserving diagnostic value?

Select 3 answers

A.Aggregate telemetry into 1-minute buckets before sending

B.Configure fixed-rate sampling

C.Enable adaptive sampling

D.Set a maximum telemetry throughput limit on the Application Insights instance

E.Use ITelemetryProcessor to filter out low-importance telemetry

AnswersB, C, E

Keeps only a percentage of telemetry.

Why this answer

Option B is correct because fixed-rate sampling in Application Insights randomly selects a percentage of telemetry items to send, reducing volume predictably while preserving a representative sample for diagnostics. This technique is ideal when you need consistent, controllable data reduction without losing the ability to detect trends and anomalies across all telemetry types.

Exam trap

The trap here is that candidates often confuse aggregation (Option A) with sampling, not realizing that Application Insights does not natively support pre-send aggregation and that aggregation destroys the per-event diagnostic context needed for root-cause analysis.

Full explanation →

548

MCQmedium

Refer to the exhibit. An Azure DevOps pipeline has the YAML configuration shown. A developer creates a pull request from a feature branch to the develop branch. What will happen?

A.The pipeline runs only if the PR is merged

B.The pipeline runs as a CI build on the feature branch

C.The pipeline runs as a PR validation build

D.The pipeline does not run automatically

AnswerD

Neither CI nor PR triggers match.

Why this answer

Option C is correct. The pipeline trigger includes develop branch, but the pr trigger only includes main. Since the PR target is develop (not main), the pr trigger does not fire.

The CI trigger fires on push to develop, but the PR is from feature to develop, so the CI trigger (on push to develop) would run only after the PR is merged. Option A is wrong because the PR trigger is for main only. Option B is wrong because the CI trigger is for main and develop, but the PR push is not to develop directly.

Option D is wrong because the pipeline does not run.

Full explanation →

549

MCQeasy

Your team uses Azure Pipelines and wants to ensure that builds cannot access the internet to prevent data exfiltration. What should you do?

A.Create a private agent pool with no internet access

B.Use Microsoft-hosted agents with network isolation

C.Set the pipeline variable 'DisableInternetAccess' to true

D.Use self-hosted agents on an isolated network

AnswerB

Microsoft-hosted agents can be configured for network isolation.

Why this answer

Option C is correct because Microsoft-hosted agents have network isolation capabilities. Option A is wrong because self-hosted agents with no internet access would work, but the question implies using Azure DevOps hosted. Option B is wrong because a private agent pool with isolated network is similar.

Option D is wrong because Azure DevOps does not have a 'Disable internet access' setting.

Full explanation →

550

MCQmedium

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

A.Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

B.Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

C.Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.

D.Use the same config file for all environments and override settings using pipeline variables based on branch name.

AnswerC

App Service configuration handles non-secrets, variable groups for secrets, and token replacement for environment values.

Why this answer

Using environment-specific variable groups and token replacement is secure and supports local development with config transforms. Option B exposes secrets in logs. Option C relies on branch names, which is inflexible.

Option D uses a single config, which is not environment-specific.

Full explanation →

551

MCQeasy

Your team uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key. Which branch protection rule should you configure?

A.Require pull request reviews before merging.

B.Require status checks to pass before merging.

C.Require linear history.

D.Require signed commits.

AnswerD

Enforces GPG or S/MIME signing on every commit.

Why this answer

Option D is correct because the 'Require signed commits' branch protection rule enforces that every commit pushed to the protected branch must be signed with a GPG key. This ensures cryptographic verification of the commit author's identity, directly addressing the requirement to enforce signed commits on the main branch.

Exam trap

The trap here is that candidates confuse 'Require signed commits' with 'Require status checks to pass before merging', mistakenly thinking a CI status check can enforce signing, but GitHub's built-in rule is the only way to natively reject unsigned commits at the server level.

How to eliminate wrong answers

Option A is wrong because requiring pull request reviews before merging enforces code review, not commit signing. Option B is wrong because requiring status checks to pass before merging enforces CI/CD pipeline checks (e.g., tests, builds), not cryptographic signing of commits. Option C is wrong because requiring linear history enforces a linear commit graph (no merge commits), but does not require commits to be signed with a GPG key.

Full explanation →

552

MCQhard

You are implementing a release pipeline for a containerized application using Azure Kubernetes Service (AKS). The pipeline should use canary deployments to gradually shift traffic from the stable version to the new version. Which strategy should you use to manage the traffic shift?

A.Blue-green deployment strategy

B.Rolling update strategy

C.A/B testing with feature flags

D.Canary deployment using a service mesh (e.g., Istio)

AnswerD

Service mesh enables fine-grained traffic splitting for canary deployments.

Why this answer

Option C is correct because a virtual node or service mesh like Istio can be used to implement canary deployments with traffic splitting. Option A is wrong because rolling update replaces pods gradually but does not support fine-grained traffic splitting. Option B is wrong because blue-green deployment uses two environments, not gradual traffic shift.

Option D is wrong because A/B testing is typically feature-specific, not for traffic shifting at the deployment level.

Full explanation →

553

Drag & Dropmedium

Drag and drop the steps to implement infrastructure as code with Azure Resource Manager (ARM) templates into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

ARM template workflow includes definition, parameterization, deployment, validation, and version control.

Full explanation →

554

MCQeasy

A DevOps engineer needs to ensure that only approved Azure Resource Manager (ARM) templates are used for deployments. They want to enforce this at the subscription level. Which Azure service should they use?

A.Azure Role-Based Access Control (RBAC)

B.Azure Policy

C.Azure Blueprints

D.Azure Management Groups

AnswerB

Azure Policy can enforce allowed template versions or deny non-compliant deployments.

Why this answer

Azure Policy is the correct service because it allows you to create, assign, and manage policies that enforce specific rules on your Azure resources. By using a built-in or custom policy definition (e.g., 'Allowed resource types' or 'Audit if ARM template is not from approved location'), you can restrict ARM template deployments at the subscription level. Azure Policy evaluates all resource creation and update requests against these rules, blocking or auditing any non-compliant ARM template usage.

Exam trap

The trap here is that candidates often confuse Azure Policy with Azure RBAC, thinking that role-based access can restrict template content, when in fact RBAC only controls who can deploy, not what they deploy.

How to eliminate wrong answers

Option A is wrong because Azure RBAC controls who can perform actions (authentication and authorization) on resources, not what specific ARM templates are allowed; it cannot inspect the content or source of a template. Option C is wrong because Azure Blueprints is used to orchestrate the deployment of a repeatable set of Azure resources (including policies, RBAC, and resource groups) but does not itself enforce which ARM templates are used; it relies on Azure Policy for enforcement. Option D is wrong because Azure Management Groups provide a hierarchical structure for managing access, policies, and compliance across multiple subscriptions, but they do not directly enforce ARM template restrictions; they are a container for applying policies, not the enforcement mechanism itself.

Full explanation →

555

MCQhard

Your team uses GitHub Actions for CI/CD. You need to enforce that all workflows use approved actions from a private marketplace. Which GitHub feature should you configure?

A.Use environment secrets to store allowed action names.

B.Require self-hosted runners.

C.Set the Actions permissions to 'Allow only specified actions'.

D.Configure OpenID Connect (OIDC) for Actions.

AnswerC

This policy restricts workflows to an approved list.

Why this answer

Option C is correct because the 'Allow only specified actions' setting in GitHub Actions permissions allows you to restrict workflow execution to a curated list of actions from a private marketplace or specific verified publishers. This enforces governance by preventing the use of unapproved actions, which is critical for compliance and security in enterprise CI/CD pipelines.

Exam trap

The trap here is that candidates often confuse runner-level controls (self-hosted runners) with action-level governance, mistakenly thinking that restricting where code runs also restricts what actions can be used.

How to eliminate wrong answers

Option A is wrong because environment secrets are used to store sensitive values like API tokens, not to enforce action allowlists; they cannot control which actions are permitted at the repository or organization level. Option B is wrong because self-hosted runners control where workflows execute, not which actions they can use; they do not provide a mechanism to restrict action selection. Option D is wrong because OpenID Connect (OIDC) is used for short-lived authentication tokens between GitHub Actions and cloud providers, not for managing action permissions or marketplace access.

Full explanation →

556

MCQhard

You have the YAML pipeline snippet shown in the exhibit. The first run produces version 1.0.0. What will be the version produced on the third run?

A.1.0.1

B.1.0.3

C.1.0.2

D.1.0.0

AnswerC

Counter increments each run: 0,1,2.

Why this answer

Option C is correct because the counter expression starts at 0 for majorVersion=1 and increments each run. First run: 0, second: 1, third: 2. Option A is wrong because counter does not reset.

Option B is wrong because it is the first run value. Option D is wrong because counter increments by 1 each run, not by 2.

Full explanation →

557

MCQhard

Refer to the exhibit. The workflow runs successfully but the deployment fails because the Azure CLI is not authenticated. What should you add to the workflow to authenticate?

A.Add the 'azure/login' action with Azure credentials

B.Add the 'actions/setup-node' action

C.Add the 'azure/webapps-deploy' action

D.Add the 'actions/github-script' action to use the GitHub token

AnswerA

The azure/login action authenticates the CLI with service principal credentials.

Why this answer

Option B is correct because the 'azure/login' action authenticates using Azure credentials stored as secrets. Option A is wrong because 'azure/webapps-deploy' is a deployment action, not authentication. Option C is wrong because the GitHub token is for GitHub API, not Azure.

Option D is wrong because 'actions/setup-node' is for Node.js, not authentication.

Full explanation →

558

MCQhard

Your release pipeline uses a 'Run Azure CLI' task to execute a script. The script authenticates using a service principal. However, the deployment fails with 'insufficient privileges to complete the operation'. What is the most likely cause?

A.The Azure CLI task is not logged in.

B.The service principal secret has expired.

C.The service principal lacks the necessary RBAC role on the target resource.

D.The service principal does not have a secret.

AnswerC

Insufficient privileges indicate missing RBAC assignment.

Why this answer

Option C is correct because the service principal likely lacks the required RBAC role. Option A is wrong because the CLI task can use service principal authentication. Option B is wrong because service principal secret expiration would cause a different error.

Option D is wrong because the error is about privileges, not token expiry.

Full explanation →

559

MCQeasy

You are designing a release pipeline in Azure Pipelines that deploys a web app to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which trigger type should you use?

A.Pull request trigger

B.Continuous deployment trigger on the release pipeline

C.Schedule trigger

D.Build completion trigger

AnswerB

Continuous deployment trigger automatically starts a release when a new build artifact is available, using that same artifact for all stages.

Why this answer

Option A is correct because a release pipeline uses a build artifact trigger to start deployment after a build completes. Option B is wrong because continuous deployment trigger happens after a build artifact is available. Option C is wrong because schedule triggers are time-based.

Option D is wrong because pull request triggers are for builds, not releases.

Full explanation →

560

MCQhard

Your company uses Azure DevOps for CI/CD. You have a YAML build pipeline that builds a .NET Core application and publishes artifacts. The build runs on a Microsoft-hosted agent. Recently, the build started failing with the error 'The process cannot access the file because it is being used by another process.' This occurs intermittently during the 'dotnet build' step. The pipeline uses multiple jobs that run in parallel. You suspect that one job is interfering with another because they share the same workspace on the agent. You need to ensure that each job runs in its own isolated workspace. What should you do?

A.Add a 'demands' section to the job to ensure each job runs on a different agent.

B.Set 'workspace: clean' in the pipeline root.

C.Use a 'multi-job' configuration with a matrix to run each job in separate folders.

D.Set 'clean: all' on the checkout step in each job.

AnswerD

Cleaning the workspace ensures no leftover files from previous jobs.

Why this answer

Option B is correct because setting 'clean: all' on the checkout step ensures that the workspace is cleaned before the job runs, preventing file conflicts. Option A is wrong because 'demands' are for selecting agents, not for workspace isolation. Option C is wrong because 'multi-job config' is for matrix strategies, not for isolation.

Option D is wrong because 'workspace' is not a valid pipeline setting.

Full explanation →

561

MCQeasy

Your team uses GitHub Copilot for code suggestions. To comply with your organization's data protection policies, you need to ensure that code snippets and prompts sent to Copilot are not stored or used by Microsoft for service improvement. What should you configure?

A.Set a compliance grade in Microsoft Defender for Cloud

B.Enable the 'Data Exclusion' setting in Copilot's enterprise settings

C.Apply a Microsoft Purview Data Loss Prevention policy

D.Configure Azure OpenAI Service content filtering

AnswerB

This setting prevents Microsoft from storing or using your code snippets for service improvement.

Why this answer

Option A (Enable the 'Data Exclusion' setting in Copilot's enterprise settings) is correct because GitHub Copilot for Business provides a data exclusion setting that prevents Microsoft from storing or using code snippets. Option B is for Azure OpenAI, not Copilot. Option C is a generic compliance setting.

Option D is for Azure DevOps, not GitHub Copilot.

Full explanation →

562

MCQhard

Refer to the exhibit. A team wants to release version 1.0 from the main branch. They notice that the tag v1.0 is already on the current main commit. However, they also see that the origin/feature/experiment branch has commits that are not merged into main. What is the most likely scenario?

A.The team should delete the experiment branch because it is not merged.

B.The tag v1.0 was applied to the wrong commit; it should be on the merge commit of the experiment branch.

C.The main branch is missing the experiment branch commits; a merge is required before release.

D.The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.

AnswerD

The experiment branch is separate and its commits are not part of main, so they are not included in the release.

Why this answer

The tag v1.0 is on the current main commit (9a8b7c6). The feature/experiment branch (1a2b3c4) is a child of the initial commit, but it is not merged into main. The main branch has commits that are ahead of the experiment branch.

The team wants to release v1.0 from main; the tag already exists. The presence of the experiment branch not merged suggests that it was not intended for this release. The most likely scenario is that the experiment branch was created from an older commit and is not ready for release, so it was not merged.

The release v1.0 is correctly tagged on main.

Full explanation →

563

MCQmedium

Your organization uses Azure DevOps and requires that all pipelines enforce branch policy for pull requests. A developer creates a pipeline that builds and tests code on push to any branch. The security team wants to ensure that no code can be deployed to production without passing through a pull request with required reviewers. Which action should you take to meet this requirement?

A.Disable CI triggers on the pipeline and require manual builds.

B.Modify the service connection to require admin approval.

C.Set the pipeline to require approval from the security team before running.

D.Configure branch policy on the main branch to require a pull request with a minimum number of reviewers.

AnswerD

Branch policies enforce pull request requirements before merging.

Why this answer

Option C is correct because branch policies in Azure Repos can enforce that changes must go through a pull request with required reviewers before merging to the main branch. Option A is incorrect because disabling CI triggers does not enforce pull request requirements. Option B is incorrect because pipeline permissions don't enforce code review.

Option D is incorrect because service connections control access to external resources, not code review.

Full explanation →

564

Multi-Selectmedium

Which TWO are valid strategies to reduce build times in Azure Pipelines? (Choose 2)

Select 2 answers

A.Use the Cache task to cache NuGet packages or npm modules.

B.Use 'dotnet build --no-restore' to skip restore.

C.Enable incremental builds by using the 'clean: false' option.

D.Use a larger agent pool with more parallel jobs.

E.Increase the build job timeout.

AnswersA, C

Caching avoids downloading dependencies each time.

Why this answer

Options A and D are correct. A: Incremental builds only compile changed files, reducing build time. D: Using the Cache task for package dependencies avoids re-downloading.

Option B is wrong because more agents increase parallelism but not per-build time. Option C is wrong because the 'dotnet build' command with '--no-restore' skips restore but doesn't reduce build time if restore is already cached; however, it saves time if restore is already done. But the question asks for strategies to reduce build times; incremental builds and caching are direct strategies.

Option E is wrong because increasing timeout doesn't reduce build time.

Full explanation →

565

MCQmedium

You are reviewing an Azure Policy definition. What does this policy do?

A.Denies pipelines that use an outdated template version.

B.Allows only pipelines that use a specific YAML template.

C.Allows only pipelines in the pipeline-templates folder.

D.Denies any pipeline that does not use a specific YAML template.

AnswerD

The deny effect prevents creation of pipelines with a different YAML path.

Why this answer

Option B is correct because the policy denies any pipeline whose YAML file path is not exactly '/pipeline-templates/secure-pipeline.yml'. Option A is wrong because it denies, not allows. Option C is wrong because it targets all pipelines, not just those in a specific folder.

Option D is wrong because it does not enforce a specific template version.

Full explanation →

566

MCQeasy

Your organization uses GitHub for source control. You need to enforce that all pull requests require at least one approval and that branches must be up to date with the base branch before merging. Which branch protection rule settings should you enable?

A.Require branches to be up to date only

B.Require a pull request before merging only

C.Require status checks to pass before merging only

D.Require a pull request before merging and require branches to be up to date

AnswerD

Both settings enforce the required policies.

Why this answer

Option D is correct because GitHub branch protection rules allow you to enforce both that pull requests require at least one approval and that branches are up to date with the base branch before merging. The 'Require a pull request before merging' setting ensures that changes cannot be pushed directly to the protected branch and must go through a PR with required approvals. The 'Require branches to be up to date' setting (under 'Require status checks to pass before merging') ensures that the branch is tested against the latest base branch code, preventing stale merges.

Exam trap

The trap here is that candidates often think 'Require status checks to pass before merging' alone covers both the approval and up-to-date requirements, but it does not enforce the pull request workflow or the branch freshness check unless those specific status checks are explicitly configured.

How to eliminate wrong answers

Option A is wrong because 'Require branches to be up to date only' does not enforce that pull requests require approval; it only ensures the branch is current, leaving the repository vulnerable to direct pushes without review. Option B is wrong because 'Require a pull request before merging only' does not enforce that the branch is up to date with the base branch, allowing merges from outdated branches that may break the build. Option C is wrong because 'Require status checks to pass before merging only' does not inherently require a pull request or an approval; it only mandates that defined status checks (e.g., CI tests) succeed, which can be bypassed by direct pushes if no PR requirement is set.

Full explanation →

567

MCQhard

Your organization uses Azure DevOps Server (on-premises) and plans to migrate to Azure DevOps Services. You have hundreds of classic build and release pipelines. You need to design a migration strategy that minimizes downtime and allows for a gradual transition. The team wants to use the new YAML-based pipelines after migration. What should you do?

A.Export the classic pipeline definitions as JSON, and manually recreate them as YAML pipelines in Azure DevOps Services.

B.Recreate all pipelines from scratch using YAML in the new organization.

C.Use the Azure DevOps Migration Tools to automatically convert classic pipelines to YAML.

D.Migrate all pipelines as-is (classic) and then plan a separate project to convert them to YAML.

AnswerA

This allows gradual migration while maintaining existing pipelines.

Why this answer

Option B is correct: Exporting pipeline definitions and converting them to YAML manually allows gradual migration. Option A is incorrect because the migration tool does not convert classic pipelines to YAML. Option C is incorrect because using classic pipelines after migration is not leveraging YAML.

Option D is incorrect because recreating from scratch is inefficient and error-prone.

Full explanation →

568

Multi-Selectmedium

Which TWO features can you use to enforce quality gates before a production deployment in Azure Pipelines?

Select 2 answers

A.Scheduled triggers

B.Branch policies on repositories

C.Pipeline decorators

D.Approval checks on environments

E.Deployment gates evaluating health metrics

AnswersD, E

Requires manual approval.

Why this answer

Approval checks and deployment gates are both quality gates. Option B (branch policies) applies to source control. Option D (pipeline decorators) adds steps but not gates.

Option E (scheduled triggers) is for timing.

Full explanation →

569

MCQmedium

You are implementing a secrets management strategy for a multi-cloud deployment. You need to securely store and rotate API keys for a third-party service. Which Azure service should you use?

A.Azure Key Vault

B.Microsoft Entra ID

C.Azure App Configuration

D.Azure Storage Blob

AnswerA

Key Vault is designed for secure storage and rotation of secrets.

Why this answer

Option B is correct because Azure Key Vault provides secure storage and automatic rotation of secrets. Option A is wrong because Microsoft Entra ID is for identity management, not secret storage. Option C is wrong because Azure App Configuration is for application configuration, not secrets.

Option D is wrong because Azure Storage is not designed for secret management.

Full explanation →

570

MCQeasy

You are setting up a CI/CD pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Your team wants to automatically generate release notes from commit messages and work items. Which Azure DevOps feature should you use?

A.Copy Files task

B.Azure Repos Wiki

C.Azure Test Plans

D.Generate release notes task (from YAML pipeline)

AnswerD

This built-in task automates release notes from commits and work items.

Why this answer

The Generate release notes task (from YAML pipeline) is the correct choice because it is specifically designed to automatically generate release notes from commit messages and work items in Azure Pipelines. This task parses the commit history and linked work items between two Git refs (e.g., tags or branches) and outputs a formatted markdown file, which can be published as an artifact or used in a release pipeline. It directly addresses the requirement to derive release notes from commits and work items without manual effort.

Exam trap

The trap here is that candidates may confuse the Generate release notes task with other documentation or file-copy tasks, but only this task is purpose-built to parse commit messages and work items into structured release notes within a YAML pipeline.

How to eliminate wrong answers

Option A is wrong because the Copy Files task is used to copy files from a source folder to a destination folder within the pipeline, not to generate release notes from commit messages or work items. Option B is wrong because Azure Repos Wiki is a documentation repository for project wikis, not a pipeline task that can automatically generate release notes from commits and work items. Option C is wrong because Azure Test Plans is a testing and quality management tool for manual and exploratory testing, not a feature for generating release notes from commit messages or work items.

Full explanation →

571

Multi-Selectmedium

Which TWO actions help reduce the size of a Git repository over time?

Select 2 answers

A.Use Git LFS for large binary files.

B.Squash commits before pushing to the remote.

C.Perform shallow clones when cloning the repository.

D.Regularly run 'git gc' to compress objects.

E.Use 'git filter-branch' or 'git filter-repo' to remove obsolete files from history.

AnswersA, E

Git LFS replaces large files with pointers, reducing repo size.

Why this answer

Option A is correct because Git LFS (Large File Storage) replaces large binary files with text pointers in the repository, storing the actual binary content in an external server. This prevents the repository from bloating with large files that are stored in full in every commit, significantly reducing the repository size over time.

Exam trap

The trap here is that candidates often confuse 'reducing repository size' with 'improving performance' or 'reducing clone time', leading them to select shallow clones or commit squashing as valid answers, when in fact only actions that remove or externalize file content (like LFS or history rewriting) actually shrink the repository size.

Full explanation →

572

Multi-Selecteasy

Which THREE are true about using deployment groups in Azure Pipelines? (Choose 3)

Select 3 answers

A.Each machine in a deployment group must have the Azure Pipelines agent installed.

B.Deployment groups can only be used with Windows-based machines.

C.Deployment groups allow you to deploy an application to multiple machines in a rolling fashion.

D.Deployment groups can be used in classic release pipelines.

E.Deployment groups are tied to a specific environment.

AnswersA, C, D

Agent is required to receive tasks.

Why this answer

Options A, C, and D are correct. A: Deployment groups are used to target multiple machines for rolling deployments. C: Each machine in a deployment group runs an agent that listens for jobs.

D: Deployment groups can be used in release pipelines with the 'Deployment group' phase. Option B is wrong because deployment groups are not limited to Windows; they support Linux, macOS, etc. Option E is wrong because deployment groups are not environment-specific; environments are a separate concept.

Full explanation →

573

MCQmedium

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

A.The push triggers the build validation pipeline

B.The push is allowed because allowForcePush is false

C.The push is rejected because branch policies require a pull request

D.The push is allowed because requireLinearHistory is false

AnswerC

Branch policies enforce pull request requirement.

Why this answer

Option D is correct. The policy has 'requireLinearHistory' false, but 'allowForcePush' is false, and there is no branch policy that allows direct pushes. By default, branch policies require pull requests.

Option A is wrong because allowForcePush false prevents force pushes. Option B is wrong because requireLinearHistory false does not allow direct pushes. Option C is wrong because build validation does not block the push; it is part of PR policy.

Full explanation →

574

MCQmedium

A team is designing a release pipeline for a .NET Core web application. They want to deploy to Azure App Service using a blue-green deployment strategy to minimize downtime. Which Azure App Service feature should they use to implement this?

A.Use Azure Load Balancer in front of two separate App Services.

B.Use deployment slots with swap operation.

C.Configure auto-scaling rules.

D.Use Azure Traffic Manager to route traffic between slots.

AnswerB

Deployment slots enable blue-green swaps with zero downtime.

Why this answer

Deployment slots in Azure App Service support swap operations that enable blue-green deployment by swapping the production slot with a staging slot. This minimizes downtime because the swap is warm-up and validation is done in the staging slot before traffic is redirected, and the swap itself is instantaneous under the hood. No external load balancer or traffic manager is needed because the swap operation handles the routing internally.

Exam trap

The trap here is that candidates may confuse Azure Traffic Manager or Load Balancer as necessary for blue-green deployments, but Azure App Service's built-in deployment slots with swap operation are the correct and simplest implementation for this specific service.

How to eliminate wrong answers

Option A is wrong because using Azure Load Balancer in front of two separate App Services adds unnecessary complexity and cost; it does not leverage the built-in slot swap mechanism that Azure App Service provides for zero-downtime deployments. Option C is wrong because auto-scaling rules handle scaling out or in based on demand, not traffic routing or deployment strategies like blue-green. Option D is wrong because Azure Traffic Manager is a DNS-based traffic routing service that operates at the DNS level and cannot perform instant slot swaps; it would introduce DNS propagation delays and is not designed for the warm-up and validation workflow of blue-green deployments.

Full explanation →

575

MCQeasy

A company uses Azure DevOps and has a security policy that all pipeline runs must use a specific service connection scoped to a resource group. A developer reports that a pipeline fails with the error: 'The service connection does not have permission to access the resource.' What is the most likely cause?

A.The Azure subscription linked to the service connection is disabled.

B.The service connection name is misspelled in the pipeline YAML.

C.The variable group in the library does not include the service connection ID.

D.The service principal used by the service connection does not have the required role assignment on the resource group.

AnswerD

Missing role assignments cause access denied errors.

Why this answer

Option D is correct because the error 'The service connection does not have permission to access the resource' indicates that the service principal associated with the service connection lacks the necessary Azure RBAC role assignment on the target resource group. In Azure DevOps, a service connection authenticates via a service principal, and that principal must have a role (e.g., Contributor) explicitly assigned at the resource group scope to perform actions like deploying resources. Without this role assignment, the pipeline fails with an access-denied error.

Exam trap

The trap here is that candidates often confuse service connection authentication (which always works if the connection is valid) with authorization (RBAC role assignments), leading them to pick options about disabled subscriptions or misspelled names instead of the missing role assignment.

How to eliminate wrong answers

Option A is wrong because a disabled Azure subscription would cause a different error (e.g., 'Subscription not found' or 'Authorization failed'), not a specific permission-denied message on a resource group. Option B is wrong because a misspelled service connection name in the YAML would result in a 'Service connection not found' error, not a permission error. Option C is wrong because variable groups in the library store variables, not service connection IDs; service connections are referenced by name in the pipeline, and the ID is not required for permission checks.

Full explanation →

576

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 is the native identity provider for Azure DevOps.

Why this answer

Option C is correct because Azure DevOps can be integrated with Microsoft Entra ID for SSO. Option A is wrong because GitHub ID is not supported for Azure DevOps SSO. Option B is wrong because Google Workspace is not a native identity provider.

Option D is wrong because Microsoft account is for personal use, not enterprise SSO.

Full explanation →

577

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 converts TFVC changesets into Git commits preserving history.

Why this answer

Option C is correct because 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 →

578

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

Service hooks can integrate with Teams connectors.

Why this answer

Service hooks in Azure DevOps allow you to integrate with external services like Microsoft Teams by triggering on specific events, such as the creation of a bug work item. This enables automatic notification to the on-call engineer via Teams without requiring a release pipeline or email configuration. The service hook listens for the 'Work item created' event and sends a customizable message to a Teams channel, directly addressing the requirement for automated notification.

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 →

579

MCQmedium

You are responsible for managing build pipelines in Azure DevOps for a large .NET solution that consists of multiple projects. The build takes approximately 45 minutes, which is too long. The solution has unit tests and integration tests. The integration tests require a database that is provisioned during the build. You need to reduce the build time while maintaining code quality. What should you do?

A.Enable incremental build by using the 'Build' task's 'Clean' option set to false, and separate unit and integration tests into different stages.

B.Remove integration tests from the build pipeline and run them only in the release pipeline.

C.Increase the number of parallel jobs and use a multi-agent job to build projects in parallel.

D.Disable the 'Test' step in the build pipeline and rely on a separate test pipeline.

AnswerA

Incremental builds reduce build time, and separating tests allows quicker feedback from unit tests.

Why this answer

Option D is correct: Using incremental builds restores and builds only changed projects, and separating unit and integration tests allows faster feedback. Option A is incorrect because removing integration tests reduces quality. Option B is incorrect because using more agents does not reduce the build time of a single build.

Option C is incorrect because disabling tests altogether is not acceptable.

Full explanation →

580

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

Option A is correct because the 'Cache' task is used to cache dependencies including NuGet packages. Option B is wrong because 'NuGet restore' does not cache across builds. Option C is wrong because 'DownloadBuildArtifacts' is for downloading artifacts, not caching.

Option D is wrong because 'DotNetCoreCLI' with 'restore' does not provide caching across builds.

Full explanation →

581

MCQmedium

Your team is migrating from Jenkins to Azure Pipelines. You have a Jenkins pipeline that builds a Java application, runs unit tests, performs static code analysis with SonarQube, packages the application as a WAR file, and deploys to a Tomcat server. You need to replicate this pipeline in Azure Pipelines using YAML. The build and deployment must be triggered by commits to the main branch. You also need to ensure that the SonarQube analysis results are published to the SonarQube server and that the pipeline breaks if the quality gate fails. The Tomcat server is on-premises and requires a service connection. Which YAML pipeline structure should you use?

A.Use the Maven task to build and test, and use the Azure Web App task to deploy to Azure App Service.

B.Use the Maven task with SonarQube goals (sonar:sonar) for analysis, then use the Copy Files task and Windows Machine File Copy task to deploy to the on-premises Tomcat server.

C.Use the Maven task to build, then use PowerShell to copy the WAR file to the Tomcat server via Invoke-Command.

D.Use the Maven task to build and test, and use SSH tasks to copy the WAR file to the Tomcat server and restart the service.

AnswerB

Correct: Maven handles build/test/SonarQube, and Windows Machine File Copy deploys to on-premises.

Why this answer

Option C is correct because it uses Maven for build/test, SonarQubePrepare/Analyze tasks (or Maven with SonarQube goals), and a CopyFiles/WindowsMachineFileCopy task for on-premises deployment. Option A is wrong because SSH tasks may not work for Tomcat deployment directly. Option B is wrong because Azure App Service is not on-premises.

Option D is wrong because it uses PowerShell to copy files, which is less maintainable and doesn't leverage Azure Pipelines tasks.

Full explanation →

582

MCQhard

Refer to the exhibit. The pipeline is configured as shown. A developer pushes a change to the `main` branch that modifies a file under `src/Controllers/HomeController.cs` and also adds a new file under `docs/readme.md`. Which of the following best describes what happens?

A.The pipeline does not trigger because the `docs/` path is excluded and includes a change.

B.The pipeline triggers because the change to `src/Controllers/HomeController.cs` is not in an excluded path.

C.The pipeline triggers only if the change is on a branch matching `release/*`.

D.The pipeline triggers but runs only tests because the build is skipped due to excluded paths.

AnswerB

The trigger includes main branch and excludes docs/* and tests/*. The src change is not excluded, so the pipeline runs.

Why this answer

Option B is correct because the pipeline's trigger configuration uses path filters that exclude `docs/*` but include `src/*`. Since the developer's push includes a change to `src/Controllers/HomeController.cs`, which is not in an excluded path, the pipeline triggers. The addition of `docs/readme.md` does not prevent triggering because the trigger evaluates the union of all changed files; as long as at least one changed file matches an included path (or is not excluded), the pipeline runs.

Exam trap

The trap here is that candidates mistakenly think a change in an excluded path will block the entire pipeline trigger, when in reality Azure Pipelines triggers if any changed file is not in an excluded path.

How to eliminate wrong answers

Option A is wrong because the pipeline triggers when any changed file is not in an excluded path; the presence of a change in an excluded path (`docs/`) does not suppress the trigger if another change (to `src/`) is outside the excluded paths. Option C is wrong because the exhibit shows no branch filter; the trigger is based on path filters, not branch patterns like `release/*`. Option D is wrong because path filters control whether the pipeline triggers at all, not which stages or jobs run; if the pipeline triggers, all configured stages (including build) execute unless separate conditional logic is added.

Full explanation →

583

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

Branch policies can require specific reviewers for pull requests to main.

Why this answer

Option A is correct because branch policies in Azure Repos allow you to require specific reviewers (security team) for pull requests to main. Option B is wrong because Azure Pipelines is for CI/CD, not code review policies. Option C is wrong because Microsoft Defender for Cloud is for security posture.

Option D is wrong because Microsoft Sentinel is for SIEM.

Full explanation →

584

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 provides standardized distributed tracing and can export to Application Insights.

Why this answer

Option B is correct because OpenTelemetry is the industry standard for distributed tracing, and the Application Insights exporter allows telemetry data to be sent directly to Azure Monitor. This approach provides a vendor-neutral instrumentation layer that works across multiple languages and platforms, making it ideal for microservices on AKS.

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 →

585

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 includes main, so a push triggers one build.

Why this answer

The trigger includes main, so a push to main triggers a build. The PR trigger includes develop, but since it's a push to main, not a PR, only the CI trigger applies. Option A is wrong because PR trigger only applies to PRs.

Option C is wrong because the pipeline will run once for the CI trigger. Option D is wrong because the PR trigger does not cover pushes to main.

Full explanation →

586

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

Templates allow reusing steps or jobs across pipelines.

Why this answer

Option C is correct because 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 →

587

Multi-Selectmedium

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates. Which TWO options should you use?

Select 2 answers

A.Set the deployment replica count to zero before updating.

B.Use a canary deployment with a service mesh.

C.Configure a rolling update strategy in the Kubernetes manifest.

D.Use a recreate deployment strategy.

E.Implement a blue-green deployment pattern using separate namespaces.

AnswersC, E

Rolling updates replace pods incrementally.

Why this answer

Option C is correct because a rolling update strategy in Kubernetes gradually replaces old pods with new ones, ensuring that a minimum number of pods remain available throughout the update. This minimizes downtime by only terminating old pods after new ones are healthy, controlled by parameters like `maxSurge` and `maxUnavailable` in the Deployment manifest.

Exam trap

The trap here is that candidates may confuse a canary deployment (which is a valid zero-downtime strategy) with a blue-green deployment, but the question specifically asks for two options, and the correct pair is rolling update and blue-green, not canary.

Full explanation →

588

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

Short-lived branches and feature flags reduce conflicts.

Why this answer

Option C is correct because feature flags allow developers to merge incomplete features into the main branch without affecting users, reducing long-lived branches and conflicts. Option A is wrong because GitFlow has long-lived branches that increase conflict risk. Option B is wrong because trunk-based development with short-lived branches is the recommended approach.

Option D is wrong because release branches do not reduce conflicts on the main branch.

Full explanation →

589

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

Azure DevOps supports streaming audit events to Microsoft Sentinel for real-time monitoring.

Why this answer

Option A is correct because Azure DevOps audit logs can be streamed to Microsoft Sentinel via the Azure DevOps data connector. Option B is wrong because service hooks don't directly integrate with Sentinel. Option C is wrong because Microsoft Purview is for data governance, not real-time auditing.

Option D is wrong because export to CSV is a manual process.

Full explanation →

590

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

Option C is correct because the workflow must have a name that matches the status check name used in branch protection rules. Often the workflow name is different from the job name or the check suite name. Option A is incorrect because the event type is correct.

Option B is incorrect because the YAML is valid for pull_request events. Option D is incorrect because the action is not a third-party problem.

Full explanation →

591

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

Environment approvals allow manual checks before deployment.

Why this answer

Option B is correct because environment approvals are configured on the 'Production' environment, and the deployment job references that environment. Option A is wrong because stages don't have approval gates. Option C is wrong because branch policies are for PRs, not pipeline approvals.

Option D is wrong because pipeline-level approvals apply to all runs.

Full explanation →

592

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

Content exclusions prevent specific repositories from being used as context by Copilot.

Why this answer

Option C is correct because GitHub Copilot for Business allows administrators to configure content exclusions to prevent certain repositories from being used as context. Option A is wrong because disabling Copilot entirely is not necessary and reduces productivity. Option B is wrong because network segmentation does not affect Copilot's data usage.

Option D is wrong because auditing alone does not prevent sharing.

Full explanation →

593

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

Options B and D are correct. Approval gates and deployment gates with health evaluation are key components of gated deployment. Option A is not specific to gated deployment.

Option C is about monitoring, not gating. Option E is about rollback, not gating.

Full explanation →

594

Multi-Selectmedium

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

Select 2 answers

A.Limit the number of discussion categories to one.

B.Automatically close discussions that are unanswered for 7 days.

C.Create a template for new discussions to guide users.

D.Assign a team of maintainers to monitor unanswered discussions.

E.Convert unanswered discussions to issues.

AnswersC, D

Helps users ask clear questions.

Why this answer

Option C is correct because providing a template for new discussions guides users to include essential details (e.g., environment, error logs, steps to reproduce), which reduces ambiguity and makes it easier for community members to provide accurate answers. This directly increases the likelihood of receiving responses by setting clear expectations and reducing back-and-forth clarification.

Exam trap

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

Full explanation →

595

MCQeasy

You need to ensure that a release pipeline in Azure Pipelines automatically deploys to production only if the deployment to staging succeeds and all manual intervention checks pass. What is the best way to configure this?

A.Add a pre-deployment approval gate on the production stage

B.Configure a branch policy on the main branch

C.Assign a deployment group to the production stage

D.Add a post-deployment approval gate on the staging stage

AnswerD

A post-deployment approval ensures manual sign-off after staging succeeds before proceeding to production.

Why this answer

Option A is correct because a post-deployment approval gate can require manual sign-off after staging deployment. Option B is wrong because a pre-deployment approval is before staging. Option C is wrong because a branch policy is for repositories.

Option D is wrong because a deployment group is for targets.

Full explanation →

596

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

Option C is correct because rolling updates can be configured with health probes and automatic rollback on failure. Option A is wrong because blue-green requires manual switch. Option B is wrong because canary routes traffic gradually but does not auto-rollback.

Option D is wrong because redeploying the same version doesn't fix the issue.

Full explanation →

597

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

This task publishes code coverage results in formats like Cobertura and displays them in the pipeline summary.

Why this answer

Option B is correct because the PublishCodeCoverageResults task consumes coverage data (e.g., Cobertura format) and displays it in the pipeline summary. Option A is wrong because the PublishTestResults task only publishes test results, not coverage. Option C is wrong because the Visual Studio Test task is for .NET, not Node.js.

Option D is wrong because the Copy Files task only copies files, it does not process coverage.

Full explanation →

598

MCQeasy

Your build pipeline for a Java application uses Maven. You need to run unit tests and integration tests separately. Unit tests should run on every commit, while integration tests should run only when the build is triggered by a pull request to the main branch. How should you configure the pipeline?

A.Add both test types as steps in the same job and use a step condition.

B.Create two separate stages: one for unit tests, one for integration tests.

C.Create two jobs: one with unit tests (always), one with integration tests conditioned on 'eq(variables['Build.Reason'], 'PullRequest')'.

D.Use a single job with both tests, but set the 'always()' condition on the integration test step.

AnswerC

Jobs can run in parallel or conditionally based on build reason.

Why this answer

Option C is correct because using two jobs with different conditions allows selective execution. Option A is wrong because the same condition applies to all steps. Option B is wrong because stages run sequentially, not conditionally.

Option D is wrong because 'always()' would run both jobs regardless.

Full explanation →

599

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

OData provides structured telemetry data that can be streamed.

Why this answer

Option D is correct because 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 →

600

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

Paths filter specifies which files or folders trigger the pipeline.

Why this answer

Option A is correct because the path trigger filters changes to specific paths. Option B is wrong because it would trigger on any change. Option C is wrong because batch changes the number of triggers but not the path.

Option D is wrong because branches filter by branch, not path.

Full explanation →

Page 8 of 13

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Configure processes and communications Design and implement source control Design and implement build and release pipelines Develop a security and compliance plan Implement an instrumentation strategy Design and implement a DevOps infrastructure Design and implement a source control strategy

See all domains with question counts →