Design compute solutions

Nimbus Retail is building an order-processing platform made of 14 Linux microservices. Services communicate through Dapr service invocation and Dapr pub/sub, several services should scale to zero overnight, and one service must scale on the length of an Azure Service Bus queue. The platform team has no Kubernetes experience and must not manage cluster upgrades or nodes.

Which service should you recommend?

1. AAzure Kubernetes Service with the Dapr cluster extension and KEDA add-onAKS with Dapr and KEDA meets the functional needs, but the team would still own cluster upgrades, node pools, and networking, which the scenario explicitly forbids.
2. BAzure Container Apps with Dapr enabled and KEDA-based scale rulesContainer Apps is a serverless container platform with built-in managed Dapr, scale-to-zero, and KEDA scalers such as Service Bus queue length, with no visible cluster to upgrade or patch.
3. CAzure App Service multi-container deployments on a Premium v3 planApp Service does not provide managed Dapr sidecars or queue-length scaling rules, and a dedicated plan does not scale to zero.
4. DAzure Container Instances with one container group per microserviceContainer Instances has no autoscaling or scale-to-zero capability and no managed Dapr integration, so each service would run at a fixed size.

Brightwater Insurance runs a claims engine on four Windows Server virtual machines that depend on a third-party kernel driver, so the workload cannot be replatformed to PaaS. The business requires a 99.99 percent availability SLA for the VM tier within a single Azure region and requires the solution to survive the loss of an entire datacenter. The VMs will sit behind an Azure Standard Load Balancer.

Which deployment pattern should you recommend for the virtual machines?

1. ADeploy all four VMs into a single availability set with three fault domainsAn availability set protects against rack-level hardware failure and planned maintenance inside one datacenter, which yields a 99.95 percent SLA and does not survive loss of a datacenter.
2. BDeploy two VMs in each of two availability zones in the regionSpreading VMs across two or more availability zones gives the 99.99 percent VM SLA and places instances in physically separate datacenters, so losing one datacenter leaves the other zone serving traffic through the zone-redundant Standard Load Balancer.
3. CDeploy all four VMs as single-instance VMs with Premium SSD disksA single VM with Premium SSD or Ultra Disk carries a 99.9 percent SLA and no datacenter-level isolation, so it meets neither requirement.
4. DDeploy two VMs in the primary region and two in a paired region with Azure Site RecoveryA paired-region design is a disaster recovery pattern with failover, not an active in-region SLA; it also exceeds the stated single-region scope.

Ravenhurst Publishing is building an invoice pipeline in C#. For each uploaded batch, the pipeline fans out to validate up to 500 invoices in parallel, aggregates the results, pauses until a finance manager approves or rejects the batch through an external callback that can take up to 20 days, and then resumes to post the entries. The team wants orchestration state managed for them, wants to write the orchestration in code, and wants per-execution billing.

Which solution should you recommend?

1. AAzure Functions on the Flex Consumption plan using Durable Functions with an orchestrator, activity functions, and a durable external event for the approvalDurable Functions implements fan-out/fan-in and human-interaction patterns in code, checkpoints orchestration state automatically, and can wait for an external event for weeks without consuming compute, all on consumption billing.
2. BStateless Azure Functions that pass intermediate results through Azure Storage queues and store approval status in Azure Table StorageThis recreates orchestration state and correlation by hand, which is error-prone and adds the operational burden the team wants to avoid.
3. CAzure Logic Apps (Consumption) with a parallel For each action and a Wait for approval email actionLogic Apps can implement this flow, but the team explicitly wants the orchestration in C# code rather than in a designer, and the Consumption For each action caps parallelism below the 500 required.
4. DAzure Batch with a job that runs the validation tasks and a long-running task that polls for approvalA Batch task that polls for up to 20 days occupies a billed compute node continuously, and Batch does not manage workflow state or callbacks.

Pinecrest Ticketing processes bursts of event-driven payment callbacks in Azure Functions. The function must reach a database over a private endpoint through virtual network integration, must keep a small number of always-ready instances so that first requests do not wait on a cold start, and must scale to zero outside of sales windows so that there is no charge for idle on-demand compute. Minimizing cost while meeting these requirements is the deciding factor.

Which Azure Functions hosting plan should you recommend?

1. AConsumption planThe classic Consumption plan scales to zero and is cheapest when idle, but it does not support virtual network integration or always-ready instances.
2. BFlex Consumption plan with always-ready instancesFlex Consumption adds virtual network integration and configurable always-ready instances to a pay-for-what-you-use model in which the on-demand instances still scale to zero.
3. CPremium plan (Elastic Premium) with pre-warmed instancesThe Premium plan provides virtual network integration and pre-warmed instances but always keeps at least one full instance running and billed per plan, so it does not offer per-execution billing for the burst capacity.
4. DDedicated App Service plan with Always On enabledA dedicated plan supports virtual network integration but is billed for the plan instances continuously and does not scale to zero.