This chapter covers Azure Static Web Apps, a fully managed service for hosting modern web applications with static content and serverless APIs. For the AZ-204 exam, this topic appears in roughly 5-10% of questions, focusing on deployment, authentication, and integration with Azure Functions. You will learn the architecture, configuration, and common patterns to build and deploy static web apps efficiently. Mastery of this service is essential for developers building Jamstack applications on Azure.
Jump to a section
Imagine a pop-up bookstore that appears in a busy square for a limited time. The bookstore has a fixed set of books (static content) pre-printed and arranged on shelves. Customers can browse and pick books, but they cannot write in them or change them. If a customer wants a custom book (dynamic content), the store has a small back-office where a clerk (serverless function) can assemble a personalized booklet on demand. The store also has a sign-up sheet for a newsletter (form handling) that gets processed by the clerk. The store is managed by a coordinator (Azure Static Web Apps service) who sets up the shelves, ensures the clerk is available, and handles security (authentication) so only authorized customers can access certain sections. The store is designed to be low-cost and easy to set up, perfect for a weekend event or a small business. If the event grows, the coordinator can quickly add more shelves or clerks. The store automatically closes and reopens each day (global distribution) to serve customers in different time zones. This mirrors how Azure Static Web Apps serves pre-built static files, uses serverless APIs for dynamic needs, integrates authentication, and scales globally without managing servers.
What is Azure Static Web Apps?
Azure Static Web Apps is a PaaS (Platform as a Service) offering that automatically builds and deploys full-stack web applications to Azure from a code repository. It is designed for modern web frameworks like React, Angular, Vue, and static site generators like Gatsby, Hugo, and Next.js. The service combines static content hosting with serverless APIs via Azure Functions, and includes built-in authentication, custom domains, and global distribution.
Why it Exists
Traditional web hosting requires managing servers, scaling, and security. Static Web Apps eliminates this by automatically handling build and deployment from a Git repository, providing a globally distributed CDN for static assets, and integrating serverless functions for backend logic. This reduces operational overhead and cost, as you only pay for the Azure Functions usage and bandwidth.
How it Works Internally
When you connect a GitHub or Azure DevOps repository to Static Web Apps, the service creates a GitHub Action or Azure DevOps pipeline that triggers on every push to the specified branch. The pipeline runs a build step (e.g., npm run build) to generate static files, then deploys them to Azure Storage and CDN. The static content is served from a global edge network (Azure CDN from Microsoft) with automatic HTTPS. Serverless functions (Azure Functions) are deployed separately and run on demand. The service also provides a built-in authentication provider that integrates with Azure AD, GitHub, Twitter, etc.
Key Components
Static Content: HTML, CSS, JavaScript, images, fonts. Served via CDN with caching headers.
Serverless APIs: Azure Functions (HTTP triggers) for backend logic. They run in the same region as the app.
Authentication: Built-in authentication using social providers (GitHub, Twitter) or Azure AD. No need to write auth code.
Custom Domains: Map your own domain with automatic TLS/SSL certificates.
Staging Environments: Each pull request creates a temporary staging environment with a unique URL.
Routing: Define custom routes for API calls and fallback rules.
Configuration and Defaults
Build Configuration: The service expects a build configuration file (staticwebapp.config.json) in the root of your app. This file controls routing, security, and response headers.
Default Index Document: index.html
API Directory: By default, the API folder is named 'api' at the root. You can change this.
App Location: The folder containing the static content. Default is the root of the repository.
Output Location: The folder where the build output is placed (e.g., 'dist' or 'build').
CDN: Uses Azure CDN from Microsoft with a default TTL of 3600 seconds for static assets.
Authentication: You can configure allowed roles and routes in the config file.
Verification Commands
Deploy via CLI: az staticwebapp create -n MyApp -g MyRG -l eastus2 -s https://github.com/MyRepo -b main --app-location "/" --api-location "api" --output-location "dist"
List Static Web Apps: az staticwebapp list
Show Details: az staticwebapp show -n MyApp
Delete: az staticwebapp delete -n MyApp
Interaction with Related Technologies
Azure Functions: The API backend is an Azure Functions app (Consumption plan) that is automatically created and linked to the static web app. You can use any language supported by Functions.
Azure CDN: Static content is delivered via Azure CDN from Microsoft. You can configure custom caching rules.
Azure AD: You can use Azure AD as an identity provider for authentication, which allows integration with enterprise Single Sign-On.
Key Vault: You can reference secrets from Key Vault in your static web app configuration.
Application Insights: Not integrated by default, but you can enable it for the Functions backend.
Step-by-Step Deployment Process
Repository Setup: Connect your GitHub or Azure DevOps repository.
Build Configuration: Create staticwebapp.config.json for routing and security.
Azure Static Web Apps Resource: Create the resource in Azure portal or via CLI.
GitHub Action/DevOps Pipeline: Automatically created; you can customize the build step.
Deployment: On push, the pipeline builds and deploys.
Verify: Access the provided URL.
Important Values and Defaults
Region: Choose a region; content is distributed globally via CDN.
SKU: Free or Standard. Free includes 1 custom domain, 100 GB bandwidth, 500 MB storage. Standard includes 5 custom domains, 500 GB bandwidth, 2 GB storage, and SLA.
Authentication Providers: Azure AD, GitHub, Twitter, Facebook, Google.
Role-based access: Define routes with allowed roles.
Custom 404 page: Can be specified in config.
Response headers: Can be set globally or per route.
Common Exam Scenarios
Deploying a React app: Set output-location to 'build'.
Securing API routes: Use allowedRoles in config.
Custom domain: Add a CNAME record pointing to the default domain.
Staging environments: PR previews automatically created.
Using Azure Functions: Write HTTP-triggered functions in the api folder.
Trap Patterns
Wrong output location: If you set output-location to the root, the build artifacts may conflict with source files.
Misconfigured API directory: If the API folder is not at the expected path, functions won't be deployed.
CORS issues: Static Web Apps automatically handles CORS for its own domain, but if you call external APIs, you need to configure CORS there.
Authentication redirect: After login, the user is redirected to the page they were on, but you must handle the redirect in your app.
Edge Cases
Client-side routing: For SPAs, you need a fallback route to index.html.
Large static sites: Consider using Azure CDN custom rules to optimize caching.
Private endpoints: Not supported; Static Web Apps is a public service.
WebSocket: Not supported; use Azure SignalR Service separately.
Conclusion
Azure Static Web Apps simplifies hosting modern web applications by combining static hosting with serverless APIs, authentication, and global CDN. It is ideal for Jamstack applications and is a key service for AZ-204 exam candidates to understand.
Create Azure Static Web App
First, you create an Azure Static Web Apps resource in the Azure portal or via CLI. You specify the resource group, name, region, and SKU (Free or Standard). During creation, you link to a GitHub or Azure DevOps repository and specify the branch to deploy from. The service then creates a GitHub Action or Azure DevOps pipeline in your repository. This pipeline will automatically build and deploy your app on every push to the specified branch. The creation process also sets up an Azure Functions backend if you have an api folder.
Configure Build Settings
You must configure the build settings in the staticwebapp.config.json file placed in the root of your repository. This file defines routing rules, authentication settings, response headers, and fallback routes. For example, you can set a custom 404 page, define allowed roles for specific routes, and configure redirects. The build process also uses the app-location, api-location, and output-location parameters to know where your source code and build artifacts are. These can be set during resource creation or in the pipeline.
Push Code to Repository
When you push code to the configured branch (e.g., main), the GitHub Action or Azure DevOps pipeline triggers. The pipeline runs the build command specified in the workflow (e.g., npm run build). It then deploys the static files from the output-location to Azure Storage, which is fronted by Azure CDN. The serverless functions in the api-location are deployed as an Azure Functions app. The entire process takes a few minutes. You can monitor the pipeline run in the repository's Actions tab.
Access the Deployed App
After deployment, the app is accessible via a default URL like https://<appname>.<region>.azurestaticapps.net. The static content is served from the CDN edge nodes, ensuring low latency for users worldwide. The serverless API endpoints are available under /api. The app automatically handles HTTPS with a managed certificate. You can also configure a custom domain by adding a CNAME record pointing to the default domain. The service then provisions a TLS certificate for the custom domain.
Manage Staging Environments
When you create a pull request in the repository, Azure Static Web Apps automatically creates a staging environment with a unique URL like https://<pr-number>.<appname>.<region>.azurestaticapps.net. This allows you to preview changes before merging. The staging environment is a full deployment of the app with its own functions. You can add labels to the pull request to control which environments are created. Once the PR is merged, the staging environment is deleted, and the main branch is deployed.
Enterprise Scenario 1: Marketing Landing Pages
A large retail company uses Azure Static Web Apps to deploy hundreds of marketing landing pages. Each campaign team works on a separate branch and uses pull request previews to review the page before going live. The static content includes HTML, CSS, and JavaScript, with forms handled by Azure Functions. The company uses Azure AD for authentication to restrict access to internal stakeholders during review. The service automatically scales to handle traffic spikes during product launches. The main challenge is managing multiple custom domains for each campaign, which is handled by the Standard SKU that supports up to 5 custom domains per app. The team uses staticwebapp.config.json to set caching headers for optimal performance.
Enterprise Scenario 2: Documentation Portal
A SaaS company hosts its product documentation on Azure Static Web Apps. The documentation is built using a static site generator (Docusaurus) and includes a search function powered by Azure Functions that queries Azure Cognitive Search. The app uses GitHub Actions to rebuild on every commit. The company leverages the built-in authentication to provide different docs for free vs. premium users based on roles. The global CDN ensures fast load times for customers worldwide. A common pitfall is misconfiguring the fallback route for client-side routing, which they solved by adding a custom 404 rule that serves index.html.
Enterprise Scenario 3: E-commerce Storefront
A startup builds a Jamstack e-commerce frontend with React and a serverless backend using Azure Functions for cart and checkout. They use Static Web Apps for the frontend and deploy the functions in the same repo. The app integrates with Stripe for payments via a function. They use the Free SKU initially, then upgrade to Standard for SLA and more bandwidth. The team encountered issues with CORS when calling external APIs, which they resolved by configuring the external API to allow the static web app's domain. They also use staging environments to test new features before pushing to production. The service's automatic SSL and custom domain setup saved them significant time.
What AZ-204 Tests on This Topic
The exam objective 1.3 focuses on creating and managing Azure Static Web Apps. Specifically, you need to know how to:
Create a static web app resource using Azure CLI, PowerShell, or portal.
Configure build settings (app-location, api-location, output-location).
Set up custom domains and manage TLS certificates.
Configure authentication and authorization using built-in providers.
Integrate with Azure Functions for serverless APIs.
Manage staging environments (pull request previews).
Understand the difference between Free and Standard SKUs.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong: Static Web Apps can host any type of web app including ASP.NET. - *Why chosen:* Candidates confuse Static Web Apps with App Service. Static Web Apps is only for static content and serverless functions. ASP.NET requires a server runtime. 2. Wrong: You must manually configure a CDN for static content. - *Why chosen:* Candidates think CDN is separate. Actually, Static Web Apps automatically uses Azure CDN from Microsoft. 3. Wrong: Staging environments are only available in Standard SKU. - *Why chosen:* Many Azure services reserve advanced features for paid tiers. But staging environments (PR previews) are available in Free SKU as well. 4. Wrong: Custom domains require manual SSL certificate management. - *Why chosen:* In other services like App Service, you often need to upload certificates. Static Web Apps automatically provisions and manages TLS for custom domains.
Specific Numbers and Terms on the Exam
Free SKU limits: 1 custom domain, 100 GB bandwidth, 500 MB storage, 1 staging environment.
Standard SKU limits: 5 custom domains, 500 GB bandwidth, 2 GB storage, 10 staging environments, SLA of 99.95%.
Default index document: index.html.
Configuration file: staticwebapp.config.json.
Authentication providers: Azure AD, GitHub, Twitter, Facebook, Google.
API directory default: 'api'.
Output location common values: 'dist', 'build', 'public'.
Edge Cases and Exceptions
Client-side routing: Must configure a fallback route to index.html for SPAs.
API routes: The /api prefix is reserved for Azure Functions. You cannot route static content to /api.
Private endpoints: Not supported.
WebSocket: Not supported.
Large file uploads: Limited by Functions timeout and request size.
How to Eliminate Wrong Answers
If the question mentions hosting a .NET application, eliminate Static Web Apps (use App Service).
If the question mentions WebSocket or SignalR, eliminate Static Web Apps.
If the question mentions private network integration, eliminate Static Web Apps.
If the question mentions custom SSL certificate upload, Static Web Apps does not support that (it auto-manages).
If the question mentions staging environments, remember Free SKU includes 1 staging environment.
Azure Static Web Apps is for static content and serverless APIs only; not for server-side rendered apps.
Built-in authentication supports Azure AD, GitHub, Twitter, Facebook, and Google.
Each pull request automatically creates a staging environment with a unique URL.
Custom domains are automatically provisioned with TLS certificates.
Free SKU includes 1 custom domain, 100 GB bandwidth, 500 MB storage, and 1 staging environment.
Standard SKU includes 5 custom domains, 500 GB bandwidth, 2 GB storage, 10 staging environments, and 99.95% SLA.
Configuration is done via staticwebapp.config.json in the repository root.
The /api route is reserved for Azure Functions; you cannot serve static content there.
These come up on the exam all the time. Here's how to tell them apart.
Azure Static Web Apps
Static content + serverless functions only
Built-in global CDN
Built-in authentication providers
Automatic staging environments per PR
Free SKU available with limited features
Azure App Service (Web Apps)
Full web application hosting (any runtime)
No built-in CDN (must add separately)
Authentication via App Service Authentication
Deployment slots (not automatic per PR)
No free tier (only Basic and above)
Mistake
Azure Static Web Apps can host server-side rendered applications like ASP.NET Core.
Correct
Static Web Apps only hosts static content (HTML, CSS, JS) and serverless functions (Azure Functions). For server-side rendered apps, use Azure App Service.
Mistake
You need to configure a separate CDN for Azure Static Web Apps.
Correct
Static Web Apps automatically uses Azure CDN from Microsoft for global distribution. No additional configuration is needed.
Mistake
Staging environments (pull request previews) are only available in the Standard SKU.
Correct
Staging environments are available in both Free (1 environment) and Standard (up to 10 environments) SKUs.
Mistake
Custom domains require you to upload and manage SSL certificates.
Correct
Azure Static Web Apps automatically provisions and manages TLS certificates for custom domains. You only need to add a DNS CNAME record.
Mistake
You can use any backend language for the API, not just JavaScript.
Correct
The API is powered by Azure Functions, which supports C#, Java, Python, Node.js, and PowerShell. You are not limited to JavaScript.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Set the output-location to 'build' (or 'dist' for Angular). Ensure your build script outputs to that folder. The service will run npm run build during deployment. Also set app-location to the root (if package.json is at root) or the folder containing package.json.
Yes. Add a CNAME record in your DNS provider pointing to the default domain (e.g., <appname>.azurestaticapps.net). Then configure the custom domain in the Azure portal or CLI. The service will automatically provision a TLS certificate.
In staticwebapp.config.json, define routes under the 'routes' array and set 'allowedRoles' to an array of roles (e.g., ['authenticated']). Then configure authentication providers in the portal. Only users with the specified roles can access those routes.
Free SKU includes 1 custom domain, 100 GB bandwidth, 500 MB storage, 1 staging environment, and no SLA. Standard SKU includes 5 custom domains, 500 GB bandwidth, 2 GB storage, 10 staging environments, and 99.95% SLA.
Yes. Azure Functions supports C#, Java, Python, Node.js, and PowerShell. You can use any of these in your api folder.
In staticwebapp.config.json, add a catch-all route that serves index.html for all paths that don't match a file. Example: { "route": "/*", "serve": "/index.html" }.
No. Azure Static Web Apps is a public service and does not support private endpoints or VNet integration. For private networking, use App Service with VNet integration.
You've just covered Azure Static Web Apps — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?