Chapter 1 of 6 · Scope and outcomes

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

Governed foundation 5 hours in a non-production POC

Chapter 1 of 6

Session scope#

What we will do#

Objective. Deploy an owned Microsoft Foundry baseline with workspace-based Application Insights, then stage resource-group guardrails before approved enforcement.

Bicep creates one current AIServices Foundry resource, one child project, a Log Analytics workspace, Application Insights, and the project connection, tagged with the approved ownership, risk, cost, environment, and expiry values. The guardrails assignment starts in DoNotEnforce. The observable result is a live resource group whose tags, resources, and staged assignment match the approved inputs.

Why it matters#

Problem. Without a redeployable baseline, later sessions have no shared Foundry resource to build on, and no record of who owns it. Turning on policy enforcement before checking its effect risks blocking changes the team did not anticipate.

Solution. This session deploys that reusable, tagged baseline and stages the guardrails in DoNotEnforce so the cloud platform owner sees the likely effect before the change authority approves Default enforcement.

Boundaries#

Use one approved sandbox or nonproduction resource group. This session owns the Foundry baseline, its optional BYO VNet foundation, and the policy assignment on that resource group.

Azure holds live resource and policy state. The repository holds the Bicep definitions. Platform operations keeps live inventory in the customer system, and the customer change system holds the promotion decision and any exemptions.

The Application Insights connection uses the stable ApiKey configuration without placing its connection string in parameters or outputs. A future approved change may adopt the preview ProjectManagedIdentity trace-ingestion path.

Private networking and DNS guide adds private endpoints and DNS. Existing resources need separate policy remediation.

Session preparation

Who should join

  • Cloud and AI platform engineers
  • Solution architects
  • Azure landing-zone architects
  • Security, risk, and operations reviewers

What you need

  • The approved sandbox subscription, exact resource group, customer-owned Git repository, and change record are recorded. The cloud platform owner confirms that each names the same approved scope.
  • Select public, public-private-inbound, or byo-vnet before creating the Foundry account. For byo-vnet, approve the subnet, route, firewall next hop, and network owner.
  • Give the deployment operator time-bound Contributor on the exact approved sandbox resource group and time-bound Resource Policy Contributor on the approved subscription. The cloud platform owner approves both assignments through the customer access process and removes them after confirmation.
  • Allow deployment what-if at resource-group and subscription scope. The cloud platform owner reviews inherited policy assignments and exemptions before the change authority approves enforcement through the approved policy change record.
  • Register the required resource providers and identify the approved regions, governance tags, control owners, and promotion authority.

Session 01

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