Overview
Domain 1 is the process layer of AZ-400. Microsoft lists three functional groups. Traceability and flow of work covers GitHub Flow, feedback cycles with notifications and GitHub Issues, tracking work across GitHub projects, Azure Boards and repositories, and tracing source, bugs and quality back to requirements. The metrics group asks you to build dashboards for cycle time, lead time and time to recovery, plus queries for planning, development, testing, security, delivery and operations.
The collaboration group covers project wikis with Markdown and Mermaid diagrams, release notes and API documentation, generating documentation from Git history, webhooks, the Azure Boards app for GitHub, and Microsoft Teams integration for both GitHub and Azure DevOps. AZ-400 is active as of October 2026, with skills measured last updated on July 27, 2026 and no retirement announced.
How it's tested
Process questions describe a team using GitHub, Azure DevOps or both, and a gap such as missing traceability, no visibility of flow, or scattered documentation. You choose the integration, metric, query or documentation feature that closes the gap with the least custom work. Expect tool names to matter more than theory.
-
Link the work
Commits, pull requests and work items live in different tools, and you pick the integration or mention syntax that connects them.
-
Pick the metric
A manager wants to measure delivery speed or stability, and you choose lead time, cycle time, deployment frequency or time to recovery.
-
Document and notify
A team needs diagrams in a wiki, release notes or chat alerts, and you choose Mermaid, a webhook or the Teams app.
A team plans in Azure Boards but stores code in GitHub, and auditors want every merged change tied to a work item. Building a custom webhook service would work but adds maintenance. Installing the Azure Boards app for GitHub, connecting the repositories, and requiring AB#ID mentions in commits and pull requests gives two-way links and can transition items on merge. That is the lowest-effort answer the exam expects.
Functional groups 3
Official functional groups from the Microsoft outline, in outline order.
1.1 Design and implement traceability and flow of workGitHub Flow, feedback cycles, work tracking integration and end-to-end traceability.
- What it means
- This group covers designing a structure for the flow of work such as GitHub Flow, setting up feedback loops through notifications and GitHub Issues, integrating work tracking across GitHub projects, Azure Boards and repositories, and making sure source changes, bugs and quality results can be traced back to the requirement that caused them.
- What to understand
- GitHub Flow is a lightweight model: branch from main, commit, open a pull request, review, deploy or test, then merge. Work tracking can sit in GitHub Issues with GitHub Projects boards, or in Azure Boards with Agile, Scrum, Basic or CMMI processes. When code is in GitHub and planning is in Azure Boards, the Azure Boards app links them, and AB# mentions in commits or pull requests create links; a keyword such as fixes AB#42 can move the item to Done on merge. Traceability also means linking test results and bugs to builds and requirements so a release can be audited.
- How it shows up
- Expect a mixed GitHub and Azure Boards scenario asking how to link commits or close work items automatically.
- Common confusion
- Using a #42 mention, which links a GitHub issue, when the item actually lives in Azure Boards and needs AB#42.
1.2 Design and implement appropriate metrics and queries for DevOpsDashboards and queries for flow, planning, development, testing, security, delivery and operations.
- What it means
- This group asks you to design dashboards that show flow of work, such as cycle time, time to recovery and lead time, and to pick useful metrics and queries for each stage: project planning, development, testing, security, delivery and operations.
- What to understand
- Lead time runs from when work is requested to when it is delivered; cycle time runs from when work starts to when it is done. The DORA measures add deployment frequency, change failure rate and time to restore service. Azure DevOps dashboards use widgets such as Lead Time, Cycle Time, Burndown, Velocity and Cumulative Flow, and Analytics views feed Power BI. Work item queries written with the query editor or WIQL drive charts, for example active bugs by severity. Testing metrics include test success trends and flaky tests; security metrics include open vulnerability counts by severity; operations metrics include mean time to recover and availability.
- How it shows up
- Expect a stakeholder question naming a goal, such as faster delivery or fewer failed changes, and asking which metric or widget shows it.
- Common confusion
- Swapping lead time and cycle time; lead time starts at the request, cycle time starts when someone begins work.
1.3 Configure collaboration and communicationWikis, Mermaid, release notes, Git-history docs, webhooks, Boards-GitHub and Teams integration.
- What it means
- This group covers documenting a project with wikis and process diagrams in Markdown and Mermaid, producing release notes and API documentation, automating documentation from Git history, integrating systems with webhooks, connecting Azure Boards to GitHub repositories, and integrating GitHub or Azure DevOps with Microsoft Teams.
- What to understand
- Azure DevOps offers a project wiki and a publish-code-as-wiki option that renders Markdown from a repository branch; both support Mermaid diagrams with the ::: mermaid block. GitHub renders Mermaid in fenced code blocks in Markdown files, issues and wikis. Release notes can be generated from commit messages or pull request titles in a pipeline task or with GitHub's automatically generated release notes. Webhooks in Azure DevOps are service hooks that post JSON to an endpoint on events such as build completed. Teams integration uses the Azure Boards, Azure Pipelines and Azure Repos apps or the GitHub app for Teams, with subscriptions per channel.
- How it shows up
- Expect a scenario asking how to notify a channel, render a flow diagram, or produce release notes without manual editing.
- Common confusion
- Assuming one Teams app covers every Azure DevOps service; Boards, Pipelines and Repos have separate subscriptions.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
GitHub Flow
Branch, commit, pull request, review, merge to main.
- Remember
- Short-lived branches and a deployable main.
- Tested as
- Flow of work design.
- Trap
- Confusing it with Git Flow's develop and release branches.
-
AB# mention
Syntax that links a GitHub commit or pull request to an Azure Boards item.
- Remember
- Fix or close keywords can transition the item on merge.
- Tested as
- Traceability questions.
- Trap
- Using # alone, which targets GitHub issues.
-
Azure Boards app for GitHub
Connects an Azure DevOps project to GitHub repositories.
- Remember
- Installed from GitHub Marketplace.
- Tested as
- Integration questions.
- Trap
- Building a custom webhook instead.
-
Lead time
Time from work item creation to completion.
- Remember
- The customer-facing view of speed.
- Tested as
- Metrics selection.
- Trap
- Using cycle time for a customer view.
-
Cycle time
Time from when work starts to completion.
- Remember
- Shows team throughput once work begins.
- Tested as
- Metrics selection.
- Trap
- Starting the clock at creation.
-
Time to recovery
How quickly service is restored after a failure.
- Remember
- A DORA stability measure.
- Tested as
- Operations dashboards.
- Trap
- Measuring it from ticket close rather than outage start.
-
Cumulative flow diagram
Chart of work item counts per state over time.
- Remember
- Widening bands reveal bottlenecks.
- Tested as
- Flow analysis.
- Trap
- Reading it as a burndown chart.
-
WIQL and work item queries
Queries that filter and chart work items.
- Remember
- Shared queries feed dashboard widgets.
- Tested as
- Planning and testing metrics.
- Trap
- Expecting queries to read pipeline logs.
-
Mermaid in wikis
Text-based diagrams rendered in Markdown.
- Remember
- Azure DevOps wiki uses ::: mermaid; GitHub uses a fenced mermaid block.
- Tested as
- Documentation questions.
- Trap
- Embedding static images that drift from reality.
-
Service hooks
Azure DevOps webhooks that send event payloads to other services.
- Remember
- Triggered by events like work item updated or build completed.
- Tested as
- Integration questions.
- Trap
- Polling the REST API on a schedule instead.
-
Teams integration apps
Azure Boards, Pipelines, Repos and GitHub apps for Microsoft Teams.
- Remember
- Each channel subscribes to chosen events.
- Tested as
- Communication questions.
- Trap
- Assuming email notifications cover chat.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Lead time vs cycle time vs time to recovery
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Lead time | Request to delivery | Includes waiting before work starts | Treating it as development time only |
| Cycle time | Work started to done | Excludes backlog wait | Using it to report customer wait |
| Time to recovery | Failure to restored service | Measures stability, not speed of features | Mixing it with incident close time |
Where work is tracked
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| GitHub Issues with Projects | Issues and boards inside GitHub | Native for GitHub-only teams | Expecting Azure Boards process templates |
| Azure Boards | Work items with process templates and queries | Rich queries, Analytics and dashboards | Forgetting the GitHub app for code links |
| Azure Boards with GitHub repos | Planning in Boards, code in GitHub | Linked with AB# mentions | Expecting automatic links without the app |
Documentation options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Project wiki | Wiki stored in a hidden repo per project | Edited in the web UI | Expecting branch-based versioning |
| Code wiki | Markdown published from a repo folder | Versioned with branches and pull requests | Thinking it is editable without commits |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Cycle time for customers
- What candidates pick
- Report cycle time to show how long customers wait.
- Why it looks right
- It sounds like end-to-end time.
- Why it's wrong
- Cycle time starts when work begins, so it hides backlog wait that customers experience.
Clue to watch for The scenario says from request or from when the item was created.
-
Custom sync service
- What candidates pick
- Write an Azure Function to sync GitHub commits with Azure Boards.
- Why it looks right
- It feels flexible.
- Why it's wrong
- The Azure Boards app plus AB# mentions already provides links and state transitions with no code to maintain.
Clue to watch for Least effort or minimal maintenance is stated.
-
Email for chat
- What candidates pick
- Configure email notifications for build failures.
- Why it looks right
- Email notifications are easy to set up.
- Why it's wrong
- The requirement is a Teams channel, which needs the Azure Pipelines or GitHub app subscription.
Clue to watch for A Teams channel is named in the scenario.
-
Burndown for bottlenecks
- What candidates pick
- Use a burndown chart to find where work piles up.
- Why it looks right
- Burndown is a familiar sprint chart.
- Why it's wrong
- Burndown shows remaining work, while a cumulative flow diagram exposes growing queues in specific states.
Clue to watch for Words like bottleneck or stuck in a state.
-
Manual release notes
- What candidates pick
- Ask developers to edit a release notes page each sprint.
- Why it looks right
- It gives full control over wording.
- Why it's wrong
- Generating notes from commit messages or pull requests in the pipeline keeps them accurate and repeatable.
Clue to watch for Automate creation of documentation from Git history.
Answer framework
Use these steps to choose a process, metric or communication answer in a Domain 1 scenario.
- Identify where planning lives and where code lives, because GitHub-only, Azure DevOps-only and mixed setups need different integrations.
- For traceability, pick the built-in link: AB# mentions with the Azure Boards app, or issue references for GitHub-only teams.
- For measurement, map the stakeholder goal to a metric: lead time for customer wait, cycle time for team flow, time to recovery for stability.
- Choose the delivery surface for the metric: a dashboard widget, a work item query chart, or an Analytics view in Power BI.
- For communication, prefer native features first: wiki with Mermaid, generated release notes, service hooks and the Teams apps before custom code.
Practice question
Want more like this? The AZ-400 practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this domain as vocabulary plus a handful of integrations. Start by writing one-line definitions of lead time, cycle time, deployment frequency, change failure rate and time to recovery, then say which Azure DevOps widget or query would show each one. Build a small dashboard in a free Azure DevOps organization with Lead Time, Cycle Time and Cumulative Flow widgets so the charts are familiar.
Next, connect a test GitHub repository to Azure Boards with the Azure Boards app. Push commits with AB# mentions and merge a pull request containing fixes AB#ID, then watch the item change state. Repeat with GitHub Issues and a GitHub Projects board so you can contrast the two tracking options.
Finish with documentation and chat. Create a project wiki, publish a repo folder as a code wiki, and render a Mermaid flowchart in each. Install the Azure Pipelines app in a Teams channel and subscribe to failed builds. Plan around eight to ten hours, then move on to the pipelines domain, which carries far more weight.
FAQ
How much of AZ-400 is Domain 1, Design and implement processes and communications?
Microsoft weights it at 10–15% across three functional groups: traceability and flow of work, metrics and queries, and collaboration and communication.
Is AZ-400 retiring?
No retirement was announced as of October 2026. Microsoft refreshed the skills measured on July 27, 2026 with minor changes.
What is the prerequisite for the DevOps Engineer Expert certification?
Microsoft's certification page lists Azure Administrator Associate or Azure Developer Associate. The Developer Associate is now marked retired, so check the current requirement on Microsoft Learn before booking.
Do I need to know DORA metrics by name?
The study guide names cycle time, time to recovery and lead time explicitly. Knowing deployment frequency and change failure rate helps with delivery and operations metric questions.
What syntax links a GitHub commit to an Azure Boards work item?
Use AB# followed by the work item ID in the commit message or pull request, after connecting the repository with the Azure Boards app.
How do I draw diagrams in an Azure DevOps wiki?
Use Mermaid syntax inside a ::: mermaid block. GitHub Markdown renders Mermaid in a fenced code block tagged mermaid.
Which Teams integration should I use for build alerts?
Install the Azure Pipelines app for Microsoft Teams, or the GitHub app for GitHub Actions, and subscribe the channel to the events you need.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
You have covered flow of work, traceability, DevOps metrics and collaboration tools. Check whether you can pick the right integration and metric under exam conditions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the AZ-400 AI tutor Get any concept explained your way