This chapter covers serverless architecture patterns in Azure, including Azure Functions, Logic Apps, Event Grid, and Durable Functions. For the AZ-305 exam, serverless topics appear in approximately 10-15% of questions, primarily under objective 4.4 (Design compute solutions) and 4.5 (Design application architecture). Understanding serverless patterns is critical because they enable cost-effective, event-driven, and scalable solutions that reduce operational overhead. This chapter will provide the deep technical knowledge needed to answer scenario-based questions correctly, including trade-offs between serverless and other compute options.
Jump to a section
Consider two ways to get lunch for your team. Option A: You hire a full catering crew, rent a kitchen, buy ingredients, and manage the logistics. You pay for the kitchen and staff even on slow days. This is like provisioning VMs or containers — you pay for capacity regardless of usage. Option B: You use a vending machine. You don't own the machine, you don't hire staff, and you don't pay for electricity when no one buys a snack. Each time a customer inserts money and selects a product, the machine's internal mechanism dispenses the item. The machine automatically restocks itself (via a service contract), and scales to handle multiple customers in parallel — but you only pay per transaction. In serverless, Azure Functions and Logic Apps work like that vending machine: they run code only when triggered (like a coin insertion), automatically scale to handle concurrent requests, and you are billed only for execution time and resources consumed. The platform handles all infrastructure — patching, scaling, availability — just as the vending machine company handles restocking and maintenance. You focus on the code (the product selection) and the trigger (the coin), not the machine internals.
What Is Serverless Architecture?
Serverless computing is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. The term 'serverless' is a misnomer — servers are still involved, but developers do not need to provision, scale, or manage them. Instead, code is executed in stateless compute containers that are event-triggered, ephemeral (may last only milliseconds), and fully managed by the platform. In Azure, the primary serverless compute services are Azure Functions (for code execution) and Azure Logic Apps (for workflow orchestration). Supporting services include Azure Event Grid (event routing), Azure Service Bus (messaging), and Azure Storage Queues (async communication).
Why Serverless Exists
Traditional infrastructure (IaaS) and containers (PaaS) require capacity planning, scaling rules, and always-on resources. Serverless eliminates idle capacity: you pay only when your code runs. This is ideal for variable workloads, event-driven architectures, and microservices that need to scale rapidly. The exam focuses on when to choose serverless over other compute options, how to design event-driven solutions, and how to handle state, durability, and orchestration.
How Azure Functions Work Internally
Azure Functions are built on the Azure App Service platform (same sandbox as Web Apps) but with a specialized runtime. When a function is triggered, the Functions host (a process called Microsoft.Azure.WebJobs.Script.WebHost) receives the event and invokes the function code. The host manages the function's lifecycle:
Scaling: The Azure Functions scale controller monitors the number of events in the trigger source (e.g., queue length, HTTP requests). It decides to add or remove worker instances. For Consumption plan, scaling is based on the number of pending triggers. The scale controller uses a metric like functionExecutionCount and queueLength.
Concurrency: Each function instance can handle multiple executions concurrently, controlled by the maxConcurrentCalls setting (default 16 for Service Bus, 32 for queues).
Warm-up: Cold start occurs when a new instance is created — the runtime loads the function code and dependencies. This adds latency (typically 1-5 seconds for C#, less for JavaScript). Premium plan keeps instances warm to avoid cold starts.
Statelessness: Functions are stateless by default. For stateful workflows, use Durable Functions which provide orchestration and entity patterns.
Key Components and Defaults
- Azure Functions: - Triggers: HTTP, Timer (cron), Blob, Queue, Service Bus, Event Grid, Event Hub, Cosmos DB, etc. - Bindings: Input/output bindings connect to Azure services declaratively. For example, a blob output binding writes data to Azure Blob Storage without writing SDK code. - Hosting Plans: - Consumption: Pay-per-execution, auto-scale, max timeout 10 minutes (default 5), max memory 1.5 GB. - Premium: Pre-warmed instances, unlimited execution duration (60 min default), VNET integration, larger instances (up to 14 GB). - Dedicated (App Service Plan): Full control, always-on, predictable pricing. - Azure Logic Apps: - Workflow engine: Uses connectors (over 200) to integrate SaaS and enterprise systems. - Pricing: Pay per action execution (standard connector: ~$0.000025/action, enterprise: ~$0.000125/action). - Triggers: Polling (e.g., when an email arrives) or push (via Event Grid). - Azure Event Grid: - Event routing: Pub/sub model with topics and subscriptions. Supports custom events and Azure service events (e.g., blob created, VM started). - Schema: CloudEvents v1.0 compliant. - Retry: Exponential backoff with 30-second initial delay, max 24 hours. - Azure Durable Functions: - Patterns: Function chaining, fan-out/fan-in, async HTTP APIs, monitoring, human interaction. - State: Orchestrator functions are replayed to rebuild state — they must be deterministic.
Configuration and Verification
To create an Azure Function using Azure CLI:
az functionapp create --resource-group myRG --consumption-plan-location westus --runtime dotnet --functions-version 4 --name myFuncApp --storage-account myStorageKey settings to verify:
- FUNCTIONS_WORKER_RUNTIME: dotnet, node, python, java, powershell
- AzureWebJobsStorage: connection string for the storage account used by the runtime
- WEBSITE_RUN_FROM_PACKAGE: enables running from a deployment package (reduces cold start)
For monitoring, use Application Insights:
az monitor app-insights component create --app myFuncApp --location westus --resource-group myRG
az webapp config appsettings set --name myFuncApp --resource-group myRG --settings APPINSIGHTS_INSTRUMENTATIONKEY=<key>Interaction with Related Technologies
Serverless functions often integrate with: - Azure API Management: Expose HTTP-triggered functions as APIs with rate limiting, caching, and authentication. - Azure Storage Queues: Decouple function calls. A function writes a message to a queue; another function reads and processes it. - Azure Event Grid: Publish events from functions to trigger other functions or Logic Apps. - Azure Cosmos DB: Use change feed to trigger functions on data changes. - Azure Service Bus: Reliable messaging for enterprise scenarios.
Durable Functions Patterns in Detail
Durable Functions extend Azure Functions to write stateful workflows. The orchestrator function coordinates execution using a task hub (backed by Azure Storage). The key patterns:
Function Chaining: A sequence of functions executes in order. The orchestrator calls each function via context.CallActivityAsync. If a function fails, the orchestrator can retry.
Fan-out/Fan-in: The orchestrator calls multiple functions in parallel using Task.WhenAll, then aggregates results.
Async HTTP API: The orchestrator returns a check-status URL. External clients poll the URL until completion.
Monitor: A function polls an external system until a condition is met, then exits.
Human Interaction: The orchestrator waits for an external event (e.g., approval) with a timeout.
Timer and Cron Expressions
Azure Functions Timer trigger uses NCronTab format: {second} {minute} {hour} {day} {month} {day-of-week}. Example: 0 0 */1 * * * runs every hour at the top of the hour. The exam may ask about scheduling and timezone handling (use WEBSITE_TIME_ZONE app setting).
Cold Start Mitigation
Cold start occurs when a new instance is created. Mitigation strategies:
Use Premium plan to keep instances warm.
Reduce package size: trim dependencies, use WEBSITE_RUN_FROM_PACKAGE.
Use language with faster startup (JavaScript vs C#).
Pre-warm with a timer trigger.
Security Considerations
Authentication: Use Managed Identity to access Azure resources without keys.
Authorization: For HTTP triggers, use Function Keys or Azure AD authentication.
Network: Premium plan supports VNET integration for private access.
Secrets: Store in Key Vault and reference via app settings.
Pricing Models
Consumption: $0.000016/GB-s (execution time * memory). 1 million executions free per month.
Premium: Fixed cost per instance (e.g., Y1: ~$0.000058/GB-s) plus execution time.
Dedicated: App Service Plan cost (e.g., B1: ~$0.075/hr).
The exam expects you to choose the plan based on cost, performance, and feature requirements.
Define the Trigger Source
Identify the event that initiates the serverless workflow. Common triggers include an HTTP request, a new blob in Azure Storage, a message on a queue, a timer schedule, or an event from Event Grid. The trigger determines the execution model. For example, a Blob trigger fires when a blob is created or updated in a specified container. The trigger's properties (e.g., path, connection string) are configured in the function's `function.json` or via attributes in code. The exam tests understanding of which trigger to use for given scenarios, such as using Event Grid for high-throughput events or Service Bus for reliable messaging.
Configure Bindings and Connect to Services
Bindings provide a declarative way to connect your function to Azure services without writing SDK code. Input bindings read data (e.g., from Cosmos DB), output bindings write data (e.g., to a queue). For example, an HTTP-triggered function can have an output binding to Blob Storage to save the request body. Bindings are defined in `function.json` or via attributes in C# (e.g., `[Blob("container/{name}")]`). The exam emphasizes that bindings reduce boilerplate code and improve maintainability. A common mistake is to forget that bindings are optional — you can use SDKs directly if needed.
Write the Function Code and Handle State
Write the business logic in the function code. Since functions are stateless, state must be stored externally (e.g., in a database, queue, or Durable Functions). For stateful workflows, use Durable Functions: the orchestrator function coordinates activities and persists state via the task hub. The orchestrator must be deterministic (no random numbers, no direct I/O). The exam tests how to handle state in a stateless environment and when to use Durable Functions over simple functions.
Deploy and Configure Scaling Settings
Deploy the function app using Azure CLI, ARM templates, or CI/CD pipelines. Configure the hosting plan (Consumption, Premium, or Dedicated). For Consumption plan, scaling is automatic — no settings required. For Premium plan, set minimum and maximum instance counts. For Dedicated plan, configure App Service Plan scaling rules. The exam tests the impact of plan choice on cold start, execution duration, and cost. Use Application Insights to monitor performance and set alerts.
Monitor, Debug, and Optimize
Use Application Insights to track function executions, failures, and durations. Enable detailed logging by setting `FUNCTIONS_EXTENSION_VERSION` and configuring `APPINSIGHTS_INSTRUMENTATIONKEY`. Debug locally using Azure Functions Core Tools. Optimize by reducing cold start (use Premium plan or pre-warm), minimizing execution time (efficient code), and managing concurrency (adjust `maxConcurrentCalls`). The exam expects you to interpret metrics to identify bottlenecks and suggest optimizations.
Enterprise Scenario 1: Image Processing Pipeline
A media company ingests thousands of images per hour from users. They use Azure Blob Storage as the landing zone. A Blob-triggered Azure Function (Consumption plan) is automatically invoked for each new image. The function resizes the image (using a library), generates a thumbnail, and writes both to separate containers. It also updates a Cosmos DB database with metadata. The function uses output bindings to write to Blob and Cosmos DB. In production, the scale controller can spin up hundreds of instances to handle bursts. A common misconfiguration is not setting the AzureWebJobsStorage connection string correctly, causing the function to fail silently. Monitoring via Application Insights reveals that cold starts add ~2 seconds latency for C# functions, so for latency-sensitive users, they moved to Premium plan with pre-warmed instances. The cost is higher but acceptable for the SLA requirement.
Enterprise Scenario 2: Order Processing Workflow
An e-commerce company processes orders using Durable Functions. An HTTP-triggered function starts the orchestration. The orchestrator calls activities: validate inventory, process payment, update database, send confirmation email. If payment fails, the orchestrator waits for a human approval via an external event (e.g., a Logic App that sends an email to a manager). The orchestrator uses a timeout of 24 hours for the approval. The task hub is backed by Azure Storage. In production, they encountered a bug where the orchestrator was non-deterministic (used DateTime.Now instead of context.CurrentUtcDateTime), causing replay failures. The fix was to use the context-provided time. The exam tests this exact pitfall: orchestrator functions must be deterministic.
Enterprise Scenario 3: Real-Time Event Routing
A financial services firm uses Event Grid to route events from multiple sources (trade executions, market data feeds) to different subscribers. They have topics for 'trades', 'positions', and 'alerts'. Subscribers include Azure Functions (to update dashboards), Logic Apps (to send notifications), and a webhook to a third-party system. Event Grid guarantees at-least-once delivery with retry policy. They configured dead-lettering to a storage queue for failed deliveries. A misconfiguration: they set the retry policy to 5 retries with 1-second interval, causing throttling. They changed to exponential backoff with 30-second initial delay. The exam focuses on Event Grid's retry behavior and dead-lettering.
What AZ-305 Tests on Serverless
Objective 4.4 (Design compute solutions) includes selecting appropriate compute services, including Azure Functions and Logic Apps. Objective 4.5 (Design application architecture) covers event-driven architectures, messaging, and orchestration. Specific sub-objectives:
Design for event-driven and message-based architectures (4.5.1)
Design for decoupling (4.5.2)
Design for serverless compute (4.4.2)
The exam expects you to compare serverless with other compute options (VMs, containers, App Service) based on cost, scalability, state management, and operational overhead.
Common Wrong Answers
'Use Azure Functions for long-running workflows' — Wrong. Functions have execution time limits (10 min Consumption, 60 min Premium). For long-running workflows, use Durable Functions or Logic Apps.
'Serverless always costs less than VMs' — Wrong. For steady-state workloads with constant traffic, a dedicated App Service plan can be cheaper than Consumption plan due to per-execution costs.
'Logic Apps can replace Functions for custom code' — Wrong. Logic Apps are for workflow orchestration using connectors, not for writing custom business logic. Use Functions for code, Logic Apps for integration.
'Event Grid guarantees exactly-once delivery' — Wrong. Event Grid provides at-least-once delivery. For exactly-once, you need idempotent receivers.
Specific Numbers and Terms
Consumption plan timeout: 10 minutes (default 5)
Premium plan timeout: 60 minutes (default 30)
Max memory Consumption: 1.5 GB
Max memory Premium: 14 GB
Max execution count per instance: unlimited (but concurrency limits apply)
Default concurrency for Service Bus: 16
Default concurrency for Queue: 32
Event Grid retry: exponential backoff, initial 30s, max 24h
Durable Functions task hub: uses Azure Storage tables and queues
Edge Cases and Exceptions
Cold start in Premium plan: Even with pre-warmed instances, the first request after idle may experience a slight delay if the instance was recycled.
Functions with VNET integration: Only Premium plan supports VNET integration. Consumption plan cannot access VNET resources.
Durable Functions storage: If the storage account is deleted, the orchestration state is lost. Use geo-redundant storage for DR.
Timer trigger timezone: The default is UTC. To use a different timezone, set WEBSITE_TIME_ZONE app setting.
How to Eliminate Wrong Answers
If the scenario requires stateful, long-running workflows, eliminate simple Functions and consider Durable Functions or Logic Apps.
If the scenario mentions cost optimization for sporadic traffic, serverless (Consumption) is likely correct.
If the scenario requires VNET access, eliminate Consumption plan.
If the scenario requires exactly-once delivery, look for idempotent processing rather than relying on the messaging system.
Serverless in Azure is primarily Azure Functions (code) and Logic Apps (workflow).
Consumption plan functions have a 10-minute execution timeout (default 5).
Premium plan functions support VNET integration and pre-warmed instances.
Durable Functions enable stateful orchestration with patterns like chaining and fan-out/fan-in.
Event Grid provides at-least-once delivery with exponential backoff retry (initial 30s, max 24h).
Bindings reduce boilerplate by connecting functions to Azure services declaratively.
Cold start can be mitigated by using Premium plan or reducing package size.
For steady-state workloads, Dedicated plan may be cheaper than Consumption.
Logic Apps are for integration, Functions are for custom code.
Orchestrator functions in Durable Functions must be deterministic (use context time, not DateTime.Now).
These come up on the exam all the time. Here's how to tell them apart.
Azure Functions (Consumption)
Pay-per-execution (GB-s and executions)
Max execution time: 10 minutes (default 5)
Cold start for each new instance (1-5 seconds)
No VNET integration
Max memory: 1.5 GB
Azure Functions (Premium)
Fixed cost per instance + per-execution
Max execution time: 60 minutes (default 30)
Pre-warmed instances reduce cold start
VNET integration supported
Max memory: 14 GB
Azure Functions
Code-based (C#, JavaScript, Python, etc.)
Best for custom business logic
Stateful via Durable Functions
Triggers: HTTP, timer, Azure services
Pricing: per execution + GB-s
Azure Logic Apps
Low-code/no-code workflow designer
Best for integrating SaaS and enterprise systems
Stateful by default (workflow persists)
Connectors: 200+ pre-built connectors
Pricing: per action execution
Mistake
Serverless means no servers are involved.
Correct
Servers are still used, but they are abstracted from the developer. The cloud provider manages the infrastructure. You pay only for execution time and resources consumed.
Mistake
Azure Functions can run indefinitely.
Correct
Functions have execution time limits: 10 minutes on Consumption plan (default 5), 60 minutes on Premium plan (default 30), and unlimited on Dedicated plan (but App Service plan has its own limits).
Mistake
Logic Apps are the same as Azure Functions.
Correct
Logic Apps are for workflow orchestration using connectors and no-code/low-code. Azure Functions are for custom code execution. They can work together: Logic Apps can call Functions.
Mistake
Event Grid guarantees exactly-once delivery.
Correct
Event Grid provides at-least-once delivery. Subscribers must be idempotent to handle duplicate events. Retry policy can cause duplicates.
Mistake
Consumption plan always costs less than Dedicated plan.
Correct
For steady-state high-traffic workloads, Dedicated plan can be more cost-effective due to predictable pricing. Consumption plan can be expensive for always-on functions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Functions are designed for executing custom code (C#, JavaScript, Python, etc.) in response to events. They are ideal for business logic. Azure Logic Apps are low-code workflows that integrate with over 200 connectors (e.g., Office 365, Salesforce) and are best for orchestrating services without writing code. The exam tests when to use each: choose Functions for custom processing, Logic Apps for integration workflows.
Standard Azure Functions have execution time limits (10 min Consumption, 60 min Premium). For long-running processes, use Durable Functions which provide orchestration patterns that can run for hours or days. Alternatively, use Logic Apps which can handle long-running workflows natively.
Cold start is the latency when a new function instance is created because no warm instance exists. It typically adds 1-5 seconds. To avoid it, use the Premium plan which keeps instances warm, or use a timer trigger to keep the function active. Also, reduce package size and use languages with faster startup (e.g., JavaScript).
Yes, but only with the Premium plan or Dedicated plan. The Consumption plan does not support VNET integration. To access VNET resources, you must use the Premium plan and configure VNET integration via the portal or CLI.
Event Grid uses exponential backoff retry with an initial delay of 30 seconds, up to a maximum of 24 hours. It provides at-least-once delivery, so subscribers should be idempotent. Dead-lettering can be configured for events that fail after all retries.
Consumption plan: pay per execution ($0.20 per million executions) and per GB-s of resource consumption ($0.000016/GB-s). Premium plan: pay per instance (e.g., Y1: ~$0.000058/GB-s) plus execution time. Dedicated plan: pay for the App Service Plan (e.g., B1: ~$0.075/hr).
Use Durable Functions when you need stateful orchestration, such as function chaining, fan-out/fan-in, async HTTP APIs, or human interaction. Simple Functions are stateless and best for single-purpose, short-lived tasks.
You've just covered Serverless Architecture Patterns — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?