Choose appropriate deployment options

Deployment type is where cost, latency, and residency requirements become concrete. The same model can be served four or five different ways, and the differences are not about capability — they are about whose capacity you are using, where the request is processed, and what happens under pressure.

Why This Matters

A deployment choice is a promise about behaviour under load, and the promise differs sharply between options.

Shared capacity behaves differently from dedicated capacity. On a Standard deployment "occasional transient 429s are expected behavior, not a service defect", and demand from other customers can trigger a temporary rate limit adjustment you did not cause. That is acceptable for most interactive traffic and unacceptable for a trading desk at market open.

Where processing happens is a compliance fact, not a performance one. A residency requirement is satisfied by choosing a deployment type that constrains geography, not by choosing a faster model or a nearer region for the client.

Cost and latency trade against each other explicitly. Asynchronous batch processing is materially cheaper and unusable for anything interactive. Deciding which of your workloads can wait is a design activity, not an afterthought.

Exam scenarios usually name several workloads with different requirements and ask you to assign a deployment type to each — the skill is refusing to pick one type for everything.

Prerequisites

• That a model is deployed and then addressed by its deployment name.
• What TPM and RPM mean as rate limits.
• The distinction between synchronous and asynchronous processing.
• From the previous lesson: the resource type decision, and that an Azure OpenAI resource serves only /openai/v1.

Learning Objectives

By the end of this lesson you will be able to:

1. Name the standard deployment types and read them from the skuName field.
2. Match a workload requirement — throughput guarantee, residency, cost, dedicated hardware — to the right type.
3. Explain what managed compute is for and how its control plane differs.
4. Choose between prompt agents and hosted agents as a deployment decision.
5. Recognise which requirements do not indicate a particular deployment type.

Building Blocks

The standard deployment types. The Model Capacities API returns properties.skuName as the "Deployment type (Standard, GlobalStandard, DataZoneStandard, ProvisionedManaged, etc.)", and quota lines are named {Provider}.{DeploymentType}.{Model} — so the deployment type is part of the quota identity, not a detail of it.

Standard (pay-as-you-go). Shared capacity. "Standard (pay-as-you-go) deployments use a shared resource pool. Throttling protects overall service reliability for all users." Cheap, elastic, and subject to transient 429s by design.

Global and data-zone variants. These change where a request may be processed. Global spreads across regions for capacity; a data-zone type constrains processing to a defined geography, which is what a residency requirement needs.

Provisioned throughput (PTU). Dedicated capacity. For "workloads that require predictable latency and guaranteed throughput, Provisioned Throughput (PTU) provides dedicated capacity with guaranteed rate limits." Rate limits are calculated differently — utilization-based rather than by the TPM estimate.

Global Batch. Asynchronous processing at reduced cost, for work that tolerates a long turnaround.

Managed compute (preview). A distinct family for deploying open-source models onto accelerator capacity you control. It is governed by its own resource-provider operations — managedComputeDeployments/read|write|delete, locations/managedComputeCapacities/read, locations/usages/read — separate from the standard deployment operations. The documented path is "Deploy open-source models with managed compute."

Agent deployment types. Orthogonal to model deployment. Prompt agents are "defined entirely through configuration — instructions, model selection, and tools… no application code to maintain, no compute to pay for." Hosted agents are "code-based agents you build with Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK, or your own code", which Foundry runs "with a managed endpoint, automatic scaling, a dedicated Microsoft Entra identity, session-level state persistence, and end-to-end observability."

Deep Dive

Matching requirement to type

Work through the requirement words rather than the option names.

"Guaranteed", "predictable latency", "no rate-limit errors under surge" → provisioned throughput. This is the only type that promises capacity. No TPM assignment on a shared deployment makes throughput guaranteed; it makes it larger, and a temporary shared-pool adjustment can still reduce your effective limit below what you configured.

"Processed within a defined geography", "data residency" → a data-zone deployment type. Global Standard is the direct contradiction here: routing across regions is exactly what a residency rule forbids.

"Overnight", "millions of documents", "latency does not matter", "lowest cost" → Global Batch. The asynchronous turnaround is the price of the discount, and it disqualifies anything interactive.

"Open-source model", "accelerator capacity we control" → managed compute. Note the operations differ from standard deployments — and a custom role written with a locations/*/read wildcard "matches locations/usages/read but does not match locations/managedComputeCapacities/read", so capacity reads fail on managed compute while working on standard deployments.

Ordinary interactive traffic where the occasional transient throttle is survivable → Standard, which is the correct default rather than a compromise.

What a deployment type does not fix

Several requirements look like deployment questions and are not.

Schema-valid output is structured outputs on the call, not a deployment type. Safety screening is a content filter associated with the deployment — filters are created at the resource level and "can be associated with one or more deployments", so the same policy can cover many. Cost that tracks request complexity is model-router, which selects a model per request; provisioned throughput reserves capacity for one model and would run the simple majority on frontier compute.

The general shape: deployment type answers how the capacity behaves. It does not answer what the model returns, whether the output is safe, or which model should handle this particular request.

Prompt or hosted

This is a deployment decision even though it does not appear on the skuName list, and it turns on what the team brings.

Choose prompt agents when there is no custom orchestration to run. The payoff is that there is genuinely nothing to operate — no containers to patch, no scaling to tune, no compute line on the bill. And they are not portal-only: they can be "define[d] programmatically with the SDKs or REST API to integrate with your CI/CD workflows", which is the code-first path enabling version control, review, and automated rollout.

Choose hosted agents when the team has agent code they intend to keep, or genuinely needs custom orchestration. The platform still supplies the managed endpoint, autoscaling "per session and request volume", the per-agent Entra identity, and session-level state persistence — so hosted does not mean self-managed. What changes is that you own the agent logic and pay container compute on top of inference and tools.

The mistake in both directions is treating uniformity as a virtue: putting every team on hosted agents adds compute cost and runtime code for teams that need neither, while forcing code-owning teams onto prompt agents asks instructions to do the work of custom logic.

Worked Examples

Example 1 — three workloads, one bank. Payments must be processed within a defined geography; a trading assistant needs predictable latency through market open; an overnight job summarizes forty million archived documents.

A data-zone deployment for payments, provisioned throughput for trading, Global Batch for the overnight job. One type for all three fails at least one requirement — Global Standard breaks residency, and Standard cannot promise the trading latency.

Example 2 — an open-source model on your own accelerators. The team wants dedicated accelerator capacity rather than per-token consumption.

Managed compute (preview). Its control plane is separate: managedComputeDeployments/* and managedComputeCapacities/read. When authoring a custom role, list Microsoft.CognitiveServices/locations/managedComputeCapacities/read explicitly, because a locations/*/read wildcard does not match it.

Example 3 — six product teams. Four want an agent with nothing to operate; two have existing Python agent code they intend to keep, each needing to authenticate as itself downstream.

Prompt agents for the four — configuration only, no compute on the bill. Hosted agents for the two — their code, run by Foundry, with an automatic dedicated Entra identity per agent which is exactly the authentication requirement.

Visual Explanations

Choosing a model deployment type:

Two independent deployment decisions:

Common Mistakes

Answering a guarantee with more quota. Larger is not guaranteed on shared capacity.

Using Global Standard under a residency requirement. Routing across regions is what the rule forbids.

Putting an interactive workload on Batch. The discount is paid for in turnaround.

Treating managed compute as a synonym for provisioned throughput. Different families, different operations, different purpose — one is your accelerators for open-source models, the other is reserved capacity for a served model.

Choosing a deployment type to obtain structured output or safety filtering. Those are structured outputs and content filters.

Standardising every team on hosted agents. It adds container compute and runtime code for teams with no custom orchestration.

Assuming prompt agents cannot be managed as code. They can be defined via SDK or REST for CI/CD, with version control and automated rollout.

Practice Exercises

1. A workload must hold predictable latency through a demand surge with no rate-limit errors. Which type, and why is a larger TPM assignment insufficient?
2. Which skuName values would you expect from the Model Capacities API?
3. Which deployment family serves an open-source model on accelerator capacity you control, and what is the custom-role trap?
4. Six teams: four need no custom orchestration, two have existing Python agent code needing per-agent downstream identity. Assign agent types and justify.
5. A team wants cost to follow request complexity on mixed interactive traffic. Is that a deployment-type decision? What is the answer?

Summary & Concept Map

Deployment choice answers how capacity behaves, not what the model produces. Provisioned buys a guarantee; Standard shares a pool where transient 429s are expected; data-zone types constrain geography; Global Batch trades latency for cost; managed compute puts open-source models on accelerators you control, with its own control-plane operations. Alongside that sits an independent decision — prompt agents for teams with nothing to operate, hosted agents for teams bringing code, paying container compute and gaining a per-agent identity and session-level state. And several requirements that look like deployment questions are not: schema validity, safety, and cost-by-complexity each belong elsewhere.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.