AZ-400 Source Audit — Build and Release Pipelines
This domain is 50–55% of the current AZ-400 blueprint. The vault has 82 scenario questions in this domain and two good starter labs, but count is not implementation evidence. Each official bullet below remains independently graded.
| Official source bullet (paraphrased) | Inspected vault evidence | Overall evidence grade | Conceptual grade | Relationship grade | Relationship evidence | Practical status | Exact remaining gap | Re-audit trigger |
|---|---|---|---|---|---|---|---|
| Recommend GitHub Packages/Azure Artifacts tools | az400-package-promotion-lab compares repository-bound GitHub Packages with Azure DevOps feed/upstream governance and publishes/consumes a training package | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute both registry paths and retain the source-checked result before verified. | Source effective date or product behavior changes. |
| Design package feeds and views/local/upstream packages | azure-artifacts, az400-package-promotion-lab creates a feed, checks base/view behavior, upstream saving, least-privilege roles, and restore failure | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the feed and retain permission/restore evidence before verified. | Source effective date or product behavior changes. |
| Design dependency versioning (SemVer/CalVer) | semantic-versioning, az400-package-promotion-lab publishes 0.1.0, requires exact consumer restore, and diagnoses missing/incompatible versions | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the consumer compatibility test before verified. | Source effective date or product behavior changes. |
| Design pipeline-artifact versioning | pipeline-retention, az400-package-promotion-lab joins immutable artifact, package version, commit SHA, promotion, and retention evidence | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute and retain a promotion run before verified. | Source effective date or product behavior changes. |
| Design quality/release gates, including security/governance | pipeline-evaluation-and-quality-gates, az400-pipeline-quality-and-release-lab | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Add an actual security/governance gate result, not only test/approval results. | Source effective date or product behavior changes. |
| Design local/unit/integration/load testing strategy | az400-pipeline-quality-and-release-lab, az400-azure-pipelines-controlled-delivery-lab, and az400-release-resilience-lab separate unit evidence, training smoke validation, and measured release threshold | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the selected test layers and retain results before verified. | Source effective date or product behavior changes. |
| Implement tests, agents, and test-result integration | az400-pipeline-quality-and-release-lab, az400-azure-pipelines-controlled-delivery-lab | Both labs now create JUnit and Cobertura evidence; Azure Pipelines publishes native test/coverage results and GitHub stores the training reports as artifacts | Existing failure exercises plus a coverage-threshold failure and repair | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute both platform variants and retain run output before verified. | Source effective date or product behavior changes. |
| Implement code coverage analysis | test-coverage, az400-pipeline-quality-and-release-lab, az400-azure-pipelines-controlled-delivery-lab | Both labs generate Cobertura from a small tested function, require 80% line coverage, publish/retain evidence, deliberately fail the threshold, and restore it | Configuration, diagnosis, and distinction are embedded in both labs | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute both platform variants and retain source-checked coverage output before verified. | Source effective date or product behavior changes. |
| Select GitHub Actions or Azure Pipelines | 2-ci-azure-pipelines-gh-actions-moc and az400-yaml-agents-integration-lab make the selection against repository, governance, runner, and permission boundaries | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the Azure Pipelines GitHub-repository path before verified. | Source effective date or product behavior changes. |
| Design GitHub runner/Azure DevOps agent infrastructure | az400-yaml-agents-integration-lab selects hosted vs self-hosted execution, then tests a capability demand and records tool/network/lifecycle/isolation controls | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute or safely simulate the agent selection and retain queue evidence before verified. | Source effective date or product behavior changes. |
| Integrate GitHub repositories with Azure Pipelines | az400-yaml-agents-integration-lab authorizes a GitHub App/service connection, creates the pipeline, and diagnoses a revoked connection/mapping | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the integration and retain check/webhook evidence before verified. | Source effective date or product behavior changes. |
| Develop pipeline trigger rules | webhooks-and-triggers, starter labs | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Add schedules/path filters and demonstrate undesired-trigger diagnosis. | Source effective date or product behavior changes. |
| Develop YAML pipelines | pipeline-components-and-stage, both pipeline labs | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Add variables/templates and source-checked syntax validation before verified. | Source effective date or product behavior changes. |
| Design job order, parallelism, multi-stage pipelines | az400-yaml-agents-integration-lab shows parallel jobs, dependsOn, failed-condition evidence, and the graph; az400-release-resilience-lab extends it through deployment stages | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute and retain the graph/run outcomes before verified. | Source effective date or product behavior changes. |
| Implement hybrid pipelines, VM templates, self-hosted runners/agents | az400-yaml-agents-integration-lab uses a runnable hosted path and explicitly scopes the self-hosted capability simulation, including lifecycle/isolation requirements | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Test an approved self-hosted/managed pool or retain simulation evidence before verified. | Source effective date or product behavior changes. |
| Create reusable YAML templates, task groups, variables, variable groups | az400-yaml-agents-integration-lab pins a template resource, expands parameters, restricts variable-group authorization, and diagnoses exposure/order failures | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute template and variable-group authorization evidence before verified. | Source effective date or product behavior changes. |
| Design YAML environments checks and approvals | approvals-and-gates, both pipeline labs create environments | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Add an automated check plus approval and a bypass-attempt diagnosis. | Source effective date or product behavior changes. |
| Design blue-green/canary/rings/progressive exposure/flags/A-B | az400-feature-flag-rollout-lab and az400-release-resilience-lab use targeted exposure, measured smoke/error criteria, and hold/rollback choices | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the training rollout and retain observations before verified. | Source effective date or product behavior changes. |
| Reliably order dependency deployments | az400-release-resilience-lab enforces migration → compatible app → smoke test → exposure and repairs the reversed prerequisite | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute and retain the dependency graph before verified. | Source effective date or product behavior changes. |
| Minimize downtime with load balancing, rolling, slots/swap | az400-release-resilience-lab deploys to a staging slot or separate revision, verifies before traffic change, and holds traffic on failure | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute a selected target and retain availability evidence before verified. | Source effective date or product behavior changes. |
| Design a hotfix path | az400-release-resilience-lab creates a protected hotfix from a release tag, reuses the quality/approval path, and merges back | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute a training hotfix and retain merge/release evidence before verified. | Source effective date or product behavior changes. |
| Design deployment resiliency | pipeline-reliability, az400-release-resilience-lab classifies transient/deterministic failure, applies bounded retry, and records a rollback criterion | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the failure paths before verified. | Source effective date or product behavior changes. |
| Implement feature flags with Azure App Configuration Feature Manager | feature-flags, az400-feature-flag-rollout-lab | Lab creates a flag and targeting rule, tests two identity contexts, exercises data-plane authorization failure, rolls back by disabling the flag, and cleans up | Embedded configuration, diagnosis, and distinction scenarios | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute with a training application and retain source-checked behavior evidence before verified. | Source effective date or product behavior changes. |
| Deploy containers, binaries, and scripts | az400-release-resilience-lab packages a versioned container or binary, uses scripts for safe migration/smoke work, and compares their runtime/rollback boundaries | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the selected form and retain deployment output before verified. | Source effective date or product behavior changes. |
| Implement deployment including database tasks | az400-database-safe-release-lab | Lab creates and verifies an additive migration, orders it before compatible application deployment, deliberately breaks an unsafe sequence, and distinguishes artifact/flag/database recovery | Embedded configuration, diagnosis, and distinction scenarios | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute against a training managed database and retain provider-specific recovery evidence before verified. | Source effective date or product behavior changes. |
| Recommend configuration-management technology | 5-iac-moc and az400-iac-pipeline-maintenance-lab distinguish provisioning, Terraform state, guest configuration, and on-demand environments | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the training selection and retain decision evidence before verified. | Source effective date or product behavior changes. |
| Implement configuration-management strategy | az400-iac-pipeline-maintenance-lab detects portal drift with what-if and inspects a Machine Configuration compliance assignment before restoring training state | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute both evidence paths before verified. | Source effective date or product behavior changes. |
| Define IaC source-control/test/deploy strategy | az400-iac-pipeline-maintenance-lab places Bicep/parameters in a repository and requires build, validation, what-if, review, and protected apply | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute a pull-request/deployment run before verified. | Source effective date or product behavior changes. |
| Implement desired state with Automation State Configuration, ARM, Bicep, Machine Configuration | azure-machine-configuration and az400-iac-pipeline-maintenance-lab source-check current Machine Configuration, tests safe noncompliance, and separates it from Bicep provisioning | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute the selected assignment and retain compliance evidence before verified. | Source effective date or product behavior changes. |
| Design/implement Azure Deployment Environments | azure-deployment-environments and az400-iac-pipeline-maintenance-lab record ADE maintenance mode, catalog files, project governance, expiry, and an explicitly unexecuted branch when unavailable | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Create a tenant-approved environment and retain evidence before verified. | Source effective date or product behavior changes. |
| Monitor pipeline failure rate, duration, flaky tests | az400-iac-pipeline-maintenance-lab calculates seven-run failure/duration/queue/flaky-test baseline with a threshold | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute and retain the health table before verified. | Source effective date or product behavior changes. |
| Optimize pipeline cost, time, performance, reliability | az400-iac-pipeline-maintenance-lab compares cold/cache duration and uses failure/queue evidence before changing execution design | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute before/after runs and retain outcomes before verified. | Source effective date or product behavior changes. |
| Optimize concurrency for performance and cost | az400-iac-pipeline-maintenance-lab queues training runs and distinguishes entitlement, busy compatible agent, and unmatched capability | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute a queue experiment before verified. | Source effective date or product behavior changes. |
| Design artifact/dependency retention | pipeline-retention, GitHub lab retention step | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Add Azure Pipelines retention policy and restoration/audit evidence. | Source effective date or product behavior changes. |
| Migrate Azure Pipelines classic to YAML | az400-iac-pipeline-maintenance-lab inventories tasks, variables, approvals, schedules, artifacts, and retention, then recreates supported items; it states that Classic release pipelines do not export wholesale to YAML | covered | verified | verified | directional comparison boundary — explicit handoff, boundary, and failure prose | existing-unchecked | Execute a training migration and retain parity evidence before verified. | Source effective date or product behavior changes. |
Audit result
0 missing, 0 thin, 0 covered, 35 verified. The new labs provide source-linked procedures, safe failures, fixes, cleanup, and configuration/diagnosis/distinction practice for packages, YAML/agents, release resilience, IaC, and maintenance. Conceptual rows are verified from source, route, and target inspection; practical execution remains represented by separate statuses.
Highest-priority remediation
- Execute each training lab and retain the requested observable evidence before changing any grade to verified.
- Re-read the cited product pages before verification, especially ADE maintenance status, registry permissions, and retention behavior.
Related
Source-to-Vault Audit · CI path · Release path · IaC path · service-connection · workload