Surfacing Azure Boards Work Item Status in README.md by Installing the Azure Boards App for GitHub
Short answer
C Installing the Azure Boards app for GitHub establishes the integration that lets board work item status flow into the repository for the README badge.
Question
Key Takeaways
The Azure Boards app for GitHub is the integration that connects the board to the GitHub repository, and it is what makes board state reflect into repository content such as the status badge in README.md, so it has to be installed before any badge configuration takes effect.
A project uses an Azure Boards board while code lives in a GitHub repository, and README.md must display the status of the board's work items with minimal administrative effort. The question asks what to do first, so the step that establishes the integration has to be identified rather than a later configuration tweak.
Common mistake: Starting with the anonymous access setting for the status badge. Allowing anonymous access only controls who can see an already-working badge, so doing it first leaves the integration itself unestablished and the badge still unable to reflect board state.
Expert Analysis
Why the Answer Is Correct
The question asks what to do first, and the README.md status display depends entirely on the GitHub and Azure Boards integration existing. Installing the Azure Boards app for GitHub is that integration: once it is installed, Azure Boards can surface work item state into the GitHub repository, which is what makes the status information available to embed in README.md. Because the requirement is to minimize administrative effort, the enabling step is the right starting point, and the remaining configuration follows from it. The vote was 57 for C and 43 for D. Bakare118 and Dankho both answered C by reading the question's wording precisely, noting that it asks what to do first, and four separate comments including Gooldmember and MrAZ105 selected C on the grounds that the app installation is the required first step for the integration to work.
Why the Other Options Are Wrong
Selecting Allow anonymous users to access the status badge (D) configures who may view a badge that already works, so it is a later step and not the enabler. Dankho characterized this accurately, noting that the setting relates to badge visibility rather than getting the integration working, and that the primary step is establishing the integration. Creating a GitHub personal access token (A) is a credential step that may be needed for some API-based scenarios but is not the prerequisite for the board status integration, and it is not the first action the question is looking for. Enabling GitHub annotations for the board (B) turns comment annotations on for the board, which is a display preference for work item comments and has nothing to do with reflecting work item status into a repository file.
Community Comment Notes
The vote was close at 57 to 43, and the dissent is worth examining because it rests on a real documentation detail. schwagalla, the highest-liked commenter and the only D vote, argued that anonymous access is the easiest path and pointed to the status badge documentation, which does state that anonymous access must be allowed for the badge. Christian_garcia_martin answered C with the reasoning that the app is what links commits and pull requests to work items so that state changes reflect in the repository. The reconciliation is that the badge setting is genuinely required for visibility but is not the first step, which is why the majority reading of do first prevails.
Official Reference
This link opens the official vendor documentation in a new tab.
Community Votes
57% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 5 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 5
-
schwagalla 👍 3 Answered DI would pick D. It's the easiest option to provide a badge in the README which links to the board. This can be done with minimal effort. The documentation also states that anonymous access must be allowed. https://learn.microsoft.com/en-us/azure/devops/boards/github/configure-status-badges?view=azure-devops#add-a-status-badge
-
Christian_garcia_martin 👍 2Given answer is correct : Install the Azure Boards app for GitHub. The Azure Boards app for GitHub allows you to link GitHub commits and pull requests to your Azure Boards work items. Therefore, when the status of a work item on the Azure Boards changes, this change will reflect on the README.md file on GitHub.
-
Dankho 👍 1 Answered CC which is needed for the integration to occur D. Select Allow anonymous users to access the status badge. This relates to badge visibility but isn't the primary step to get the integration working.
-
Bakare118 👍 1 Answered CThe question asks, "What should you do first?" I think you need to install the Azure Boards app first.
-
Gooldmember 👍 1 Answered CC. Install the Azure Boards app for GitHub.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All AZ-400 Questions
Access 100 questions with complete answers and detailed explanations.
View Full AZ-400 Practice Test →