This chapter covers Azure Mobile Apps, a service within Azure App Service that enables you to build and host mobile app backends with built-in capabilities for offline sync, authentication, and push notifications. For the AZ-900 exam, this topic falls under Domain 3: Azure Management and Governance, Objective 3.4: Describe Azure management and governance features. Mobile Apps is a specific service you need to recognize as part of Azure App Service, and questions may test your understanding of its key features and use cases. This objective area carries approximately 10–15% of the exam weight, so while not dominant, you should be familiar with the core capabilities of Mobile Apps.
Jump to a section
Imagine a regional sales team that needs to access customer data, update orders, and sync files while traveling. Before the cloud, each salesperson carried a briefcase with paper records and a USB drive. Every night, they'd return to the office to hand over their USB drive to IT, who would manually merge updates into the central database. This was slow, error-prone, and if a salesperson lost their USB drive, data was gone. Now, think of Azure Mobile Apps as giving each salesperson a 'smart briefcase' that automatically syncs with the main office via a secure radio channel. When a salesperson updates an order on their phone, the change is instantly sent to a central cloud database (Azure SQL Database or Cosmos DB) and also cached locally on the device. If the network drops, the app continues working offline, queueing changes locally. Once connectivity returns, the app syncs all queued changes automatically, resolving conflicts using a 'last writer wins' rule. The briefcase never loses data because the cloud is the authoritative copy. Developers build these smart briefcases using Azure App Service (the backend) and client SDKs that handle authentication, offline sync, and push notifications. The mechanism: a mobile client SDK communicates with a mobile app backend hosted on Azure App Service, which connects to data storage and enterprise systems. The SDK manages a local SQLite database for offline data and uses a sync engine to reconcile with the cloud when online.
What is Azure Mobile Apps and What Business Problem Does It Solve?
Azure Mobile Apps is a feature of Azure App Service that provides a fully managed backend for mobile applications. It solves the business problem of building and maintaining server-side infrastructure for mobile apps that require user authentication, data synchronization across devices, offline capabilities, and push notifications. Without Mobile Apps, developers would need to build these features from scratch, handle server scaling, manage security, and deal with complex synchronization logic. Mobile Apps abstracts these challenges, allowing developers to focus on the client-side app experience.
How It Works: Step-by-Step Mechanism
Backend Hosting: The mobile app backend is hosted as a Web App within Azure App Service. You can write the backend code in .NET, Node.js, or other supported languages. The backend exposes RESTful APIs that the mobile client calls.
Client SDK Integration: On the mobile client (iOS, Android, Xamarin, or Windows), you integrate the Azure Mobile Apps client SDK. This SDK handles communication with the backend, manages offline data storage, and provides authentication helpers.
Authentication: Mobile Apps integrates with Azure Active Directory, Facebook, Google, Twitter, and Microsoft Account for authentication. The client SDK triggers a login flow, and the backend validates the token. This eliminates the need to build custom authentication.
Offline Sync: The client SDK automatically maintains a local SQLite database on the device. When the app is online, it syncs data with the backend. When offline, the app reads/writes to the local store. The sync engine tracks changes using a system properties like __updatedAt and __version. On reconnection, it pushes local changes and pulls remote changes. Conflicts are detected and can be handled with strategies like client wins or server wins.
Push Notifications: Mobile Apps integrates with Azure Notification Hubs. The backend can send push notifications to specific devices or users. The client registers its device token with Notification Hubs via the Mobile Apps SDK.
Scalability: Because the backend runs on Azure App Service, it can scale out (more instances) or up (larger instances) automatically or manually. The data layer (Azure SQL Database or Cosmos DB) also scales independently.
Key Components, Tiers, and Pricing
Azure App Service Plan: The underlying compute resources. Tiers: Free (F1), Shared (D1), Basic (B1–B3), Standard (S1–S3), Premium (P1–P3), and Isolated. For production mobile apps, Standard or Premium is recommended for features like custom domains, SSL, and auto-scaling.
Mobile Apps Feature: Enabled on the App Service by creating a Mobile App resource. No additional cost beyond the App Service plan and any connected services (e.g., SQL Database, Notification Hubs).
Azure SQL Database or Cosmos DB: Backend data storage. Cosmos DB is often preferred for mobile because of its global distribution and flexible schema.
Notification Hubs: Separate service with its own pricing tiers (Free, Basic, Standard).
Comparison to On-Premises Equivalent
On-premises, building a mobile backend would require:
Purchasing and configuring servers.
Installing a web server (IIS) and database server (SQL Server).
Implementing authentication (e.g., Active Directory Federation Services).
Building offline sync logic (often using custom conflict resolution).
Setting up push notification infrastructure (e.g., Windows Push Notification Services).
Managing scaling manually (adding more servers).
With Azure Mobile Apps, all these are handled by the platform. You only write the business logic code. The cloud provides automatic patching, scaling, and high availability.
Azure Portal and CLI Touchpoints
Portal:
Create a Mobile App resource: Azure portal > Create a resource > Mobile > Mobile App.
Configure authentication: Under Settings > Authentication / Authorization.
Configure offline sync: Under Settings > Data Connections.
Manage push notifications: Under Settings > Push.
CLI:
Create a Mobile App:
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name myMobileApp --runtime "DOTNET|6.0"Enable authentication:
az webapp auth update --resource-group myResourceGroup --name myMobileApp --enabled true --action LoginWithAzureActiveDirectory --aad-allowed-token-audiences https://myMobileApp.azurewebsites.netView logs:
az webapp log tail --resource-group myResourceGroup --name myMobileAppConcrete Business Scenarios
Field Service: Technicians use a mobile app to view work orders, update job status, and capture signatures. Offline sync ensures they can work in basements or rural areas. Push notifications alert them of urgent jobs.
Retail Inventory: Store associates scan items using a mobile app that syncs inventory data. The backend updates central ERP. Offline sync prevents data loss during store network outages.
Healthcare: Doctors use a mobile app to access patient records and prescribe medications. Authentication via Azure AD ensures HIPAA compliance. Offline sync allows access in areas with poor connectivity.
Common Pitfalls
Not planning for conflict resolution: If two users update the same record offline, conflicts arise. Default 'last writer wins' may not be acceptable for some scenarios.
Overlooking offline sync setup: Developers must enable offline sync on the backend and configure the client SDK properly. Otherwise, the app will fail when offline.
Ignoring scalability: The App Service plan must be sized appropriately for expected load. A Free tier plan will throttle requests.
Exam Relevance
For AZ-900, you need to know that Azure Mobile Apps is a feature of Azure App Service, not a separate service. It provides:
- Authentication (multiple identity providers) - Offline data sync - Push notifications - Scalable backend You should also know that it uses Azure SQL Database or Cosmos DB for storage, and Notification Hubs for push notifications. Questions may ask: "Which Azure service provides built-in offline sync for mobile apps?" Answer: Azure Mobile Apps (part of App Service).
Create a Mobile App Backend
In the Azure portal, search for 'Mobile App' and click Create. You'll need to specify a resource group, App Service plan, and runtime stack (.NET or Node.js). Behind the scenes, Azure creates a Web App with the Mobile Apps feature enabled. This Web App acts as your backend API. The App Service plan determines the compute resources (CPU, memory) and features like custom domains and auto-scaling. For production, choose Standard or higher. After creation, you can access the backend via the URL https://<your-app>.azurewebsites.net.
Configure Authentication
In the Mobile App resource, under Settings > Authentication / Authorization, enable App Service Authentication. Choose one or more identity providers (Azure AD, Facebook, Google, Twitter, Microsoft Account). For each provider, you must provide the client ID and secret from the provider's developer console. When a user logs in from the mobile app, the client SDK redirects to the provider's login page. The backend validates the token and returns an authentication token for subsequent API calls. This eliminates the need to write custom authentication code.
Set Up Offline Data Sync
On the backend, you need to enable offline sync by adding the appropriate NuGet package (for .NET) and configuring a connection to a database (Azure SQL or Cosmos DB). The client SDK automatically creates a local SQLite database. You must define a sync context and a sync table. The SDK tracks changes using system properties like `__updatedAt`. When online, it pulls changes from the server and pushes local changes. If the network is unavailable, the app continues to work with local data. On reconnection, the sync engine runs. Conflicts can be handled by subscribing to the `MobileServiceSyncHandler` event.
Implement Push Notifications
First, create an Azure Notification Hubs resource. Then, in the Mobile App backend, under Settings > Push, configure the connection to the Notification Hubs. On the client, register the device for push notifications using the platform-specific notification service (e.g., Firebase Cloud Messaging for Android, Apple Push Notification Service for iOS). The client SDK sends the device token to the backend, which registers it with Notification Hubs. To send a notification, your backend code calls the Notification Hubs SDK. You can target specific users or devices using tags.
Test and Deploy the Mobile App
Use the Azure portal's App Service Editor or deploy via Git, FTP, or CI/CD pipelines (Azure DevOps, GitHub Actions). For testing, you can run the mobile client app on an emulator or physical device. The client SDK communicates with the backend URL. Monitor logs using `az webapp log tail` or the portal's Log Stream. Check for authentication failures, sync errors, or push notification delivery issues. Scale out the App Service plan if performance is insufficient. Remember that the Free tier has CPU quotas, so it's not suitable for load testing.
Scenario 1: Field Service Management for a Utility Company A utility company deploys a mobile app for field technicians to view work orders, update job status, and capture photos of equipment. The app needs to work in remote areas with intermittent connectivity. The team creates an Azure Mobile App backend with offline sync enabled. They use Azure SQL Database to store work orders and Cosmos DB for flexible schema for photos metadata. Authentication is set up with Azure AD so that only company employees can log in. Push notifications alert technicians of urgent jobs. The system handles thousands of technicians. Scaling is managed by setting the App Service plan to Standard with auto-scaling rules based on CPU usage. A common mistake is not testing offline sync thoroughly; if the sync conflict resolution is not configured, data loss can occur. The company uses a 'client wins' strategy for simple updates and a custom conflict handler for critical fields like job status.
Scenario 2: Retail Inventory Management A retail chain uses a mobile app for store associates to scan inventory barcodes and update stock levels. The app must sync data to a central ERP system. They use Azure Mobile Apps with offline sync to ensure that even if the store's Wi-Fi goes down, associates can continue scanning. The backend uses Cosmos DB for its low-latency reads and writes. Authentication is integrated with Azure AD B2C for customer-facing apps and Azure AD for employees. Push notifications are used to alert managers when stock of popular items is low. The App Service plan is set to Premium to ensure consistent performance during peak shopping seasons. A pitfall is not setting up proper conflict resolution; if two associates scan the same item offline, the last update may overwrite a correct count. The team implements a 'server wins' policy for inventory counts to ensure data integrity.
Scenario 3: Healthcare Patient Portal A hospital provides a mobile app for patients to view lab results, schedule appointments, and message their doctor. The app must be HIPAA compliant. They use Azure Mobile Apps with Azure AD for authentication, ensuring only verified patients access their data. Offline sync allows patients to view results even without internet. The backend uses Azure SQL Database with transparent data encryption. Push notifications remind patients of upcoming appointments. The App Service plan is deployed in an Isolated tier for network isolation and compliance. A common issue is not configuring the authentication token expiration correctly, causing users to be logged out frequently. The team sets a longer token lifetime and implements silent token refresh.
Exam Objective 3.4: Describe Azure management and governance features Within this objective, Azure Mobile Apps is a specific service you need to recognize. The exam may ask: 'Which Azure service provides built-in offline sync for mobile applications?' or 'Which Azure service can be used to add authentication to a mobile app backend?' The correct answer is Azure Mobile Apps (part of App Service).
Common Wrong Answers and Why Candidates Choose Them 1. Azure API Management: Candidates confuse API Management with Mobile Apps because both expose APIs. However, API Management is for managing, securing, and analyzing APIs, not for mobile-specific features like offline sync. API Management does not provide client SDKs for offline data. 2. Azure Notification Hubs: Candidates think push notifications are the only feature of Mobile Apps. Notification Hubs is a component used by Mobile Apps, but it is not the mobile backend itself. Mobile Apps includes authentication, offline sync, and more. 3. Azure Logic Apps: Candidates confuse Logic Apps (workflow automation) with Mobile Apps because both can integrate with other services. Logic Apps is for orchestrating business processes, not for building mobile backends. 4. Azure Functions: Candidates think Azure Functions can replace Mobile Apps because both can host APIs. While Functions can be used for mobile backends, they lack built-in offline sync and authentication integration. Mobile Apps provides these out-of-the-box.
Specific Terms and Values - Offline sync uses a local SQLite database. - Authentication providers: Azure AD, Facebook, Google, Twitter, Microsoft Account. - Push notifications use Azure Notification Hubs. - Backend runs on Azure App Service (Web App).
Edge Cases and Tricky Distinctions - The exam may present a scenario where an app needs to work offline and ask which Azure service provides that capability. The answer is Azure Mobile Apps, not Azure SQL Database (which is just storage). - Another scenario: 'You need to add authentication to a mobile app without writing custom code.' Answer: Azure Mobile Apps (or Azure App Service Authentication). - The exam might ask about the data store: 'Which data store is commonly used with Mobile Apps for offline sync?' Answer: Azure SQL Database or Cosmos DB. The local store is SQLite.
Memory Trick Think MAP: Mobile Apps provides Mobile backend, Authentication, and Push notifications. Offline sync is the 'A' (always available).
Azure Mobile Apps is a feature of Azure App Service for building mobile backends.
Key capabilities: authentication, offline sync, and push notifications.
Offline sync uses a local SQLite database on the device and syncs with the cloud backend.
Authentication supports Azure AD, Facebook, Google, Twitter, and Microsoft Account.
Push notifications require Azure Notification Hubs.
Backend data can be stored in Azure SQL Database or Cosmos DB.
The client SDK handles communication, offline data, and authentication flows.
These come up on the exam all the time. Here's how to tell them apart.
Azure Mobile Apps
Built-in offline sync with local SQLite database
Integrated authentication for multiple identity providers
Push notifications via Notification Hubs
Backend hosted on Azure App Service (Web App)
Client SDK for iOS, Android, Xamarin, Windows
Azure API Management
No built-in offline sync; it's an API gateway
Authentication policies but no client SDK integration
No push notification capability
Sits in front of APIs, not a hosting service
Used for managing, securing, and analyzing APIs
Mistake
Azure Mobile Apps is a separate standalone service from Azure App Service.
Correct
Azure Mobile Apps is a feature of Azure App Service. When you create a Mobile App resource, you are actually creating a Web App with the Mobile Apps feature enabled. It is not a separate service category.
Mistake
Offline sync stores data on the server when offline.
Correct
Offline sync stores data locally on the device using a SQLite database. When the device is offline, the app reads and writes to this local database. Once connectivity is restored, changes are synced with the backend.
Mistake
Push notifications are built into Mobile Apps without any additional service.
Correct
Mobile Apps integrates with Azure Notification Hubs for push notifications. You must create a Notification Hubs resource and configure it within the Mobile App backend.
Mistake
Mobile Apps can only use Azure SQL Database for storage.
Correct
Mobile Apps can use either Azure SQL Database or Azure Cosmos DB as the backend data store. Cosmos DB is often preferred for mobile apps due to its global distribution and flexible schema.
Mistake
Authentication in Mobile Apps requires writing custom code.
Correct
Azure App Service Authentication provides built-in authentication for multiple identity providers. You can enable it with a few clicks in the portal, without writing custom code. The client SDK handles the login flow.
Azure Mobile Apps is a feature of Azure App Service that provides a fully managed backend for mobile applications. It is not a separate service; it is a Web App with additional capabilities like offline sync, authentication, and push notifications. When you create a Mobile App resource, you are essentially creating an App Service Web App with these features pre-configured. The difference from a regular Web App is that Mobile Apps includes client SDKs and server-side libraries that simplify mobile development. For the exam, remember that Mobile Apps is part of App Service, not a standalone service.
Offline sync works by maintaining a local copy of data in a SQLite database on the mobile device. The client SDK tracks changes using system properties like `__updatedAt` and `__version`. When the device is online, the SDK pulls changes from the backend and pushes any local changes. If offline, the app reads and writes to the local database. When connectivity returns, the sync engine runs: it first pushes local changes to the server, then pulls server changes. Conflicts are detected if the same record was modified both locally and on the server. The default conflict resolution is 'last writer wins', but you can customize it. For the exam, know that offline sync uses SQLite locally and Azure SQL or Cosmos DB on the backend.
Azure Mobile Apps supports Azure Active Directory, Facebook, Google, Twitter, and Microsoft Account. You can enable one or more providers in the Azure portal under Authentication / Authorization. The client SDK handles the login flow by redirecting to the provider's login page. The backend validates the token and returns an authentication token for subsequent API calls. No custom code is needed. For the exam, remember that Azure AD is the enterprise option, and the other providers are for consumer apps.
Yes, you can use Azure Functions to build a mobile backend, but you would miss out on built-in features like offline sync, client SDK integration, and built-in authentication. Azure Functions is a serverless compute service that can host REST APIs, but you would need to implement offline sync, authentication, and push notifications yourself. Azure Mobile Apps provides these out-of-the-box, saving development time. For the exam, if a question asks for a service that provides offline sync and authentication for mobile apps, the answer is Azure Mobile Apps, not Azure Functions.
Azure Mobile Apps is a backend service for mobile apps that includes features like authentication, offline sync, and the ability to send push notifications. Azure Notification Hubs is a separate service that handles the delivery of push notifications to various platforms (iOS, Android, Windows). Mobile Apps integrates with Notification Hubs to send push notifications. You cannot use Notification Hubs alone to build a mobile backend; it is just for push notifications. For the exam, know that Mobile Apps uses Notification Hubs for push, but they are different services.
Azure Mobile Apps can use Azure SQL Database or Azure Cosmos DB as the backend data store. Azure SQL Database is a relational database, while Cosmos DB is a NoSQL database. Cosmos DB is often preferred for mobile apps because of its low latency, global distribution, and flexible schema. The local store on the device is always SQLite. For the exam, know that both Azure SQL and Cosmos DB are supported, but the local store is SQLite.
Azure Mobile Apps itself does not have an additional cost beyond the underlying Azure App Service plan and any connected services. The App Service plan has a Free tier (F1) that includes 1 GB of storage and 60 minutes of CPU per day, but it is not suitable for production. For production, you need at least a Basic or Standard plan, which incurs costs. Additionally, if you use Azure SQL Database or Cosmos DB, you pay for those resources separately. Notification Hubs also has its own pricing. So while there is no direct cost for the Mobile Apps feature, the overall solution is not free.
You've just covered Azure Mobile App — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?