AI-103 · Practice set 11 of 13
Choosing a Deployment Type: 10 practice questions
10 free AI-103 practice questions on Choosing a Deployment Type, with an explanation for every answer. Untimed. The full mock exam and the timed version are in the app.
-
Question 1 of 10
A team with no data residency or throughput constraints deploys a newly released model. Which deployment type is the recommended starting point?
- ARegional Provisioned
- BDeveloper deployment
- CGlobal Standard
- DData Zone Standard
Show the answer
Global Standard is the default because it launches first for new models, has the lowest price, and has the broadest region coverage. You move away from it only for a reason: data residency, reserved throughput, or batch work. With no such constraint, there is nothing to trade for.
Next → 1 / 10 -
Question 2 of 10
Which deployment type is meant only for evaluating a fine-tuned model, has no SLA, and is deleted automatically after 24 hours?
- AGlobal Standard
- BData Zone Batch
- CGlobal Batch
- DDeveloper
Show the answer
Developer (DeveloperTier) is the evaluation type for fine-tuned models: cheap, temporary, with a fixed 24-hour lifetime, no SLA, and no data residency guarantee. Its 24 hours is a lifetime, which is easy to confuse with the 24-hour target turnaround of batch.
Next → 2 / 10 -
Question 3 of 10
Compared with Global Standard, what does Global Batch offer for large asynchronous jobs?
- AProcessing that stays inside one Azure region
- BLower latency variance through reserved PTUs
- CA guaranteed 24-hour completion under an SLA
- D50% lower cost and a 24-hour target turnaround
Show the answer
Batch trades speed for price: it costs 50% less than Global Standard, aims to finish within 24 hours, and draws on a separate enqueued token quota. The 24 hours is a target, and batch has no real-time SLA.
Next → 3 / 10 -
Question 4 of 10
A European company must keep inference processing inside the EU data zone. Its traffic is bursty and it wants pay-per-token billing. Which deployment type fits?
- AGlobal Standard
- BData Zone Provisioned
- CGlobal Provisioned
- DData Zone Standard
Show the answer
Two requirements decide it: processing inside the data zone and pay-per-token billing. Data Zone types keep processing in the US, EU, or Asia Pacific zone, and the Standard flavor bills per token, which suits bursty traffic. Provisioned flavors reserve capacity instead.
Next → 4 / 10 -
Question 5 of 10
A subscription has enough Data Zone Provisioned PTU quota in a region, yet creating a provisioned deployment there fails. What is the most likely cause?
- AThe model needs its own model-specific PTU quota
- BThe PTU quota first requires an Azure Reservation
- CProvisioned types are billed per token, not per PTU
- DThe region lacks available capacity
Show the answer
Quota and capacity are different. Quota is a free policy limit on how many PTUs you may deploy; capacity is what is actually available in the region right now. If capacity is short for the requested PTU count, the deployment fails even with quota in hand.
Next → 5 / 10 -
Keep the ones you got wrong
In the app, every question you miss comes back exactly when you’re about to forget it.
-
Question 6 of 10
A team wants the discounted reservation rate for a new provisioned deployment. In which order should it act?
- ABuy the reservation, then request PTU capacity
- BBuy the reservation to secure capacity, then deploy
- CRequest more PTU quota, then buy the reservation
- DCreate the deployment, then buy the reservation
Show the answer
Reservations are a discount on the PTU billing meter and are loosely coupled to deployments. Because a reservation doesn't guarantee capacity, you first create the deployment to confirm that capacity exists, then buy the reservation to lock in the rate.
Next → 6 / 10 -
Question 7 of 10
A team deploys an open-source Qwen model with managed compute. They plan to use the GPU quota they already hold for Azure virtual machines. What should they expect?
- ATheir Azure VM GPU quota covers the deployment
- BReserved PTU quota shared with provisioned types
- CA separate Foundry quota per accelerator SKU
- DPay-per-token billing like Global Standard
Show the answer
Managed compute is a PaaS with its own rules: quota is granted per accelerator SKU per region through the Foundry quota process, and billing is hourly per accelerator SKU. Existing Azure VM quota can't be applied, because VMs are an IaaS offering with regional SKUs.
Next → 7 / 10 -
Question 8 of 10
A customer chat service has steady, predictable high volume and needs consistent low latency. Processing must stay within the EU data zone, and the team wants higher availability than a single-region deployment gives. Which deployment type fits best?
- AData Zone Standard
- BData Zone Provisioned
- CRegional Provisioned
- DGlobal Provisioned
Show the answer
Three constraints combine. Steady volume with consistent latency points to provisioned capacity; the EU requirement rules out global routing; and Data Zone Provisioned routes across the zone, giving higher availability than a regional deployment while keeping residency at the zone level.
Next → 8 / 10 -
Question 9 of 10
Each night, 50,000 prompts must be processed: half by one model deployment and half by another. The team accepts a 24-hour target rather than real-time results, cost matters, and the online chat quota must not be affected. What setup fits?
- AGlobal Standard calls spread evenly over the night
- BTwo Global Batch jobs, one input file per deployment
- CA Developer deployment for each of the two models
- DOne Global Batch job whose file lists both deployments
Show the answer
Batch fits overnight, cost-sensitive work: 50% cheaper than Global Standard, a 24-hour target, and a separate enqueued token quota that leaves online traffic alone. Every line in a batch file must name the same deployment, so two deployments mean two files and two jobs.
Next → 9 / 10 -
Question 10 of 10
A production workload needs a partner model, built-in content filtering, an SLA, and inference processing inside a data zone. The model is offered both as a Serverless API deployment and on managed compute. Which option fits?
- AA Serverless API deployment with a Data Zone type
- BInstant access, calling the model by its name
- CA managed compute deployment in the Foundry project
- DA managed compute deployment with Data Zone routing
Show the answer
Serverless API is the preferred path when a model supports it: it offers regional, data zone, and global processing, plus built-in and customizable content filtering. Managed compute is a preview without an SLA, global-only, and without content filtering in public preview.
Next → 10 / 10 -
You’ve finished this set
That’s 10 questions on Choosing a Deployment Type. In the app the ones you miss come back exactly when you’re about to forget them.
