Implementation | Session 14: Foundry estate and lifecycle operations

Chapter 5 of 6

Implement#

1. Complete the estate scope record#

Resolve every __REQUIRED_*__ value in the approved private configuration path. Set the approved workbook deployment scope, then run preflight:

PowerShell

$targetScope = "<approved estate scope alias>"
$workbookSubscriptionId = $env:AZURE_SUBSCRIPTION_ID
$workbookResourceGroup = "approved-estate-workbook-resource-group"
.\scripts\preflight.ps1 `
  -TargetScope $targetScope `
  -WorkbookSubscriptionId $workbookSubscriptionId `
  -WorkbookResourceGroup $workbookResourceGroup

Bash

target_scope="<approved estate scope alias>"
workbook_subscription_id="${AZURE_SUBSCRIPTION_ID}"
workbook_resource_group="approved-estate-workbook-resource-group"
./scripts/preflight.sh \
  --target-scope "$target_scope" \
  --workbook-subscription-id "$workbook_subscription_id" \
  --workbook-resource-group "$workbook_resource_group"

Preflight confirms read access to each management group with a counting query and previews the shared workbook. A management group that fails here is a missing role assignment, not a missing estate.

2. Deploy the estate issues and model retirement workbook#

After the workbook operator approves the preview:

PowerShell

.\scripts\deploy-workbook.ps1 `
  -TargetScope $targetScope `
  -SubscriptionId $workbookSubscriptionId `
  -ResourceGroup $workbookResourceGroup

Bash

./scripts/deploy-workbook.sh \
  --target-scope "$target_scope" \
  --subscription-id "$workbook_subscription_id" \
  --resource-group "$workbook_resource_group"

The portal route deploys the same tagged workbook without running preflight. Use it only after the scope and access checks above pass:

![Deploy to Azure](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fmicrosoft%2Ffrontier-ai-governance-rvas%2Fmain%2Fsessions%2F14-foundry-estate-inventory%2Fimplementation%2Fartifacts%2Finfra%2Fdeploy-workbook.json)

Open Azure AI estate issues and model retirement in Azure Workbooks. Select only subscriptions within the approved management groups. The dashboard is for live triage. It does not add a subscription to the governed estate.

3. Run the estate report#

PowerShell

.\scripts\build-estate-report.ps1

Bash

./scripts/build-estate-report.sh

The console summary shows the account counts, model deployment count, Service Health signals, Azure Advisor recommendations, and every finding. The JSON report includes the lifecycle fields and account owner tag for each deployment. To keep the full record for a review, pass a path outside this repository:

PowerShell

.\scripts\build-estate-report.ps1 -OutputPath "<path outside this repository>\estate-report.json"

Bash

./scripts/build-estate-report.sh --output-path "<path outside this repository>/estate-report.json"

4. Give every finding an owner#

Work through account findings with the platform team. Each one ends in one of four places: the account gets its tags, it moves to an approved region, it joins the approved platform path, or it becomes a recorded exception with an owner and expiry.

Triage the adjacent list separately. An unexpected account kind is often a team using an Azure AI service outside the governed path.

The lifecycle owner handles deployment and service-retirement findings. Assess the suggested or available replacement against the workload, use the model governance process to approve and deploy it, then remove the old deployment only after its consumers have moved. Service Health and Advisor findings close through their linked service-owner change path.

5. Connect the cost view#

Open Microsoft Cost Management for the same subscriptions and filter by the cost tag key, using the tag values the report printed. The amounts come from Cost Management; the inventory comes from this report. Together they answer which AI accounts exist and what each one costs.