Quick Note — Specify Components of a Compute Solution Based on Workload Requirements
AZ-305 › Unit 4: Design infrastructure solutions › Design compute solutions › Specify components of a compute solution based on workload requirements
Quick Note — Specify Components of a Compute Solution Based on Workload Requirements
A platform team at a logistics firm has spent the past quarter building a fleet of VMs to run a new image-recognition microservice. Throughput targets are unmet, the team is paged most weekends because a cron job inside a VM falls behind, and the bill from the autoscaling group has grown in three months. The architect who reviews the situation asks one question: "Why is this on VMs?" The team's answer — "We always start with VMs" — is the architecture problem in one sentence. The right answer was probably Azure Container Apps with a job-trigger queue, but no one ran the decision tree on paper.…
Retrieval target
- Specify Components of a Compute Solution Based on Workload Requirements
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
IaaS compute (VM-based) | Infrastructure-as-a-Service — you get the VM, OS, and full control; Microsoft owns hardware and hypervisor. You patch the OS, install runtimes, configure middleware, manage HA. Largest ops surface, most flexibility. Pick when you need a specific OS / kernel / driver, lift-and-shift a legacy app, or run software incompatible with PaaS sandboxes. |
PaaS compute (App Service / Containers / Serverless) | Platform-as-a-Service — Microsoft owns OS, runtime, scaling, and HA; you supply the app and the configuration. Less surface area, less control, faster iteration. Families on Azure: App Service (web/api), AKS / ACI (containers), Functions / Logic Apps (serverless code/workflow). Choose by your packaging unit and operational tolerance. |
Stateful vs stateless workload | Stateless — every request stands alone; can route to any instance. Trivial to scale horizontally; ideal for serverless / PaaS. Push state to an external store (DB, cache). Stateful — instance keeps in-memory state across requests (session data, lock holders, leader election).… |
Packaging unit (compute choice driver) | How the app is delivered shapes which compute fits: VM image (Marketplace / custom) → Azure VM, VMSS. Container image (OCI) → AKS, ACI, App Service for Containers, Container Apps. Code + runtime (.zip, jar, etc.) → App Service, Functions. Workflow definition (declarative) → Logic Apps. Job binary + input → Azure Batch.… |
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.