AZ-400 processes and communications explained
Design and implement processes and communications is 10-15% of AZ-400. It covers how work is tracked from idea to release, which metrics tell you whether delivery is healthy, and how teams document and talk about their work. The questions are less technical than the pipeline domain and are often won by knowing which tool links to which: Azure Boards, GitHub Issues and Projects, wikis, webhooks and Microsoft Teams.
Traceability and flow of work
The outline names three sub-topics here.
Flow of work. GitHub Flow is a lightweight branching model: branch from main, commit, open a pull request, review, merge, deploy. It suits teams that release continuously. The exam may contrast it with models that carry release branches.
Feedback cycles. Notifications, GitHub Issues and the way bugs and requests return to the team. Know that issues can be labelled, assigned and grouped into milestones and projects.
Tracking and traceability. You should be able to connect a work item to the code that implements it and to the build that carries it. In Azure Boards, a work item can be linked from a commit or pull request by writing AB#123 in the message once the GitHub repository is connected. In the other direction, the pipeline run shows associated work items and commits. The point is source, bug and quality traceability: from a failing test or a production bug back to the change and the requirement.
| Need | Typical answer |
|---|---|
| Link GitHub commits and pull requests to Azure Boards work items | Connect the repo to Boards; reference AB#<id> |
| Plan work in GitHub itself | GitHub Issues and GitHub Projects |
| Show which work items shipped in a release | Associated work items on the pipeline run |
| Notify a channel when a pull request opens | Teams integration for GitHub or Azure DevOps |
Metrics and dashboards
You are expected to know what flow metrics mean and where to surface them.
| Metric | Meaning |
|---|---|
| Lead time | From a request being created to it being delivered |
| Cycle time | From work starting to it being finished |
| Time to recovery | How quickly service is restored after a failure |
| Failure rate / change failure | How often a release causes a problem |
Azure DevOps dashboards use widgets backed by queries and analytics views, for example a cumulative flow diagram, velocity or a query tile. The outline asks for metrics and queries for planning, development, testing, security, delivery and operations, so expect scenario questions such as “which widget shows how long bugs stay open”.
Collaboration and communication
- Wikis. Azure DevOps project wikis and GitHub wikis are written in Markdown. The outline specifically names Mermaid for process diagrams inside Markdown.
- Release documentation. Release notes and API documentation, and automating them from Git history, for example generating a changelog from commit messages or pull request titles.
- Webhooks. A service hook or webhook sends an HTTP POST to another system when an event occurs, such as a build completing or a pull request being created.
- Boards and GitHub. The Azure Boards app for GitHub connects the two products.
- Teams. Both GitHub and Azure DevOps can post notifications to Microsoft Teams channels.
Common mistakes
- Treating lead time and cycle time as the same measurement.
- Choosing a custom script when a native integration exists. If the requirement is “link commits to work items”, the answer is the Boards integration, not a pipeline task.
- Forgetting that a webhook delivers events to a URL you control, while an integration is a managed connection.
Example questions
Question 1. A team keeps requirements in Azure Boards and code in GitHub. A reviewer wants to open a pull request and see which work item it implements. What is the simplest solution?
- A. Maintain a wiki table that maps pull requests to work items
- B. Add a pipeline task that posts the work item URL as a comment
- C. Connect the repository to Azure Boards and reference AB# and the work item number in the pull request
- D. Copy the pull request URL into each work item description
Show answer
Answer: C
With the Azure Boards app connected to the repository, mentioning AB# followed by the work item number in a commit message or pull request description creates a link visible on both sides. A wiki table or manual copy of URLs needs ongoing effort, and a pipeline task that posts comments does not create a native work item link.
Want more questions like this? Full AZ-400 practice tests →
Question 2. Management wants a dashboard that shows how long it takes from a developer starting work on a change until the change is finished. Which metric should the dashboard show?
- A. Cycle time
- B. Lead time
- C. Time to recovery
- D. Change failure rate
Show answer
Answer: A
Cycle time measures the time from work starting to work completing. Lead time starts earlier, when the request is created. Time to recovery measures restoring service after a failure, and change failure rate measures how many releases cause problems; neither measures how long work takes.
Want more questions like this? Full AZ-400 practice tests →
Question 3. You want to include a sequence diagram of the release process in the Azure DevOps project wiki, stored as text so that it can be reviewed and versioned. What should you use?
- A. A screenshot uploaded as an attachment
- B. A Visio file attached to the page
- C. A PDF exported from a diagramming tool
- D. A Mermaid diagram in a Markdown wiki page
Show answer
Answer: D
Mermaid syntax inside a Markdown wiki page renders diagrams from plain text, so it can be diffed and versioned like code. An uploaded image cannot be reviewed as text. A Visio file is a binary attachment, and a PDF export is not editable in the wiki.
Want more questions like this? Full AZ-400 practice tests →
Next
Continue with source control, or test the whole exam with the practice test.