Deployment types — quota, cost and where inference runs

A deployment type is the arrangement you buy when you put a model into service. It decides three things at once: how much capacity you get, what you pay, and — the part people miss — which part of the world your requests are processed in.

Questions on this topic almost always work backwards. They describe a requirement and expect you to name the deployment. So learn it in that direction.

Reading the requirement, naming the deployment

What the question says it needs	What to answer	Why
The most capacity, nothing unusual	Global Standard	Largest quota and highest throughput, and it gets new models first
Predictable throughput and steady latency	Provisioned	Capacity reserved for you. Note it is not auto-upgraded when a model retires
Large jobs, cheap, no rush	Batch	Around half the price, with turnaround measured in hours rather than seconds
Data must remain in the EU or the US	Data Zone	Restricted to those two areas
Data must remain in the UK	Regional or Standard	See below — this is the trap
Just trying a fine-tuned model out	Developer	Pay per token, with no service level agreement

The United Kingdom is not a data zone

This one catches people, and it matters well beyond the exam.

A data zone is a broad geography. There is a European Union zone and a United States zone. There is no United Kingdom zone. So if a requirement says data must stay in the UK, Data Zone is the wrong answer — it would permit processing anywhere in the EU. The answer is a regional deployment pinned to a UK region.

Worth carrying into real work: UK-only residency is a common requirement in regulated organisations here, and Data Zone looks like it satisfies it right up until someone reads the small print.

At rest is not the same as in flight

This is the distinction the exam leans on hardest, and it is genuinely two different things.

Data at rest — your stored data — always stays in the Azure geography you chose. You chose it when you created the project. The deployment type does not affect it at all.

Inference location — where your request is actually processed as it happens — is exactly what the deployment type controls. Global means it may be processed anywhere. Data Zone narrows that to the US or the EU. Regional keeps it in the single region you picked.

So a question that says "our data never leaves the UK" is asking about two separate controls, and only one of them is the deployment type. Storage residency is set by the project's geography; processing residency is set by the deployment.

The five lifecycle stages

Models move through named stages, and each one carries a different promise:

• Preview — may still change. Not for production.
• Generally available — weights and interface are fixed.
• Legacy — still works, but start planning your move. This stage is optional; not every model passes through it.
• Deprecated — existing customers only. It still answers.
• Retired — it does not. A request returns HTTP 410 Gone.

The naming trap

The words in the interface do not line up with the words in the documentation, and this is a real source of production surprises rather than just an exam curiosity.

In the API, a lifecycleStatus of "Deprecating" means the model is deprecated — it still works. A status of "Deprecated" means the model is retired — it returns 410 Gone and your integration is down.

The lesson generalises. Read the field value, not the word it resembles.