The "create and configure Azure App Service" item in the AZ-104 skills outline has eight entries: provision an App Service plan, configure scaling for the plan, create an App Service, configure certificates and TLS, map an existing custom DNS name, configure backup, configure networking settings, and configure deployment slots. Plans and deployment slots were covered in an earlier article, but scaling, certificates, custom domains, and backup were barely touched. The exam especially likes to ask "What's the minimum tier needed to use this feature?"
This article covers the tasks you run into while operating App Service: the features each plan tier unlocks, scaling up and scaling out (autoscale and automatic scaling), the DNS records for custom domains, choosing a TLS certificate, automatic and custom backups, and networking settings for inbound and outbound traffic. The basics of App Service plans and deployment slots are in Mastering Azure Containers and App Service.
---
The Plan Tier Decides Which Features You Get
Upgrading a phone plan doesn't just add data; it also unlocks features such as tethering or international roaming. App Service plans work the same way: the tier (pricing tier) changes not only performance but also which features you can use. Free and Shared share VMs with other customers' apps, Basic and above run on dedicated VMs, and Isolated v2 also isolates the virtual network.
!Features unlocked as the App Service plan tier goes up
| Tier | Maximum instances | Key features first unlocked at this tier | |------|------|------| | Free · Shared | 1 shared (can't scale out) | For dev and test; Free can't use custom domains | | Basic | 3 dedicated | TLS for custom domains, backup, VNet integration, private endpoints | | Standard | 10 dedicated | Autoscale, 5 deployment slots | | Premium (v2, v3, v4) | 30 dedicated | 20 deployment slots, automatic scaling (based on HTTP traffic), larger instances | | Isolated v2 | 100 dedicated | App Service Environment, network isolation |
Apps in one plan share the same VM instances, so scaling the plan up or adding instances affects every app in that plan.
Exam tip: "The app is on a Basic plan and needs deployment slots" means scaling up to Standard or higher. "Add instances automatically based on CPU usage" also needs Standard or higher.
---
Scaling Up and Scaling Out
When a restaurant gets busy, moving the kitchen to a bigger space and hiring more cooks are different solutions. In App Service, the first is scaling up and the second is scaling out.
| Method | What it does | What to remember | |------|------|------| | Scale up | Changes the plan's tier or size (CPU, memory, disk, extra features) | Scale up when you lack a feature | | Manual scale out | Sets the instance count directly | Basic and higher | | Autoscale (Azure autoscale) | Adjusts the instance count with rules based on metrics (CPU, memory, request count) or schedules | Standard and higher; define minimum, maximum, and default instances plus scale-out and scale-in rules | | Automatic scaling | The platform adjusts based on HTTP traffic, no rules needed | Premium v2–v4, maximum burst up to 30, not supported for deployment slot traffic |
Autoscale rules should come in pairs: one to scale out and one to scale in. With only a scale-out rule, instances never shrink when load drops, and costs keep running.
Exam tip: "Increase to 5 instances every Monday at 9 a.m. and drop to 2 at 6 p.m." is schedule-based autoscale. "Add one instance when CPU is above 70%" is a metric-based rule, and it needs a matching scale-in rule (for example, below 30%).
---
Mapping a Custom Domain
An App Service app gets an appname.azurewebsites.net address by default. To use your company domain (www.contoso.com), create records in the domain's public DNS zone and add the domain in App Service. The Free tier can't use custom domains, and private DNS zones aren't supported.
| Name to map | Record to create | Value | |------|------|------| | Subdomain (www.contoso.com) | CNAME | appname.azurewebsites.net | | Subdomain ownership verification | TXT (asuid.www) | The app's domain verification ID | | Root domain (contoso.com) | A | The app's IP address (don't use CNAME for the root) | | Root domain ownership verification | TXT (asuid) | The app's domain verification ID |
The domain verification ID in the TXT record prevents subdomain takeover, where someone else maps the same subdomain to their own App Service app. You can use an A record for a subdomain, but the app's IP can change, so CNAME is recommended.
Exam tip: "Map the contoso.com root domain" means an A record plus an asuid TXT record; "www.contoso.com" means a CNAME plus an asuid.www TXT record. An option that creates a CNAME at the root domain is wrong.
---
TLS Certificates and HTTPS
To serve HTTPS on a custom domain, you bind a certificate to the app, which requires Basic or higher. There are four ways to get a certificate.
| Method | Cost | Characteristics | |------|------|------| | App Service managed certificate | Free | Renews automatically; no wildcard, can't be exported, not supported in App Service Environment | | App Service certificate | Purchased | Managed by Azure, wildcard available, can be renewed and exported | | Import from Key Vault | Depends on the certificate | When you manage certificates centrally in Key Vault | | Upload a private certificate | Depends on the certificate | A PFX file bought from another certificate authority |
Choose a binding type: SNI SSL (Basic and higher, unlimited) or IP SSL (one included from Standard) Turning on HTTPS Only redirects HTTP requests to HTTPS Set a minimum TLS version to reject connections that use older TLS versions A managed certificate for a root domain requires the app to be reachable from the internet during creation and renewal, so IP restrictions can make it fail
Exam tip: "A free *.contoso.com wildcard certificate" is an impossible requirement. The free managed certificate doesn't support wildcards, so buy an App Service certificate or import one from Key Vault.
---
Backup and Restore
App Service backup is supported in the Basic, Standard, Premium, and Isolated tiers, and comes in two kinds.
| Item | Automatic backup | Custom backup | |------|------|------| | Configuration | None needed; runs hourly on its own | You configure it with a storage account | | Size | 30 GB | 10 GB (up to 4 GB of which can be a linked database) | | Linked database | Not backed up | Some databases supported (support ends March 31, 2028) | | Frequency | Hourly, not configurable | Scheduled (as often as hourly on Premium) or manual | | Retention | 30 days, not configurable | 0–30 days or indefinite | | Download | Not possible | Downloadable as blobs |
You can restore a backup by overwriting an existing app or by restoring to a new app or slot. On the Basic tier, only the production slot can be backed up and restored.
Exam tip: "Download the backup files and keep them for 90 days" means custom backups. Automatic backups can't change their retention and can't be downloaded.
---
Networking: The Way In and the Way Out
App Service networking is much less confusing once you separate the directions. Features that control traffic coming into the app are different from features for traffic the app sends out.
| Direction | Feature | What it does | |------|------|------| | Inbound | Access restrictions | Allow or deny rules by IP address, service endpoint, or service tag (up to 512 per app) | | Inbound | Private endpoint | Reach the app over a private IP in the VNet; Basic and higher | | Outbound | Virtual network integration | Lets the app reach resources inside the VNet (VMs, private endpoints, and so on); Basic and higher; needs a dedicated, delegated subnet | | Outbound | Hybrid connections | Reaches a specific on-premises host and port through a relay |
Virtual network integration is outbound only, so on its own it doesn't give private access from the VNet to the app. You can attach an NSG and a UDR to the integration subnet to control the app's outbound traffic.
Exam tip: "The app must reach a SQL Server VM in the VNet over its private IP" means VNet integration; "hide the app from the internet and allow access only from the VNet" means a private endpoint (plus blocking public access). The two work in opposite directions and can't replace each other.
---
Exam Quick Reference
Key points to check one last time before the exam.
| Topic | What to remember | |------|------| | Free · Shared | Shared VMs, no scale out; Free can't use custom domains | | Basic | 3 dedicated; custom domain TLS, backup, VNet integration, private endpoints | | Standard | 10 dedicated; autoscale; 5 deployment slots | | Premium | 30 dedicated; 20 slots; automatic scaling | | Scale up vs scale out | Change tier or size vs change instance count; every app in the plan is affected | | Autoscale rules | Pair a scale-out rule with a scale-in rule | | Subdomain | CNAME + TXT asuid.subdomain | | Root domain | A + TXT asuid; no CNAME at the root | | Managed certificate | Free, auto-renewing; no wildcard, not exportable | | SNI vs IP SSL | Unlimited from Basic vs one included from Standard | | Automatic vs custom backup | Hourly, fixed 30 days, no download vs storage account, chosen retention, downloadable | | VNet integration vs private endpoint | Traffic out of the app vs traffic into the app |
---
Next Steps
With App Service operations covered, revisit how it differs from the container services in Mastering Azure Containers and App Service, and continue to AZ-104 Look-Alike Services: A Side-by-Side Comparison for review right before the exam.
Knowing "from which tier is this feature available?" solves half of the App Service questions. Picture the tier table as you work through App Service questions in the AZ-104 practice exam.