Create and Configure Azure App Service for AZ-104

This part of AZ-104 is about App Service as an administrative platform, not as an application-development framework. Microsoft expects you to know how plans and apps relate, how scaling and networking settings affect operations, and how slots, TLS, and backups reduce deployment and recovery risk.

What Microsoft is explicitly testing

The current study guide includes:

• provisioning an App Service plan
• configuring scaling for an App Service plan
• creating an App Service
• configuring certificates and TLS
• mapping an existing custom DNS name
• configuring backup
• configuring networking settings
• configuring deployment slots

The plan-versus-app boundary is the core distinction

Many AZ-104 misses happen because candidates blend the plan and the app together.

If the prompt is really about pricing tier, region, scaling, or shared compute, think plan first. If it is about the website or app behavior, think app first.

App Service admin chooser

App Service operational frame

AZ-104 is testing whether you can keep the platform administration clean:

• know whether the change belongs to the plan or the app
• understand that slots are for safer deployment flow, not just duplication
• treat TLS and custom DNS as admin tasks, not optional polish
• know that backups help recovery but do not automatically create a complete disaster-recovery design

Bicep example: plan and app boundary

This example shows the distinction Microsoft likes to test.

 1resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
 2  name: 'app-plan'
 3  location: resourceGroup().location
 4  sku: {
 5    name: 'P1v3'
 6    capacity: 1
 7  }
 8  kind: 'linux'
 9  properties: {
10    reserved: true
11  }
12}
13
14resource app 'Microsoft.Web/sites@2023-12-01' = {
15  name: 'examdemo-web'
16  location: resourceGroup().location
17  properties: {
18    serverFarmId: plan.id
19    httpsOnly: true
20  }
21}

What to notice:

• the plan is the compute boundary that controls scale tier and region
• the app attaches to that plan and carries workload-specific behavior
• httpsOnly belongs to the app-level operational posture, not to the abstract idea of “having a website”

Deployment slots are a release-control feature

Slots matter on AZ-104 because they reduce release risk without forcing a full production cutover every time.

    flowchart LR
	  B["New build"] --> S["Staging slot"]
	  S --> V["Validate config, TLS, and app behavior"]
	  V --> W["Swap into production"]

The lesson is simple: a slot is not just another app copy. It is a safer deployment path that lets you validate before production traffic takes the new version.

Networking and backup reminders

App Service questions often combine platform administration with practical operations:

• if the prompt mentions custom hostname or certificate, stay on the app surface
• if it mentions plan scaling, focus on the plan boundary first
• if it mentions networking settings, think about the app’s connectivity posture rather than generic VNet theory
• if it mentions backup, remember that this is an app-level recovery feature, not a full substitute for broader business continuity design

Common traps

• changing the app when the requirement is really about the plan
• treating deployment slots as if they were just extra copies with no deployment purpose
• assuming a valid app deployment automatically implies correct TLS or DNS configuration
• describing backups as if they automatically solve every recovery requirement

Quiz

The next domain is Virtual Networking, where these compute surfaces start interacting with real connectivity, DNS, and security constraints.