Quick Note — Recommend a Database Service Tier and Compute Tier
AZ-305 › Unit 2 › Design data storage for relational data › Recommend a database service tier and compute tier
Quick Note — Recommend a Database Service Tier and Compute Tier
Choosing a service tier and compute tier for Azure SQL Database is the point in your architecture where you translate workload behaviour into a monthly bill. The exam tests whether you can map a written business requirement — RTO targets, peak IOPS, burstiness, licence portfolio — to the correct combination of purchasing model (DTU vs vCore), service tier (General Purpose / Business Critical / Hyperscale), compute tier (Provisioned vs Serverless), and hardware generation.
Retrieval target
- Recommend a Database Service Tier and Compute Tier
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
DTU-based purchasing model | Database Transaction Unit — a bundled measure of CPU + memory + I/O sold as Basic, Standard, or Premium. You pick a pre-mixed bundle (e.g., S3 = 100 DTUs) rather than sizing components independently. Best for simple workloads where you don't know component-level requirements. New designs usually prefer vCore for clarity and AHB savings. |
vCore-based purchasing model | Lets you size compute (vCores), memory, and storage independently. Service tiers: General Purpose, Business Critical, Hyperscale. Supports Azure Hybrid Benefit — re-use on-prem SQL Server licenses with Software Assurance for ~30% discount. Required for SQL Managed Instance; default for new SQL Database designs. |
General Purpose tier (vCore) | The budget-oriented balanced tier — Microsoft now names Hyperscale the recommended and default service tier for all new and modernizing OLTP and HTAP workloads. Uses premium remote storage (Azure Premium SSD, separated from compute). SQL DB: 1 GB–4 TB. SQL MI: 32 GB–32 TB (16 TB for classic General Purpose; 32 TB only for Next-gen General Purpose). SLA 99.99%. No in-memory OLTP, no read scale-out, no local SSD. Pick when latency requirements are moderate and cost matters. |
Business Critical tier (vCore) | The low-latency, HA tier. Uses super-fast local SSD on each compute node and runs an Always-On replica set internally. Adds in-memory OLTP and read scale-out (read-only secondary endpoint). 99.99% SLA → 99.995% with zone-redundant option. SQL DB up to 4 TB; SQL MI up to 4 TB on standard-series (Gen5), up to 16 TB on premium-series or memory-optimized premium-series ($5.5 TB in regions without 16 TB support). Pick for mission-critical OLTP with strict latency. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.