Source-to-Vault Audit
Purpose
This ledger tests whether the vault can teach an objective independently. It is not a count of notes, links, modules, or questions.
Do not interpret in-progress as exam-ready or self-contained. A row is only verified when source, concept, route, procedure, lab evidence, and the three practice modes have been inspected.
Authoritative baseline
| Course | Source | Current source version | Re-audit trigger |
|---|---|---|---|
| AZ-900 | Microsoft study guide | Skills measured as of 2026-07-20; page updated 2026-06-22 | Source effective date or change log changes. |
| AZ-104 | Microsoft study guide | Skills measured as of 2026-04-17; page updated 2026-03-19 | Source effective date or change log changes. |
| AZ-204 | Microsoft study guide | Final skills measured as of 2026-01-14; exam retired 2026-07-31; courseware retired 2026-05-29 | Retirement record, source change, or product behavior changes. |
| AZ-400 | Microsoft study guide | Skills measured as of 2026-07-27; page updated 2026-06-26 | Source effective date or change log changes. |
Source sweep — 2026-08-22
The current official study guides were re-read against the detailed ledgers. The AZ-900 inventory contains 57 atomic study-guide rows; the legacy ledgers contain 82 AZ-104 bullets and 86 AZ-400 bullets; and the initial AZ-204 inventory adds 37 atomic study-guide rows. The AZ-900 and AZ-204 rows are intentionally missing until actual targets are built and inspected.
This confirms coverage of the terms and operations named by the two study guides. It does not claim coverage of every Azure, Entra, GitHub, or Azure DevOps term that might appear in product documentation, because Microsoft states that related topics can also be assessed. Product-documentation changes remain re-audit triggers.
Audit rule
Use the project’s source-to-vault-audit skill and its evidence schema. In particular, “a glossary page exists” and “a question exists” are not proof that the learner can configure or diagnose the source objective.
Structural check on 2026-08-22: bash scripts/verify-learning-content.sh passed with 77 module hands-on sections, 50 standalone labs that each expose practical stages, three-mode scenario practice, source links, and a re-audit trigger, and 5,079 unambiguous active Obsidian wikilinks. This prevents a broken graph edge or an incomplete lab structure; it does not upgrade an objective’s pedagogical grade.
bash scripts/verify-source-audit-status.sh also checks that the detailed ledgers and this dashboard report the same grade totals. It checks accounting, not source accuracy or lab execution.
Phase 1 finding
The earlier coverage matrix was a structural mapping, not a source-to-vault verification. It treated linked concepts and a generic module lab as sufficient evidence. This audit replaces that interpretation.
The vault’s conceptual audit is complete for the current source baseline, but it is not a claim of live operational or exam readiness. The detailed ledgers currently contain 0 missing, 0 thin, 0 covered, and 270 verified conceptual rows. Practical status remains separate and visible in each ledger.
The separate course syllabus and prerequisite ledger adds eight covered teaching-baseline rows across the four courses; final verification still requires the cold-reader pass.
The two high-risk tables below preserve the initial Phase 1 snapshot. Their thin labels are historical; use the detailed ledgers for current row grades and the remediation queue for current work.
AZ-104 high-risk objective audit
Detailed, bullet-level ledger: AZ-104 Identity and Governance.
Detailed, bullet-level ledger: AZ-104 Storage.
Detailed, bullet-level ledger: AZ-104 Compute.
Detailed, bullet-level ledger: AZ-104 Networking.
Detailed, bullet-level ledger: AZ-104 Monitor and Recovery.
Detailed, bullet-level ledger: AZ-400 Build and Release Pipelines.
Detailed, bullet-level ledger: AZ-400 Security and Instrumentation.
Detailed, bullet-level ledger: AZ-400 Processes and Communications.
Detailed, bullet-level ledger: AZ-400 Source Control.
Detailed, bullet-level ledger: Retired AZ-204 application-development foundation.
| Source objective (paraphrased) | Inspected vault evidence | Grade | Exact gap / next evidence |
|---|---|---|---|
| Manage Entra users, groups, licenses, external users, and SSPR | user-account, groups, license-management, identity modules/questions | thin | Individually verify create/edit/query/guest-removal procedures in portal and CLI/Graph where relevant; split one generic identity lab into observable tasks. |
| Manage built-in Azure roles, scope assignments, and interpret access | rbac, scope, role-assignment, identity scenarios | covered | Add a deterministic effective-access troubleshooting procedure using the portal and CLI; verify deny-assignment treatment from current docs. |
| Policy, locks, tags, subscriptions, budgets, Advisor, management groups | Governance modules and scenarios | thin | Verify each portal operation and inheritance/failure behavior; separate budget alert and Advisor recommendation labs. |
| Storage firewalls/VNets, SAS, stored access policies, keys, Azure Files identity access | Storage notes/questions | thin | The concepts exist, but the audit has not confirmed a complete end-to-end Azure Files identity configuration and failure diagnosis. |
| Storage account, redundancy, object replication, encryption, Storage Explorer, AzCopy | Storage modules and concepts | thin | Reproduce source prerequisites and cleanup for each operation; pricing/limit claims require product-doc citations. |
| File shares and Blob: tiers, soft delete, snapshots, lifecycle, versioning | Storage notes/questions | thin | Create a distinct recovery lab with expected versions/snapshots, deletion, restore, and cleanup evidence. |
| ARM/Bicep interpretation, modification, deployment, export/conversion | arm, bicep, az104-arm-bicep-change-lab | covered | Execute the source-linked export/decompile, validation, what-if, deployment, failure, and cleanup steps before verified. |
| VM create/configure, encryption-at-host, moves, sizing/disks, zones/sets/VMSS | VM notes/questions | thin | Add a source-checked procedure per move type and an observable disk/VMSS scale exercise. |
| ACR, ACI, Container Apps, sizing and scaling | acr, aci, azure-app-container-apps, az104-container-sizing-scaling-lab | thin | The ACI/Container Apps sizing and scaling operation is now covered; add ACR and Container Apps provisioning evidence before this aggregate row can advance. |
| App Service plan/scaling/app/certs/custom DNS/backup/networking/slots | App Service notes/questions, az104-app-service-backup-restore-lab | thin | Backup/restore is now covered; one end-to-end lab still needs TLS, custom domain, private networking, and slot evidence. |
| VNet/subnet/peering/public IP/UDR/connectivity troubleshooting | Networking concepts and scenarios | thin | Inspect actual routes/effective paths; add a public-IP and UDR procedure with a controlled broken route. |
| NSG/ASG/effective rules, Bastion, service endpoints, private endpoints | nsg, asg, azure-bastion, service-endpoint, private-endpoint | covered | Verify the distinct service-endpoint/private-endpoint lab and DNS failure evidence. |
| DNS, public/internal load balancers, load-balancing troubleshooting | DNS/load-balancing concepts and scenarios | thin | Add a health-probe failure procedure and internal-vs-public load balancer selection exercise. |
| Monitor metrics/log settings/KQL/alerts/Insights/Network Watcher | Monitor notes and scenarios | thin | Confirm ingestion settings, query outputs, and alert-processing behavior in an executable lab. |
| Vaults, policies, backup/restore, Site Recovery failover, reports/alerts | Backup concepts and lab | thin | Separately verify Recovery Services vs Backup vault support, restore evidence, test failover, and cleanup. |
AZ-400 high-risk objective audit
| Source objective (paraphrased) | Inspected vault evidence | Grade | Exact gap / next evidence |
|---|---|---|---|
| GitHub Flow, feedback, Issues/Projects/Boards, traceability | Process path and scenarios | thin | Prove an issue → PR → commit → build → deployment → incident feedback chain in both GitHub and Azure DevOps. |
| Dashboards, metrics, and queries for planning through operations | devops-flow-metrics, instrumentation content | thin | Add real query/dashboard artifacts and expected interpretation, not only definitions. |
| Markdown/Mermaid, release/API documentation, Git-history automation, webhooks, Teams integration | Documentation/communication modules | thin | Verify real GitHub/Azure DevOps/Teams integration configuration; do not treat a Markdown note as integration evidence. |
| Branch strategies, PR workflow/protection/restrictions | Git notes/questions | thin | Add a branch-policy lab for GitHub and Azure Repos and a broken-policy diagnosis. |
| Large files, repo scaling, permissions/tags, Git recovery/removal | git-repository-scaling, Git scenarios | thin | Add safe sandbox Git exercises for LFS, recovery, and removal; source-check destructive history operations. |
| Packages, feeds/views, dependency/artifact versioning | Package notes and pipeline scenarios | thin | Prove publish/consume/retention flow in both a GitHub and Azure Artifacts context. |
| Pipeline tests, test agents/results, coverage, quality/release gates | CI content and lab | thin | Inspect an actual YAML implementation and gate outcomes; demonstrate a failed test and blocked release. |
| Runners/agents, triggers, YAML, execution order, templates, variables/groups, environments/approvals | Pipeline path and 82 scenarios | thin | This is well represented conceptually, but the audit still needs source-to-YAML evidence for every official sub-bullet. |
| Strategies, feature flags, ordered dependencies, downtime, hotfix, resilience, containers/binaries/scripts/database tasks | Release content | thin | Add a coherent deployment lab that includes a database-safe change and measured rollback decision. |
| IaC, desired state, Azure Machine Configuration, Deployment Environments | IaC modules/notes | thin | Verify current product state and one working desired-state/on-demand-environment procedure. |
| Pipeline health/cost/concurrency/retention/classic-to-YAML migration | Maintenance notes/questions | thin | Add measurable health dashboard, retention test, and classic-migration artifact. |
| Service principals/managed identities, GitHub/Azure DevOps auth, service connections, security groups, access levels/projects/teams | Existing identity notes; new service-account, service-connection, security-group | thin | The canonical second-brain nodes were missing before this audit. Add both-platform configuration and permission-boundary exercises. |
| Key Vault, secretless auth, secure files, leak prevention | Security notes/lab | thin | Separate Azure DevOps secure-files handling from Key Vault and OIDC exercises; test a deliberate authorization failure. |
| Defender/GHAS/CodeQL/container/dependency scanning | Security notes/questions | thin | Verify current product availability and configure an actual scan, finding, gate, remediation, and exception lifecycle. |
| Azure Monitor/Logs, Insights, GitHub insights/charts, pipeline alerts, telemetry/KQL/distributed tracing | Instrumentation notes/lab | thin | Add actual query, trace, chart, and alert outputs for both platform and Azure telemetry paths. |
Vocabulary and graph findings
| Finding | Impact | Remediation state |
|---|---|---|
Service connection was only canonically named subscription-connection; other pages referenced service-connection. | A learner cannot tell pipeline authorization from Azure networking. | Added service-connection with a direct contrast to service-endpoint and private-endpoint. |
| “Service account” had no canonical node. | Human, service-principal, managed-identity, and OIDC roles could blur. | Added service-account. |
| “Workload” was used as prose but not a graph node. | The vault remains product-first rather than system-first. | Added workload as a cross-domain integration node. |
| “Security group” has three incompatible meanings. | Learners can apply identity, DevOps, or networking controls in the wrong plane. | Added security-group disambiguation. |
| Azure DevOps security groups, access levels, secure files, and GitHub Project insights were only mentioned in surrounding prose. | Crucial AZ-400 platform boundaries lacked canonical definitions and comparison links. | Added azure-devops-security-groups, azure-devops-access-levels, azure-pipelines-secure-files, and github-project-insights. Their operational rows remain thin until labs exist. |
Prioritized remediation queue
- Execute each source-linked training procedure and retain its requested success, failure, repair, and cleanup evidence.
- Re-read the cited product source and inspect rendered links before changing an individual
coveredrow toverified. - Build an evidence record for configuration, diagnosis, and distinction practice per objective; questions and notes alone do not verify it.
- Re-audit immediately when a study guide, product behavior, permission model, or service state changes.
Related
Structural coverage matrix · Readiness standard · workload · service-connection · security-group