Design Processes & Communications — MOC
Start here for AZ-400. DevOps is not a pipeline product list. Before choosing Git workflow or deployment tooling, establish how work is planned, traced, measured, documented, and communicated.
The core idea
A delivery system has an evidence trail: a problem becomes a work item; work becomes a branch and pull request; the pipeline produces a tested artifact; deployment reaches an environment; telemetry and incidents feed the next decision. This path teaches the links between those events.
Concepts
- github-flow and branching-strategy
- devops-traceability
- devops-flow-metrics
- docs-as-code and release-notes-templates
- devops-collaboration-integration, azure-boards, github, and webhooks
Modules in this path
- Design flow of work and traceability
- Measure DevOps flow and delivery health
- Document and integrate collaboration
Skills measured (current AZ-400 blueprint)
- Design flow of work, feedback cycles, tracking integration, and source/bug/quality traceability.
- Design dashboards, metrics, and queries for planning, development, testing, security, delivery, and operations.
- Configure Markdown/Mermaid documentation, release documentation, Git-history automation, webhooks, Boards/GitHub integration, and team communication.
Route check: Trace one proposed feature from issue to deployed artifact to production metric. If any step relies on manually copying status between tools, identify the integration or evidence that is missing.
Practice questions
- Q: preserve delivery traceability
- Q: choose delivery metrics
- Q: secure a webhook integration
- Q: docs as code
- Q: operational feedback to backlog
- Q: make work items releasable
- Q: expose blocked work
- Q: turn an incident into improvement
- Q: keep runbooks current
- Q: triage customer feedback
- Q: reduce overloaded delivery
- Q: choose a planning system
- Q: use delivery metrics responsibly
- Q: keep a roadmap connected
- Q: communicate a risky change
- Q: prioritize production debt
- Q: make a retrospective actionable
- Q: identify a service owner
Related
AZ-400 course MOC · Next: Git for enterprise DevOps
Conceptual checkpoint
Explain the sequence in this path using one workload scenario: identify the boundary being changed, the identity or tool acting on it, the expected evidence, and the failure that would change your decision.
Sources and re-audit
- AZ-400 course overview, checked 2026-08-31.
- AZ-400 study guide, checked 2026-08-31.
Re-audit when the AZ-400 course path, study-guide effective date, or the services and permissions taught here change.