AZ-400 exam's collaboration and communication section asks you one core question: which tool connects your team with the least operational overhead? Code can ship flawlessly, but without documentation a new hire spends days getting up to speed, and a successful deployment that no one knows about delays stakeholder validation. The guiding principle throughout this domain is straightforward. Reach for official apps first and write custom code only when nothing else fits.
Choosing Between Project Wiki and Published Wiki
Imagine joining a company where no onboarding documents exist and every question requires a Slack thread. Azure DevOps Wiki prevents exactly that, and the exam tests which of its two variants you would choose.
is the faster starting point because Azure DevOps automatically creates a dedicated Git repository and you can begin editing immediately. , on the other hand, requires you to commit Markdown files to an existing Azure Repos repository before you can activate it. That prerequisite step is the most common trap question.
| Attribute | Project Wiki | Published Wiki | |-----------|-------------|----------------| | Repository | Dedicated Git repo auto-created | Connected to existing Repos repo | | Getting started | Immediate | Markdown files must be committed first | | Contribution model | Wiki-only editor | Standard PR workflow |
When the scenario calls for PR-based contributions and full Git history tracking, choose Published Wiki — committing Markdown files first is the required step.
Navigation order in the wiki sidebar is controlled by files, one per folder, listing page names in the desired sequence. Because this file lives in Git, a pipeline script can automate it. UI drag-and-drop internally rewrites the same file.
Markdown and Mermaid — Version-Controlling Docs as Text
What happens when documentation lives in Word files? Git cannot produce a useful diff, and two simultaneous edits produce a merge conflict that neither engineer wants to resolve. Markdown solves this because it is plain text and Git's diff and merge engine can track every line change. Both GitHub and Azure DevOps automatically render files as formatted HTML.
Diagrams deserve the same treatment. Dropping a PNG or Visio export into a repository makes it impossible to see what changed in a review. Mermaid expresses diagrams in text syntax and is natively rendered by GitHub and Azure DevOps Wiki without plugins. A fenced code block inside a file is all it takes.
Diagram type selection guide:
Process flow and decision branches → Message ordering between systems → State transitions and composite states → Class structure and inheritance →
For publishing Markdown documentation as a static website on GitHub Pages, Jekyll is the built-in choice. It ships with GitHub Pages and needs only a and Markdown files — a push triggers automatic build and deployment. Hugo and Gatsby both require a custom GitHub Actions pipeline, so when the scenario says no additional infrastructure, those are wrong answers.
Service Hooks and GitHub Webhooks — Pushing Events to External Systems
Picture a deployment failing at 2 a.m. and nobody finding out until morning standup. Without an event-delivery mechanism, that is exactly what happens. Azure DevOps and GitHub each offer a way to push events to external systems the moment they occur.
is Azure DevOps's built-in event-delivery feature, configurable through the UI in Project Settings without code. It supports over thirty event types and destinations including Jenkins, Slack, Teams, and generic HTTP endpoints.
| Scenario | Choice | |----------|--------| | Azure Repos → trigger Jenkins build | Service Hook with Jenkins | | Azure DevOps → internal custom system | Service Hooks Web Hooks | | GitHub → legacy external service, no polling | GitHub Webhook |
delivers email to people. Automated systems like Jenkins cannot receive HTTP requests via email, so email subscriptions are never correct for build-system integration. Exam questions regularly place Email Subscription alongside Service Hook as a distractor.
When an Azure Monitor alert must reach an external system and the payload needs transformation, create a Logic App first and reference its endpoint from an Action group. Logic App handles transformation through its HTTP connector without writing any code. For complex custom logic, Function App is the answer.
Teams Integration — Official Apps Come First
Suppose the engineering team uses Microsoft Teams but must open the Azure DevOps portal every time they want a pipeline status. Installing the right official app removes that friction. Whenever a scenario pairs with , an official app is the first answer.
| App | Source | What it delivers | |-----|--------|------------------| | Azure DevOps for Teams | Azure DevOps events | PR and work item status updates per channel | | Azure Pipelines for Teams | Azure Pipelines | Build and release success/failure subscriptions | | Azure Boards app for Teams | Azure Boards | Work item state-change notifications | | Microsoft Teams for GitHub | GitHub | PR, issue, and workflow run results in real time |
When every build event floods a single channel and useful alerts get lost in the noise, adding a filter to the existing subscription is the right move. The Azure Pipelines Teams app supports the command to filter by Build status, Pipeline name, or Branch name. The exam distinguishes between — low overhead — and — high overhead and therefore wrong.
Boards–GitHub Integration — The First Step That Everyone Forgets
Imagine a developer merging a pull request on GitHub while the project manager on Azure Boards has no idea the work item is done. Boards–GitHub integration removes that double-entry work.
The official way to connect GitHub to Azure Boards is , installed from GitHub Marketplace. Typing in a commit message or PR description automatically creates a bidirectional link. Authentication uses OAuth.
OAuth versus alternative authentication methods:
OAuth → delegated web application authorization (Azure Boards ↔ GitHub) SSH key → remote repository access for git clone and push Managed identity → Azure-to-Azure resource authentication, cannot link directly to GitHub
Pull request discussions and code review workflows are collaboration tools in their own right. ChatOps takes this further: in a ChatOps model the chat platform — Teams or Slack — becomes the control plane for operations. Commands like and let engineers trigger pipelines or check deployment status without ever leaving the chat window.
Exam Key Takeaways
Published Wiki prerequisite -- commit Markdown files to Azure Repos first Wiki navigation order automation -- edit the file GitHub PR + Git-versioned documentation -- Markdown Text-based diagrams with GitHub native rendering -- Mermaid Composite state visualization -- Mermaid GitHub Pages + Markdown, no additional infrastructure -- Jekyll Azure Repos → Jenkins build trigger, no code -- Service Hook with Jenkins Automated system integration instead of email -- Service Hooks (not Email Subscription) GitHub → Teams notifications, no custom code -- Microsoft Teams for GitHub app Azure Pipelines failures → Teams -- Azure Pipelines for Teams Reduce Teams notification noise -- add a Subscription filter GitHub PR ↔ Azure Boards first step -- install Azure Boards app for GitHub (OAuth) Payload transformation + external webhook, no-code -- Logic App + Action group