A ferry webhook Function is idle most nights and can tolerate cold starts, while a clerk-office Function must join a VNet and stay pre-warmed. How should the developer match Azure Functions hosting plans?
Select an answer to reveal the explanation.
Short Explanation
Idle ferry webhooks love Consumption—pay when the boat calls, shrug at cold starts. Clerk-office work that needs VNet and warm workers steps up to Premium or Dedicated. Flip those and either the wallet or the network story breaks.
Full Explanation
The ferry webhook Function is idle most nights and can tolerate cold starts, while the clerk-office Function must join a VNet and stay pre-warmed. Match hosting plans to those constraints: use Consumption (or Flex Consumption) for the intermittent webhook so you pay per execution and accept cold starts, and use Premium (Elastic Premium) or Dedicated (App Service plan) for the clerk-office function that needs VNet integration and pre-warmed workers. Plan choice is how Azure Functions expresses cost-versus-network-versus-warmth tradeoffs.
Running both on Consumption only fails the clerk-office requirements: classic Consumption is a poor fit when you need straightforward VNet integration and always-warm instances. Hosting both on AKS so Functions always share a Kubernetes node pool ignores the managed Functions hosting plans the exam emphasizes. Using Dedicated for the idle webhook and Consumption for the VNet clerk function flips the mapping—Dedicated wastes money on an idle webhook, while Consumption struggles to meet the VNet/pre-warm story for the clerk workload.
Exam caveat: Flex Consumption evolves networking and concurrency options—still map “idle/cold-OK” versus “VNet + pre-warmed” to the appropriate plan family rather than forcing one plan for both. Operational check: place the webhook on Consumption/Flex and confirm it scales to zero when idle; place the clerk function on Premium/Dedicated, enable VNet integration, and verify pre-warmed instances serve without cold-start penalties.