4 of the 7 questions we have for this objective, shown with the answer and the reasoning.
Configure collaboration and communication
Coldwater Foods plans work in an Azure DevOps project named SupplyChain and keeps code in five repositories in the GitHub organization coldwater-foods. The team wants GitHub commits and pull requests to link to Azure Boards work items, and wants to connect all five repositories with minimal administrative effort.
What should you do first?
- AInstall the Azure Boards app for GitHub on the coldwater-foods organization and connect the repositories to the SupplyChain projectThe Azure Boards app for GitHub authorizes the connection between the GitHub organization and the Azure DevOps project and lets you select the repositories, which enables AB# linking.
- BCreate a GitHub service connection in SupplyChain project settings for each repositoryA GitHub service connection lets Azure Pipelines access GitHub for builds; it does not enable Azure Boards to link commits and pull requests to work items.
- CInstall the Azure Pipelines app for GitHub on the coldwater-foods organizationThe Azure Pipelines app integrates GitHub repositories with pipeline builds and checks, not with Azure Boards work item tracking.
- DImport the five repositories into Azure Repos so that work items can be linkedImporting moves the code out of GitHub, which is unnecessary because Azure Boards links natively to GitHub repositories.
Why: Azure Boards integrates with GitHub through the Azure Boards app, installed from GitHub Marketplace or started from the GitHub connections page in Azure DevOps project settings. The app grants Azure Boards access to selected repositories in a GitHub organization and associates them with one Azure DevOps project. After the connection exists, AB#ID mentions in commits, pull requests, and issues create links that appear in the work item's Development section. The distractors confuse Boards integration with the Azure Pipelines app or service connections, which serve builds rather than work tracking.
Configure collaboration and communication
Vellmar Robotics hosts firmware in the GitHub repository vellmar/firmware-core. An Azure Functions app named fw-indexer must start a symbol-indexing job whenever commits are pushed, and it must not receive payloads for issues, stars, or other activity. The security team requires the function to reject any request that did not originate from GitHub for this repository's webhook.
Which two actions should you perform? Each correct answer presents part of the solution.
- ACreate a repository webhook that uses Let me select individual events and selects only PushesSelecting only the push event limits deliveries to pushes, so the function does not receive payloads for issues, stars, or other activity.
- BConfigure a webhook secret and have the function verify the X-Hub-Signature-256 header as an HMAC SHA-256 of the payloadWith a secret configured, GitHub signs each payload and sends the signature in X-Hub-Signature-256; recomputing the HMAC with the shared secret proves the request came from this webhook.
- CCreate the webhook with Send me everything and filter event types inside the functionSend me everything delivers every event type, which directly violates the requirement that the function not receive issue or star payloads.
- DHave the function accept only requests whose X-GitHub-Delivery header contains a valid GUIDX-GitHub-Delivery is an unsigned identifier for the delivery; anyone can send a GUID, so it provides no proof of origin.
- EAdd a GitHub Actions workflow on push that sends a personal access token to the function in the request bodyA workflow could call the function, but placing a personal access token in a request body exposes a credential and replaces the webhook integration the scenario asks for.
Why: Webhooks push event notifications to an HTTP endpoint, so the two design questions are which events to send and how the receiver authenticates them. GitHub lets you subscribe to individual events, which keeps the receiver simple and reduces load. A webhook secret enables payload signing, and the receiver must compute an HMAC SHA-256 over the raw body and compare it to X-Hub-Signature-256 with a constant-time comparison. Azure DevOps service hooks follow the same pattern with event filters and a Web Hooks consumer that can send basic authentication or custom headers.
Configure collaboration and communication
Redfern Utilities runs a multi-stage YAML pipeline named billing-release in the Azure DevOps project Metering. The release team uses a Microsoft Teams channel named Billing Releases and wants notifications in that channel only when a stage fails, plus the ability to approve pending production deployments directly from the channel. Minimizing administrative effort is the deciding factor.
What should you do?
- AAdd the Azure Boards app to the channel and subscribe it to the Metering area pathThe Azure Boards app for Teams posts work item activity, not pipeline run results or deployment approvals.
- BAdd the Azure Pipelines app to the channel, run @azure pipelines subscribe with the pipeline URL, and filter the stage notifications to failed resultsThe Azure Pipelines app for Teams subscribes a channel to a pipeline, lets you filter the Run stage state changed subscription by result, and its default Run stage waiting for approval subscription lets approvers approve or reject deployments from the channel.
- CAdd the GitHub app to the channel and subscribe it to the repository with workflows notifications enabledThe GitHub app for Teams reports GitHub Actions workflow runs and other GitHub activity; it does not receive Azure Pipelines events or approvals.
- DCreate a project notification subscription for failed builds that emails the channel's email addressEmailing the channel can post failure messages, but email posts do not support approving deployments from Teams, so the approval requirement is not met.
Why: Microsoft provides separate Teams apps for Azure Pipelines, Azure Boards, and Azure Repos, plus a GitHub app, and picking the one that matches the source of events is the first decision. The Azure Pipelines app subscribes a channel to a pipeline with @azure pipelines subscribe, and subscriptions can be filtered, for example to failed stages only, to avoid noisy channels. Because approval requests are delivered as actionable cards, approvers can act without leaving Teams. Email-based notifications and the wrong app are real features, but they either lack interactivity or report on the wrong product; Office 365 connectors are also retired, so the apps or the Workflows app are the supported integration paths.
Configure collaboration and communication
Ashgrove Bank has connected the GitHub repository ashgrove/loan-portal to the Azure DevOps project Lending, which uses the Agile process, by using the Azure Boards app for GitHub. A developer is fixing Bug 4812 in a feature branch. The team wants the pull request to appear on the Bug's Development section and wants Bug 4812 to move to the Resolved state automatically when the pull request is merged into the default branch, without any manual update in Azure Boards.
What should the developer include in the pull request description?
- A#4812In GitHub, #4812 references GitHub issue or pull request number 4812 in the repository, not an Azure Boards work item.
- BCloses #4812Closes #4812 closes GitHub issue 4812 when merged, which is the GitHub Issues keyword behavior and does not affect the Azure Boards Bug.
- CAB#4812AB#4812 creates the link to the Bug, but without a fix keyword or state name the work item stays in its current state after the merge.
- DFixes AB#4812AB#4812 links the pull request to the Bug, and the preceding fix, fixes, or fixed keyword transitions the work item to the first state in the Resolved category, which is Resolved for an Agile Bug, when the pull request merges into the default branch.
Why: With the Azure Boards app connected, the AB#ID syntax in a commit message, pull request title or description, or GitHub issue creates a link to the Azure Boards work item. Prefixing the mention with fix, fixes, or fixed also transitions the work item to the first state in the Resolved category, or to the first Completed state if the process has no Resolved state, but only when the pull request is merged into the default branch. A state name such as Closed AB#4812 moves the item to that specific state instead. The trap options use GitHub's own #number and Closes #number syntax, which target GitHub issues rather than Azure Boards. This combination gives traceability from the work item to the code and removes a manual status update.