Task 3.1: Implement Foundry environments and platform configuration

• AA Foundry resource per production agent, plus one shared resource with projects for the sandbox

  Correct

  Production defaults to isolation per workload, while colocation suits exploration with shared deployments.

• BOne Foundry resource with three projects: fraud triage, customer chat and the sandbox, all sharing its deployments

  Incorrect

  Projects in one resource share its blast radius, quota and deployments, which production here can't accept.

• COne Foundry resource per data scientist for the sandbox, and one shared resource holding both production projects

  Incorrect

  That isolates the sandbox, which wants sharing, and colocates production, which needs isolation.

• DOne hub-based project per agent in a shared hub, with the sandbox as a third project in the same hub

  Incorrect

  Hub-based projects aren't supported in the new Foundry portal, and they'd still share the hub's resources.

Foundry's rollout guidance contrasts colocated workloads (one Foundry resource with multiple projects, good for experimentation and shared deployments but with a shared blast radius for incidents, quota exhaustion and misconfiguration) with fully isolated workloads (one Foundry resource per production workload boundary, for independent access control, quota and cost). For production, treat isolation as the default.

• ASet public network access to Enabled for the upgrade, then disable it again once the kind has changed

  Incorrect

  Opening public access doesn't remove the private endpoint block on the portal upgrade.

• BCreate a new Foundry resource and move every app to its endpoint and keys

  Incorrect

  The upgrade keeps the existing endpoint and keys; a new resource forces every app to change.

• CKeep the private endpoints and add only the Foundry DNS zones next to the existing Azure OpenAI zone

  Incorrect

  DNS zones are needed, but the portal upgrade still fails while private endpoints exist.

• DDelete the private endpoints, upgrade, then re-create them so the Foundry IP configurations exist

  Correct

  Resources with private endpoints can't be upgraded in the portals, and re-created endpoints add the Foundry IP configurations.

Upgrading an Azure OpenAI resource to Foundry keeps its API endpoint, keys and configuration. Resources with existing private endpoints can't be upgraded through the Foundry portal or Azure portal: delete the private endpoints first and re-create them afterward (re-creation adds the services.ai.azure.com and custom-domain IP configurations), or manage the upgrade with Bicep or Terraform. Private networks also need the extra DNS zone configuration.

• AOwner role assignments on the resource group for the developer group and the project identity

  Incorrect

  Owner is far broader than building in a project needs.

• BCognitive Services Contributor for the developers and Cognitive Services User for the project identity

  Incorrect

  Cognitive Services roles target AI Services resources directly, not Foundry projects.

• CFoundry User role assignments for the developer group and for the project's managed identity

  Correct

  Automatic assignment happens only through the portal UI, not for SDK, CLI or template deployments.

• DAzure AI Developer for the developers and Reader on the Foundry resource for the project's managed identity

  Incorrect

  Azure AI Developer is scoped to Azure Machine Learning workspaces and hubs, not Foundry projects.

When a user who can assign roles creates a Foundry resource or project in the portal, Foundry User is assigned automatically; this doesn't happen when you deploy with the SDK, CLI or templates. Grant Foundry User to the developers (least privilege for building) and to the project's managed identity on the Foundry resource. Cognitive Services roles (other than Usages Reader) and Azure AI Developer don't apply to Foundry projects.

• AAdd an Azure OpenAI connection to the central resource, since connections work across subscriptions in one tenant

  Incorrect

  Connections used for model deployments can't point at a resource in a different subscription, even in the same tenant.

• BAdd the connection with the central resource's API key, so that the subscription boundary no longer applies

  Incorrect

  The limit is about the subscription, not about the authentication method.

• CDeploy the models in a resource in the project's own subscription, since such connections can't cross subscriptions

  Correct

  Cross-subscription connections for model deployment aren't supported, so the deployments have to sit in the same subscription.

• DPeer the two subscriptions' virtual networks so that the project connection can reach the central deployments

  Incorrect

  Network peering doesn't change the rule: the connection itself isn't supported across subscriptions.

Connections let a Foundry project authenticate to other resources, but cross-subscription connections used for model deployment (Foundry and Azure OpenAI connections) aren't supported: you can't connect to resources from a different subscription for model deployments. Keep the deployments that a project uses in a resource in the same subscription.

• AThe tag AZML_DISABLE_PREVIEW_FEATURE set to true on the subscription, resource group or Foundry resource

  Correct

  The tag hides preview surfaces in the new and classic portals.

• BA resource lock of type ReadOnly on each production Foundry resource

  Incorrect

  A lock blocks management changes, not preview features.

• CA custom role that lists the preview operations under notDataActions, assigned in place of broader roles

  Correct

  Custom roles block specific preview operations at the API level.

• DRemoving every user's Foundry User role and assigning Reader instead

  Incorrect

  That blocks building entirely, not only preview features.

• EThe tag alone, since hidden preview features can't be called from the SDK

  Incorrect

  Tags only hide portal surfaces; API calls need a custom role to block them.

Microsoft documents two ways to restrict preview features in Foundry: the AZML_DISABLE_PREVIEW_FEATURE tag with value true hides preview surfaces in the portals at the scope where you apply it, and custom RBAC roles that exclude permissions with notDataActions (or notActions for control-plane features such as tracing) block the operations at the API level.

• AA custom role that removes the Deploy action from the model catalog for every user

  Incorrect

  It blocks all deployments, not only Preview models.

• BThe built-in eligibility requirements policy, set to exclude models whose lifecycle is Preview

  Correct

  It restricts deployments by attributes such as lifecycle status, evaluated at deployment time.

• CA tag on each Foundry resource that hides models in the Preview lifecycle from the catalog

  Incorrect

  Tags hide portal surfaces; they don't enforce deployment rules.

• DThe built-in policy Foundry model deployments should only use approved models, listing every GA model

  Incorrect

  That's a per-model allow-list, which the team doesn't want to maintain.

Foundry provides two generally available built-in Azure Policy definitions for model deployments: one restricts deployments to an approved list of models or publishers, the other restricts them by model attributes such as source (Direct from Azure) and lifecycle status (Preview). Both are evaluated at deployment time; the catalog still shows models, and the Deploy action is disabled with a reason. Assigning them needs Owner or Resource Policy Contributor.

• ARoll back to Azure OpenAI after deleting the configurations the article lists

  Correct

  The upgrade is opt-in and can be rolled back.

• BNothing, since an upgrade to Foundry can't be undone once it completes

  Incorrect

  A rollback option exists.

• CDelete the resource and restore the Azure OpenAI setup from backup

  Incorrect

  Rollback doesn't need a restore.

• DOpen a support case, since support is the only way to revert an upgrade

  Incorrect

  The portal and ARM templates offer rollback.

Upgrading Azure OpenAI to Foundry is opt-in, and you can roll back if you run into problems: delete the configurations listed in the article, then use the classic portal, the Azure portal or an ARM template to roll back.

• ACopy the settings from the Foundry portal's Home page into a new file

  Incorrect

  The Home page doesn't produce templates.

• BRun az cognitiveservices account show and rename the output .bicep

  Incorrect

  JSON output isn't a Bicep template.

• CExport the resource's configuration as a Bicep file from the portal

  Correct

  The export captures network rules, identity and project settings.

• DAsk Microsoft support to generate the template from the resource

  Incorrect

  The portal can export it.

If you already configured a Foundry resource in the Azure portal, you can export that configuration as a Bicep file. The exported file captures current settings, including network rules, identity configuration and project associations, as a starting point.

• AFoundry Owner

  Incorrect

  It manages projects and resources but isn't the documented requirement.

• BContributor

  Incorrect

  Contributor can't create custom roles.

• CFoundry Project Manager

  Incorrect

  It isn't the role the guidance names for creating custom roles.

• DOwner

  Correct

  Creating custom roles in a resource needs Owner on that scope.

You need the Owner role on a resource's scope to create custom roles in that resource. Custom roles are useful, for example, to tailor permissions beyond the built-in Foundry roles.

• ARole assignments apply only after the resource restarts

  Incorrect

  Resources don't need restarting.

• BRole assignments can take up to five minutes to propagate

  Correct

  Wait briefly, or manage access with security groups.

• CRole assignments apply at the next hour boundary

  Incorrect

  Propagation takes up to minutes.

• DRole assignments apply only after the developer's next password change

  Incorrect

  Passwords don't affect role propagation.

Azure role assignments can take up to five minutes to propagate. When you use security groups, adding or removing users from the group propagates immediately.