Scenario practice questions

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?

Trap 1: GitHub Importer

For importing to GitHub.

Trap 2: Azure DevOps Migration Tools

Migrates work items, not repo history.

Trap 3: git-svn

For Subversion, not TFVC.

A
GitHub Importer
Why wrong: For importing to GitHub.
B
Azure DevOps Migration Tools
Why wrong: Migrates work items, not repo history.
C
git-tfs tool
Preserves history and branches.
D
git-svn
Why wrong: For Subversion, not TFVC.

Question 2hardmultiple choice

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

Exhibit

{
  "triggers": [
    {
      "branchFilters": ["main", "develop"],
      "paths": {
        "include": ["/src/*"],
        "exclude": ["/src/tests/*"]
      },
      "batchChanges": true,
      "maxConcurrentBuildsPerBranch": 1,
      "triggerType": "continuousIntegration"
    }
  ]
}

Trap 1: 0 builds, because the excluded path takes precedence.

The excluded path does not blindly outrank included paths; Azure Pipelines evaluates the set of changed files against the include/exclude filters as a whole. A build is triggered whenever any changed file matches an include, even if other files match an exclusion. Since the change set contains an included path, the excluded path cannot suppress the build, so zero builds is impossible.

Trap 2: 3 builds, because maxConcurrentBuildsPerBranch is 1 but…

maxConcurrentBuildsPerBranch controls the maximum number of builds that can run simultaneously for a branch, not the number of builds triggered by a single push. Setting it to 1 means one build runs at a time; any additional triggered builds would wait in the queue, but batchChanges already consolidates all changes from the same push into a single build. Therefore, the concurrency limit does not multiply the trigger count to three.

Trap 3: 2 builds, one for each modified folder.

The trigger is branch-conditioned and path-filtered, but it does not iterate over folders and create one build per folder; a single push is processed as one event. When batchChanges is enabled, every change in that push is folded into one build, so having changes in two modified folders does not yield two builds. This option confuses path filtering (which merely includes or excludes files) with build-per-path semantics.

A
1 build, because batchChanges is true.
With batchChanges set to true, all commits and file changes from a single push are coalesced into one build invocation; you don't get a separate build per modified file or folder. Because at least one changed path matches an include pattern, the pipeline queues exactly one batched build for that change set.
B
0 builds, because the excluded path takes precedence.
Why wrong: The excluded path does not blindly outrank included paths; Azure Pipelines evaluates the set of changed files against the include/exclude filters as a whole. A build is triggered whenever any changed file matches an include, even if other files match an exclusion. Since the change set contains an included path, the excluded path cannot suppress the build, so zero builds is impossible.
C
3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.
Why wrong: maxConcurrentBuildsPerBranch controls the maximum number of builds that can run simultaneously for a branch, not the number of builds triggered by a single push. Setting it to 1 means one build runs at a time; any additional triggered builds would wait in the queue, but batchChanges already consolidates all changes from the same push into a single build. Therefore, the concurrency limit does not multiply the trigger count to three.
D
2 builds, one for each modified folder.
Why wrong: The trigger is branch-conditioned and path-filtered, but it does not iterate over folders and create one build per folder; a single push is processed as one event. When batchChanges is enabled, every change in that push is folded into one build, so having changes in two modified folders does not yield two builds. This option confuses path filtering (which merely includes or excludes files) with build-per-path semantics.

Question 3mediummultiple choice

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

Trap 1: Switch to Git with a central repository and require merge commits.

Switching to Git with a central repository does not add file locking or conflict prevention: Git's distributed model allows concurrent edits to the same file, and requiring merge commits only preserves history, it does not prevent the merge conflicts that arise when two developers modify overlapping lines. Without exclusive checkout, Git will still need manual resolution when simultaneous pushes touch the same code.

Trap 2: Enforce a rebase strategy for all pull requests in the branch…

Enforcing a rebase strategy rewrites commits to create a linear history, but a rebase does not lock files or serialize edits; when two users have the same file checked out and push concurrently, the second rebase still has to resolve the same merge conflict against the updated remote branch. Branch policies govern pull request completion, not preventing overlapping edits in real time.

Trap 3: Configure Azure Repos to use squash merge when completing pull…

Squash-merge settings only collapse all pull request commits into a single commit on merge; they do nothing to coordinate simultaneous work, so multiple developers can still push conflicting changes to the same files in the source branch and manual conflict resolution will still be required.

A
Switch to Git with a central repository and require merge commits.
Why wrong: Switching to Git with a central repository does not add file locking or conflict prevention: Git's distributed model allows concurrent edits to the same file, and requiring merge commits only preserves history, it does not prevent the merge conflicts that arise when two developers modify overlapping lines. Without exclusive checkout, Git will still need manual resolution when simultaneous pushes touch the same code.
B
Enforce a rebase strategy for all pull requests in the branch policy.
Why wrong: Enforcing a rebase strategy rewrites commits to create a linear history, but a rebase does not lock files or serialize edits; when two users have the same file checked out and push concurrently, the second rebase still has to resolve the same merge conflict against the updated remote branch. Branch policies govern pull request completion, not preventing overlapping edits in real time.
C
Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.
TFVC with exclusive checkout is correct because it enables server-side, per-file locking: as soon as one developer checks out a file, any other user's attempt to check out that same file is blocked until the first check-in, thereby ensuring no concurrent edits can create conflicts and enforcing a strictly linear history over the shared files.
D
Configure Azure Repos to use squash merge when completing pull requests.
Why wrong: Squash-merge settings only collapse all pull request commits into a single commit on merge; they do nothing to coordinate simultaneous work, so multiple developers can still push conflicting changes to the same files in the source branch and manual conflict resolution will still be required.

Question 4easymultiple choice

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?

Trap 1: Enable 'Automatically approve' for security group.

The 'Automatically approve' setting for a security group would cause the system to automatically approve pull requests for members of that group, effectively bypassing the need for a human code review and eliminating the intended assignment of an actual reviewer who would inspect the code.

Trap 2: Code ownership policy with automatic reviewer assignment.

A code ownership policy defines which users or groups are responsible for specific files or paths, and when a pull request modifies those files, Azure DevOps automatically assigns the matching owner as the reviewer, ensuring the appropriate expert is selected for the change.

Trap 3: Branch policy with minimum number of reviewers.

A branch policy requiring a minimum number of reviewers ensures a certain count of approvals before completion, but it does not specify who those reviewers should be; it leaves reviewer selection to the team, so it cannot automatically assign a particular code owner based on the modified files.

A
Add a required reviewer policy for the branch.
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.
B
Enable 'Automatically approve' for security group.
Why wrong: The 'Automatically approve' setting for a security group would cause the system to automatically approve pull requests for members of that group, effectively bypassing the need for a human code review and eliminating the intended assignment of an actual reviewer who would inspect the code.
C
Code ownership policy with automatic reviewer assignment.
Why wrong: A code ownership policy defines which users or groups are responsible for specific files or paths, and when a pull request modifies those files, Azure DevOps automatically assigns the matching owner as the reviewer, ensuring the appropriate expert is selected for the change.
D
Branch policy with minimum number of reviewers.
Why wrong: A branch policy requiring a minimum number of reviewers ensures a certain count of approvals before completion, but it does not specify who those reviewers should be; it leaves reviewer selection to the team, so it cannot automatically assign a particular code owner based on the modified files.

Question 5easymultiple choice

You need to integrate security scanning into your build pipeline to detect vulnerable open-source dependencies. Which Azure DevOps extension should you use?

Trap 1: Azure Policy

Azure Policy is an Azure governance service that enforces and audits compliance rules on Azure resources (such as VM SKUs, tagging, or resource locations), not a pipeline security scanner. It cannot scan code or dependency vulnerabilities inside your build artifacts, so it is not appropriate for integrating security scanning into a build pipeline.

Trap 2: GitHub Advanced Security

GitHub Advanced Security is a suite of code-scanning, secret-scanning, and dependency-review tools tightly integrated into GitHub.com or GitHub Enterprise, often used with GitHub Actions. While Microsoft owns GitHub, this tooling is not natively available as an Azure DevOps build task, so it cannot be plugged directly into an Azure Pipeline for the security scan required here.

Trap 3: SonarQube

SonarQube is a static code-analysis server that detects code smells, bugs, and some security hotspots through rules and quality gates, often run as an Azure DevOps task. It focuses on source-code quality and static analysis rather than known vulnerabilities in open-source dependencies, so it complements rather than fulfills the specific requirement of scanning open-source components.

A
WhiteSource Bolt
WhiteSource Bolt is a build-task extension in Azure DevOps that scans open-source components from package managers like npm, NuGet, and Maven against the Whitesource vulnerability database, failing the pipeline on known CVEs and generating an inline report. It fits the requirement directly because it performs security scanning during the build, whereas other options either do not target open-source dependencies or are not integrated into Azure Pipelines.
B
Azure Policy
Why wrong: Azure Policy is an Azure governance service that enforces and audits compliance rules on Azure resources (such as VM SKUs, tagging, or resource locations), not a pipeline security scanner. It cannot scan code or dependency vulnerabilities inside your build artifacts, so it is not appropriate for integrating security scanning into a build pipeline.
C
GitHub Advanced Security
Why wrong: GitHub Advanced Security is a suite of code-scanning, secret-scanning, and dependency-review tools tightly integrated into GitHub.com or GitHub Enterprise, often used with GitHub Actions. While Microsoft owns GitHub, this tooling is not natively available as an Azure DevOps build task, so it cannot be plugged directly into an Azure Pipeline for the security scan required here.
D
SonarQube
Why wrong: SonarQube is a static code-analysis server that detects code smells, bugs, and some security hotspots through rules and quality gates, often run as an Azure DevOps task. It focuses on source-code quality and static analysis rather than known vulnerabilities in open-source dependencies, so it complements rather than fulfills the specific requirement of scanning open-source components.

Question 6easymultiple choice

You are designing a release pipeline for a mission-critical application. The pipeline must deploy to multiple environments (dev, test, prod) in sequence, with manual approval required before production deployment. Which Azure Pipelines feature should you use?

Trap 1: Variable groups

Variable groups are reusable containers for variables, secrets, and certificates that can be linked to pipelines or the library, but they do not trigger manual approval steps. While they can supply values to release tasks, they have no mechanism to require human sign-off before deployment.

Trap 2: Pipeline triggers

Pipeline triggers are events or conditions that automatically start a pipeline run, such as continuous integration, scheduled schedules, or other pipeline completions. They control when execution begins but cannot add approval requirements or manual sign-off to a stage deployment.

Trap 3: Deployment gates

Deployment gates are automated health-check conditions, such as monitoring metrics, work-item queries, or Azure Function calls, that run before or after a deployment and can pause or fail the release if criteria aren't met. Unlike pre-deployment approvals, they are fully automatic and require no manual approval from a human.

A
Pre-deployment approvals
Pre-deployment approvals define mandatory manual sign-off by designated approvers before a release is deployed to a stage. They act as a compliance checkpoint in the release pipeline and are distinct from automated gates, ensuring human oversight for mission-critical environments.
B
Variable groups
Why wrong: Variable groups are reusable containers for variables, secrets, and certificates that can be linked to pipelines or the library, but they do not trigger manual approval steps. While they can supply values to release tasks, they have no mechanism to require human sign-off before deployment.
C
Pipeline triggers
Why wrong: Pipeline triggers are events or conditions that automatically start a pipeline run, such as continuous integration, scheduled schedules, or other pipeline completions. They control when execution begins but cannot add approval requirements or manual sign-off to a stage deployment.
D
Deployment gates
Why wrong: Deployment gates are automated health-check conditions, such as monitoring metrics, work-item queries, or Azure Function calls, that run before or after a deployment and can pause or fail the release if criteria aren't met. Unlike pre-deployment approvals, they are fully automatic and require no manual approval from a human.

Question 7hardmultiple choice

You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?

Trap 1: The SQL Server firewall is blocking the application IP; add a…

A SQL Server firewall rule blocks traffic at the network or login layer, producing an immediate connection failure or login error before the application can acquire a connection; it does not cause wait-based timeouts after the connection pool is already in use, so this is not the cause of intermittent timeout symptoms.

Trap 2: The database is experiencing deadlocks; enable read committed…

Deadlocks are detected by SQL Server's lock manager and immediately terminated with error 1205, not by the application waiting for a connection timeout; enabling read committed snapshot isolation can reduce deadlock occurrences but does not affect connection pool timeout behavior.

Trap 3: The database DTU limit is being exceeded; scale up the service tier.

Exceeding the DTU limit causes Azure SQL Database to throttle or queue queries, typically surfacing as performance degradation or resource-wait errors such as DTU waits, not as connection timeout exceptions from the application; scaling the service tier would not address a connection pool exhaustion issue.

A
The application is exhausting the connection pool; increase Max Pool Size in the connection string.
Connection pool exhaustion occurs when the application requests more connections than the configured Max Pool Size, forcing new requests to wait for a free connection until the connection timeout threshold is reached, which manifests as intermittent timeouts under load; increasing Max Pool Size or ensuring connections are properly disposed can resolve this.
B
The SQL Server firewall is blocking the application IP; add a firewall rule.
Why wrong: A SQL Server firewall rule blocks traffic at the network or login layer, producing an immediate connection failure or login error before the application can acquire a connection; it does not cause wait-based timeouts after the connection pool is already in use, so this is not the cause of intermittent timeout symptoms.
C
The database is experiencing deadlocks; enable read committed snapshot isolation.
Why wrong: Deadlocks are detected by SQL Server's lock manager and immediately terminated with error 1205, not by the application waiting for a connection timeout; enabling read committed snapshot isolation can reduce deadlock occurrences but does not affect connection pool timeout behavior.
D
The database DTU limit is being exceeded; scale up the service tier.
Why wrong: Exceeding the DTU limit causes Azure SQL Database to throttle or queue queries, typically surfacing as performance degradation or resource-wait errors such as DTU waits, not as connection timeout exceptions from the application; scaling the service tier would not address a connection pool exhaustion issue.

Question 8mediummultiple choice

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

Trap 1: Copy the latest version of the code to a new Git repository and…

This approach creates a brand-new Git repository containing only the current workspace snapshot, so every TFVC changeset, label, branch, and historical audit record is permanently discarded. It also destroys the ability to trace code lineage, compare past versions, or understand why specific changes were made — a critical loss for compliance and debugging. Unlike a true migration that replays history, this is effectively a re-baseline, not a conversion, and would be unacceptable for any organization that requires an immutable audit trail or reproducible build provenance.

Trap 2: Use the Git-TF tool to clone the TFVC repository

Git-TF is a deprecated Microsoft tool that lacks the robust, actively maintained changeset conversion and branch/tag mapping provided by git-tfs, so using it would create an incomplete or brittle migration artifact with potential data loss.

Trap 3: Export TFVC as a Git bundle and import with --no-metadata

A Git bundle is a Git-specific archive format that TFVC cannot produce, and --no-metadata is not a conversion mechanism for TFVC history; this approach is technically invalid and would not bring any TFVC changesets into Git.

A
Copy the latest version of the code to a new Git repository and start fresh
Why wrong: This approach creates a brand-new Git repository containing only the current workspace snapshot, so every TFVC changeset, label, branch, and historical audit record is permanently discarded. It also destroys the ability to trace code lineage, compare past versions, or understand why specific changes were made — a critical loss for compliance and debugging. Unlike a true migration that replays history, this is effectively a re-baseline, not a conversion, and would be unacceptable for any organization that requires an immutable audit trail or reproducible build provenance.
B
Use the Git-TF tool to clone the TFVC repository
Why wrong: Git-TF is a deprecated Microsoft tool that lacks the robust, actively maintained changeset conversion and branch/tag mapping provided by git-tfs, so using it would create an incomplete or brittle migration artifact with potential data loss.
C
Use the git-tfs tool to clone the TFVC repository with changesets
git-tfs is the standard community-maintained bridge that clones a TFVC repository by replaying each TFVC changeset into a corresponding Git commit, preserving the original author, timestamp, commit message, branch structure, and merge topology. It handles the TFVC-to-Git ID mapping and can also fetch shelvesets, making it the preferred tool for a full-fidelity migration. Because it reconstructs the entire commit graph rather than just copying files, it maintains the historical context needed for auditing, bisecting, and code review — which is exactly what the team needs when moving from TFVC to Git.
D
Export TFVC as a Git bundle and import with --no-metadata
Why wrong: A Git bundle is a Git-specific archive format that TFVC cannot produce, and --no-metadata is not a conversion mechanism for TFVC history; this approach is technically invalid and would not bring any TFVC changesets into Git.

Question 9hardmultiple choice

You are the lead DevOps engineer for a large e-commerce company. The company has a multi-region Azure Kubernetes Service (AKS) cluster deployment for its microservices. The current CI/CD pipeline uses Azure DevOps to build Docker images and deploy to AKS via Helm charts. Recently, the team noticed that after a deployment to the West Europe region, the application experienced a 5-minute downtime due to a configuration error where the new pods couldn't connect to the database because the connection string was pointing to a staging database instead of production. The issue was detected manually after a customer reported the outage. The team wants to implement a mechanism to automatically detect such misconfigurations before they affect production traffic. They also want to ensure that if a deployment fails health checks, the previous version is automatically rolled back. The pipeline currently runs all stages in sequence: build, deploy to West Europe, then deploy to East US. The team has a small budget for additional resources. Which approach should the team implement?

Trap 1: Use a blue-green deployment strategy with deployment slots in AKS.

A blue-green deployment with AKS doesn't map cleanly because AKS has no native 'deployment slots' like Azure App Service; you'd manage two full environments yourself. More importantly, blue-green switches all production traffic to the new version at once, so if a health check fails after the switch, you've already exposed 100% of users to the broken configuration. Without additional automation (e.g., a separate watch dog that reverts the service selector), there's no automatic rollback on health check failure, meaning downtime until manual intervention. Canary avoids this by shifting only a small percentage of traffic first, so the bad release is caught before widespread impact.

Trap 2: Add a manual approval gate before the deployment to East US,…

Requiring a manual approval gate after a deployment to West Europe does not protect a different region like East US, because configuration issues are often region-specific (e.g., Azure SQL firewall rules, regional key vaults, or CDN endpoints). A single tester manually verifying a deployment in West Europe is slow and can miss automated checks like load testing, error-rate spikes, or subtle logic errors that only manifest under real traffic. Moreover, this gate happens before the East US deployment, so it can't react to health issues that appear after traffic is shifted; there's no automatic rollback mechanism. Automated canary health checks provide continuous, objective validation on the actual East US environment and trigger rollback without human delay or regional blind spots.

Trap 3: Deploy to a separate test environment first, run integration tests,…

A separate test environment often suffers from configuration drift, especially connection strings, feature flags, and environment-specific variables, which is exactly the type of misconfiguration that caused past incidents. Integration tests passing in test give false confidence because the production environment may have different secrets, network policies, or cluster-scoped settings. Even if tests pass, this approach doesn't add any post-deployment safety net; after deploying to production, there is no automated health check or rollback if the app fails with the actual production configuration. The canary strategy directly tests the real production environment with a subset of live traffic, so config mismatches are caught under authentic conditions.

A
Implement a canary deployment strategy with automated health checks and automatic rollback on failure.
A canary deployment with automated health checks and automatic rollback is the correct choice because it incrementally routes a small percentage of production traffic to the new release, say 5%, then gradually increases it only if health checks pass. Automated checks monitor key signal like HTTP 5xx error rate, request latency, and custom application health endpoints, and if a threshold is breached, the release pipeline automatically reverts the routing to the previous stable version. This catches misconfigurations and regressions early with a minimal blast radius, preventing full-scale downtime. Unlike blue-green or a staged test deploy, it validates against real production load and configuration while keeping the majority of users on the safe version.
B
Use a blue-green deployment strategy with deployment slots in AKS.
Why wrong: A blue-green deployment with AKS doesn't map cleanly because AKS has no native 'deployment slots' like Azure App Service; you'd manage two full environments yourself. More importantly, blue-green switches all production traffic to the new version at once, so if a health check fails after the switch, you've already exposed 100% of users to the broken configuration. Without additional automation (e.g., a separate watch dog that reverts the service selector), there's no automatic rollback on health check failure, meaning downtime until manual intervention. Canary avoids this by shifting only a small percentage of traffic first, so the bad release is caught before widespread impact.
C
Add a manual approval gate before the deployment to East US, requiring a tester to verify the deployment in West Europe.
Why wrong: Requiring a manual approval gate after a deployment to West Europe does not protect a different region like East US, because configuration issues are often region-specific (e.g., Azure SQL firewall rules, regional key vaults, or CDN endpoints). A single tester manually verifying a deployment in West Europe is slow and can miss automated checks like load testing, error-rate spikes, or subtle logic errors that only manifest under real traffic. Moreover, this gate happens before the East US deployment, so it can't react to health issues that appear after traffic is shifted; there's no automatic rollback mechanism. Automated canary health checks provide continuous, objective validation on the actual East US environment and trigger rollback without human delay or regional blind spots.
D
Deploy to a separate test environment first, run integration tests, then deploy to production.
Why wrong: A separate test environment often suffers from configuration drift, especially connection strings, feature flags, and environment-specific variables, which is exactly the type of misconfiguration that caused past incidents. Integration tests passing in test give false confidence because the production environment may have different secrets, network policies, or cluster-scoped settings. Even if tests pass, this approach doesn't add any post-deployment safety net; after deploying to production, there is no automated health check or rollback if the app fails with the actual production configuration. The canary strategy directly tests the real production environment with a subset of live traffic, so config mismatches are caught under authentic conditions.

Question 10mediummultiple choice

Your team uses Azure Boards to manage work items. They want to automatically update the status of a work item to 'Resolved' when a pull request that contains the work item ID is merged. Which feature should you configure?

Trap 1: Instruct developers to manually update the work item after merging.

Relying on developers to manually update work items after merging introduces human error and inconsistency because there is no enforced trigger linking the merge event to a state transition. Developers may forget, update the wrong state, or close items prematurely, which breaks the traceability audit trail and requires recurring process policing. This is not a technical solution to the automation request; it shifts responsibility onto individuals and contradicts the goal of enforcing workflow without toil.

Trap 2: Set up a branch policy that requires linked work items.

The branch policy 'Check for linked work items' (or 'Require linked work items') only validates that a pull request contains at least one approved work item link at creation time, blocking completion if the link is absent. It does not execute any post-merge state change, so the work item remains in its original state even after the PR is completed. This policy enforces an input condition, not an output action; it would guarantee association, but fail to update status automatically.

Trap 3: Create a service hook to call Azure DevOps REST API on pull request…

A service hook that listens for the 'pull request.merged' event and calls the Azure DevOps REST API to update work items is functionally possible but introduces a custom development overhead: you must implement authentication (e.g., OAuth or PAT), handle retries for transient failures, and deploy/maintain a listener service. This approach duplicates functionality that already exists natively, increases the attack surface, and is far more complex than configuring the built-in automation. Unless there is a custom transformation or an outside-DevOps destination required, it is the anti-pattern here.

A
Enable the 'Automatically update work item status' setting in the repository's pull request configuration.
The 'Automatically update work item status' setting in a repository's Pull Request configuration is the native Azure DevOps mechanism that transitions linked work items to their resolved/closed state (e.g., Done) when the pull request is successfully merged. This server-side automation triggers on merge, uses the work item state mapping defined in the project's process configuration, and requires zero custom code or maintenance. For a team wanting automated status updates, this is the built-in, supported approach.
B
Instruct developers to manually update the work item after merging.
Why wrong: Relying on developers to manually update work items after merging introduces human error and inconsistency because there is no enforced trigger linking the merge event to a state transition. Developers may forget, update the wrong state, or close items prematurely, which breaks the traceability audit trail and requires recurring process policing. This is not a technical solution to the automation request; it shifts responsibility onto individuals and contradicts the goal of enforcing workflow without toil.
C
Set up a branch policy that requires linked work items.
Why wrong: The branch policy 'Check for linked work items' (or 'Require linked work items') only validates that a pull request contains at least one approved work item link at creation time, blocking completion if the link is absent. It does not execute any post-merge state change, so the work item remains in its original state even after the PR is completed. This policy enforces an input condition, not an output action; it would guarantee association, but fail to update status automatically.
D
Create a service hook to call Azure DevOps REST API on pull request merge.
Why wrong: A service hook that listens for the 'pull request.merged' event and calls the Azure DevOps REST API to update work items is functionally possible but introduces a custom development overhead: you must implement authentication (e.g., OAuth or PAT), handle retries for transient failures, and deploy/maintain a listener service. This approach duplicates functionality that already exists natively, increases the attack surface, and is far more complex than configuring the built-in automation. Unless there is a custom transformation or an outside-DevOps destination required, it is the anti-pattern here.