Configure processes and communications practice questions

Enable 'Create a merge commit' option in the branch policy.

Why it fails: This option changes merge strategy, not branch deletion.

Configure branch retention policy in the pipeline to delete branches after build.

Why it fails: Retention policies delete old runs, not branches.

Create a work item to remind developers to delete branches after merge.

Why it fails: This is not automated enforcement.

Set up a pipeline notification for the work item.

Why it fails: Pipeline notifications are designed for build and release pipeline events (e.g., pipeline runs, stage approvals, deployment completions), not for work item change events, so they cannot be used to broadcast a work item update to a webhook.

Configure team alerts in the project settings.

Why it fails: Team alerts in Azure DevOps are subscription-based notifications configured per team, and they deliver work item-related emails only to members of that team; they do not integrate with external systems or webhooks, so they cannot send events to a webhook.

Configure the Epic work item type to require a link to a Bug.

Why it fails: This does not prevent Bug-to-Epic links; it only requires a link.

Use a work item rule to set the parent type to Feature when a Bug is created.

Why it fails: This does not block linking to Epics; it only sets a default.

Add a rule to the Bug work item type that prohibits linking to Epics.

Why it fails: Rules cannot restrict link types; they can only set or clear fields.

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Why it fails: Webhooks require custom logic, not a built-in integration.

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Why it fails: Service Hooks send events to external systems, not directly update work items.

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Why it fails: This is a custom solution, not a built-in configuration.

Configure a branch policy requiring CAB member approval on pull requests.

Why it fails: Branch policies gate merges into a branch, which occurs before the build completes, not after it and before production deployment. Pull request approvals suit protecting source branches, whereas this scenario needs an environment check recording CAB approval on the release.

Add a manual intervention task in the YAML pipeline.

Why it fails: A manual intervention task pauses the run and resumes on manual completion, but it records no approver identity or approval decision against the environment, so CAB sign-off is not auditable. Manual intervention suits pausing for human action, not approval-gated deployment.

Set up a service hook to send an email to the CAB and wait for a reply.

Why it fails: A service hook emailing the CAB records no approval state in the pipeline, so the release gate cannot verify or enforce it. Service hooks are for reacting to Azure DevOps events by notifying external systems, which suits integration alerts rather than gated production deployment.

Issue OAuth 2.0 tokens to the partner users.

Why it fails: OAuth 2.0 tokens are bearer tokens used to authorize API calls (e.g., Azure DevOps REST APIs), not to provide interactive UI access. They do not create a user identity or assign the partner users to a project, so partners could not sign in to the Azure DevOps portal.

Configure Microsoft Entra ID identity protection to allow the partner IP range.

Why it fails: Identity Protection evaluates sign-in risk and user risk signals to trigger conditional access policies; it does not federate external identities or scope authorisation to a single Azure Boards project. Partner access without guest accounts requires Microsoft Entra B2B direct connect or an external collaboration setting tied to the project, which this configuration cannot deliver. It would be relevant when blocking risky sign-ins from known IP ranges.

Create service principals for the partner users.

Why it fails: Service principals are Microsoft Entra ID identities designed for automated tools, scripts, and applications, not for interactive human sign-in. They cannot be used to grant individual partner users access to Azure DevOps because they lack a UI-based authentication experience and are not assigned to projects as user accounts.

Repository settings to restrict file paths.

Why it fails: Repository settings like path restrictions control which branches or files specific users can modify, but they don't inspect commit messages or enforce work item linkage. They are purely about access control, not validation of commit message content.

Branch policy to require a minimum comment length.

Why it fails: This policy only validates that the pull request description reaches a minimum character count, without parsing for a work item reference or ID. A lengthy comment may still lack any linked work item, so it fails to enforce traceability for changes.

Pre-push Git hook.

Why it fails: A pre-push hook is configured locally in each developer's repository, so it can be bypassed, modified, or not installed at all, providing no central enforcement. It cannot serve as a mandatory server-side policy for Azure Repos, making it insufficient for team-wide compliance.

The push is blocked because required status checks are not met.

Why it fails: In Azure DevOps, required status checks are part of pull request branch policies and are evaluated only when a pull request is created or updated. A direct push does not create a PR, so status checks are never triggered and cannot block the push.

The push is blocked because enforceAdmins is true.

Why it fails: The enforceAdmins setting simply removes the Admin user bypass for existing branch policies; it does not itself impose a push restriction. Because no push-related policy is defined here, enforceAdmins has no effect and the push is allowed by standard Git permissions.

The push is rejected because lockBranch is false.

Why it fails: lockBranch: false explicitly means the branch is not locked, so this setting does not cause rejection. Branch locking is a separate Azure DevOps feature that prevents updates only when set to true; with false, there is no lock restriction.

Use a script to periodically check and add templates.

Why it fails: Not enforced and not scalable.

Create a repository template and require all new repos to use it.

Why it fails: Does not affect existing repositories.

Configure a CODEOWNERS file in each repository.

Why it fails: CODEOWNERS is for code review, not templates.

Add a GitHub Action that triggers on pipeline completion.

Why it fails: GitHub Actions cannot be directly triggered by Azure Pipelines.

Configure a Service Hook in Azure DevOps to GitHub Issues.

Why it fails: Service Hooks are for Azure DevOps, not Azure Pipelines YAML.

Add a task to create a work item in Azure Boards.

Why it fails: Azure Boards is not GitHub Issues.

Configure an email notification to the team.

Why it fails: Email is not Teams.

Use Azure Monitor alerts to send to Teams.

Why it fails: Azure Monitor is for Azure resources, not pipelines.

Add a Service Hook endpoint for Teams.

Why it fails: Service Hooks are possible but not a pipeline task.

Pipeline decorators.

Why it fails: Pipeline decorators inject additional steps into pipeline runs at compile time, but they cannot enforce a manual validation gate because they lack the ability to pause execution and wait for human approval.

Environment checks.

Why it fails: Environment checks are automated evaluations (e.g., branch protection or resource availability) that run as part of the deployment, but they do not provide a manual approval step for a human to review and approve before the deployment begins.

Post-deployment gates.

Why it fails: Post-deployment gates run after the deployment has already completed, so they can only approve or reject the outcome of a finished deployment and cannot block or validate the deployment before it starts.

Service principal with client secret

Why it fails: A service principal with client secret authenticates the application itself to Microsoft Entra ID, but the question requires Azure DevOps to trust tokens issued by Entra ID for service connections. This method lacks the token-exchange capability needed to validate an externally issued identity token. It is tempting because service principals are the standard way to authorise automated tools in Azure, and they would be correct if the goal were to grant DevOps direct resource access via a stored secret rather than trusting an external token.

OAuth 2.0 authorization code grant

Why it fails: This is for user authentication, not service-to-service.

Personal access token (PAT)

Why it fails: PATs are not Entra ID tokens and require manual rotation.

The commit is accepted because S/MIME is implicitly allowed.

Why it fails: Only explicitly listed types are allowed.

The commit is accepted because it is signed.

Why it fails: The policy restricts signature types.

The commit is rejected because the policy is in 'block' mode, which blocks all pushes.

Why it fails: 'Block' mode blocks violations, not all pushes.

The variable 'env' is a secret variable and cannot be used in YAML.

Why it fails: Secret variables are not referenced this way; in Azure Pipelines, secret variables are masked, and the variable group 'Config' does not mark 'env' as secret. A secret variable can be used in YAML by mapping it into a step's `env` block, but the error here is an undefined variable due to case mismatch, not a secret-access restriction.

The variable name is case-sensitive; the YAML uses 'Env' instead of 'env'.

Why it fails: Azure Pipelines variable names are case-sensitive, so when the YAML references `$(Env)` but the variable group 'Config' defines `env`, the reference is treated as a different, nonexistent variable. This matches the error: the variable group is loaded, but the exact name `Env` is not found, causing the pipeline to fail at parse/runtime.

The variable group is scoped to a specific branch, and the pipeline is running on a different branch.

Why it fails: While variable groups can be scoped to branches or resource authorization, a branch-scoping issue would manifest as a failure to load or access the variable group itself (e.g., 'variable group not found' or authorization error), not as a 'variable not found' for an existing variable. Since the variable group contains `env` and the YAML uses `Env`, the mismatch in case is the actual cause, independent of branch scope.

Define a pipeline variable to update the field during build.

Why it fails: Pipeline variables are not used for work item field updates.

Use a service hook to trigger an Azure Function that updates the work item.

Why it fails: Service hooks are for external integrations; Azure DevOps can update work items natively.

Create a work item template that sets remaining work.

Why it fails: Templates only apply when creating new work items, not updating existing ones.

Release gates with work item update actions.

Why it fails: Release gates are used to evaluate conditions (e.g., monitoring metrics) before allowing a release to proceed; they do not have built-in actions to update work items.

Work item query charts.

Why it fails: Work item query charts are for visualizing query results and do not automate updates.

Branch policy with required reviewers.

Why it fails: Branch policies with required reviewers enforce pull request approvals, not work item updates.

Comment requirements

Why it fails: Azure Repos branch policies do not include a native 'comment requirements' setting. The only comment-related policy is 'Comment resolution' (whether comment threads must be resolved), which merely requires active discussions to be closed, not a minimum number of PR comments. To enforce a comment count, you would need an external service or a custom build status check, making this option incorrect.

Check for linked work items

Why it fails: The 'Check for linked work items' policy only verifies that at least one work item is linked to the pull request; it does not inspect or enforce labels on that work item. The policy will pass as long as any work item link exists, even if the required label (e.g., 'approved') is absent. Therefore it cannot satisfy the requirement to enforce a specific label.

Required status check (using a custom build pipeline)

Why it fails: A required status check backed by a custom build pipeline can run arbitrary logic, including querying the pull request's work item links and checking their labels. Because the build pipeline runs in your Azure DevOps project, it can call the REST API to validate both presence of a linked work item and the exact label value, and only produce a successful status if both conditions pass. Making it a required status check on the branch policy blocks the merge until that custom validation succeeds.

Branch policy with required reviewers for main

Why it fails: Required reviewers do not enforce deployment checks.

Required status check for 'Check for linked work items'

Why it fails: This does not restrict branch sources or require deployment.

Build validation policy on main

Why it fails: Build validation runs on PR creation, not on merge, and does not enforce deployment.

Add a .gitattributes file

Why it fails: .gitattributes handles file normalization, not commit messages.

Set the default branch to main

Why it fails: Default branch does not enforce commit message conventions.

Set up an issue template

Why it fails: Issue templates are for issues, not commits.