Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 676–696 | Page 10/10

676

MCQmedium

Your team is migrating from TFVC to Git in Azure Repos. They want to preserve the history of all branches. Which migration tool should you use?

A.GitHub Importer

B.Azure DevOps Migration Tools

C.git-tfs tool

D.git-svn

AnswerC

The git-tfs tool bridges TFVC and Git, cloning a TFVC repository into a Git repository while preserving full changeset history across all branches. This satisfies the requirement to retain branch history during migration to Azure Repos, which a plain git init or export would discard.

Why this answer

The git-tfs tool is specifically designed to migrate TFVC repositories to Git while preserving full branch history, including changesets, branch relationships, and merge history. It bridges the gap between TFVC and Git by converting TFVC changesets into Git commits and mapping TFVC branches to Git branches, making it the correct choice for this migration scenario.

Exam trap

The trap here is that candidates often confuse git-tfs with git-svn, assuming both are interchangeable for any centralized-to-distributed migration, but git-tfs is TFVC-specific while git-svn is for Subversion, and Azure DevOps Migration Tools are for organizational data migration, not source control conversion.

How to eliminate wrong answers

Option A is wrong because GitHub Importer is used to import repositories from other Git hosts (like SVN, Mercurial, or another Git server) into GitHub, not from TFVC to Azure Repos. Option B is wrong because Azure DevOps Migration Tools are designed for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC source control history to Git. Option D is wrong because git-svn is a tool for bidirectional operation between Git and Subversion (SVN), not for TFVC migration.

Full explanation →

677

MCQhard

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

A.Use Git LFS to store all files

B.Split the monorepo into multiple smaller repositories

C.Add a .gitattributes file with filter directives

D.Enable sparse checkout and shallow fetch

AnswerD

Sparse checkout restricts the working tree to only the directories or files you actually need, reducing checkout time and disk usage. Shallow fetch with a depth limit downloads only the most recent commits, drastically reducing the number of objects transferred; combined, these are the standard Git techniques to speed up work with a large monorepo.

Why this answer

Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

Exam trap

The trap here is that candidates often confuse performance improvements with repository restructuring, assuming that splitting the repo (Option B) is the only way to speed up Git, when Azure DevOps supports native Git features like sparse checkout and shallow fetch that preserve the monorepo architecture.

How to eliminate wrong answers

Option A is wrong because Git LFS is intended for large binary files, not for improving general Git performance on a large monorepo; storing all files in LFS would introduce overhead and break normal Git workflows. Option B is wrong because splitting the monorepo into multiple smaller repositories violates the requirement to maintain a single repository. Option C is wrong because .gitattributes with filter directives is used for custom smudge/clean filters (e.g., for Git LFS or keyword expansion), not for reducing the size or history of the repository to speed up operations.

Full explanation →

678

MCQmedium

Refer to the exhibit. You are reviewing an ARM template used in an Azure Pipeline deployment. Which security concern should you address?

A.The VM size is too small for production

B.The apiVersion is outdated

C.The admin password is hardcoded in the template

D.The location parameter has a default value

AnswerC

Hardcoding the admin password as a plaintext string in the ARM template or its default parameters exposes the secret to anyone with read access to the source repository or deployment history. The template should accept the password via a secureString parameter and reference an Azure Key Vault secret, or use a managed identity and guest configuration to set credentials without embedding them.

Why this answer

Hardcoding an admin password directly in an ARM template exposes credentials in source control, pipeline logs, and deployment history, creating a serious security vulnerability. The correct remediation is to reference a secret from Azure Key Vault or use a secure parameter, not to embed the value. This is the security concern the question asks you to identify.

Exam trap

The trap is that candidates focus on technical template correctness (apiVersion, VM size, defaults) rather than the security anti-pattern — the exam expects you to spot the hardcoded credential as the priority security issue.

How to eliminate wrong answers

Option A is wrong because VM size is a performance/cost consideration, not a security concern, and the question asks specifically about security. Option B is wrong because an outdated apiVersion is a compatibility/maintenance issue that may cause deployment failures, but it is not a security vulnerability. Option D is wrong because having a default value for the location parameter is a normal and acceptable ARM template practice, not a security risk.

Full explanation →

679

Multi-Selecthard

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Select 2 answers

A.In the Deploy stage, set 'dependsOn: [Build, Test]'

B.In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'

C.In the Deploy stage, set 'condition: succeeded()' and 'dependsOn: [Build, Test]'

D.In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''

AnswersA, C

Setting 'dependsOn: [Build, Test]' is correct because the default stage condition is 'succeeded()', which evaluates to true only if all explicitly listed dependency stages (Build and Test) complete successfully. This ensures Deploy runs only after both stages succeed without requiring an explicit condition.

Why this answer

Setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Exam trap

The trap here is that candidates often confuse the 'succeeded()' function with the ability to check individual stage results, leading them to incorrectly select Option B, or they misremember the exact syntax for accessing stage dependencies in Option D.

Why the other options are wrong

This syntax is for job conditions; stage conditions do not accept string arguments for succeeded().

'stageDependencies' is not a valid expression; you would use 'dependencies.Build.result'.

Full explanation →

680

MCQmedium

Refer to the exhibit. You have this GitHub Actions workflow YAML. The workflow does not trigger when you push to the main branch. What is the most likely issue?

A.The branch name should be in a list under 'branches' inside 'push'.

B.The 'vmImage' should be 'windows-latest' for scripts.

C.The correct keyword is 'on', not 'triggers'.

D.The 'triggers' keyword is misspelled; it should be 'trigger'.

AnswerC

GitHub Actions uses the top-level `on` key to define the events that trigger a workflow, such as `push` or `pull_request`. The exhibit incorrectly uses `triggers`, which is not a recognized key in GitHub Actions syntax, causing the workflow to be invalid or never run.

Why this answer

GitHub Actions workflows use the `on` keyword to define triggers, not `triggers`. The YAML snippet incorrectly uses `triggers`, which is not a valid key in GitHub Actions syntax; the workflow engine ignores it, so no push event on `main` will start the workflow. This is a common syntax error where the candidate confuses Azure Pipelines (which uses `trigger`) with GitHub Actions (which uses `on`).

Exam trap

The trap here is that candidates familiar with Azure Pipelines might choose option D, thinking `triggers` is a misspelling of `trigger`, but GitHub Actions requires `on`, not `trigger`.

How to eliminate wrong answers

Option A is wrong because GitHub Actions allows a single string or a list under `branches`; a single string like `main` is valid, so the issue is not the format. Option B is wrong because `vmImage: 'ubuntu-latest'` is perfectly valid for running scripts; there is no requirement to use `windows-latest` for scripts. Option D is wrong because the keyword is not `trigger`; GitHub Actions uses `on`, not `trigger` or `triggers`, so the misspelling is irrelevant.

Full explanation →

681

MCQhard

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

A.Set the 'Timeout in minutes' for the entire stage to 15.

B.In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.

C.Configure a pre-deployment approval with a timeout of 15 minutes.

D.Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.

AnswerB

The Manual Validation task has a 'Timeout' property and an 'On timeout' action. By setting the timeout to 15 and 'On timeout' to 'Reject', if a user does not respond within 15 minutes, the task automatically rejects the deployment, which immediately stops the pipeline and marks the deployment as rejected. This is the only option that directly enforces the desired rejection on a per-validation basis.

Why this answer

The Manual Validation task has a 'Timeout' setting and an 'On timeout' option. Setting Timeout to 15 minutes and On timeout to 'Reject' will automatically reject the deployment if not approved within 15 minutes. Additionally, you can configure a notification using an Azure DevOps subscription or service hook for the rejection event.

Option A is incorrect because the stage timeout does not specifically handle manual validation rejection. Option C is incorrect because, although pre-deployment approvals do have a timeout that can reject on timeout, they apply to the approval gate before the stage, not to a manual validation task within the stage. Option D is incorrect because adding a PowerShell task is unnecessary and less reliable than the built-in timeout behavior.

Full explanation →

682

MCQeasy

Your team uses GitHub Flow for feature development. A developer commits directly to the main branch without creating a pull request. Which practice should you enforce to ensure code quality and prevent direct commits?

A.Require a manual sign-off from a team lead after each commit.

B.Configure branch protection rules on the main branch to require pull request reviews before merging.

C.Set up a .gitignore file to prevent certain file types from being committed.

D.Add a CODEOWNERS file that automatically assigns reviewers to any changes.

AnswerB

Configuring branch protection rules on the main branch to require pull request reviews before merging is correct because GitHub branch policies natively block direct pushes and enforce PR-based collaboration. By requiring at least one approved review, you integrate quality checks into the merge workflow, ensuring feature changes go through review before reaching the main branch—a core mechanism in GitHub Flow.

Why this answer

Branch protection rules on the main branch are the GitHub-native mechanism to require pull request reviews before any merge, which directly prevents direct commits. Enabling 'Require a pull request before merging' with a minimum number of approvals blocks the developer's direct push and forces the GitHub Flow review step.

Exam trap

The trap is assuming CODEOWNERS or .gitignore enforce policy — they only suggest reviewers or ignore files; only branch protection rules actually block direct commits to a protected branch.

How to eliminate wrong answers

Option A is wrong because a manual sign-off after each commit is a post-hoc, human process with no enforcement — the commit already landed on main, so quality was not prevented. Option C is wrong because .gitignore only prevents untracked files from being staged; it has no effect on commits to tracked files or on branch-level policy. Option D is wrong because a CODEOWNERS file only auto-assigns reviewers to pull requests — it does not block direct pushes and does nothing if no PR is opened.

Full explanation →

683

MCQmedium

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

A.Skip the approval for this deployment by overriding the settings.

B.Add an additional approver in the pre-deployment approval settings.

C.Configure the approval to time out after 24 hours and automatically approve.

D.Remove the approval requirement from the pipeline.

AnswerB

Adding an additional approver in the pre-deployment approval settings ensures that if the primary approver is unavailable, a designated backup can review and approve the release, allowing the deployment to proceed without delay. This maintains the required human gate and auditability, unlike skipping or auto-approving, making it the correct approach to handle approver unavailability.

Why this answer

Adding an additional approver in the pre-deployment approval settings allows another authorized user (e.g., a backup manager or team lead) to approve the deployment while the primary manager is unavailable. This maintains the required governance and security controls without blocking the critical release. Azure Pipelines supports multiple approvers, and any one of them can approve to proceed.

Exam trap

The trap here is that candidates may think skipping or removing the approval is acceptable for a critical release, but Azure DevOps enforces governance; the correct approach is to add an additional approver to maintain control while enabling progress.

How to eliminate wrong answers

Option A is wrong because skipping the approval by overriding settings bypasses the required governance and security controls, which violates compliance policies and could lead to unauthorized deployments. Option C is wrong because configuring the approval to time out after 24 hours and automatically approve would cause an unacceptable delay for a critical release and still does not guarantee timely approval. Option D is wrong because removing the approval requirement from the pipeline permanently eliminates the approval gate for all future deployments, which is an overreaction and weakens the release governance.

Full explanation →

684

Multi-Selecthard

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Select 3 answers

A.Run CI builds on the main branch.

B.Use feature flags and pair programming.

C.Merge to main only once per week.

D.Use short-lived feature branches that are merged within a day.

E.Create release branches for each production release.

AnswersA, B, D

Running CI builds on the main branch is a core trunk-based development practice: every commit to main must compile and pass automated tests, ensuring the integration point is always stable and deployable, which allows teams to merge frequently without accumulating integration debt.

Why this answer

Trunk-based development requires developers to integrate into the main branch frequently. In Azure Repos, you set a CI trigger on main so every commit is built and validated (A). Developers use short-lived feature branches that are merged into main within a day (D) to keep integration conflicts small.

Feature flags and pair programming are supporting practices that allow work to be integrated even before a feature is complete, avoiding long-running branches (B). Merging to main only once per week (C) contradicts the continuous-integration principle, and creating a release branch for every production release (E) is characteristic of GitFlow/release-flow, not trunk-based development.

Exam trap

The trap here is that candidates confuse trunk-based development with GitFlow or release-based branching strategies, leading them to select options like creating release branches or infrequent merges, which are antithetical to the trunk-based workflow's emphasis on continuous integration and minimal branching.

Full explanation →

685

MCQmedium

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

A.Define the parameter in the 'parameters:' section of the YAML pipeline.

B.Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.

C.Use a task to replace the string '${environment}' in the Bicep file before deployment.

D.Modify the Bicep file to include a default value for environment.

AnswerB

The overrideParameters field in the AzureResourceManagerTemplateDeployment task accepts key-value pairs that override Bicep/ARM template parameters at deployment time. By setting a pipeline variable and referencing it like -environment $(environment), you dynamically supply the environment-specific value per stage, leveraging Azure DevOps native variable scoping.

Why this answer

The AzureResourceManagerTemplateDeployment task's `overrideParameters` property allows you to dynamically pass parameter values at deployment time. By setting a pipeline variable named `environment` (which can be scoped per stage) and referencing it as `$(environment)` in `overrideParameters`, you can inject the correct value ('dev', 'qa', or 'prod') based on the release stage without modifying the Bicep file or its defaults.

Exam trap

The trap here is that candidates confuse YAML pipeline parameters (defined with `parameters:`) with Bicep file parameters, or assume that modifying the Bicep file's default value is a valid dynamic override, when in fact `overrideParameters` is the intended mechanism for stage-specific value injection.

How to eliminate wrong answers

Option A is wrong because the `parameters:` section in a YAML pipeline defines pipeline-level parameters (e.g., for manual triggers or template inputs), not runtime overrides for a Bicep file's parameters; it cannot pass values directly to the ARM deployment task's `overrideParameters`. Option C is wrong because string replacement in the Bicep file before deployment is an unnecessary and fragile workaround; Bicep files are compiled to ARM templates, and the proper way to supply parameter values is via the deployment task's `overrideParameters` or parameter file. Option D is wrong because adding a default value to the Bicep file would fix the parameter to a single value (e.g., 'dev') and prevent dynamic assignment per stage, which defeats the purpose of stage-specific overrides.

Full explanation →

686

MCQhard

Your Azure DevOps pipeline deploys to multiple environments. You want to require manual approval before production deployment, but only if the deployment originated from a branch other than 'main'. How can you implement this?

A.Set a pre-deployment approval on the production environment

B.Configure a deployment group with approval gates

C.Use a branch policy that requires approval for non-main branches

D.Add a manual validation task with a condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')

AnswerD

Add a manual validation task with a condition: This is the correct method. However, the condition in the option uses `eq` instead of `ne`, which would trigger approval for main branches. When corrected to `ne(variables['Build.SourceBranch'], 'refs/heads/main')`, it pauses the pipeline for approval only when the source branch is not main, fulfilling the requirement.

Why this answer

To require manual approval only for non-main branches, add a manual validation task to the production deployment job with a condition checking that the source branch is not main: `ne(variables['Build.SourceBranch'], 'refs/heads/main')`. This pauses the pipeline and waits for approval. Pre-deployment approvals (A) cannot be conditional on branch, and deployment groups (B) are not for manual approval.

Branch policies (C) do not apply to pipeline stages.

Exam trap

The trap is to use the condition `eq` instead of `ne`, which would require approval on main branches instead of non-main branches. Pre-deployment approvals (option A) are unconditional and cannot be scoped to branch conditions.

How to eliminate wrong answers

Option A is wrong because a pre-deployment approval on the production environment applies to ALL deployments to that environment, regardless of the source branch, and cannot be conditionally applied based on branch. Option B is wrong because deployment group approval gates are used for controlling deployments to physical or virtual machines in a deployment group, not for conditional branch-based approvals in multi-environment pipelines. Option C is wrong because branch policies apply to pull requests and code changes in the repository, not to pipeline deployment approvals; they cannot gate a release pipeline's deployment step.

Full explanation →

687

MCQeasy

You need to ensure that only approved users can deploy to production from Azure Pipelines. What should you implement?

A.Pipeline approval gates

B.Microsoft Entra ID Conditional Access policies

C.Environment checks with required approvers

D.Branch protection rules in GitHub

AnswerC

In Azure Pipelines, an environment acts as a container for deployment targets and supports checks that control entry before a job executes. Adding an Approvals check to the Production environment lets you designate specific users or groups as required approvers; when a pipeline tries to deploy to that environment, the run pauses until one of those approvers explicitly approves or rejects the deployment. This is the native, supported mechanism that ensures only approved users can authorize releases to production, and it can be combined with other checks like branch control or time windows.

Why this answer

Azure Pipelines environment checks with required approvers allow you to enforce that only specific users or groups can approve deployments to a production environment. This is a native Azure DevOps feature that integrates with pipeline stages to gate deployments based on manual approval, ensuring that unauthorized users cannot trigger or approve production releases.

Exam trap

The trap here is that candidates often confuse pipeline approval gates (which are checks like monitoring or security scans) with environment-level required approvers (which are manual approval steps), leading them to select option A instead of C.

How to eliminate wrong answers

Option A is wrong because pipeline approval gates are a broader concept that can include manual approval checks, but they are not specifically designed to restrict which users can deploy to production; they are more about adding checks before a stage runs. Option B is wrong because Microsoft Entra ID Conditional Access policies control access to Azure resources and applications based on conditions like location or device compliance, but they do not directly integrate with Azure Pipelines to restrict who can approve or execute a deployment. Option D is wrong because branch protection rules in GitHub protect branches from direct pushes or merges without review, but they do not control who can deploy from Azure Pipelines to a production environment; they are a source control mechanism, not a deployment approval mechanism.

Full explanation →

688

Multi-Selectmedium

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Select 2 answers

A.Built-in secrets management for connection strings.

B.Reduced cost because VMs are shut down when not in use.

C.Automatic scaling of virtual machines based on load.

D.Simplified targeting of multiple machines with a single pipeline run.

E.Rolling deployment support with health checks.

AnswersD, E

Deployment groups register multiple target machines as one logical set, letting a single pipeline run fan out to all of them. This removes the need to define and maintain separate pipeline stages or jobs per machine.

Why this answer

Option D is correct because deployment groups let a single pipeline job target a logical set of machines (defined by tags), so one pipeline run can deploy to many VMs without enumerating each machine individually. Option E is correct because deployment groups natively support rolling deployments, where the agent on each target machine runs the deployment steps and the pipeline can perform health checks and stop the rollout if a machine fails. Option A is not a deployment group feature; secrets such as connection strings are handled by Azure Key Vault, variable groups, or secret variables, not by deployment groups themselves.

Option B is incorrect because deployment groups do not shut down VMs to save cost; they only orchestrate deployment to registered machines. Option C is incorrect because automatic VM scaling is provided by VM scale sets or autoscale settings, not by deployment groups.

Exam trap

The trap here is confusing deployment groups with Azure VM scale sets, leading candidates to incorrectly associate automatic scaling or cost-saving shutdown features with deployment groups, when those are separate Azure services.

Full explanation →

689

MCQhard

You are a DevOps engineer for a financial services company with strict regulatory compliance requirements (e.g., PCI-DSS, SOX). The company uses Azure DevOps for CI/CD and manages multiple projects. Each project has its own set of service connections, variable groups, and agent pools. The security team recently audited the environment and found that several service connections have been granted Contributor rights at the subscription level, and some variable groups are accessible by all pipelines across all projects. Additionally, audit logs show that a former employee's service principal still has active service connections in two projects. You need to implement a security and compliance plan to address these issues. Which approach should you take?

A.Conduct a manual audit of all service connections and variable groups every quarter, and revoke any permissions that are not needed. Disable service connections associated with the former employee.

B.Immediately delete all service connections associated with the former employee and recreate them using service principals with the least privilege. Then, update all pipelines to use the new connections.

C.Restrict all service connections to use resource-group level scoped permissions instead of subscription-level. For variable groups, set them to be accessible only to specific pipelines.

D.Implement Azure Policy to enforce that service connections cannot have subscription-level Contributor role; instead, require specific resource group roles. Use Azure AD access reviews to automatically remove stale service principals. Use pipeline decorators to enforce branch policy and approval checks on variable groups that contain secrets.

AnswerD

This answer combines three complementary Azure native controls that together provide preventive, detective, and corrective governance. Azure Policy continuously audits and denies role assignments that grant subscription-level Contributor to service connections, enforcing least privilege automatically across all resources. Azure AD access reviews periodically evaluate service principal usage and automatically remove or disable stale principals, eliminating orphaned credentials like the former employee's. Pipeline decorators inject pre-execution steps into every pipeline run, enforcing branch policies and mandatory approval checks whenever a variable group containing secrets is referenced, even if the pipeline YAML does not explicitly include those checks.

Why this answer

It provides a comprehensive, automated, and scalable approach to enforcing least privilege and compliance. Azure Policy can audit and enforce that service connections are scoped to resource groups rather than subscriptions, preventing over-permissioned Contributor access. Azure AD access reviews automate the detection and removal of stale service principals, addressing the former employee issue without manual effort.

Pipeline decorators enforce mandatory approval checks and branch policies on variable groups containing secrets, ensuring that sensitive variables are not accessible to all pipelines across projects.

Exam trap

The trap here is that candidates often choose a manual or reactive approach (like Option A or B) because they focus on the immediate fix for the former employee, overlooking the need for automated, continuous enforcement that Azure Policy, access reviews, and pipeline decorators provide for long-term compliance.

How to eliminate wrong answers

Option A is wrong because a manual quarterly audit is reactive, error-prone, and does not scale across multiple projects; it fails to meet the strict regulatory compliance requirements that demand continuous enforcement. Option B is wrong because immediately deleting all service connections associated with the former employee could break running pipelines and does not address the root cause of over-permissioned service connections or variable group accessibility; it also lacks automation for ongoing compliance. Option C is wrong because restricting service connections to resource-group level scopes is a partial fix that does not enforce the change across existing connections, and setting variable groups to be accessible only to specific pipelines is a manual configuration that does not prevent future misconfigurations or provide audit trails.

Full explanation →

690

MCQeasy

You need to automatically create a work item in Azure Boards when a GitHub issue is opened. What is the most efficient way to achieve this?

A.Install the GitHub + Azure Boards integration

B.Create a GitHub Action that calls Azure DevOps REST API

C.Use Azure Pipelines with a GitHub trigger

D.Configure a webhook in GitHub to Azure DevOps

AnswerA

The GitHub + Azure Boards integration is a native, two-way sync that automatically creates and links Azure Boards work items from GitHub commits, branches, and pull requests, and can be configured to create work items from GitHub issues. This is the official, supported method that requires no custom code and provides rich traceability between GitHub and Azure Boards.

Why this answer

The GitHub + Azure Boards integration is a built-in, officially supported connector that automatically links GitHub repositories to Azure Boards and can create work items from GitHub issues with minimal configuration. It is the most efficient method because it requires no custom code, no webhook scripting, and no pipeline setup—just install the integration from the Azure DevOps Marketplace and authorize it.

Exam trap

The trap is overengineering the solution—candidates may choose custom GitHub Actions or webhooks because they sound more 'technical' or flexible, but the exam rewards the simplest, most efficient native integration for the stated requirement.

How to eliminate wrong answers

Option B is wrong because creating a GitHub Action that calls the Azure DevOps REST API requires writing and maintaining custom YAML/workflow code, handling authentication tokens, and managing error cases—far less efficient than the native integration. Option C is wrong because Azure Pipelines with a GitHub trigger is designed for CI/CD build/release automation, not for creating work items in Azure Boards; it does not natively create work items from issues. Option D is wrong because configuring a raw webhook from GitHub to Azure DevOps requires a custom endpoint or Azure Function to receive and process the payload, which is more complex and error-prone than the official integration.

Full explanation →

691

Multi-Selecthard

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Select 3 answers

A.The agent software installed on the target machine

B.A deployment group target

C.The agent pool name and URL of the Azure DevOps organization

D.Azure VM extension for Azure Pipelines Agent

E.A personal access token (PAT) for authentication

AnswersA, C, E

Installing the agent software on the target machine is mandatory: the agent listener establishes the outbound connection to Azure Pipelines and executes queued jobs. Without it, the machine cannot register with the pool or run pipeline work, so the self-hosted capability simply does not exist.

Why this answer

To set up a self-hosted agent pool in Azure Pipelines, you must install the agent software on the target machine (option A), which provides the listener that polls Azure DevOps for jobs and runs them locally. You also need to configure the agent with the agent pool name and the URL of the Azure DevOps organization (option C), since the agent registers itself into a specific pool under a specific organization endpoint. Authentication requires a personal access token (option E) with the appropriate scope (typically Agent Pools read/manage), which the agent uses during configuration to register with the service.

Option B is incorrect because deployment groups are a separate feature for classic release pipelines targeting machines, not the mechanism for creating an agent pool. Option D is incorrect because the Azure VM extension for Azure Pipelines Agent is an optional convenience for provisioning agents on Azure VMs, not a required component of a self-hosted agent pool.

Exam trap

The trap here is that candidates often confuse the Azure VM extension (a convenience tool) with a mandatory requirement, or they mistakenly think a deployment group target is needed for agent pools, when in fact deployment groups are for targeting specific machines in a release context, not for agent registration.

Full explanation →

692

MCQmedium

You are using Microsoft Defender for Cloud to secure Azure Pipelines. You need to receive alerts when a pipeline run uses a service principal with excessive permissions. Which feature should you enable?

A.Enable Azure DevOps audit logs and review them manually.

B.Create an Azure Policy to deny over-privileged service principals.

C.Enable Microsoft Defender for Cloud's identity and access monitoring.

D.Configure Microsoft Entra ID Conditional Access policies.

AnswerC

Enabling Microsoft Defender for Cloud's identity and access monitoring activates continuous analysis of Azure AD identities and service principals, including their sign-in patterns, permissions, and usage anomalies. This feature leverages Microsoft Defender for Identity sensors to detect risky behaviors such as suspicious service principal credential usage and over-permissioned resource access, and it emits real-time security alerts. That gives the team the required detection and response capability for identity-based threats in Azure Pipelines.

Why this answer

Microsoft Defender for Cloud's identity and access monitoring continuously assesses the permissions of service principals used in Azure Pipelines and generates alerts when it detects over-privileged or anomalous usage. This feature is specifically designed to identify excessive permissions in real-time, enabling proactive security responses without manual log review or policy enforcement.

Exam trap

The trap here is that candidates often confuse Azure Policy (which enforces resource compliance) with identity monitoring (which detects permission misuse), leading them to select Option B instead of the correct identity-focused alerting feature.

How to eliminate wrong answers

Option A is wrong because manually reviewing Azure DevOps audit logs is reactive and does not provide automated, real-time alerts for over-privileged service principals; it requires constant human oversight. Option B is wrong because Azure Policy can enforce compliance on Azure resources but cannot directly deny or monitor pipeline runs that use over-privileged service principals; it operates at the resource management layer, not the pipeline execution layer. Option D is wrong because Microsoft Entra ID Conditional Access policies control authentication and access to applications based on conditions like location or device state, but they do not evaluate the permissions of service principals within Azure Pipelines or generate alerts for excessive privileges.

Full explanation →

693

MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

A.Hardcoded values in the workflow YAML

B.Environment variables in the workflow

C.GitHub Secrets

D.Artifact storage

AnswerC

GitHub Secrets are the correct way to store sensitive data because they are encrypted at rest and only decrypted for the specific actions or workflows that reference them. Secrets are automatically masked in logs, preventing accidental exposure, and they support environment-based scoping for granular access control. This ensures credentials and API tokens remain protected throughout the CI/CD pipeline.

Why this answer

GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Exam trap

The trap here is that candidates often confuse environment variables (which can be set in the workflow YAML) with GitHub Secrets, not realizing that environment variables are not automatically masked and can leak in logs, whereas GitHub Secrets are specifically designed for secure injection and automatic log redaction.

How to eliminate wrong answers

Option A is wrong because hardcoded values in the workflow YAML are stored as plaintext in the repository, visible to anyone with read access and exposed in logs if the workflow prints them. Option B is wrong because environment variables defined in the workflow YAML (e.g., `env: MY_VAR: value`) are not automatically masked; if a step echoes the variable or an error message includes it, the value appears in plaintext in the logs. Option D is wrong because artifact storage is used to persist build outputs (e.g., compiled binaries, test results) between jobs, not to securely store or inject secrets at runtime.

Full explanation →

694

MCQmedium

A company uses Azure DevOps for CI/CD. They have a multi-stage YAML pipeline that builds a Java application, runs unit tests, and deploys to a test environment. The test environment uses an Azure SQL Database. The pipeline currently runs successfully but the team notices that the test database schema is not always up-to-date. They want to apply database migrations automatically as part of the pipeline. Which tool or task should they integrate?

A.Use the Azure SQL Database deployment task to run a SQL script manually.

B.Use Azure SQL Database backup and restore to update the schema.

C.Add a PowerShell task that runs SQLCMD.

D.Integrate Flyway or similar database migration tool in the pipeline.

AnswerD

Integrating Flyway or a similar database migration tool gives the pipeline a versioned, repeatable way to manage schema changes. Flyway tracks applied migrations in a metadata table, applies scripts in order, and supports incremental upgrades and rollback, ensuring the database schema is synchronized with application code automatically as part of CI/CD.

Why this answer

Flyway is a dedicated database migration tool that integrates seamlessly with Azure DevOps pipelines, allowing you to version-control and apply schema changes automatically. Unlike ad-hoc scripts, Flyway tracks which migrations have been applied, ensuring the test database schema is always up-to-date without manual intervention.

Exam trap

The trap here is that candidates may think any SQL execution task (like SQLCMD or the Azure SQL task) is sufficient for schema updates, overlooking the critical need for version control, state tracking, and repeatability that dedicated migration tools provide.

How to eliminate wrong answers

Option A is wrong because the Azure SQL Database deployment task is designed for deploying a DACPAC or running a single SQL script, but it does not provide versioning or incremental migration tracking, so it cannot reliably keep the schema up-to-date across multiple changes. Option B is wrong because backup and restore is a data recovery operation, not a schema migration strategy; it would overwrite the entire database rather than applying incremental schema changes. Option C is wrong because a PowerShell task running SQLCMD can execute arbitrary SQL scripts, but it lacks migration state management, rollback capabilities, and version control, making it error-prone and non-repeatable for continuous schema updates.

Full explanation →

695

MCQmedium

Your company uses Microsoft Teams for collaboration. You want to send notifications to a Teams channel whenever a build pipeline in Azure Pipelines fails. Which approach should you use?

A.Configure an email subscription in Azure DevOps to send alerts to the Teams channel email address.

B.Set up a webhook in Azure DevOps to post to the Teams channel's incoming webhook URL.

C.Install the Azure Pipelines app for Microsoft Teams and subscribe the channel to pipeline notifications.

D.Use the 'Post to a Microsoft Teams channel' task in the pipeline.

AnswerC

The Azure Pipelines app for Microsoft Teams is the official integration that lets you subscribe a channel to pipeline events, such as completed builds and releases, failed jobs, and pending approvals. It uses the Teams bot framework to deliver structured, interactive cards and does not require custom code, webhook secrets, or manual service hook construction, making it the recommended and simplest setup.

Why this answer

The Azure Pipelines app for Microsoft Teams is the officially supported integration that lets you subscribe a Teams channel to pipeline events, including build failures, with rich notifications and actionable cards. Installing the app and configuring the channel subscription is the intended approach. It provides native integration without custom webhooks or email workarounds.

Exam trap

The trap is choosing a generic webhook or email subscription because it seems simpler; candidates often miss that the native Azure Pipelines app provides the supported, low-effort subscription model for Teams channels.

How to eliminate wrong answers

Option A is wrong because email subscriptions send email to an address; Teams channel email addresses are not designed for structured pipeline notifications and lack the rich formatting and actions of the native app. Option B is wrong because while a generic webhook can post to a Teams incoming webhook URL, it requires custom payload formatting and does not provide the out-of-the-box subscription model or event filtering that the Azure Pipelines app offers. Option D is wrong because there is no built-in 'Post to a Microsoft Teams channel' task in Azure Pipelines; you would need a custom script or extension, which is more effort and less integrated.

Full explanation →

696

MCQhard

You have a YAML pipeline that builds a container image and pushes it to Azure Container Registry (ACR). The pipeline uses a Docker task to build and push the image. You need to ensure that the image is tagged with both the build ID and the latest tag, but only when the build is from the main branch. Which approach should you use?

A.Use a single Docker task with the command buildAndPush and specify multiple tags in the tags input, and add a condition to the task to run only for the main branch.

B.Use two separate Docker tasks: one to build and push with the build ID tag, and another to build and push with the latest tag, each with its own condition.

C.Use a Docker task to build and push with the build ID tag, then use an Azure CLI task to run az acr repository update to add the latest tag, with a condition on the CLI task.

D.Use a Docker task to build and push with the latest tag, then use a script to retag the image with the build ID using docker tag and docker push, with a condition on the script.

AnswerA

The Docker task's buildAndPush command supports multiple tags via a comma-separated list in the tags input. You can specify both $(Build.BuildId) and latest. By adding a condition such as eq(variables['Build.SourceBranch'], 'refs/heads/main'), the task will only execute for the main branch, ensuring the tags are applied only in that case. This is the most straightforward and supported method.

Why this answer

The Docker task's buildAndPush command accepts multiple tags in the tags input, allowing both the build ID and latest to be applied in a single build and push operation. Adding a condition to the task ensures it only runs for the main branch. This is the most efficient and maintainable solution.

Exam trap

The trap here is overcomplicating the solution by using separate tasks or CLI commands to add tags, when the Docker task natively supports multiple tags in one step.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 676–696