Create and Configure Azure App Service (AZ-104)

Azure App Service is a fully managed platform as a service (PaaS) for hosting web applications, REST APIs, and mobile back ends. You bring your code or a container image and Azure runs it on managed infrastructure, patching the OS, load balancing, and providing HTTPS endpoints, so you never manage a virtual machine.

Every app runs on an App Service plan, and understanding this relationship is the key to the whole topic. The plan represents the set of compute resources (VMs) that host your apps: its operating system, region, and pricing tier. The plan is what you pay for; apps themselves add no separate compute charge. Multiple apps can share a single plan, in which case they share that plan's CPU, memory, and instances; if one app is busy, the others feel it.

You provision a plan when you create your first app, or ahead of time from Create a resource > App Service Plan, choosing the operating system (Windows or Linux), region, and pricing tier. That tier choice is the single most important decision here, because it determines how much power each instance has, how many instances you can run, whether apps share hardware with other customers, and which features (autoscale, deployment slots, custom TLS, backups, and network isolation) you can use at all.

App Service plans come in a ladder of pricing tiers, and each unlocks more resources and features. On the exam you match a requirement to the lowest tier that supports it.

Two dividing lines matter most. First, Free and Shared run on shared infrastructure, so your app sits on VMs alongside other customers' apps and cannot autoscale, while Basic and above run on dedicated VMs. Second, several exam-favorite features have a minimum tier: custom TLS bindings need Basic, and autoscale, deployment slots, and scheduled backups all need Standard or higher. Isolated adds an App Service Environment (ASE) for full network isolation inside your own virtual network. When a question asks for the cheapest tier that supports deployment slots, the answer is Standard; for autoscale, also Standard.

App Service scales in two independent directions, and telling them apart is one of the most reliably tested points in this domain.

Scale up (vertical scaling) means moving to a higher pricing tier so each instance gets more CPU, memory, and features, for example going from B1 to P1v3. You do it under Scale up (App Service plan), and it also unlocks capabilities like slots or backups that a lower tier lacked.

Scale out (horizontal scaling) means adding more instances that each run a copy of your app, spreading load across them. You do it under Scale out (App Service plan), either by setting a manual instance count or by configuring autoscale rules. Autoscale (Standard tier and above) adjusts the instance count automatically based on a metric, such as CPU percentage, memory, or HTTP queue length, or on a schedule, for example running more instances during business hours.

On the exam, change to a bigger tier for more power is scale up; add more instances to handle load is scale out; and automatically add instances when CPU is high is an autoscale rule, which requires Standard or above.

With a plan in place, you create the app itself. From Create a resource > Web App, you name the app (its default hostname becomes <name>.azurewebsites.net) and select the App Service plan (new or existing), region, and operating system.

The important choice is the Publish option, which sets how your app is packaged:

• Code means you deploy application code and pick a runtime stack such as .NET, Node.js, Python, Java, or PHP. App Service provides and maintains the runtime.
• Container means you deploy a custom container image (for example from Azure Container Registry), giving you full control over the runtime and dependencies. This runs on a Linux plan.

After creation you deploy your app through any supported method: continuous deployment from GitHub or Azure DevOps, ZIP deploy, a container registry pull, or local Git. You manage settings such as application settings and connection strings in the app's Configuration blade. Because App Service is PaaS, you never touch the underlying VM; you only manage the app and its configuration. The remaining tasks in this lesson (certificates, custom domains, backups, networking, and deployment slots) are all configured on this web app resource once it exists.

By default your app answers on <name>.azurewebsites.net over HTTPS. To use your own domain and certificate, you configure two related things: the custom domain and the TLS/SSL binding.

Mapping a custom DNS name. Under Custom domains > Add custom domain, you point your domain at the app through your DNS provider. You add a CNAME record pointing your subdomain (for example www) to <name>.azurewebsites.net, or an A record to the app's inbound IP for a root or apex domain. To prove you own the domain, you also add a TXT verification record (an asuid value Azure supplies). Custom domains require at least the Shared tier, and a TLS binding requires Basic or higher.

Certificates and TLS. You have several options for the certificate that secures the domain: a free App Service managed certificate, which Azure creates and auto-renews for your custom domain; a certificate you bring yourself by uploading a PFX file; or one imported from Azure Key Vault. You then create a TLS/SSL binding that ties the certificate to the custom domain (typically SNI-based). Finally, turn on the HTTPS Only setting so any HTTP request is redirected to HTTPS, and optionally raise the minimum TLS version. On the exam, a free auto-renewing certificate is the App Service managed certificate, and forcing secure traffic is the HTTPS Only toggle.

Deployment slots are the standout App Service feature, and the exam loves them. A slot is a live app running in the same plan with its own hostname and configuration, for example a staging slot alongside production. Slots are available on Standard (up to 5) and Premium (up to 20) tiers.

The point of a slot is the swap. You deploy a new version to staging, let its instances warm up, and test it on the staging hostname. When you are satisfied, you swap staging with production: Azure exchanges the two slots' running instances so the warmed-up build instantly becomes production with zero downtime. If something is wrong, you swap back to roll back just as quickly.

Some settings should not move during a swap. You mark app settings and connection strings as deployment slot settings ("sticky" settings) so they stay with their slot: for instance, a staging database connection string stays on staging and never follows the app into production. Settings not marked as sticky swap along with the app.

Admin scenario. You must release a new version of a busy production web app with no outage. You deploy the build to the staging slot, verify it on the staging URL, and then perform a swap with production, so users move to the new, already-warm instances seamlessly. A defect appears in production, so you immediately swap back, restoring the previous version. That test-in-staging-then-swap pattern is the exam's canonical zero-downtime deployment.

Two more admin tasks round out App Service configuration: backups and networking.

Backup. App Service can take scheduled or on-demand backups of your app to an Azure Storage account, including the app's configuration, file content, and a connected database, and restore them to the same or a new app. Backup is available on Standard tier and above; you configure it under the app's Backups blade, choosing the storage account, a schedule, and a retention period. Free, Shared, and Basic plans do not offer built-in backups, so a scenario that requires scheduled backups implies at least Standard.

Networking. App Service networking splits by direction. For outbound traffic, meaning your app calling into private resources such as a database or storage account in a virtual network, you enable VNet integration, which lets the app reach resources inside a VNet. For inbound traffic you control who can reach the app: access restrictions are IP-based allow and deny rules, and a private endpoint gives the app a private IP inside your VNet and removes its public exposure entirely. On AZ-104 you configure these at a recognition level (VNet integration for outbound, access restrictions and private endpoints for inbound), while the deeper virtual-network mechanics belong to the networking domain. Together, backups and these network controls make an App Service production-ready.