AZ-400 is one continuous-delivery system. Work tracking and collaboration define intent. Source control records change. CI builds and tests. Package management produces versioned artifacts. Release pipelines deploy through controlled strategies. Security and compliance protect the process. Instrumentation measures the result and feeds new work back into the system. The current AZ-400 weighting makes the pipeline layer the center of this map.
Flow of work starts before source control
Azure Boards, GitHub Issues/Projects, feedback cycles, traceability, and metrics define what the team intends to change and why. A work-management model should connect requirements and bugs to commits, pull requests, builds, releases, and incidents.
Without traceability, teams can deploy quickly yet struggle to explain which business request produced a change.
Source control creates the auditable change boundary
Branch strategy, pull requests, branch protection/policies, permissions, tagging, repository scale, large-file handling, and sensitive-data cleanup determine how code changes enter the delivery system.
Trunk-based, feature-branch, and release-branch approaches should be chosen from team size, release cadence, risk, and product needs.
Packages and artifacts carry tested outputs forward
Azure Artifacts, GitHub Packages, feeds/views, dependency versions, SemVer/CalVer, and pipeline-artifact versioning create reproducible inputs and outputs.
Artifact identity should be stable across environments so teams deploy the same tested build rather than rebuilding differently for production.
CI connects source changes to quality evidence
Build triggers, YAML, agents/runners, tests, code coverage, security scanning, and quality gates provide fast feedback after change. The CI/CD pipeline is therefore both an automation path and an evidence path.
Pipeline speed matters, but so does confidence; teams should move expensive tests later only when earlier checks preserve useful feedback.
Release strategy manages production risk
Blue-green, canary, rings, progressive exposure, A/B testing, feature flags, rolling deployments, slots, hotfix paths, and approvals reduce blast radius and provide rollback or controlled expansion.
The map should show deployment decision points connected to telemetry so a release can stop or roll back when evidence degrades.
IaC extends source control into infrastructure
Bicep, ARM, Azure Machine Configuration, Automation State Configuration, or other configuration/IaC approaches turn environments into versioned definitions.
The same pull-request, testing, security, and promotion discipline used for application code should apply to infrastructure changes.
Identity and secrets protect the automation plane
Managed identities, service principals, GitHub Apps, GITHUB_TOKEN, PATs, service connections, OIDC/workload identity federation, Key Vault, and secure files determine what pipelines can access.
A Key Vault approach is strongest when long-lived secrets are minimized and permissions are scoped to the job.
DevSecOps inserts control throughout the path
Dependency, code, secret, license, container, and vulnerability scanning plus GitHub Advanced Security and Defender for Cloud DevOps Security create automated security feedback.
A DevSecOps model belongs from commit through build and release, not as one gate at the end.
Instrumentation turns releases into learning
Azure Monitor, Application Insights, infrastructure metrics, GitHub insights, pipeline alerts, distributed tracing, and KQL help teams understand performance, reliability, user behavior, and deployment impact.
The feedback should create work items, rollback decisions, reliability improvements, or capacity changes rather than exist only in dashboards.
The complete map is a feedback cycle
Idea → work item → branch/PR → CI/test/security → versioned artifact → deployment strategy → production telemetry → incident/feedback → new work. That cycle is the architecture behind the AZ-400 DevOps role.
The map should show feedback cycles between work management and operations. An alert or production incident can create a bug or work item, which links to the commit and pull request that fixes it, then to the deployment that restores service. This traceability is the practical meaning of closing the DevOps loop.
Cycle time and lead time should sit near flow of work rather than infrastructure metrics. They measure how efficiently change moves from request or work start to delivery. Improving them can expose bottlenecks in review, testing, environments, approvals, or release processes.
Documentation should be connected to source control and automation. Markdown/Mermaid diagrams, wikis, API docs, and release notes can be generated or versioned with code so architecture and operational instructions do not drift far from the running system.
Branch protection should sit between source control and CI. Required reviews and status checks make the merge event a governance boundary: unreviewed or failing code should not become the mainline input to downstream automation.
Large-file and repository-scaling tools should appear on the source-control operations branch. A branching strategy can be correct while a repository remains unusably slow because binaries, history size, or monorepo scale are not managed. DevOps design includes developer productivity.
Package feeds should be connected to dependency scanning and provenance. The same package that accelerates reuse can introduce a vulnerable or untrusted dependency. Approved feeds/views and version controls create a safer promotion path from dependency discovery to production use.
Test strategy should show layers of feedback speed. Unit tests run quickly near the commit; integration tests validate system interaction; load tests examine performance; security/governance gates validate risk. Not every test belongs in the same stage.
Runner and agent infrastructure belongs between pipelines and target networks. Self-hosted infrastructure can reach private resources and use custom tooling, but it needs patching, isolation, autoscaling, credentials, and lifecycle management. Hosted runners trade some control for reduced operations burden.
Environments and approvals should be drawn as deployment-control points. Production may require an approval, business-hours check, security gate, or lock even when lower environments deploy automatically. The map should show why CI success and production authorization are separate concepts.
Feature flags should sit between deployment and release. Code can be deployed but functionality remain disabled for most users. This separation allows progressive exposure and rapid rollback of behavior without necessarily redeploying the application.
Database changes should connect to dependency ordering and rollback. Applications, migrations, and data may need a sequence that preserves compatibility. A deployment map that ignores database state is incomplete for many production systems.
Infrastructure as code should include desired-state drift and self-service environments. Templates define intended infrastructure, configuration tools keep resources aligned, and deployment environments can let developers provision approved patterns. Platform automation is part of the delivery product.
Secrets should be drawn as temporary access dependencies, not static strings. Key Vault, managed identities, OIDC/workload identity federation, GITHUB_TOKEN, GitHub Apps, and service connections provide different authentication patterns. The strongest path minimizes long-lived credentials and scopes permissions narrowly.
Security scanning should feed both developer feedback and governance evidence. A secret or dependency issue discovered in a pull request can be fixed before merge; a license or container policy may gate release; Defender for Cloud can connect code findings with deployed-resource risk.
Pipeline health belongs in observability beside application health. Long queue times, flaky tests, runner exhaustion, rising failure rate, or slow stages can reduce delivery reliability even when the application itself is healthy. The delivery system is a production service for engineering teams.
Artifact retention should connect cost, rollback, and audit. Keeping every build forever can be expensive; deleting too aggressively can remove rollback or evidence. A retention strategy should distinguish release artifacts, transient CI outputs, packages, and compliance requirements.
Classic-to-YAML migration belongs on the maintainability branch because pipeline definitions become reviewable, versioned code. The value is not only modernization; it is making delivery behavior reproducible and auditable through the same source-control workflow as the application.
Application Insights distributed traces should feed release decisions. If a canary shows higher dependency latency or error rates for one user cohort, progressive exposure can stop before the whole population is affected. Telemetry and deployment strategy are therefore one connected control system.
KQL sits on the analysis layer because raw logs are rarely useful without questions. DevOps engineers should be able to query enough telemetry to diagnose deployment or application behavior, while deeper security or data analytics can remain specialist work.
The complete map should help identify bottlenecks: work waiting for review, slow CI, unreliable tests, manual approvals, unsafe secrets, deployment blast radius, or missing telemetry. The AZ-400 objective is not to automate everything blindly; it is to improve the flow of safe, observable value.
Workload identity federation should be shown as a trust relationship between the CI system and Azure rather than as “another secret.” The pipeline presents a short-lived identity assertion, Azure validates the configured trust, and access is granted according to the assigned role. This reduces secret rotation burden while preserving least privilege.
Deployment slots belong on the low-downtime branch. An application can deploy to a staging slot, validate behavior, then swap traffic. This differs from blue-green infrastructure at larger scope but serves the same architectural goal of separating deployment from immediate full production exposure.
Hotfix flow should connect source control, CI, release, and back-merge. An emergency path that bypasses all testing or never rejoins the main branch creates long-term divergence. A good hotfix process is faster because it narrows the change, not because it abandons governance.
DevOps metrics should include reliability of the delivery system itself. A team with fast lead time but frequent failed deployments or long recovery time may be optimizing throughput at the expense of stability. DORA-style measures are useful because they make speed and reliability visible together.
The map should also show ownership boundaries. Platform teams can own reusable pipeline templates and runner infrastructure, developers own application code/tests, security owns policy and scanning requirements, and SRE/operations owns reliability signals. Shared ownership reduces duplicated tooling while keeping accountability clear.
Use the map when studying scenarios: identify where the delivery loop is weak, then choose the control that fixes that stage without creating unnecessary friction elsewhere.