Quick Note — Recommend a Serverless-Based Solution — Designing Microsoft Azure Infrastructure Solutions (AZ-305) Study Notes | BrainyBee

A fintech team builds a webhook receiver for a payment provider. Volume is bursty — silent for hours, then $5{,}000$ events in two minutes when reconciliation runs. The team originally builds it on a 2-instance App Service plan ( $\sim $150$ /month, always on). The bill is fine, but the architect asks two questions during review: "What happens when reconciliation overlaps with a partner integration burst?" and "Why are you paying $24/7 $for a workload that runs 4 hours a day?". A redesign onto the `Azure Functions` **Flex Consumption** plan — the current serverless default, since Consumption is now a legacy hosting plan — cuts the bill to $$\sim$ $3/month and removes the capacity-overlap risk entirely. The Functions plan handles a 50{ $\times$ }$ burst without intervention.…

Retrieval target

Objective: Recommend a Serverless-Based Solution
Mode: Closed-book recall
Target time: 5 minutes
Escalation: Open the full lesson after a miss

Decision anchors

Prompt	Compact answer
`Azure Functions`	An event-driven serverless compute service. Write a function (Node, .NET, Python, Java, PowerShell), attach a trigger (HTTP, Timer, Blob, Queue, Event Grid, Service Bus, Cosmos, Event Hub), and the platform invokes it. Adjacent bindings wire inputs and outputs (Storage, Cosmos, Service Bus) without manual SDK code. Pay-per-execution + per-GB-second on Consumption; per-instance on Premium/Dedicated.
Functions `Consumption` plan	Legacy serverless Functions plan — Microsoft now says to use Flex Consumption for new serverless function apps and to migrate existing Consumption apps; Linux Consumption hosting is retiring on 30 September 2028. Scale-to-zero, pay only for executions (1M free + $400{,}000$ GB-s / month). Auto-scales to 200 instances max on Windows (100 on Linux), cold start can be seconds, function timeout default 5 min, max 10 min (configurable). No VNet integration. Pick it only for apps already running there — for new spiky / bursty / dev / low-volume work pick Flex Consumption.
Functions `Flex Consumption` plan	The current serverless default — Microsoft directs new serverless function apps here and tells existing Consumption apps to migrate. Scale-to-zero with fast, per-function scale-out to $1{,}000$ instances, virtual network integration built in, optional always-ready instances to cut cold starts, and selectable instance memory (512 MB, $2{,}048`MB, or `4{,}096$ MB). Linux-only. Pick for spiky / bursty / event-driven work, including anything needing private-network access.
Functions `Premium` plan	Functions running on pre-warmed instances: no cold start, VNet integration built-in, longer execution time (no 10-min cap), more memory (14 GB). You pay for the pre-warmed instance (24/7) plus consumption above it. Pick when you need predictable latency, VNet access to private resources (DB, App Gateway), or long-running functions ( $> 10$ min).
Functions on the `App Service` (Dedicated) plan	Functions sharing an App Service Plan with web apps — runs on plan VMs you've already paid for. No serverless properties (no scale-to-zero, no per-execution pricing). Useful when you have spare ASP capacity and want to colocate a small function with an app. Pick only when you can't justify Premium or Flex Consumption — i.e., when the ASP is already paid for.

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.

Recommend a Serverless-Based Solution — quick retrieval

Card 1 of 5

Azure Functions

easy

An event-driven serverless compute service. Write a function (Node, .NET, Python, Java, PowerShell), attach a trigger (HTTP, Timer, Blob, Queue, Event Grid, Service Bus, Cosmos, Event Hub), and the platform invokes it. Adjacent bindings wire inputs and outputs (Storage, Cosmos, Service Bus) without manual SDK code. Pay-per-execution + per-GB-second on Consumption; per-instance on Premium/Dedicated.

azure-functionsserverless

Recommend a Serverless-Based Solution — quick retrieval

Card 1

Front: Azure Functions
Back: An event-driven serverless compute service. Write a function (Node, .NET, Python, Java, PowerShell), attach a trigger (HTTP, Timer, Blob, Queue, Event Grid, Service Bus, Cosmos, Event Hub), and the platform invokes it. Adjacent bindings wire inputs and outputs (Storage, Cosmos, Service Bus) without manual SDK code. Pay-per-execution + per-GB-second on Consumption; per-instance on Premium/Dedicated.

Card 2

Front: Functions Consumption plan
Back: Legacy serverless Functions plan — Microsoft now says to use Flex Consumption for new serverless function apps and to migrate existing Consumption apps; Linux Consumption hosting is retiring on 30 September 2028. Scale-to-zero, pay only for executions ( $1$ M free + $400{,}000$ GB-s / month). Auto-scales to $200$ instances max on Windows ( $100$ on Linux), cold start can be seconds, function timeout default $5$ min, max $10$ min (configurable). No VNet integration. Pick it only for apps already running there — for new spiky / bursty / dev / low-volume work pick Flex Consumption.

Card 3

Front: Functions Flex Consumption plan
Back: The current serverless default — Microsoft directs new serverless function apps here and tells existing Consumption apps to migrate. Scale-to-zero with fast, per-function scale-out to $1{,}000$ instances, virtual network integration built in, optional always-ready instances to cut cold starts, and selectable instance memory ( $512$ MB, $2{,}048$ MB, or $4{,}096$ MB). Linux-only. Pick for spiky / bursty / event-driven work, including anything needing private-network access.

Card 4

Front: Functions Premium plan
Back: Functions running on pre-warmed instances: no cold start, VNet integration built-in, longer execution time (no $10$ -min cap), more memory ( $14$ GB). You pay for the pre-warmed instance ( $24$ / $7$ ) plus consumption above it. Pick when you need predictable latency, VNet access to private resources (DB, App Gateway), or long-running functions ( $> 10$ min).

Card 5

Front: Functions on the App Service (Dedicated) plan
Back: Functions sharing an App Service Plan with web apps — runs on plan VMs you've already paid for. No serverless properties (no scale-to-zero, no per-execution pricing). Useful when you have spare ASP capacity and want to colocate a small function with an app. Pick only when you can't justify Premium or Flex Consumption — i.e., when the ASP is already paid for.

Loading flashcards…

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.