Task 3.2: Deploy and manage foundation models for production workloads

• AA managed compute deployment in the Foundry project, sized by model instances on A100 GPUs

  Incorrect

  Managed compute in Foundry is currently in public preview.

• BA Global Standard deployment of the model, which runs on capacity the team reserves

  Incorrect

  The model isn't offered as a serverless deployment, and Global Standard isn't reserved capacity.

• CA Developer deployment of the model, kept running to serve the production traffic on its GPUs

  Incorrect

  Developer deployments are for fine-tuned model evaluation, last 24 hours and have no SLA.

• DAn Azure Machine Learning managed online endpoint from the model catalog, on a GPU instance type

  Correct

  Managed online endpoints are GA and host catalog models on dedicated CPU or GPU VMs.

In Foundry, the Serverless API option covers Foundry Models, and managed compute for open-source, partner and custom models on dedicated GPUs is currently in public preview. Azure Machine Learning managed online endpoints are generally available and deploy models from the model catalog, including Hugging Face models, to CPU or GPU VMs with serving, scaling, security and monitoring handled for you.

• AQuota must be purchased before use; buy a reservation for 300 PTUs and then retry the deployment

  Incorrect

  Quota has no cost and isn't bought; the deployment failed for lack of capacity, not for lack of a purchase.

• BRegional capacity for that model is short; deploy where the portal shows capacity, or retry later

  Correct

  Quota is a limit, and capacity is allocated only when a deployment is created.

• CProvisioned deployments upgrade from Standard; deploy the model as Global Standard first, then convert it

  Incorrect

  Provisioned deployments are created directly, not converted from Standard.

• DThe deployment exceeds the per-request limit; split it into three deployments of 100 PTUs each

  Incorrect

  There's no per-request limit involved; capacity is the issue.

PTU quota is the maximum number of PTUs you can deploy; it's a policy limit with no cost and doesn't guarantee capacity. Capacity is allocated at deployment time, so a deployment fails if the region lacks capacity; the portal suggests alternative regions with capacity, and availability changes through the day.

• ASend x-ms-spillover-deployment with an empty value on basic requests to switch spillover off for them

  Incorrect

  The deployment property still applies to every request while it's set.

• BPoint spilloverDeploymentName at a second Standard deployment that basic requests aren't allowed to use

  Incorrect

  Spillover would still apply to all requests, just to another deployment.

• CRemove spilloverDeploymentName from the deployment and keep sending the header on premium requests only

  Correct

  When both are set, the deployment property wins, so per-request control needs the property unset.

• DLower the Provisioned deployment's PTUs so that it rarely fills up under basic-tier load

  Incorrect

  That increases spillover and doesn't separate the tiers.

Spillover can be enabled for all requests through the spilloverDeploymentName property or per request through the x-ms-spillover-deployment header. If both are set, the system defaults to the deployment property. To make spillover strictly per request, don't set spilloverDeploymentName on the provisioned deployment.

• AThe deployment stays on its old version until the new one becomes available in the region

  Incorrect

  Azure rolls the version out to the region for the upgrade.

• BThe deployment is moved to the nearest region that has the new version

  Incorrect

  Deployments don't change region.

• CAzure deploys the new version to Japan East and upgrades the deployment on schedule

  Correct

  Upgrades proceed in the scheduled window even where the version wasn't yet available.

• DThe deployment stops until the team reselects a version

  Incorrect

  The scheduled upgrade moves the deployment to the new version; it doesn't stop it.

Even if the latest model version isn't yet available in a region, Azure automatically upgrades deployments during the scheduled upgrade window; the engineering team deploys the new version to that region starting on the announced date.

• A240,000 TPM, with a 1,440 RPM limit, since each resource has its own quota

  Incorrect

  Quota is per subscription and region, not per resource.

• B60,000 TPM, with a 60 RPM limit set separately from TPM

  Incorrect

  RPM is derived from TPM at the model's ratio.

• C150,000 TPM, with a 900 RPM limit, as quota resets for a third resource

  Incorrect

  Only 60,000 TPM of the regional quota is left.

• D60,000 TPM, with a 360 RPM limit derived from the model's ratio

  Correct

  Quota is shared across deployments in the region, and RPM follows the TPM ratio.

Azure OpenAI quota is assigned per subscription, region, model and deployment type in tokens per minute, and any number of deployments in one or more resources can share it as long as the total stays within the quota. Assigning TPM to a deployment also sets its RPM limit by the model's ratio, for example 6 RPM per 1,000 TPM, so 60,000 TPM gives 360 RPM.

• AOnce deprecated, existing customers can still create and manage deployments, while new customers can't access it

  Correct

  Deprecation at about 12 months closes the model to new customers.

• BAfter retirement, inference calls to the model version return 410 Gone

  Correct

  At about 18 months the version retires and inference fails.

• CAfter retirement, existing deployments keep serving until the team deletes them

  Incorrect

  Retired versions stop serving inference.

• DA deprecated model can't be deployed again by anyone, existing customers included

  Incorrect

  Existing customers can still create deployments.

• ERetirement dates aren't published until the replacement model is chosen

  Incorrect

  The retirement date is set at launch and available via the Models API.

Under the lifecycle policy, a GA model's retirement date (18 months out) is set at launch and exposed through the Models API. At about 12 months the model is deprecated: existing customers can continue to create and manage deployments, new customers can't access it. At retirement, all inference returns 410 Gone.

• Ax-ms-spillover-deployment

  Incorrect

  That's the request header that enables spillover per call.

• Bretry-after-ms

  Incorrect

  That header accompanies 429 throttling.

• Cx-ms-client-request-id

  Incorrect

  That's a client tracing header.

• Dx-ms-spillover-from-deployment

  Correct

  Its presence marks a spillover request and names the PTU deployment.

Spillover responses include x-ms-spillover-from-deployment with the PTU deployment name, x-ms-deployment-name with the deployment that served the request, and x-ms-spillover-error with the provisioned deployment's response code that triggered the spillover.

• AYes, for security or compliance issues, with shortened notice

  Correct

  Microsoft reserves the right for security-driven retirements.

• BNo, a published retirement date is always final and can't move

  Incorrect

  Security issues can shorten notice.

• COnly if the customer requests it

  Incorrect

  Emergency retirements are Microsoft's decision.

• DOnly for preview models

  Incorrect

  The policy covers security issues generally.

If a model is found to have compliance or security issues, Microsoft reserves the right to invoke an emergency retirement with shortened notice, as described in the Azure terms of service.

• AEvery model in the catalog, including all models from partners and community

  Incorrect

  Except for Anthropic models, models from partners and community don't support quota increases.

• BOnly Azure OpenAI models; other Foundry Models never get more quota

  Incorrect

  Foundry Models sold by Azure and Anthropic models are covered too.

• CFoundry Models sold by Azure, Azure OpenAI models and Anthropic models

  Correct

  The form covers these three; other partner and community models don't support increases.

• DOnly models that run on a provisioned deployment type

  Incorrect

  The form isn't limited to provisioned deployments; it covers the models listed above.

Submit the quota increase request form for Foundry Models sold by Azure, Azure OpenAI models and Anthropic models. Except for Anthropic models, models from partners and community don't support quota increases. Requests are processed in the order they're received, with priority for customers who actively use their existing quota.

• AOnly the model that was named when the quota was granted

  Incorrect

  Quota isn't tied to one model.

• BAny supported model; PTU quota isn't tied to one model

  Correct

  PTUs aren't bought for a specific model.

• COnly models from one provider

  Incorrect

  Quota isn't tied to a provider.

• DAny model in any region

  Incorrect

  Quota is per region and deployment type.

PTUs are generic units of model processing capacity. The same PTU quota can be used to deploy any supported model, but quota is granted per subscription, region and deployment type.