Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 601–675 | Page 9/11

601

Multi-Selecteasy

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

Select 2 answers

A.trigger: branches: exclude: - main

B.trigger: branches: include: - main

C.branches: include: - main

D.trigger: branches: main

E.trigger: branches: include: - release/*

AnswersB, E

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

Why this answer

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

Exam trap

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

Full explanation →

602

Matchingmedium

Match each Azure Artifacts feed type to its description.

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

Concepts

Matches

Accessible to all projects in the organization

Accessible only within a specific project

Caches packages from external sources like NuGet.org

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

Why these pairings

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

Full explanation →

603

MCQmedium

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

A.Use Kubernetes native deployment strategies with multiple replica sets and traffic splitting

B.Use Azure Front Door to route traffic between clusters

C.Use deployment slots in Azure App Service

D.Use Azure Container Instances as a staging environment

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

604

MCQmedium

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

A.Use trunk-based development with short-lived feature branches that merge directly to main.

B.Use a forking workflow where each developer forks the repository and creates pull requests.

C.Use Git Flow with feature, develop, release, and main branches.

D.Use GitHub Flow with feature branches and pull requests directly to main.

AnswerC

Git Flow provides release branches for stabilization before merging to main.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

605

MCQmedium

Your company uses Microsoft Purview to manage data governance. You need to classify a new dataset containing personally identifiable information (PII) and apply a data loss prevention (DLP) policy. What should you do first?

A.Create a sensitivity label in Microsoft Purview

B.Add the data source to an Azure service tag

C.Define a DLP policy in Microsoft Purview

D.Register and scan the data source in Microsoft Purview

AnswerD

Registering the data source in Microsoft Purview establishes a metadata connection, and scanning it is the action that performs automated inspection to classify data using built-in classifiers such as credit card numbers or personally identifiable information. A scan extracts the resource's schema, lineage, and technical metadata, and it applies the registered source's classification rules to produce a searchable data catalog. This is the foundational first step because all other Purview governance features—including labels and DLP policies—depend on the cataloged assets derived from scanning.

Why this answer

To classify a new dataset containing PII and apply a DLP policy, the first step is to register and scan the data source in Microsoft Purview. Scanning automatically discovers and classifies sensitive data using built-in classifiers. Only after classification can you create sensitivity labels (option A) or define a DLP policy (option C).

Adding to an Azure service tag (option B) is unrelated to data classification. Therefore, option D is the correct first step.

Full explanation →

606

MCQmedium

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

A.Use the Publish Test Results task to publish coverage data.

B.Use the Publish Build Artifacts task with coverage files.

C.Use the Copy Files task to copy coverage files and then the Publish Build Artifacts task.

D.Use the Publish Code Coverage Results task and configure the threshold in the task settings.

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

607

MCQeasy

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

A.Slot swap

B.Canary deployment

C.Rolling update

D.Blue-green deployment

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

608

MCQhard

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

A.GitLab Flow

B.Trunk-based development

C.GitHub Flow

D.Git Flow

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

609

MCQeasy

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

A.Production slot

B.Warmup slot

C.Staging slot

D.All slots simultaneously

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

610

Multi-Selectmedium

A company is adopting Azure DevOps and needs to ensure that all pipelines comply with regulatory standards. The security team wants to enforce that every build includes a security scan and that deployment to production requires approval from a compliance officer. Which TWO actions should the DevOps engineer take?

Select 2 answers

A.Configure branch policies to require a security scan on pull requests.

B.Create a required template that includes the security scan task and mandate its use via a pipeline resource.

C.Add a variable group to store security scan results and reference it in the pipeline.

D.Configure a required reviewer approval on the production stage of the release pipeline.

E.Use a pipeline decorator to automatically run a security scan on every build.

AnswersB, D

Creating a required template with the security scan task and mandating its use via a pipeline resource ensures every pipeline inherits the security scan, enforcing compliance across all builds.

Why this answer

Creating a required template with the security scan task and mandating its use via a pipeline resource ensures every pipeline inherits the security scan. Option D is correct because configuring a required reviewer approval on the production stage enforces compliance officer approval. Options A, C, and E are incorrect: Branch policies (A) only apply to pull requests, not all builds; storing results (C) does not enforce the scan; and while a pipeline decorator (E) can run a scan on every build, it does not enforce the required approval for production deployment.

Exam trap

The trap here is that candidates often confuse branch policies (Option A) with build-level enforcement, not realizing that branch policies only apply to pull request validation, not to all builds triggered by other events like CI or scheduled triggers.

Full explanation →

611

MCQmedium

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

A.Create a release pipeline that triggers on build failure and creates a work item.

B.Add the 'Create work item on failure' task to the build pipeline.

C.Configure a Service Hook to create a work item on build failure.

D.Use a PowerShell script in the pipeline to call Azure DevOps REST API.

AnswerB

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

Why this answer

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

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

Full explanation →

612

MCQmedium

Your team uses GitHub Actions for CI/CD. Security policies require that secrets must be automatically rotated every 90 days. Which Azure DevOps feature should you integrate to enforce this requirement?

A.Microsoft Purview Compliance Manager

B.GitHub Actions secrets with scheduled workflows

C.Azure Key Vault with rotation policy

D.Azure Managed Identities

AnswerC

Azure Key Vault supports secret rotation policies that can be configured to rotate secrets automatically.

Why this answer

Azure Key Vault supports automated secret rotation policies that can be configured to rotate secrets at a specified interval, such as every 90 days. By integrating Azure Key Vault with GitHub Actions, you can enforce the security policy that secrets must be automatically rotated without manual intervention. This is the correct choice because it directly meets the requirement for automated rotation within Azure's ecosystem.

Exam trap

The trap here is that candidates might confuse scheduled workflows in GitHub Actions with automated secret rotation, but GitHub Actions secrets do not support native rotation policies, whereas Azure Key Vault does.

How to eliminate wrong answers

Option A is wrong because Microsoft Purview Compliance Manager is a compliance management tool that helps assess and manage regulatory compliance, but it does not provide automated secret rotation capabilities. Option B is wrong because GitHub Actions secrets with scheduled workflows can trigger actions on a schedule, but they do not natively support automated secret rotation; you would need to implement custom logic to rotate secrets, and GitHub Actions secrets themselves cannot be rotated automatically by the platform. Option D is wrong because Azure Managed Identities provide an identity for Azure resources to authenticate to services without storing credentials, but they do not handle secret rotation; they are used for authentication, not for managing or rotating secrets.

Full explanation →

613

MCQeasy

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

A.Configure approvals and checks on the production environment in Azure Pipelines.

B.Create a branch policy that requires approval for pull requests.

C.Use a service connection with a managed identity that requires approval.

D.Store the production credentials in a variable group with approval required.

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

614

Multi-Selectmedium

Which TWO conditions should you configure in a release pipeline to ensure that a deployment to production only happens when both the staging deployment succeeded and a manual approval is granted? (Choose two.)

Select 2 answers

A.Add a post-deployment approval on the staging stage.

B.Add a pre-deployment approval on the production stage.

C.Set the trigger to 'After release' and filter by artifact.

D.Set the deployment queue setting to 'After previous deployment' for the production stage.

E.Add a gate that checks if the staging deployment succeeded.

AnswersB, E

A pre-deployment approval on the production stage forces a designated user or group to explicitly approve the release before any production deployment is attempted. This acts as a manual gate that, because the production stage only triggers after staging completes, ensures production is deployed only after staging has succeeded and been reviewed.

Why this answer

To ensure release to production only after staging success and manual approval, you need a pre-deployment approval on the production stage (B) for the manual approval, and a pre-deployment gate on production that checks that the staging deployment succeeded (E). A gate is a valid condition that verifies the required state before deployment. Option D, the deployment queue setting 'After previous deployment', only controls concurrency of the same stage and does not create a dependency on the staging stage, so it does not ensure staging succeeded.

Exam trap

Deployment queue settings do not define stage dependencies; they only control how deployments of the same stage are queued. Stage dependencies are defined via triggers (e.g., 'After stage') or through gates that check external conditions.

Full explanation →

615

MCQmedium

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

A.Use 'git filter-repo' to remove the file from history

B.Add the file to .gitignore and push again

C.Use 'git revert' to undo the commit

D.Use BFG Repo-Cleaner

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

616

MCQhard

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

A.Increase the number of AKS nodes to handle peak traffic and reduce resource contention.

B.Review the application code to ensure that Redis and SQL connections are properly opened and closed using 'using' statements.

C.Run a load test against the application to reproduce the issue and monitor system counters.

D.Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

617

MCQhard

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

A.The reference function cannot be used in a properties object.

B.The reference function syntax is incorrect.

C.The Application Insights component is not defined as a resource in the template.

D.The apiVersion for the config resource is outdated.

AnswerC

Correct: reference() can only refer to resources deployed in the same template or existing resources if using 'full' reference.

Why this answer

The error 'The resource 'Microsoft.Insights/components/...' is not defined in the template' indicates that the ARM template references an Application Insights component (e.g., via the `reference()` function or a `dependsOn` property) that is not declared as a resource within the template's `resources` array. In ARM templates, every resource you reference must be explicitly defined; otherwise, the deployment engine cannot resolve it, causing this validation error.

Exam trap

The trap here is that candidates often confuse a missing resource definition with a syntax error in the `reference()` function or an API version issue, but the error message explicitly says 'not defined', which points directly to the resource not being declared in the template's `resources` section.

How to eliminate wrong answers

Option A is wrong because the `reference()` function can be used in a `properties` object to retrieve runtime values from other resources, as long as those resources are defined in the template. Option B is wrong because the error message specifically states the resource is 'not defined', not that the syntax of `reference()` is incorrect; a syntax error would produce a different parsing error. Option D is wrong because an outdated `apiVersion` would cause a different error (e.g., 'The apiVersion parameter ... is not supported'), not a 'not defined' error for the resource itself.

Full explanation →

618

MCQhard

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

A.Require at least one code reviewer approval for all pull requests into main.

B.Configure branch protection on main to require status checks (CI build and tests) to pass before merging.

C.Adopt a GitFlow-like branching model with a separate release branch for stable code.

D.Disable direct pushes to main and enforce all merges through pull requests.

E.Require a linear history on main by enabling 'Rebase and merge' for all pull requests.

AnswerB

This ensures that only branches with passing builds and tests can be merged into main.

Why this answer

Configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.

Exam trap

The trap here is that candidates often confuse process controls (like requiring pull requests or code reviews) with automated quality gates (like status checks), mistakenly believing that human review alone is sufficient to catch all integration issues.

How to eliminate wrong answers

Option A is wrong because requiring code reviewer approval alone does not prevent incomplete or broken code from being merged; reviewers may miss issues or approve without running builds. Option C is wrong because adopting GitFlow with a separate release branch adds complexity and delays feedback, contradicting the need for fast feedback and not directly preventing accidental merges of incomplete work. Option D is wrong because disabling direct pushes and enforcing merges through pull requests is a prerequisite but does not enforce that the code is complete or passes validation; it only controls the merge mechanism.

Option E is wrong because requiring a linear history via 'Rebase and merge' only affects commit history structure, not the quality or completeness of the code being merged.

Full explanation →

619

Multi-Selectmedium

Which TWO actions should you take to implement a secure build pipeline that uses Azure Key Vault to store secrets? (Choose two.)

Select 2 answers

A.Store the Key Vault name and secret names in a secure file in the repository.

B.Define secrets as pipeline variables and mark them as secret.

C.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.

D.Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.

E.Use the 'Azure Key Vault' task to download secrets as pipeline variables.

AnswersC, E

Granting the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault is a mandatory prerequisite for the pipeline to retrieve secret names and values; without these permissions, the Azure Key Vault task fails, so you must configure an access policy or RBAC role assignment for the service principal.

Why this answer

The Azure DevOps service principal (the identity used by Azure Pipelines) must be granted 'Get' and 'List' permissions on the Key Vault's access policy. This allows the pipeline to retrieve secret values securely without storing credentials in the repository or pipeline configuration. Without these permissions, any attempt to read secrets from the vault will fail with an authorization error.

Exam trap

The trap here is that candidates often think storing secrets as pipeline variables (Option B) is sufficient, but the question specifically requires using Azure Key Vault, so the correct approach is to retrieve secrets from Key Vault at runtime using the dedicated task, not to hardcode them as pipeline variables.

Full explanation →

620

MCQmedium

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

A.The script type 'pscore' is not supported on Ubuntu.

B.The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.

C.Parameters cannot be used in YAML pipelines; they must be defined in a template.

D.The 'trigger: none' prevents the pipeline from running.

AnswerB

The macro syntax `$(environment)` in a variable resolves to a runtime variable named 'environment', not to a pipeline parameter. Parameters are expanded at compile time via `${{ parameters.environment }}`, so this use would produce a null/empty value and cause the resource group name to be incorrect or undefined.

Why this answer

In Azure DevOps YAML pipelines, the `$()` syntax is used to reference runtime variables, not parameters. Parameters are defined using `parameters:` and are referenced with `${{ parameters.parameterName }}`. Using `$(environment)` attempts to resolve a variable named 'environment', but since 'environment' is defined as a parameter, it is not available as a variable at runtime, causing the resource group name to remain unresolved and the pipeline to fail.

Exam trap

The trap here is that candidates confuse the syntax for referencing parameters (`${{ }}`) with the syntax for referencing variables (`$()`), assuming both are interchangeable in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because the script type 'pscore' (PowerShell Core) is fully supported on Ubuntu agents in Azure Pipelines; it runs pwsh, which is cross-platform. Option C is wrong because parameters are fully supported in YAML pipelines directly, not only in templates; they can be defined at the pipeline level using the `parameters:` keyword. Option D is wrong because `trigger: none` only disables CI triggers, but the pipeline can still be run manually or via other triggers; it does not cause a failure due to unresolved variables.

Full explanation →

621

MCQhard

You manage a release pipeline that deploys to multiple environments. The pipeline uses variables that differ per environment. You want to avoid duplicating variable definitions. Which strategy should you use?

A.Use variable groups linked to environments

B.Use the 'variables' section in the pipeline YAML with conditions

C.Define variables in each stage of the YAML pipeline

D.Store all variables in Azure Key Vault and reference them in the pipeline

AnswerA

Variable groups can be scoped to environments.

Why this answer

Variable groups linked to environments allow you to define variables once and have different values per environment without duplication. Option A is correct because variable groups can be scoped to specific environments, allowing you to reuse the same variable names with different values across environments. Option B is incorrect because using conditions in the 'variables' section still requires you to define each variable for each condition, leading to duplication.

Option C is incorrect because defining variables in each stage duplicates the variable definitions across stages. Option D is incorrect because while Azure Key Vault is useful for secrets, it is not designed for all types of variables, and you still need to reference the secrets per environment, which does not avoid duplication of variable references.

Full explanation →

622

MCQeasy

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

A.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

B.condition: eq(variables['Build.SourceBranch'], 'main')

C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

D.condition: ne(variables['Build.Reason'], 'PullRequest')

AnswerA

This condition is correct because the Build.SourceBranch variable returns the full ref path, such as 'refs/heads/main', so the equality check accurately triggers only when the build originates from the main branch, ignoring other branches or tags.

Why this answer

The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Exam trap

The trap here is that candidates often assume `Build.SourceBranch` contains only the short branch name (like `main`) rather than the full Git ref path (`refs/heads/main`), leading them to choose Option B.

Why the other options are wrong

Missing 'refs/heads/' prefix, so it won't match.

This checks PR target branch, not the source branch.

This excludes PRs but does not limit to main branch.

Full explanation →

623

MCQhard

Your YAML pipeline uses the 'AzureResourceManagerTemplateDeployment' task to deploy ARM templates. You need to handle incremental deployments and ensure that the task fails if any resource already exists and cannot be updated. Which deployment mode should you specify?

A.Incremental

B.Complete

C.Validate

D.CreateOrUpdate

AnswerA

Incremental mode is the default ARM deployment mode that only adds, updates, or deletes resources that are specified in the template, leaving all other resources in the resource group untouched. This allows users to perform partial updates by modifying only the relevant resources without affecting the entire resource group's existing configuration.

Why this answer

The 'Incremental' deployment mode in the AzureResourceManagerTemplateDeployment task handles only changes specified in the template, leaving existing resources unchanged. If a resource already exists and cannot be updated (e.g., due to a property conflict or immutable resource), the deployment fails, meeting the requirement to fail on such conflicts. This mode is the standard for additive, non-destructive ARM template deployments.

Exam trap

The trap here is that candidates confuse 'Incremental' with 'Complete' mode, mistakenly thinking 'Complete' is safer for incremental updates, when in fact 'Complete' can delete resources not in the template, leading to data loss.

Why the other options are wrong

Complete mode deletes resources not in the template; it does not fail on existing resources that cannot be updated.

Validate mode only validates the template without actually deploying resources.

There is no deployment mode named 'CreateOrUpdate'; it is a behavior of Incremental mode.

Full explanation →

624

MCQeasy

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

A.Use a custom action to manually mask secrets in the logs.

B.Define secrets as environment variables directly in the workflow YAML.

C.Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.

D.After the workflow runs, delete the logs from GitHub.

AnswerC

This is the recommended approach because GitHub encrypts secrets at rest, restricts access to authorized users/actions, and automatically detects the exact secret value used in the workflow to redact it from all log output. Referencing secrets via ${{ secrets.SECRET_NAME }} keeps the actual value out of the YAML source and ensures that any accidental printing of that value is masked in real time.

Why this answer

GitHub automatically masks secrets referenced via the ${{ secrets.SECRET_NAME }} syntax in workflow logs. When a secret is used in a workflow, GitHub Actions scans the log output and replaces any occurrence of the secret value with '***', preventing exposure. This built-in mechanism is the recommended best practice as it requires no additional configuration and works across all steps and actions.

Exam trap

The trap here is that candidates may think manual masking or log deletion is necessary, overlooking GitHub's built-in automatic secret masking that works seamlessly when secrets are properly referenced via the ${{ secrets.SECRET_NAME }} syntax.

How to eliminate wrong answers

Option A is wrong because using a custom action to manually mask secrets is error-prone and unnecessary; GitHub already provides automatic masking for secrets referenced in the standard way. Option B is wrong because defining secrets as environment variables directly in the workflow YAML file would expose the secret values in plain text within the repository, defeating the purpose of secure storage. Option D is wrong because deleting logs after a run does not prevent exposure during the run or before deletion, and it also removes valuable debugging information; the correct approach is to prevent exposure proactively.

Full explanation →

625

Multi-Selectmedium

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Select 2 answers

A.Add a post-deployment approval gate to the Dev and QA stages.

B.Use the 'Approvals and gates' settings in the release pipeline stage.

C.Configure branch policy on the release branch to require approvals.

D.Add a 'Manual Validation' task in the YAML pipeline.

E.Add a pre-deployment approval gate to the Staging and Production stages.

AnswersB, E

In classic release pipelines, the 'Approvals and gates' settings are configured per stage and allow you to add pre-deployment and post-deployment approvals, as well as gates such as query-based checks or Azure Monitor alerts. Pre-deployment approvals are the built-in mechanism to pause the pipeline before a stage runs, ensuring authorized reviewers approve the release before it reaches environments like Staging and Production.

Why this answer

The 'Approvals and gates' settings in a release pipeline stage allow you to configure pre-deployment approvals, which require designated users to approve the deployment before it proceeds. This is the standard mechanism in Azure DevOps for implementing manual approval gates. Option E is correct because adding a pre-deployment approval gate specifically to the Staging and Production stages ensures that deployments to these environments are blocked until the required approvals are granted, meeting the requirement for manual approval before Staging and Production.

Exam trap

The trap here is that candidates often confuse post-deployment approvals (which happen after deployment) with pre-deployment approvals (which gate the deployment), or they incorrectly think branch policies or manual validation tasks are the correct way to add manual approval gates in a release pipeline.

Full explanation →

626

Multi-Selecteasy

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Select 2 answers

A.Maintain a shared wiki with project documentation and decisions.

B.Use multiple chat channels for each topic to organize discussions.

C.Use long email threads for decision-making to ensure full documentation.

D.Schedule daily stand-up meetings at a time that works for all time zones.

E.Avoid using pull request comments to reduce noise.

AnswersA, D

Maintaining a shared wiki centralizes project documentation and decisions in a single source of truth, with versioning and searchability that reduce redundant questions and ensure all team members, regardless of location or role, can access consistent, up-to-date information.

Why this answer

A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation and decisions, accessible asynchronously—critical for distributed teams. Additionally, scheduling daily stand-up meetings at a time that works for all time zones ensures regular synchronous alignment and promotes collaboration. Multiple chat channels can fragment discussions, long email threads are hard to follow, and avoiding PR comments removes a key asynchronous review/discussion mechanism.

Exam trap

The trap here is that candidates may think multiple chat channels improve organization, but Azure DevOps emphasizes asynchronous, traceable communication via work items, pull requests, and wikis rather than real-time chat fragmentation.

Full explanation →

627

MCQeasy

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

A.Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

B.Create a copy of the template and modify the step directly.

C.Use a conditional 'if' statement in the template to skip steps based on a parameter.

D.Use template parameters with a 'steps' object that can be injected to override the step.

AnswerD

This is the supported pattern: declare a template parameter of type 'steps' and pass it through to the steps section of a job or stage. For example, define `parameters: - name: stepsOverride type: steps default: []` and then use `steps: ${{ parameters.stepsOverride }}` in the template; the caller can supply a list of steps as an argument to replace the default behavior. Because the parameter is a full steps object, the calling pipeline can inject any arbitrary step definitions without modifying the template file itself. This approach keeps the template reusable while allowing per-pipeline overrides.

Why this answer

Azure DevOps YAML templates support parameterized steps objects. By defining a template parameter of type 'steps' with a default value, the calling pipeline can pass a custom steps object as an argument to that parameter, effectively overriding the default steps without modifying the template. No 'replace' keyword is used; the override is achieved by directly injecting the steps object via the parameter.

Exam trap

The trap here is that candidates may confuse the fictional 'overrides' keyword (Option A) with a real feature, or incorrectly assume that conditional logic in the template (Option C) is the only way to control step execution, when in fact Azure DevOps provides a dedicated parameter injection pattern for step replacement using a steps object parameter.

How to eliminate wrong answers

Option A is wrong because Azure DevOps YAML does not support an `overrides` keyword; this is a fictional construct. Option B is wrong because creating a copy of the template defeats the purpose of reuse and introduces maintenance overhead, which is not the intended solution for overriding steps without modifying the template. Option C is wrong because using a conditional `if` statement in the template requires modifying the template itself, which violates the requirement to avoid modifying the template.

Full explanation →

628

Matchingmedium

Match each Azure Test Plans concept to its definition.

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

Concepts

Matches

Container for test suites and configurations

Group of test cases

Individual test with steps and expected results

Execution of a set of test cases

Why these pairings

In Azure Test Plans, a Test Plan is a container for test suites and test cases with settings. A Test Suite groups test cases. A Test Case has steps and expected results.

A Test Run is an execution of test cases. A Test Point is a test case with a specific configuration.

Full explanation →

629

MCQhard

Refer to the exhibit. You have a YAML pipeline definition that builds a .NET application. You notice that the revision number is always 0. What is the most likely cause?

A.The 'DotNetCoreCLI@2' task does not support the counter expression.

B.The counter expression uses a variable that is not defined as a counter, causing it to reset.

C.The counter expression resets every time the pipeline runs because of the 'minorVersion' variable.

D.The counter expression is evaluated after the build steps, so it always returns 0.

AnswerB

The seed should be a static value or a counter itself; using a non-counter variable as seed resets the counter each run.

Why this answer

The counter expression in Azure DevOps YAML pipelines requires a named counter variable to persist its value across pipeline runs. If the variable used as the first parameter of the `counter` function (e.g., `minorVersion`) is not defined as a counter variable, the counter resets to the seed value (0) on each run. Option B correctly identifies that the variable is not defined as a counter, causing the revision number to always be 0.

Exam trap

The trap here is that candidates assume the counter expression automatically increments without needing the first argument to be a persistent counter variable, leading them to overlook the requirement that the variable used as the counter name must be defined as a counter in the pipeline.

How to eliminate wrong answers

Option A is wrong because the `DotNetCoreCLI@2` task fully supports the counter expression; the issue is not with the task but with how the counter variable is defined. Option C is wrong because the counter expression does not reset due to the `minorVersion` variable itself; it resets because that variable is not defined as a counter variable in the pipeline. Option D is wrong because the counter expression is evaluated at compile time, before any build steps run, so evaluation order is not the cause of the always-0 result.

Full explanation →

630

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. What built-in feature of GitHub Actions automatically prevents this?

A.Audit log monitoring

B.Secret scanning alerts

C.Required reviewers on workflows

D.Automatic log redaction

AnswerD

Automatic log redaction is the correct answer because GitHub Actions detects values of configured secrets in a job's output and replaces them with '***' in real time across all workflow run logs, effectively preventing secrets from appearing.

Why this answer

GitHub Actions includes a built-in feature that automatically redacts secrets from workflow run logs. When a secret is printed to the console, GitHub detects the secret value and replaces it with '***' in the log output, preventing accidental exposure. This redaction happens at the log rendering layer, not in the workflow execution, so the secret is never visible to users viewing the logs.

Exam trap

The trap here is that candidates often confuse secret scanning (which detects secrets in source code) with log redaction (which prevents secrets from appearing in CI/CD output), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because audit log monitoring records administrative actions and events in the organization, but it does not prevent secrets from appearing in build logs—it only provides a historical record after the fact. Option B is wrong because secret scanning alerts detect secrets committed to repositories (e.g., in code or configuration files), not secrets printed during workflow execution in logs. Option C is wrong because required reviewers on workflows enforce approval for pull request workflows, but they do not inspect or redact log output for secrets.

Full explanation →

631

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

A.Add a YAML template that includes the signing task and require all pipelines to extend it.

B.Set a branch policy requiring a signed build status.

C.Configure a manual approval gate on the build pipeline.

D.Use a Pipeline decorator to inject the signing task into every build pipeline.

AnswerD

Pipeline decorators are extension-based components that automatically inject a set of tasks into every pipeline (or a filtered subset) at either the start or end of a job, at the organization level. Because the decorator runs outside the individual pipeline definition, it cannot be bypassed by pipeline authors and does not require changes to existing YAML or classic builds. This provides the required guarantee that the signing task is applied to every build pipeline.

Why this answer

Pipeline decorators allow injecting tasks (like signing) into every pipeline globally without modifying individual pipeline definitions. Option A is wrong because YAML templates require each pipeline to explicitly extend them; they do not enforce automatic inclusion. Option B is wrong because branch policies control pull request merge conditions, not build steps.

Option C is wrong because manual approval gates are used in release pipelines to control promotion, not to enforce signing during build.

Full explanation →

632

MCQeasy

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

A.Require a pull request before merging and set required number of reviewers to 1

B.Require signed commits

C.Require status checks to pass before merging

D.Require conversation resolution before merging

AnswerA

Requiring a pull request before merging and setting the required number of reviewers to 1 ensures every change is proposed via a PR and must receive at least one human approval before merge. This directly enforces the code review requirement by blocking merges until a reviewer explicitly approves the pull request.

Why this answer

GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Exam trap

The trap here is that candidates may confuse 'requiring status checks' (automated validation) with 'requiring pull request reviews' (human validation), leading them to select option C instead of A.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity and integrity via GPG or S/MIME signatures, but it does not enforce any review process. Option C is wrong because requiring status checks to pass before merging ensures that CI/CD checks (e.g., tests, builds) succeed, but it does not mandate human review. Option D is wrong because requiring conversation resolution before merging ensures that all comments on a PR are marked as resolved, but it does not guarantee that a specific number of reviewers have approved the changes.

Full explanation →

633

MCQeasy

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

A.Publish Test Results task

B.Copy Files task

C.npm test

D.Publish Build Artifacts task

AnswerA

The Publish Test Results task is correct because it explicitly consumes test result files (e.g., JUnit, NUnit, VSTest) and uploads them to Azure Pipelines, enabling test analytics, failure reporting, and trend dashboards in the build summary.

Why this answer

The Publish Test Results task (A) is correct because it specifically ingests test result files (e.g., JUnit, NUnit, xUnit, or TRX formats) and publishes them to Azure DevOps, enabling test analytics, trend charts, and pass/fail reporting in the pipeline summary. For a Node.js application, after running unit tests with a framework like Jest or Mocha, the test results are typically output as JUnit XML files, and this task is required to make those results visible in the DevOps portal.

Exam trap

The trap here is that candidates confuse running tests (npm test) with publishing test results, not realizing that Azure DevOps requires a separate task to ingest and display test outcomes in the pipeline UI.

How to eliminate wrong answers

Option B (Copy Files task) is wrong because it only copies files from source to a destination folder; it does not parse or publish test results. Option C (npm test) is wrong because it is a script step that runs the test command defined in package.json, but it does not publish test results to Azure DevOps—it only executes the tests locally in the pipeline. Option D (Publish Build Artifacts task) is wrong because it publishes build outputs (e.g., compiled code, binaries) as artifacts for deployment, not test result files for reporting.

Full explanation →

634

MCQhard

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

A.The variable 'BuildConfiguration' is misspelled.

B.The branch 'main' does not exist.

C.All agents in the pool are currently busy.

D.The pipeline definition ID is incorrect.

AnswerC

When a build is queued without explicit agent demands, Azure Pipelines can run it on any agent in the specified pool. If all agents in that pool are currently executing other jobs, the build will remain in a queued state until an agent becomes available—this is a common cause of a build appearing stuck. The queue shows the build as 'Queued' or 'Waiting for agent' without raising an immediate error, which matches the exhibit behavior.

Why this answer

When a build remains in 'notStarted' status for an extended period, it typically means the pipeline is waiting for an available agent. Since the pipeline has no demands and priority is normal, the most likely cause is that all agents in the specified agent pool are currently busy executing other jobs, so the build is queued until an agent becomes free.

Exam trap

The trap here is that candidates often assume a 'notStarted' status is caused by a configuration error (like a missing branch or misspelled variable) rather than recognizing it as a classic symptom of agent pool exhaustion or queue saturation.

How to eliminate wrong answers

Option A is wrong because a misspelled variable like 'BuildConfiguration' would cause a build-time error or unexpected behavior during the build process, not prevent the build from starting; the build would still be assigned to an agent and run. Option B is wrong because if the branch 'main' does not exist, the build would fail at the source fetch step or trigger a 'not found' error, but the build would still be assigned to an agent and attempt to run, not remain 'notStarted'. Option D is wrong because the pipeline definition ID is used internally by Azure DevOps to identify the pipeline; an incorrect ID would prevent the build from being queued at all, resulting in an error when triggering the build, not a 'notStarted' status.

Full explanation →

635

MCQmedium

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

A.Use a Docker Compose task in the pipeline to start the database container before running integration tests.

B.Configure the pipeline to use a self-hosted agent that has the database already installed and running.

C.Install the database as a service in the pipeline using the Service Fabric task.

D.Use a PowerShell script in the pipeline to install and start the database on the build agent.

AnswerA

Docker Compose provides a declarative way to run dependent services as containers.

Why this answer

Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Exam trap

The trap here is that candidates may confuse the Docker Compose task with other Azure DevOps tasks like Service Fabric or generic scripting, failing to recognize that Docker Compose is the standard, built-in method for managing container dependencies in a pipeline.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with a pre-installed database introduces statefulness and environment drift, making builds non-reproducible and harder to maintain across agents. Option C is wrong because the Service Fabric task is designed for deploying and managing microservices on Azure Service Fabric, not for starting a database container as a service in a build pipeline. Option D is wrong because using a PowerShell script to install and start a database on the build agent is error-prone, slow, and pollutes the agent's environment, whereas Docker Compose provides a cleaner, containerized solution.

Full explanation →

636

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to pass a status check before merging. The status check should be provided by a pipeline that runs when a pull request is created. Which type of trigger should you configure in the pipeline YAML?

A.Push trigger

B.Manual trigger

C.PR trigger

D.Scheduled trigger

AnswerC

A PR trigger in Azure Pipelines automatically starts a pipeline whenever a pull request is created or gets new commits, enabling validation of code changes before merging. This is the correct trigger type for validating pull requests, as it directly responds to PR events.

Why this answer

A PR trigger (pr:) in Azure Pipelines YAML automatically runs the pipeline when a pull request is created or updated against a specified branch. This allows the pipeline to produce a status check that GitHub enforces as a required check before merging, fulfilling the policy requirement.

Exam trap

The trap here is that candidates often confuse push triggers with PR triggers, thinking a push to the target branch will suffice, but the status check must be tied to the PR's merge commit or head branch, which only a PR trigger can automate.

How to eliminate wrong answers

Option A is wrong because a push trigger runs the pipeline on commits to a branch, not on pull request creation, so it cannot provide a status check tied to the PR lifecycle. Option B is wrong because a manual trigger requires a user to explicitly start the pipeline, which is not automated and cannot enforce a required status check without human intervention. Option D is wrong because a scheduled trigger runs the pipeline at specified times (e.g., nightly), independent of pull request events, so it cannot provide a real-time status check for PRs.

Full explanation →

637

Multi-Selecteasy

Which TWO are best practices when configuring alerts in Azure Monitor for a production application?

Select 2 answers

A.Use metric alerts only for simple threshold-based conditions.

B.Use dynamic thresholds for metrics with seasonal patterns.

C.Create separate alert rules for each condition to avoid complexity.

D.Configure action groups to send notifications and run automated actions.

E.Ensure each alert rule uses a unique action group to isolate notifications.

AnswersB, D

Dynamic thresholds employ machine learning to model historical metric behavior, continuously adjusting the baseline to account for seasonal patterns such as time-of-day, weekly, or yearly fluctuations. This adaptive behavior minimizes false positives during predictable peaks and troughs, while still detecting genuine deviations that deviate from the learned pattern. For metrics with recurring seasonality, dynamic thresholds are the recommended approach because they automatically recalibrate as the baseline shifts, unlike static thresholds that require manual updates.

Why this answer

Dynamic thresholds in Azure Monitor use machine learning to automatically detect and adjust alert thresholds based on historical patterns, making them ideal for metrics with seasonal or cyclical behavior (e.g., CPU usage that spikes during business hours). This reduces alert noise and manual tuning effort compared to static thresholds.

Exam trap

The trap here is that candidates often assume metric alerts are only for simple thresholds (Option A) and overlook that dynamic thresholds are purpose-built for seasonal patterns, while also mistakenly thinking unique action groups per rule (Option E) improve isolation rather than creating unnecessary complexity.

Full explanation →

638

MCQhard

You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?

A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.

B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.

C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.

D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.

AnswerD

Auto-revert is a native environment setting that, when enabled, automatically redeploys the previously successful version (the last known good deployment) whenever post-deployment conditions, such as health-check gates, mark the current deployment as failed. This provides the automatic rollback behavior required without human intervention or a classic release pipeline, and it is fully integrated with YAML multi-stage pipelines. Setting post-deployment conditions ensures that the health check is evaluated before the revert trigger fires.

Why this answer

Azure DevOps environments support an 'Auto-revert' setting that automatically triggers a rollback to the previous successful deployment when a post-deployment health check (defined via post-deployment conditions) fails. This combines manual approval (pre-deployment approvals on the environment) with automatic rollback, meeting both requirements without additional tasks or release pipelines.

Exam trap

The trap here is that candidates confuse 'Auto-revert' with classic release pipeline features or assume manual intervention tasks are needed for rollback, overlooking the environment-level automatic rollback capability in YAML pipelines.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with pre-deployment approvals and a post-deployment automatic rollback trigger, but the question specifies a multi-stage YAML pipeline, not a classic release pipeline; the 'Auto-revert' feature is environment-specific and not a release pipeline trigger. Option B is wrong because configuring a post-deployment gate that fails the deployment does not automatically roll back; it only marks the deployment as failed, requiring manual intervention to revert. Option C is wrong because adding a manual intervention task to roll back contradicts the requirement for automatic rollback; manual intervention tasks require human action, not automation.

Full explanation →

639

MCQmedium

Your team uses GitHub for source control and wants to enforce that all pull requests into the main branch require at least two reviewers and must pass a status check from a CI pipeline. Which branch protection rule configurations should you apply?

A.Require a minimum of 2 reviewers, require status checks to pass before merging

B.Require signed commits and status checks

C.Require status checks to pass, but do not require reviewers

D.Require a minimum of 2 reviewers, but do not require status checks

AnswerA

This branch protection configuration enforces both mandatory peer review and automated quality gates: at least two reviewers must approve the pull request, and all required status checks (e.g., CI build and test jobs) must pass before merging. This is the correct combination to meet the stated requirements.

Why this answer

GitHub branch protection rules allow you to require a minimum number of reviewers before merging and to require status checks to pass. By setting 'Require a minimum number of reviewers' to 2 and enabling 'Require status checks to pass before merging', you enforce that every pull request into the main branch must be approved by at least two reviewers and must pass the CI pipeline status check, meeting the stated requirements.

Exam trap

The trap here is that candidates may think requiring signed commits or only status checks is sufficient, but the question explicitly demands both two reviewers and a CI status check, which only option A satisfies.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity but does not enforce the required two reviewers or the CI status check. Option C is wrong because it omits the requirement for at least two reviewers, which is explicitly needed. Option D is wrong because it omits the requirement for status checks to pass, leaving the CI pipeline result unenforced.

Full explanation →

640

MCQmedium

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

A.Enable 'Auto-rollback' in the release pipeline settings.

B.Use a multi-stage YAML pipeline with manual intervention.

C.Configure pre-deployment approval gates.

D.Add a post-deployment script that runs a rollback script on failure.

AnswerD

A rollback script can be triggered on failure to revert changes.

Why this answer

It directly addresses the requirement to automatically roll back the deployment when a database schema migration fails. By adding a post-deployment script that runs a rollback script on failure, you can execute custom logic (e.g., reverting schema changes using SQL scripts or tools like Entity Framework migrations) immediately after the deployment step detects an error. This approach provides fine-grained control over the rollback process, which is essential for database migrations that cannot be handled by Azure Pipelines' built-in auto-rollback feature, which only reverts the application deployment (e.g., swapping slots or restoring files) and does not execute custom rollback scripts.

Exam trap

The trap here is that candidates often confuse the built-in 'Auto-rollback' feature (Option A) with a comprehensive rollback solution, not realizing that it only reverts application artifacts and cannot handle stateful changes like database schema migrations, which require custom rollback scripts.

How to eliminate wrong answers

Option A is wrong because 'Auto-rollback' in release pipeline settings only reverts the application deployment (e.g., by swapping back deployment slots or restoring previous artifacts) and does not execute custom scripts to undo database schema changes, which are stateful and require specific rollback logic. Option B is wrong because a multi-stage YAML pipeline with manual intervention introduces a human approval step, which does not provide automatic rollback on failure; it only pauses the pipeline for manual decision-making, contradicting the requirement for an automated strategy. Option C is wrong because pre-deployment approval gates are used to validate conditions (e.g., checking monitoring metrics or work items) before allowing a deployment to proceed, and they do not trigger any rollback actions after a deployment has already failed.

Full explanation →

641

Multi-Selectmedium

You manage a release pipeline for a Java application that is deployed to Azure App Service. The pipeline currently uses manual approval gates. You need to implement automated quality gates to reduce manual intervention. Which THREE conditions can you use in the 'Post-deployment approvals' settings of a release pipeline? (Choose three.)

Select 3 answers

A.Azure Policy

B.Manual approval

C.Invoke Azure Functions

D.REST API

E.Query Azure Monitor alerts

AnswersC, D, E

Invoke Azure Functions is a native release gate that executes an Azure Function with the release context, using the function's response (e.g., success/failure, custom payload) to determine if the deployment should proceed. This enables robust, custom quality logic to be hosted serverlessly and automatically evaluated.

Why this answer

'Invoke Azure Functions' is a valid gate type in Azure DevOps release pipelines. It allows you to call an Azure Function as a quality gate, enabling custom automated checks (e.g., validating deployment health or running custom logic) without manual intervention. This directly supports the goal of reducing manual approvals by automating post-deployment validation.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) with a pipeline gate, or think that manual approval can be automated, when in fact the question explicitly asks for automated quality gates that reduce manual intervention.

Full explanation →

642

Multi-Selectmedium

Which THREE measures should be implemented to protect secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Restrict which pipelines can access the variable group

B.Log secret values to pipeline console for debugging

C.Use variable groups with locked variables

D.Link Azure Key Vault as a variable group

E.Store secrets in code as environment variables

AnswersA, C, D

Scoping access reduces exposure.

Why this answer

Restricting which pipelines can access a variable group ensures that only authorized pipelines can use secrets stored in that group, preventing unauthorized access or accidental exposure. This is a key security measure in Azure Pipelines to enforce the principle of least privilege.

Exam trap

The trap here is that candidates may think logging secrets is acceptable for debugging or that storing secrets in environment variables is safe, but both practices directly contradict Azure security best practices and can lead to credential leakage.

Full explanation →

643

MCQeasy

Your team wants to automatically assign a code reviewer from a specific security group when a pull request modifies files in a 'security' folder. Which Azure DevOps feature should you use?

A.Add a required reviewer policy for the branch.

B.Enable 'Automatically approve' for security group.

C.Code ownership policy with automatic reviewer assignment.

D.Branch policy with minimum number of reviewers.

AnswerA

A required reviewer policy on a branch mandates that at least one specified reviewer must approve every pull request targeting that branch, but it does not automatically assign a specific person based on the code changes; it simply enforces a generic approval requirement and cannot dynamically select a reviewer based on file paths or expertise.

Why this answer

Azure DevOps branch policies include a 'Required reviewers' policy that can be configured with a path filter. By specifying the path 'security' and adding the security group as required reviewers, the system will automatically add those reviewers to any pull request that modifies files in that folder. This is the built-in feature designed for this scenario.

A CODEOWNERS file can also suggest reviewers based on file paths, but it is not a branch policy and does not enforce that the review must occur.

Exam trap

Candidates may confuse CODEOWNERS with branch policies. The correct approach is to use a branch policy with required reviewers and a path filter, not the CODEOWNERS file alone.

How to eliminate wrong answers

Option A is wrong because a 'required reviewer policy' for a branch is a generic branch policy that mandates a specific reviewer for all pull requests targeting that branch, but it does not allow file-path-based conditional assignment like the security folder scenario requires. Option B is wrong because 'Automatically approve' is not a built-in Azure DevOps feature; it would bypass the review process entirely, which contradicts the goal of assigning a reviewer for security oversight. Option D is wrong because a branch policy with a minimum number of reviewers only enforces a count of reviewers, not the specific assignment of a reviewer from a particular security group based on file changes.

Full explanation →

644

MCQhard

You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?

A.Configure a branch protection rule on main that requires a pull request to merge into develop.

B.Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.

C.Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.

D.Set up a webhook in GitHub that calls an Azure Function to merge main into develop.

AnswerB

This workflow triggers on every push to main, uses a script or git commands to merge main into develop, and if conflicts arise, it creates a pull request for manual conflict resolution, providing timely automation while preserving human oversight for conflicting changes.

Why this answer

It uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.

Exam trap

The trap here is that candidates may choose a scheduled workflow (Option C) thinking it is sufficient, but it fails to handle merges that occur between scheduled runs and does not gracefully manage merge conflicts by opening a pull request.

How to eliminate wrong answers

Option A is wrong because a branch protection rule on main requiring a pull request to merge into develop does not automate the merge process; it only enforces a policy, leaving the team to remember to perform the merge. Option C is wrong because a scheduled daily workflow may miss merges that occur between runs, and it does not handle conflicts gracefully by opening a pull request—it only merges if there are no conflicts, which could silently skip merges. Option D is wrong because setting up a webhook to call an Azure Function introduces unnecessary complexity and external dependencies, and it does not natively handle merge conflicts by opening a pull request within GitHub.

Full explanation →

645

MCQhard

An organization uses an on-premises Jenkins server to build Docker images and push them to Azure Container Registry (ACR). The security team requires that all images be scanned for vulnerabilities before deployment. The DevOps team needs to automate this scanning after each push. What is the most efficient way to meet this requirement?

A.Use Azure Policy to enforce vulnerability scanning.

B.Configure a Jenkins job to scan images before pushing to ACR.

C.Configure a webhook in ACR to notify Jenkins to scan the image.

D.Create an ACR task that runs a vulnerability scanner triggered by image push events.

AnswerD

ACR tasks can be triggered by push events and run custom steps like scanning.

Why this answer

ACR Tasks natively support automated vulnerability scanning via integration with Azure Security Center or third-party scanners like Trivy. By creating an ACR task that triggers on image push events, the organization can scan images immediately after they are pushed without additional infrastructure or manual intervention. This approach is event-driven, serverless, and aligns with the requirement to automate scanning after each push.

Exam trap

The trap here is that candidates may confuse Azure Policy with an action that performs scanning, or assume ACR webhooks can directly trigger Jenkins jobs for scanning, when in fact ACR Tasks provide a simpler, event-driven, and fully managed solution for post-push scanning.

How to eliminate wrong answers

Option A is wrong because Azure Policy can enforce compliance rules (e.g., requiring scanning) but does not perform the actual vulnerability scanning; it only audits or denies resources that don't meet policy definitions, not trigger scans. Option B is wrong because scanning images before pushing to ACR would require the Jenkins job to pull the image back or scan locally, which adds latency and complexity, and does not leverage the push event as required. Option C is wrong because ACR does not support webhooks that notify Jenkins of push events for vulnerability scanning; ACR webhooks can trigger actions like sending notifications or invoking HTTP endpoints, but they are not designed to initiate scanning workflows directly, and this approach would require custom Jenkins plugin configuration and polling, making it less efficient than a native ACR task.

Full explanation →

646

Multi-Selectmedium

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Select 2 answers

A.Grant the least privilege to service connections

B.Use Azure Key Vault to store secrets and fetch them at runtime

C.Use the default hosted agent for all builds

D.Store secrets as plain text in pipeline variables

E.Allow contributors to bypass the required reviewer policy

AnswersA, B

Granting least privilege to service connections means configuring each Azure Pipelines service connection with only the minimum permissions required for its intended tasks, limiting the blast radius if credentials are compromised and preventing accidental or malicious overreach to unrelated Azure resources.

Why this answer

Granting the least privilege to service connections (Option A) is a core security principle that limits the permissions of automated processes to only what is strictly necessary, reducing the blast radius of a compromised connection. Using Azure Key Vault to store secrets and fetch them at runtime (Option B) ensures that sensitive values like API keys and passwords are never exposed in pipeline definitions or logs, and are securely retrieved via managed identities or service principals at execution time.

Exam trap

The trap here is that candidates may think using default hosted agents is secure because Microsoft manages them, but they overlook the risk of unpatched vulnerabilities or unnecessary software in the default image, and they may also mistakenly believe that storing secrets as pipeline variables is acceptable if they are marked as 'secret' in the UI, when in fact they are still stored in the pipeline's metadata and can be exposed in logs.

Full explanation →

647

MCQeasy

You have an Azure DevOps Pipeline that builds a Node.js application. The pipeline uses template expressions to conditionally run certain jobs based on the branch name. You notice that the condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is not evaluating as expected. What is the most likely cause?

A.The variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.

B.The condition syntax is correct but the branch name should not include 'refs/heads/'.

C.The variable 'Build.SourceBranch' is not available in the condition context.

D.The condition should be in a template expression instead of a runtime condition.

AnswerC

Correct. Template expressions are evaluated at compile time, where runtime variables like 'Build.SourceBranch' are not available. Therefore, the condition cannot evaluate correctly. Use a runtime condition instead, or pass the branch as a parameter.

Why this answer

The condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is used in a template expression, which is evaluated at compile time. However, 'Build.SourceBranch' is a runtime variable that is not available during compile time, causing the condition to fail. Template expressions can only reference parameters or variables defined within the template itself, not runtime pipeline variables.

To conditionally run jobs based on the branch, use a runtime condition (e.g., in the 'condition' property of a job or stage) instead of a template expression.

Exam trap

Candidates may assume that all predefined variables are available in template expressions, but runtime variables like Build.SourceBranch are only available at runtime. The correct approach is to use a runtime condition (e.g., in the job's condition field) instead of a template expression for branch-based conditions.

How to eliminate wrong answers

Option B is wrong because the condition syntax is correct, but the branch name should include 'refs/heads/' when using 'Build.SourceBranch' (if it were valid), but the real issue is the variable name is incorrect. Option C is wrong because 'Build.SourceBranch' is not a predefined variable in Azure DevOps; the correct variable is 'Build.SourceBranchName', which is available in the condition context. Option D is wrong because the condition is already a runtime condition (using 'eq'), and template expressions are used for compile-time evaluation, not for runtime conditions like this.

Full explanation →

648

MCQmedium

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

A.Post-deployment approvals on the Production environment

B.Deployment queue settings on the Production environment

C.Deployment gates on the Production environment

D.Pre-deployment approvals on the Production environment

AnswerD

Pre-deployment approvals are explicitly designed to pause the release pipeline before a deployment to an environment begins, requiring a designated approver to review and approve the release. For a Production environment, this ensures that a human sign-off is obtained before any code is deployed to Production.

Why this answer

Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Exam trap

The trap here is confusing pre-deployment approvals with deployment gates, as both can pause a deployment, but gates are automated checks (e.g., monitoring metrics) while approvals require explicit human action from a designated group.

How to eliminate wrong answers

Option A is wrong because post-deployment approvals occur after the deployment has already completed, not before, so they cannot gate the deployment to Production. Option B is wrong because deployment queue settings control how releases are queued and parallel execution, not manual approval requirements for a specific environment. Option C is wrong because deployment gates evaluate health metrics or external conditions automatically (e.g., via Azure Monitor or REST APIs) and do not provide manual approval from a specific group of users.

Full explanation →

649

MCQmedium

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

A.parameters:

B.arguments:

C.inputs:

D.variables:

AnswerA

Template parameters are defined under the `parameters:` key at the top of a YAML template file, allowing values to be passed from the calling pipeline via `${{ parameters.paramName }}` syntax. This makes templates reusable and configurable at compile time, before the pipeline runs.

Why this answer

The 'parameters' key in a YAML template is used to define parameters that can be passed to the template, allowing conditional execution based on the parameter value. Option B is incorrect: 'arguments' is not a standard YAML key for passing parameters to templates; it is used for specifying script arguments. Option C is incorrect: 'inputs' is used for task inputs within a step, not for template parameters.

Option D is incorrect: 'variables' are used to define pipeline variables, not for passing parameters to templates.

Full explanation →

650

MCQmedium

Refer to the exhibit. You are reviewing the branch policy configuration for the main branch in Azure DevOps. The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. The minimum approver count is 0 and direct push is disallowed. What is the effect of this policy?

A.Developers can push directly to main without a pull request.

B.Pull requests require at least two reviewers.

C.Both status checks are required to pass.

D.Pull requests must pass the 'continuous-integration/azure-devops' check, but no reviewer approval is needed.

AnswerD

The branch policy lists 'continuous-integration/azure-devops' under required status checks, so a pull request cannot be merged until that CI check succeeds. However, the Minimum approver count is explicitly configured to 0, meaning no reviewer approval is part of the merge gate. Thus, the pull request is blocked only by the CI pipeline result, not by human code review.

Why this answer

The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. With a minimum approver count of 0 and direct push disallowed, pull requests must pass the required CI check, but no reviewer approval is needed. This means the PR can be completed automatically once the CI check passes, without any human reviewer.

Exam trap

The trap here is that candidates assume 'minimum approver count = 0' means direct push is allowed, or that all listed status checks are required, when in fact only explicitly selected checks are mandatory.

How to eliminate wrong answers

Option A is wrong because direct push is disallowed, so developers cannot push directly to main without a pull request. Option B is wrong because the minimum approver count is 0, meaning no reviewer approval is required, not at least two. Option C is wrong because the policy explicitly requires only 'continuous-integration/azure-devops' to pass; 'security-scanner' is not required.

Full explanation →

651

MCQmedium

Refer to the exhibit. A developer commits code to the 'develop' branch. The pipeline does not trigger. What is the most likely reason?

A.The trigger is configured to only run on the 'main' branch.

B.The pipeline requires a manual trigger.

C.The pipeline has a CI trigger disabled.

D.The pool 'ubuntu-latest' is not available.

AnswerA

The YAML pipeline defines a CI trigger using `trigger: - main`, which instructs Azure Pipelines to start a run only for pushes that land on the `main` branch. A commit pushed to `devel` does not match that branch filter, so no pipeline run is created. Therefore the reason for the missing run is scope, not a bad agent pool or manual mode.

Why this answer

The trigger is set to 'main' branch only. Commits to 'develop' will not trigger the pipeline.

Full explanation →

652

MCQhard

Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?

A.Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.

B.Keep the single pipeline but add caching for dependencies.

C.Use a single pipeline but add conditional stages to skip unchanged services.

D.Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.

AnswerA

This approach uses path-based triggers to run individual service pipelines only when their source changes, reducing build time and resource usage. The additional comprehensive pipeline, triggered only by modifications to shared libraries, ensures cross-service integration tests still run when dependencies change, preserving integration testing without unnecessary builds.

Why this answer

It uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.

Exam trap

The trap here is that candidates may think caching (Option B) or conditional stages (Option C) are sufficient, but they fail to address the need for integration tests across services when shared libraries change, which requires a separate comprehensive pipeline with path triggers.

How to eliminate wrong answers

Option B is wrong because caching dependencies reduces build time for repeated steps but does not address the core issue of running the entire pipeline for every commit, including unchanged services. Option C is wrong because conditional stages to skip unchanged services still require evaluating the entire pipeline, and Azure Pipelines does not natively support skipping stages based on changed paths without complex scripting; it also does not solve the integration test problem for shared library changes. Option D is wrong because disabling the comprehensive pipeline means integration tests that span multiple services will not run when shared libraries change, breaking the requirement to maintain quality.

Full explanation →

653

MCQmedium

Your team uses Azure Pipelines to deploy a Node.js application. Recently, deployments have been failing intermittently due to a missing npm package. The pipeline runs successfully on the local agent but fails on the hosted agent. Which instrumentation strategy should you implement to identify the root cause?

A.Replace the hosted agent with a self-hosted agent.

B.Configure Application Insights for the Node.js app to monitor runtime errors.

C.Enable verbose logging for the npm install task and compare the output between pipeline runs.

D.Add a pipeline cache task for npm packages to ensure consistent restore.

AnswerC

Verbose logging shows detailed dependency resolution steps.

Why this answer

Enabling verbose logging for the npm install task allows you to see detailed output of package resolution and installation steps. By comparing the logs between the local agent (success) and hosted agent (failure), you can identify differences in npm registry availability, package versions, or authentication issues that cause the intermittent missing package. Option A is wrong because self-hosted agents might not match the hosted environment's configuration, and the goal is to diagnose the problem on hosted agents.

Option B is wrong because Application Insights monitors application runtime behavior, not build-time dependency installation. Option D is wrong because pipeline caching would reuse previously installed packages, which could mask the problem by not performing a fresh install, and does not help identify why the package is missing on hosted agents.

Full explanation →

654

MCQhard

You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?

A.Use GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.

B.Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.

C.Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.

D.Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.

AnswerD

GitFlow supports hotfix propagation; policies enforce quality.

Why this answer

(GitFlow) is the correct recommendation because it provides dedicated hotfix branches that can be merged into both main and develop, ensuring hotfix changes are propagated to all active branches. GitFlow also supports feature branches, release branches for stabilization, and minimizes merge conflicts by isolating work. Branch policies on main and develop enforce pull requests with required reviewers, and a pipeline can automate merging hotfixes into both branches.

Option A (GitHub Flow) lacks dedicated hotfix branches and release branches, making hotfix propagation difficult. Option B (trunk-based) relies on feature toggles and does not isolate hotfixes, increasing risk. Option C (forking) is designed for external contributions, not internal enterprise collaboration, and does not inherently handle hotfix propagation.

Full explanation →

655

MCQmedium

Your Azure DevOps project uses Git for source control. You want to enforce that all code changes are reviewed before merging into the main branch. Which branch policy should you enable?

A.Allow only comment resolution.

B.Require a successful build before merging.

C.Limit merge types to squash merge.

D.Require a minimum number of reviewers.

AnswerD

Setting a minimum number of reviewers is the branch policy that directly enforces code review: a pull request cannot be completed until the specified number of distinct users have explicitly approved it. This ensures that changes receive independent human verification before they are merged into the target branch.

Why this answer

The 'Require a minimum number of reviewers' branch policy ensures that a specified number of reviewers must approve a pull request before it can be merged, directly enforcing code review. Option A is incorrect because 'Allow only comment resolution' pertains to how comments are resolved, not requiring approvals. Option B is incorrect because 'Require a successful build before merging' validates build status but does not enforce review.

Option C is incorrect because 'Limit merge types to squash merge' controls the merge strategy, not the review process.

Full explanation →

656

MCQmedium

Refer to the exhibit. A release is created with the above command. The Dev environment starts deploying, but the Prod environment does not. Which is the most likely reason?

A.The Prod environment requires manual approval before deployment.

B.The release definition ID 5 is incorrect.

C.The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.

D.The build artifact with ID 123 is not accessible.

AnswerC

The Prod environment's pre-deployment condition is configured to trigger only after a successful deployment to the Dev environment. In Azure DevOps release pipelines, environment-level pre-deployment gates can be set to 'After environment' and specify a dependency on a prior environment's completion. If that condition is set to require Dev to succeed, the Prod deployment will remain in a 'Waiting' state until Dev finishes, which precisely matches the observed behavior. This is the default dependency model when you add environments sequentially, and it explains why Prod is delayed even though the artifact is valid and no approvals are configured.

Why this answer

The exhibit shows a release pipeline with a sequential deployment strategy where the Prod environment has a pre-deployment condition configured to wait for the Dev environment to succeed. In Azure DevOps, pre-deployment conditions can be set to trigger only after a specific environment (like Dev) completes successfully. Since the Dev environment is still deploying, the Prod environment remains in a waiting state and does not start.

Exam trap

The AZ-400 exam often tests the distinction between manual approval and sequential environment dependencies, where candidates mistakenly assume a missing approval gate when the real issue is a pre-deployment condition waiting for a prior environment to succeed.

How to eliminate wrong answers

Option A is wrong because while manual approval is a common pre-deployment condition, the exhibit does not show any approval gates configured; the most likely reason based on the default behavior is the sequential dependency. Option B is wrong because the release definition ID 5 is used to create the release, and if it were incorrect, the release creation itself would fail, not just the Prod deployment. Option D is wrong because if the build artifact with ID 123 were not accessible, the release creation or Dev deployment would fail first, not specifically block Prod while Dev is deploying.

Full explanation →

657

MCQeasy

A team wants to automatically destroy a temporary test environment after a pull request is merged or closed. What Azure DevOps feature should they use?

A.Environment with post-deployment approvals

B.Branch policy with required reviewers

C.Pipeline trigger on branch deletion

D.Service hook to Azure Functions

AnswerD

Service hooks can trigger external processes but are not the built-in feature for environment cleanup.

Why this answer

To automatically destroy a temporary test environment after a pull request is merged or closed, a service hook can subscribe to pull request lifecycle events (e.g., 'Pull request merged' or 'Pull request updated') and invoke an Azure Function to perform the cleanup. Environments with post-deployment approvals are used for controlling manual approvals before or after deployment, not for triggering resource destruction on PR events. Branch policies and branch deletion triggers do not inherently respond to PR merge/close events with environment management.

Exam trap

The trap is confusing environment approvals (a gating mechanism) with automation triggers. Approvals require human intervention and do not automatically initiate cleanup on PR merge/close.

How to eliminate wrong answers

Option B is wrong because branch policies with required reviewers control code review and merge gates, not the lifecycle of deployed environments. Option C is wrong because pipeline triggers on branch deletion fire when a branch is removed from the repository, but they do not inherently know about pull request merge or close events, and they cannot automatically destroy a test environment without additional custom logic. Option D is wrong because service hooks to Azure Functions can be used to trigger external processes on pull request events, but they are not a built-in Azure DevOps feature for environment lifecycle management; they require custom code and do not integrate directly with Azure Pipelines environment cleanup.

Full explanation →

658

MCQmedium

Your team uses Azure Boards to manage work items. You need to ensure that when a work item is moved to 'Closed', all linked pull requests in Azure Repos are automatically completed. What should you configure?

A.Service hook to a custom Azure Function

B.Work item 'Pull Request' tab

C.Work item rule (state transition rule)

D.Branch policy on the target branch

AnswerA

A service hook in Azure DevOps can subscribe to a 'Pull request completed' or 'Pull request merged' event and invoke an HTTP endpoint, such as an Azure Function, which then uses the REST API to transition an Azure Boards work item to the appropriate state. This is a valid external automation approach because it is not a built-in feature and requires custom code to correlate the PR to work items and call the update.

Why this answer

Azure Boards service hooks can trigger a custom Azure Function when a work item state changes to 'Closed', and that function can complete linked pull requests via Azure Repos REST API. Option C is incorrect because work item rules (state transition rules) in Azure Boards do not have a built-in action to automatically complete pull requests; they only allow changes to work item fields, not external actions like completing PRs.

Full explanation →

659

Multi-Selecteasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Select 2 answers

A.pull_request: branches: [ main ]

B.push: branches: [ main ]

C.release

D.workflow_dispatch

E.schedule

AnswersA, B

The `pull_request` event triggers the workflow when a pull request is opened, synchronized, or reopened, and the `branches: [ main ]` filter ensures it only runs for PRs whose base branch is `main`. This is the correct choice because it enables CI on proposed changes before merging, catching issues early in the review process while avoiding runs for PRs targeting other branches.

Why this answer

The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

Exam trap

The trap here is that candidates often confuse `pull_request` with `pull_request_target` or forget that `push` and `pull_request` are separate events, leading them to select only one trigger or add irrelevant triggers like `release` or `schedule`.

Full explanation →

660

MCQeasy

Your team is using GitHub Actions to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate the workflow to AKS without storing credentials in the repository. What should you use?

A.Use OpenID Connect (OIDC) with a federated identity credential.

B.Use the GITHUB_TOKEN to authenticate to Azure.

C.Use an SSH deploy key to authenticate to AKS.

D.Store an Azure service principal password as a GitHub secret.

AnswerA

OpenID Connect (OIDC) with a federated identity credential is the recommended approach because it eliminates static secrets: GitHub Actions exchanges a short-lived token with Azure AD, and Azure trusts the federated identity without requiring you to store any passwords or client secrets. This provides passwordless, rotation-free authentication that is more secure and easier to manage.

Why this answer

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token for Azure credentials using a federated identity credential, eliminating the need to store any long-lived secrets in the repository. This is the recommended approach for secure, passwordless authentication to Azure services, including AKS, because it uses token-based authentication that automatically rotates and is scoped to specific workflows.

Exam trap

The trap here is that candidates often confuse the GITHUB_TOKEN (which is for GitHub API calls) with an Azure authentication token, or they assume that storing a service principal password as a secret is acceptable, missing the security and compliance benefits of OIDC-based federated identity.

How to eliminate wrong answers

Option B is wrong because the GITHUB_TOKEN is scoped to the GitHub repository and cannot authenticate to Azure resources; it is used for GitHub API operations only. Option C is wrong because SSH deploy keys are used for Git repository access (e.g., cloning private repos), not for authenticating to Azure Kubernetes Service or any Azure resource. Option D is wrong because storing an Azure service principal password as a GitHub secret still requires managing a long-lived credential, which violates the requirement to avoid storing credentials in the repository and introduces security risks such as secret rotation and exposure.

Full explanation →

661

Multi-Selecthard

Which THREE are benefits of using a monorepo with Azure Repos and CI/CD pipelines?

Select 3 answers

A.Granular repository-level permissions

B.Faster build times due to smaller codebase

C.Easier code sharing across projects

D.Simplified dependency management

E.Atomic cross-component commits

AnswersC, D, E

Shared libraries are in the same repo.

Why this answer

A monorepo enables easier code sharing across projects by allowing multiple teams to reference the same source files, libraries, and modules without needing separate package feeds or cross-repo synchronization. In Azure Repos, this means you can use common build artifacts and shared code directly within the same repository, reducing duplication and simplifying collaboration.

Exam trap

The trap here is that candidates confuse the benefits of a monorepo with those of a multi-repo setup, assuming that a monorepo inherently improves build times or permissions granularity, when in reality it often worsens both without specific pipeline optimizations like sparse checkout or path-based triggers.

Full explanation →

662

MCQeasy

You are configuring a release pipeline to deploy to Azure App Service. You want to use the 'Deploy Azure App Service' task. Which authentication method should you use to securely connect Azure DevOps to the Azure subscription?

A.Azure CLI authentication with a user account.

B.Azure Resource Manager service connection using a service principal.

C.Use a SAS token for the App Service.

D.Managed Identity assigned to the Azure DevOps agent.

AnswerB

An Azure Resource Manager service connection using a service principal is the recommended secure, automated authentication method for CI/CD pipelines; it uses an app registration with a secret or certificate, enables fine-grained role-based access control, and avoids interactive login requirements.

Why this answer

The 'Deploy Azure App Service' task requires a secure, non-interactive connection between Azure DevOps and Azure. An Azure Resource Manager service connection using a service principal is the recommended and supported method because it uses Azure AD authentication with a client secret or certificate, enabling automated, credential-free deployments without user interaction or token expiry issues.

Exam trap

The trap here is that candidates confuse SAS tokens (used for storage-level access) with service principal authentication, or mistakenly think Managed Identity can be directly assigned to a non-Azure-hosted DevOps agent, when in fact service connections require a service principal for secure, automated subscription access.

How to eliminate wrong answers

Option A is wrong because Azure CLI authentication with a user account requires interactive login and is not suitable for automated pipelines; it also lacks the necessary service principal permissions for headless deployment. Option C is wrong because a SAS token is used for granting delegated access to Azure Storage resources (like blobs or files), not for authenticating Azure DevOps to the Azure subscription or App Service management plane. Option D is wrong because Managed Identity cannot be assigned directly to an Azure DevOps agent; it is a feature for Azure resources (e.g., VMs, App Services) and is not supported as an authentication method for Azure DevOps service connections.

Full explanation →

663

MCQmedium

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

A.Add the tool as a capability of the agent pool and use the 'Install Tool' task.

B.Add the 'Run Security Scan' task from the Azure DevOps marketplace.

C.Create a custom service hook to trigger the scan externally and wait for results.

D.Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.

AnswerD

A Command-Line, Bash, or PowerShell task can directly invoke any installed security scanning executable (e.g., Trivy, OWASP ZAP, a custom CLI, or a vendor's command-line tool) with the appropriate arguments, run it against the repository workspace, and fail the pipeline based on the tool's exit code. This is the standard, supported way to integrate command-line-based security scanning into an Azure Pipeline because it runs inside the agent job and can produce actionable results.

Why this answer

The security scan tool is installed on a self-hosted agent but not available as a built-in task or marketplace extension. Using a command-line task (Bash or PowerShell) allows you to directly invoke the tool's executable from the agent's file system, passing necessary parameters and capturing exit codes to determine success or failure. This approach integrates seamlessly with Azure Pipelines' standard task execution model without requiring custom extensions or external service hooks.

Exam trap

The trap here is that candidates may assume a marketplace task or service hook is required for any third-party tool, overlooking the simplicity and directness of using a command-line task when the tool is already installed on a self-hosted agent.

How to eliminate wrong answers

Option A is wrong because the 'Install Tool' task is designed to download and install tools from a specified URL or Azure storage, not to execute a tool already installed on the agent; adding the tool as a capability only labels the agent for targeting, it does not run the scan. Option B is wrong because the 'Run Security Scan' task from the marketplace does not exist for this specific third-party tool; marketplace tasks are pre-built integrations, and if the tool is not available there, you cannot use a generic marketplace task to execute it. Option C is wrong because creating a custom service hook to trigger the scan externally and wait for results introduces unnecessary complexity, latency, and potential failure points; service hooks are for event-driven notifications, not for synchronous execution of a local tool within a pipeline job.

Full explanation →

664

MCQhard

You are setting up a GitHub Actions workflow to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate to the AKS cluster using a service principal. What is the recommended way to store and use the service principal credentials?

A.Use managed identity for GitHub Actions and assign it to the AKS cluster

B.Store the service principal credentials in a Kubernetes secret in the AKS cluster

C.Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action

D.Store the service principal credentials as environment variables in the workflow file

AnswerC

GitHub Actions secrets are encrypted at rest, masked in logs, and injected into the workflow runtime only when explicitly referenced, making them the secure, supported way to pass service principal credentials. The 'azure/login' action accepts these credentials via secret inputs (e.g., 'client-id', 'client-secret', 'subscription-id', 'tenant-id') and uses them to establish an authenticated session with Azure, so storing them as GitHub Actions secrets and referencing them in that action is the correct, best-practice approach.

Why this answer

GitHub Actions secrets are the recommended secure mechanism for storing sensitive credentials like a service principal's client ID and secret. The 'azure/login' action can directly reference these secrets (e.g., `${{ secrets.AZURE_CREDENTIALS }}`) to authenticate to Azure, and then the 'azure/aks-set-context' action uses that authenticated session to connect to the AKS cluster. This approach avoids hardcoding credentials in the workflow file and leverages GitHub's encrypted storage.

Exam trap

The trap here is that candidates may confuse storing credentials in Kubernetes secrets (which is valid for in-cluster applications) with the initial authentication needed from an external CI/CD system, or they may think managed identities can be directly assigned to GitHub Actions runners, which is not supported.

How to eliminate wrong answers

Option A is wrong because managed identity for GitHub Actions is not directly supported for authenticating to AKS; managed identities are Azure resources that cannot be assigned to GitHub Actions runners, and the AKS cluster would need to trust the GitHub runner's identity, which is not a standard authentication flow. Option B is wrong because storing service principal credentials in a Kubernetes secret within the AKS cluster does not help the GitHub Actions workflow authenticate to the cluster initially; the workflow needs credentials to access the cluster before it can read any Kubernetes secrets. Option D is wrong because storing credentials as environment variables in the workflow file exposes them in plain text in the workflow logs and repository, violating security best practices and potentially leaking secrets.

Full explanation →

665

MCQhard

Your team uses trunk-based development with short-lived feature branches. You notice that code reviews often delay merging because reviewers are not available. What is the best way to reduce review latency while maintaining quality?

A.Enable auto-merge for pull requests that have passed all checks.

B.Require only one reviewer instead of two.

C.Create a separate review team that only handles pull requests.

D.Encourage pair programming or mob programming to review code in real-time.

AnswerD

Pair or mob programming embeds code review into the development process itself—another developer is continuously reviewing as the code is written, so there is no separate async review cycle to wait through at merge time. This directly reduces trunk-based development lead time and eliminates PR queue latency.

Why this answer

Pair programming or mob programming allows code to be reviewed in real-time during development, reducing the need for asynchronous pull request reviews and thus decreasing review latency while maintaining quality. Option A is incorrect because enabling auto-merge does not address reviewer availability; it still requires a review to be completed. Option B is incorrect because requiring only one reviewer may reduce review depth and quality.

Option C is incorrect because creating a separate review team can introduce new bottlenecks and does not solve the issue of reviewer unavailability.

Full explanation →

666

MCQhard

You are deploying a multi-container application to Azure Kubernetes Service (AKS) using Azure Pipelines. You need to ensure that the deployment rollback automatically if the health checks fail. Which strategy should you implement?

A.Configure a rolling update with readiness and liveness probes

B.Use a blue-green deployment strategy

C.Use Helm charts with pre-upgrade hooks

D.Implement a canary deployment with manual verification

AnswerA

Configure a rolling update with readiness and liveness probes: This approach leverages Kubernetes' native deployment controller to gradually replace pods while continuously checking health signals. If a readiness probe fails on new pods, the rollout immediately stops and Kubernetes automatically rolls back to the last healthy replica set, ensuring zero manual intervention and no downtime.

Why this answer

A rolling update with readiness and liveness probes is the correct strategy because Kubernetes automatically monitors pod health via these probes. If a new pod fails its readiness probe, the rolling update pauses; if the liveness probe fails, the pod is restarted. Azure Pipelines can be configured to detect probe failures and trigger a rollback to the previous stable ReplicaSet, ensuring automated recovery without manual intervention.

Exam trap

The trap here is that candidates often confuse deployment strategies (blue-green, canary) with the mechanism for automated health-check-based rollback, overlooking that Kubernetes native probes combined with rolling updates provide the simplest and most automatic solution.

How to eliminate wrong answers

Option B is wrong because blue-green deployment requires manual or scripted traffic switching and does not inherently provide automatic rollback based on health checks; it typically relies on external verification. Option C is wrong because Helm pre-upgrade hooks run before the upgrade and are used for tasks like database migrations, not for monitoring health after deployment or triggering rollbacks. Option D is wrong because canary deployment with manual verification depends on human approval to proceed or roll back, which contradicts the requirement for automatic rollback based on health checks.

Full explanation →

667

Multi-Selecthard

Which THREE features are available in GitHub Actions for managing secrets across environments?

Select 3 answers

A.Encrypted variables in workflows

B.Organization-level secrets

C.Secret scanning alerts

D.Environment-specific secrets

E.Repository-level secrets

AnswersB, D, E

Organization-level secrets are a core GitHub Actions feature that lets administrators define secrets once at the organization level so they are available to all repositories within that organization, enabling centralized management and consistent access across multiple workflows without duplicating sensitive values.

Why this answer

GitHub Actions supports three types of secrets for managing sensitive data: organization-level secrets, which are encrypted and shared across multiple repositories within an organization; repository-level secrets, which are available to all workflows in a single repository; and environment-specific secrets, which are scoped to a particular environment (e.g., production) within a repository. Together these allow centralized and scoped management of secrets across different environments and repositories. Options A and C are incorrect: 'encrypted variables in workflows' is not the official GitHub Actions secret feature, and secret scanning alerts is a reactive security service, not a secret management feature.

Exam trap

The trap here is that candidates confuse 'secret scanning alerts' (a reactive security feature) with proactive secret management features, or assume 'encrypted variables' is a valid term when GitHub Actions officially uses 'secrets' for encrypted sensitive data.

Full explanation →

668

MCQeasy

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

A.Set 'trigger: none' in YAML

B.Set 'trigger: branches: include: - release/*'

C.Set 'trigger: branches: include: - main'

D.Set 'trigger: tags: include: - v*'

AnswerB

Setting 'trigger: branches: include: - release/*' configures the pipeline to automatically run on every push to any branch matching the release/* wildcard. This precisely matches the requirement to trigger only for release branches, making it the correct choice.

Why this answer

The YAML trigger configuration 'trigger: branches: include: - release/*' explicitly specifies that the pipeline should run only when changes are pushed to any branch matching the 'release/*' wildcard pattern. This is the standard way to define branch-based triggers in Azure Pipelines YAML, ensuring that only pushes to release branches initiate the build.

Exam trap

The trap here is that candidates often confuse branch triggers with tag triggers or forget that omitting a trigger defaults to 'include all branches', leading them to incorrectly select a tag-based option or a branch that doesn't match the required pattern.

How to eliminate wrong answers

Option A is wrong because 'trigger: none' disables all CI triggers, meaning the pipeline will never run automatically on any branch push, which contradicts the requirement to trigger on 'release/*' branches. Option C is wrong because it includes only the 'main' branch, which does not match the 'release/*' pattern and would ignore pushes to release branches. Option D is wrong because it configures a tag-based trigger (tags starting with 'v'), not a branch-based trigger; tags are separate from branches and do not respond to branch pushes.

Full explanation →

669

MCQmedium

The exhibit shows a deployment job in an Azure Pipelines YAML file. The deployment fails with the error 'No package found with pattern: $(Pipeline.Workspace)/drop/*.zip'. What is the most likely cause?

A.The artifact is not downloaded to the expected path; the artifact name must be included in the path.

B.The wildcard pattern '*.zip' is not supported.

C.The Azure service connection has expired.

D.The pipeline is using a Microsoft-hosted agent that does not support the download task.

AnswerA

The downloaded artifact is placed under '$(Pipeline.Workspace)/<artifact name>/'. If the artifact is named 'drop', the correct path is '$(Pipeline.Workspace)/drop'.

Why this answer

The error indicates the deployment job is looking for a .zip file in a folder named 'drop' directly under the pipeline workspace. However, in Azure Pipelines, artifacts are downloaded to a folder named after the artifact, and the published artifact contains a 'drop' folder inside it (or 'drop' is merely a folder, not the artifact name). The correct path must include the artifact name first, e.g., '$(Pipeline.Workspace)/<artifact-name>/drop/*.zip'.

Option A correctly identifies that the artifact name is missing from the path.

Exam trap

The trap is that candidates often assume 'drop' is the artifact name or a workspace root folder, but in this case it is a subfolder inside the artifact. They overlook that the artifact name itself must be included in the package path.

How to eliminate wrong answers

Option B is wrong because wildcard patterns like '*.zip' are fully supported in Azure Pipelines file matching; the issue is the path, not the pattern. Option C is wrong because an expired Azure service connection would cause authentication failures (e.g., 401 or 403 errors) when connecting to Azure resources, not a 'no package found' error during artifact download. Option D is wrong because Microsoft-hosted agents fully support the Download Pipeline Artifact task and can download artifacts from the current pipeline; the error is unrelated to agent type.

Full explanation →

670

MCQhard

You need to implement a strategy to manage secrets for your multi-stage YAML pipeline. The pipeline runs on Microsoft-hosted agents. Which approach should you use to securely pass secrets to pipeline tasks?

A.Define the secrets as environment variables in the pipeline YAML directly.

B.Use the Azure Key Vault task to download secrets and then pass them as parameters.

C.Use pipeline variables with 'secret: true' and reference them as $(variableName).

D.Store secrets in a file in the repository and read it during the build.

AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

Azure Pipelines supports secret pipeline variables that are encrypted at rest and never exposed in logs or output. By defining a variable with `secret: true` in the YAML or via the UI, you can reference it securely as `$(variableName)` in tasks, ensuring the secret value is masked during execution.

Exam trap

The trap here is that candidates often confuse secret variables with environment variables or assume that Azure Key Vault integration requires a separate task to pass secrets as parameters, when in fact secrets are automatically mapped as pipeline variables and referenced with `$(variableName)`.

How to eliminate wrong answers

Option A is wrong because defining secrets as environment variables directly in the YAML file would expose them in plaintext in the repository and pipeline logs, violating security best practices. Option B is wrong because the Azure Key Vault task downloads secrets as pipeline variables (not parameters), and you should reference them directly via `$(variableName)` rather than passing them as parameters, which could inadvertently expose them. Option D is wrong because storing secrets in a file in the repository makes them part of the source code, defeating the purpose of secret management and risking exposure in version control history.

Full explanation →

671

Multi-Selecthard

Which TWO of the following are valid ways to trigger a pipeline in Azure DevOps when a pull request is created?

Select 2 answers

A.Pull request trigger in YAML pipeline

B.Scheduled trigger

C.Continuous integration trigger

D.Branch policy with build validation

E.Pipeline completion trigger

AnswersA, D

A YAML pipeline can define a pull request trigger with the 'pr:' keyword, causing the pipeline to run automatically whenever a pull request is created or updated against the specified branch, enabling validation of the proposed changes before merge.

Why this answer

Azure DevOps YAML pipelines support a `pr` trigger that automatically runs the pipeline when a pull request is created or updated. This trigger is defined directly in the YAML file and can be scoped to specific branches or paths, making it a native and flexible way to respond to PR events.

Exam trap

The trap here is that candidates often confuse the continuous integration trigger (which fires on push) with the pull request trigger, or they overlook that branch policy build validation is a separate but equally valid method to trigger a pipeline on PR creation.

Full explanation →

672

Multi-Selecthard

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Hardcode secrets in the pipeline YAML for simplicity.

B.Store secrets as plain text variables in YAML pipelines.

C.Use Azure Key Vault to store secrets.

D.Use a library variable group linked to Azure Key Vault.

E.Reference secrets as secret variables in pipeline tasks.

AnswersC, D, E

Use Azure Key Vault to store secrets because it is a centralized, cloud-based secret management service that provides strong encryption, granular access policies with Azure AD authentication, audit logging, and automated secret rotation, ensuring secrets are never exposed in code or logs.

Why this answer

Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Exam trap

The trap here is that candidates may think storing secrets as plain text variables is acceptable if they are marked as 'secret' in the pipeline UI, but those values are still stored in the pipeline definition and can be exposed in logs or exports, whereas Key Vault provides centralized, audited secret management.

Full explanation →

673

MCQhard

The exhibit shows a parameters file for an ARM template deployment. During a release pipeline, the deployment fails with the error 'The provided value for the template parameter 'sku' is not valid'. The ARM template defines the 'sku' parameter as an allowed value set of ['F1', 'D1', 'B1', 'S1']. What could be the issue?

A.The parameter file contains an extra space or hidden character in the 'sku' value.

B.The parameter file is missing the '$schema' property.

C.The 'sku' parameter is defined in the 'variables' section instead of 'parameters'.

D.The ARM template expects a different API version for the resource.

AnswerA

Even though 'S1' appears correct, hidden characters can cause the value to not match the allowed values.

Why this answer

The error indicates that the value provided for the 'sku' parameter is not within the allowed set ['F1','D1','B1','S1']. Even if the exhibit appears to show 'S1', the actual value might contain invisible characters (e.g., leading/trailing spaces, newline, tab, or a BOM) or a typographical variation (like a different dash or letter), causing it to not exactly match 'S1'. Option B is incorrect because a missing '$schema' property would produce a different error about the parameter file schema, not about parameter value validation.

Option C is incorrect because defining 'sku' in the variables section would be a template error (or a different parameter-related error), and the error explicitly mentions the parameter 'sku', so it exists as a parameter. Option D is incorrect because an API version mismatch would cause a resource-manager-specific error about the API or resource, not the parameter value.

Full explanation →

674

MCQhard

Refer to the exhibit. You are reviewing the branch policies for the main branch in Azure Repos. The team reports that while the branch naming policy works, the approval policy does not block pull requests when only one person approves. What is the most likely cause?

A.The policy is disabled in the settings

B.The policy is not applied to the main branch

C.The main branch has a separate branch policy override that allows one approval

D.The 'creatorVoteCounts' setting is false, so the creator's approval is not counted

AnswerB

The policy's scope is set to "refs/heads/*", a wildcard that matches all branches, including "main". Therefore the policy does apply to the main branch, so this explanation cannot account for the reduced approval requirement.

Why this answer

Option B is correct. If the minimum approver count policy is configured for a branch other than `main` (or is scoped to a different branch pattern), it will not apply to pull requests targeting `main`. The branch naming policy works because that is a repository-level setting that applies to all branches.

There is no 'project-level' branch policy override in Azure Repos; branch policies are scoped to specific branches or patterns, and if multiple policies apply, all must be satisfied. A separate policy on main that allows one approval would not override an all-branches policy requiring two approvals — the stricter policy would still block. Therefore, the cause must be that the approval policy simply does not apply to main.

Exam trap

Do not confuse repository-level settings (like branch naming) with branch-level policies (like minimum reviewers). Policies are additive and cannot be 'overridden' by another policy.

Full explanation →

675

MCQeasy

A company uses Azure DevOps and needs to ensure that all pipelines use approved YAML templates from a central repository. The security team wants to prevent developers from referencing unapproved templates. What is the best way to enforce this?

A.Create a branch policy on the repository that requires all pull requests to be approved by security team members.

B.Configure a variable group with the approved template repository and require it in all pipelines.

C.Use a pipeline decorator to check the template origin and fail the pipeline if unapproved.

D.Set the 'Required template' repository setting in the Azure DevOps project to the approved central repository.

AnswerC

A custom pipeline decorator could technically inspect template origins and fail the build, but it requires you to write, publish, and maintain a private extension, which is complex and error-prone. The built-in 'Required template' repository setting provides the same enforcement more simply and reliably without custom code.

Why this answer

The correct approach is to use a pipeline decorator that runs at the start of every pipeline, inspects the YAML for template references, and fails the pipeline if any template is not from the approved central repository. The 'Required template' setting forces inclusion of a template but does not block additional unapproved template references.

Exam trap

The trap is that candidates may assume 'Required template' blocks all unapproved templates. In reality, it only enforces inclusion of a mandatory template. Pipeline decorators are a valid and robust way to enforce template origin restrictions.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval by security team members only controls changes to the repository's code, not the templates referenced in pipelines; developers could still merge code that references unapproved templates in other repositories. Option B is wrong because a variable group can store the approved repository URL, but it does not enforce that pipelines actually use it; developers can still hardcode or override the template source in their YAML files. Option C is wrong because pipeline decorators are injected at runtime and can check template origins, but they are not a native enforcement mechanism; they require custom scripting and maintenance, and can be bypassed if the decorator is not applied to all pipelines or if the pipeline agent has sufficient permissions.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 601–675