This chapter covers Azure Functions, Azure's serverless compute offering. AZ-900 tests this under objective 2.2, and it's a common example when the exam discusses serverless computing concepts.
Jump to a section
A simple way to picture Azure Functions (Serverless)
Hiring a full-time employee means paying a salary whether or not there's work to do at any given moment. Hiring a contractor for individual tasks means paying only when there's actual work to be done, with no cost during idle time. Azure Functions works like the contractor model for code: instead of running a server continuously (and paying for it whether or not it's doing anything), a function runs only when triggered by a specific event, and you're billed based on that execution rather than for idle time.
What Azure Functions is
Azure Functions is a serverless compute service that lets developers run small pieces of code ("functions") in response to specific triggers — such as an HTTP request, a message arriving in a queue, or a scheduled time — without needing to provision or manage servers.
What "serverless" means
"Serverless" doesn't mean there are no servers involved — it means the customer doesn't need to provision, manage, or think about the underlying servers at all. Azure handles all of that, automatically allocating resources when a function is triggered and scaling down when it's not needed.
How billing works conceptually
Azure Functions is generally billed based on actual execution — how often a function runs and how long it takes — rather than for infrastructure sitting idle. This fits the broader consumption-based pricing model covered in an earlier chapter, though the specific pricing details can vary and change over time.
Common use cases
Azure Functions is well suited to event-driven, short-running tasks — processing a file when it's uploaded, responding to an HTTP request, running a small scheduled job, or reacting to a message in a queue — rather than long-running, continuously active applications.
How it compares to other compute options
Compared to a Virtual Machine or App Service, which run continuously, Azure Functions runs code only in response to specific triggers, making it well suited to intermittent, event-driven workloads rather than always-on applications.
Identify an event-driven need
Azure Functions fits scenarios where code needs to run in response to a specific event, rather than continuously — like processing a file upload or responding to a scheduled trigger.
Write the function code
A small, focused piece of code is written to handle the specific task, without needing to configure a server or runtime environment manually.
Configure the trigger
A trigger (HTTP request, timer, queue message, and others) determines what causes the function to run.
Let Azure handle scaling
Azure automatically allocates resources when the function is triggered and scales down when it's idle, without the customer managing that infrastructure directly.
A company automatically resizes images whenever a new one is uploaded to storage, using an Azure Function triggered by that upload event — the function runs briefly to process the image, then goes idle until the next upload, without any server running continuously in between.
A separate team uses a timer-triggered function to run a small scheduled cleanup task once a day, rather than keeping a dedicated server running around the clock just to perform that brief daily task — illustrating the cost efficiency of serverless for intermittent workloads.
Objective 2.2 expects candidates to understand what serverless computing means conceptually, and to recognize Azure Functions as Azure's serverless compute offering.
A common wrong answer is thinking "serverless" means there are literally no servers involved — there are; the customer simply doesn't manage or provision them. Another common trap is assuming Azure Functions is meant for long-running, continuously active applications — it's designed for short, event-triggered tasks, not always-on workloads.
Stable terms: serverless, Azure Functions, trigger. Recognizing that serverless computing means the provider handles infrastructure management entirely, and billing generally follows actual execution, is the core exam-relevant idea.
Memory trick: serverless doesn't mean "no servers" — it means "you don't manage the servers." Azure Functions runs code in response to triggers, not continuously.
Azure Functions is Azure's serverless compute offering, running code in response to specific triggers.
'Serverless' means the customer doesn't manage the underlying servers, not that servers don't exist.
Azure Functions fits short, event-driven tasks well; it isn't designed for continuously active applications.
Billing for Azure Functions is generally tied to actual execution, fitting the broader consumption-based pricing model.
These come up on the exam all the time. Here's how to tell them apart.
Azure Functions (Serverless)
Runs in response to specific triggers
Scales down to zero when idle
Good fit for short, event-driven tasks
Billing generally tied to actual execution
Always-On Compute (e.g. App Service)
Runs continuously
Maintains active capacity even when idle
Good fit for continuously active applications
Billing generally tied to allocated capacity over time
Mistake
'Serverless' means there are no servers at all.
Correct
Servers are still involved — 'serverless' means the customer doesn't need to provision or manage them; Azure handles that automatically.
Mistake
Azure Functions is meant to run continuously like a web application.
Correct
Azure Functions is designed for short, event-triggered tasks that run in response to a specific trigger, not for continuously active, always-on applications.
Mistake
Azure Functions and Azure App Service are the same thing.
Correct
App Service is meant for hosting continuously running web applications and APIs; Azure Functions is meant for short, event-triggered pieces of code — they serve different use cases.
It means the customer doesn't need to provision or manage the underlying servers — the cloud provider handles that automatically. Servers are still involved behind the scenes; the customer just doesn't have to think about them.
It's used for running small pieces of code in response to specific triggers — like an HTTP request, a scheduled time, or a message arriving in a queue — making it well suited to short, event-driven tasks rather than continuously running applications.
Generally based on actual execution — how often a function runs and how long it takes — rather than for infrastructure sitting idle, following the broader consumption-based pricing model. Specific pricing details can change over time, so check current Azure pricing documentation for exact figures.
You've just covered Azure Functions (Serverless) — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?