Chapter 2 of 6 · Architecture

Microsoft Foundry platform baseline, inventory, and landing-zone guardrails

Governed foundation 5 hours in a non-production POC

Chapter 2 of 6

Architecture at a glance#

The customer repository deploys the Foundry resource, child project, and observability resources into the approved resource group. Operations records the resulting live resources in the customer inventory system.

Azure Policy evaluates resource changes in the same group. A subscription-level initiative groups the allowed-location and required-tag built-ins. Its resource-group assignment moves from DoNotEnforce to Default after review and approval.

A customer Git repository deploys the Foundry baseline, connects Application Insights, and hands live inventory to operations.
Azure Policy moves from built-in resolution to staged assignment, owner approval, enforcement, and operation.

Design choices and tradeoffs#

DecisionChosen approachTradeoff
Foundry resource modelCurrent AIServices resource with one child projectConfirmed classic assets need separate migration work
Network patternSelect public, public-private-inbound, or byo-vnet before account creationBYO VNet needs the approved subnet and route before the baseline deploys
Tracing authenticationStable ApiKey project connection, resolved inside BicepThe connection remains key-based until an approved preview upgrade
Policy rolloutAssign to the exact sandbox group in DoNotEnforce, then promote the same assignmentEvaluation takes time, so stale findings delay enforcement

Architecture guidance#

Session 01

Microsoft Foundry platform baseline, inventory, and landing-zone guardrails slide deck