Validate the Implementation

In the validate phase a second person checks the deployment against checklists. The deployment engineer cannot validate their own work. Record every result, including the failed checks and what was done about them, in the work item or ticket of the implementation. The record is the evidence you present at the hand-over.

How to validate

1. Agree who validates. In a self-managed team, use someone who did not do the deployment.
2. Create one work item for the validation, with the four checklists below as tasks.
3. Work through each checklist. For each item write passed, failed or not applicable, a short note, and a link to the evidence (pipeline run, screenshot or portal location).
4. Fix every failed item, or agree in writing with the customer to accept it, and check it again.
5. Close the work item when all items are passed or accepted.

Minimum and additions

Rows 1 to 3 of the security baseline, the hub and the spoke canvas tables, and rows 1 to 5 of the pipelines and agents table, are the minimum checks of the original runbooks. The remaining rows are additions that follow from the rest of this section. Keep or remove them to fit your quality standard.

Security baseline

#	Check	How
1	Branch protection ensures four-eyes	Open the branch policy or ruleset of the default branch of the configuration repository. A pull request with at least one approval from someone other than the author is required, and force pushes are blocked.
2	Production runs need an approval	Open the prod environment (and the spoke production environment, if any). Approvers are set, self-approval is off, and administrators cannot bypass.
3	Production and canary use different service connections or credentials	Compare the service connections (or the federated credentials) that the entry pipelines use for canary and for prod.
4	The code repository cannot be changed by the customer team or by pipelines	Check the ruleset or policy on the code repository.
5	The platform team has no permanent privileged access	The maintainers group has no active members. Engineers get access through an eligible PIM assignment with approval (Prepare identity).
6	Deployment secrets are stored safely, or federated credentials are used	Check the secret store, the expiry date of every client secret and who may read them.

Cloud platform (hub)

#	Check	How
1	Everything is merged to main	No open implementation branches with unmerged changes. The default branch is main.
2	The platform is deployed with the pipelines, for canary and for prod	Every layer in every region shows a successful run.
3	A new run shows no changes	Run hub again in Plan mode from main. The plan shows no changes, or only the known noise listed in Known issues (for example policy or Application Gateway attributes).
4	The pinned code version is the intended release	The same version in every entry pipeline (Versioning).
5	The design is reflected	The regions, features, address ranges, firewall SKU and gateways match the accepted design or discovery sheet.
6	Alerts and contacts are right	The action group receivers and the Defender security contact are set to the customer's addresses (Day-one checklist).

Pipelines and agents

#	Check	How
1	Everything is merged to main	As above, for the repositories and pipelines that deploy the runners
2	The job runners are deployed	The infrastructure run was successful for canary and for prod
3	A new run shows no changes	Run infrastructure again. It reports no changes.
4	The agent pools are available in the project	Project settings, Agent pools (Azure DevOps), or the runner groups (GitHub), show the pools with online agents
5	A pipeline ran on the agents and succeeded	The hub run itself proves this. Name the run.
6	The smoke tests passed	The result of the pool smoke tests in the infrastructure run
7	The mcp image is in the registry with a version tag	Container Registry, Repositories

Spoke canvas

#	Check	How
1	Everything is merged to main	As above, for the spoke files
2	A test spoke is deployed with the pipeline	The spoke run was successful and the spoke is as described in New spoke
3	A new run shows no changes	Run spoke again for that file. The plan shows no changes, apart from the known spoke noise (Known issues).
4	Access through PIM works	A member of the team group activates a spoke role and sees the subscription

Record of the validation

Use a table like this in the work item:

Area	Checks	Passed	Failed	Accepted exceptions	Validated by	Date
Security baseline
Cloud platform
Pipelines and agents
Spoke canvas

Open points go on the list of the steering report or into the backlog of the platform team.