Part 2: Build an Azure Compute Selector

Deploy a web app and container, then build an Azure compute selection dashboard.

Introduction

30 Second Summary

Azure compute questions can feel like a wall of similar service names. The challenge is choosing the option that fits when a workload needs different levels of control or scaling.

In this project, you will build an Azure portal dashboard that turns compute terminology into decisions you can explain. You will support those decisions with a managed web app in Azure App Service plus a public sample container in Azure Container Instances.

What You'll Build

Your finished dashboard lets you demo two live endpoints before defending the best compute choice for each workload.

By the end of this project, you'll have:

A managed web app demo that opens in your browser from Azure App Service.
A container demo with a public sample page plus its browser request recorded in Logs.
A compute decision dashboard that distinguishes seven Azure options by control, scaling, and workload fit.
Secret Mission: Recommend and defend a mixed Azure compute design for a retailer with web, event-driven, legacy, and remote desktop needs.

Are there any prerequisites?

You need an active Azure subscription with permission to create and delete resources.

You will work in Microsoft Edge or Google Chrome without any local development tools.

Before We Start

Your Azure subscription and browser give you everything needed for the hands-on work. First, commit to building a compute service selector that matches each workload to the right balance of control, management, and scaling.

Set Up the Compute Decision Dashboard

Every hands-on result needs a home beside the service-selection decision it teaches. Without one visual workspace, the compute options can blur into disconnected facts.

A dashboard in the Azure portal keeps each result beside its decision. In this step, you'll create a private dashboard with a Markdown tile that frames every later comparison.

In this step, get ready to:

Access Dashboard in the signed-in Azure portal.
Create a private dashboard named AZ-900 Compute Service Selector.
Add an introductory Markdown tile with the compute decision question.

Why a Dashboard Instead of Flashcards?

The dashboard keeps deployment evidence beside each service decision inside the portal you use throughout the lab. Reopening one page for revision makes comparisons faster than rebuilding context from separate flashcards.

Sign in and open Dashboard

In Microsoft Edge or Google Chrome, navigate to the Microsoft Azure portal.
Sign in with the account connected to your active Azure subscription.
Select Dashboard from the Azure portal navigation.

You should see the Dashboard page in the Azure portal.

Cannot Reach Dashboard?

Confirm that your browser is signed in with the account connected to your active Azure subscription.
Select Dashboard again from the Azure portal navigation.

Help me troubleshoot Azure portal sign-in or Dashboard access. You can also describe what you see to the NextWork community.

Create and save the private dashboard

Azure makes every new dashboard private by default. A clear name gives you one reliable place for the evidence you collect throughout this project.

Select Create on the Dashboard page.
Select Custom.
Enter AZ-900 Compute Service Selector as the dashboard name.
Select Save.

That's your study workspace in place. The saved private dashboard now has a clear home for every compute decision.

Add the Markdown decision question

Markdown turns the dashboard into a decision worksheet. A consistent question gives each later tile the same comparison lens.

Select Edit in the dashboard toolbar.
Locate Markdown in the Tile Gallery.
Select Add for the Markdown tile.
Select Inline editing.
Enter Compute Service Decision as the tile title.
Enter Which compute service gives this workload the right balance of control, management, and scaling? below the title.
Select Done.
Select Save in the dashboard editor.

Before you reopen the dashboard, think about the two pieces of text you expect on its introductory tile.

Return to Dashboard from the Azure portal navigation.
Select AZ-900 Compute Service Selector from your dashboards.

You should see the saved private dashboard with an introductory Markdown tile. The tile should show Compute Service Decision above Which compute service gives this workload the right balance of control, management, and scaling?.

You've built the study anchor for the whole project. Each later deployment now has a clear question to answer.

Tile Missing After Save?

Select Done in Inline editing to keep the tile content.
Select Save in the dashboard editor to keep the tile on the dashboard.

Help me restore my Markdown tile.

Your compute selector dashboard is ready. Next up, you'll launch a managed web app with Azure App Service and place the first hosting model in your decision workspace.

Launch a Platform-Managed Web App

Your Azure portal dashboard now anchors each compute decision in one workspace. The next proof point needs to be a page you can open in your browser.

Azure App Service provides managed web hosting through PaaS. Its platform runs a web endpoint without asking you to configure a virtual machine.

In this step, get ready to:

Create an App Service web app in a dedicated resource group.
Configure the web app for managed Linux hosting on Free F1.
Capture the working App Service result on your decision dashboard.

Why PaaS for This App?

An individual VM gives you full control of the operating system. That control also makes you responsible for managing the operating system.

App Service manages the hosting platform for this web endpoint. Your dashboard note records that management trade-off.

Create the web app resource

A resource group keeps related Azure resources together. The web app name must be globally unique.

In the Azure portal from earlier, select Create a resource.
Select Web.
Select Web App.

You'll see the form where Azure collects the web app's resource details.

Use the Resource group field to create rg-az900-compute-lab.
Give the app a globally unique name that follows az900-compute-<your-initials>-<four-digits>.

Configure managed hosting

Each setting defines how App Service hosts the web app. Together, these choices create a managed Linux environment for application code.

Set Publish to Code.
Set Runtime stack to .NET 8 (LTS).

The form now pairs code-based publishing with the .NET 8 (LTS) runtime.

Set Operating System to Linux.
Set Region to Central US.

The form now places the Linux web app in Central US.

Pricing plan choices can feel risky. Free F1 keeps this web app on the project's free App Service plan.

Set Pricing plan to Free F1.
Select Review + Create.

The review page summarizes the web app configuration before Azure creates any resources.

Provisioning can take a few minutes while Azure creates the App Service plan plus the web app. A short wait here is normal.

Select Create.
After the deployment finishes, select Go to resource.

Good progress. Azure has created the managed web app without requiring you to provision a VM.

App Service Deployment Not Completing?

If Azure rejects the app name, change the initials or four digits so the name becomes unique.
If Free F1 cannot be selected in Central US, stop before choosing another plan.

Help me diagnose my App Service deployment.

Prove the PaaS result

The Default domain is the browser address for your web app. Opening it proves that the managed hosting platform is already responding.

Before you open the endpoint, consider whether managed hosting can return a page before you deploy application code.

Select the URL under Default domain.

You'll see a placeholder page confirming that the web app is running and ready for application code.

That's a real milestone. Your first live PaaS endpoint is responding through a public browser address.

Switch back to the App Service resource tab.
Use the pin control on the resource page to pin the App Service resource to AZ-900 Compute Service Selector.

The pinned resource keeps your live deployment beside the compute decision it demonstrates.

Switch back to the AZ-900 Compute Service Selector dashboard from earlier.
Select Edit.
Locate Markdown in the Tile Gallery.
Select Add.
Choose Inline editing.
Enter Azure App Service: PaaS managed web hosting in the editor.
Select Done.
Select Save.

Before you check the finished dashboard, consider which two pieces of evidence should connect the deployment to the hosting decision.

Refresh the saved dashboard.

You'll see the pinned App Service resource beside the Markdown note identifying it as PaaS managed web hosting.

Your managed web app is live with its hosting model recorded on the dashboard. Next, you'll run the same idea as a container to compare the two hosting models.

Run the Same Idea as a Container

Your Azure portal dashboard already shows a live Azure App Service endpoint. That page proves managed PaaS can put a web app online without a virtual machine.

Azure Container Instances runs a standalone container without requiring you to configure a VM. You will use it to launch another browser-visible page.

Fast deployment answers only one part of the hosting decision. How much scaling support and traffic distribution does this option include?

In this step, get ready to:

Create an Azure Container Instances container group from a Quickstart image.
Open the sample page and find its browser request in the container Logs.
Record the service limitations and stop the container group.

Create the container group

This resource is billed by the second while it runs. The project keeps the billed window short because you stop the group after the demo.

Select Create a resource in the Azure portal from earlier.
Select Containers.
Select Container Instances.

The creation wizard now shows the settings that define your container group.

Choose the existing rg-az900-compute-lab resource group.
Enter az900-container as the container name.
Choose Quickstart images as the image source.
Select mcr.microsoft.com/azuredocs/aci-helloworld:latest as the image.
Select Linux as the operating system.
Set Availability zones to None.

What Does This Configuration Prove?

The Quickstart image gives you a known Linux workload. Its browser result makes the hosting model easy to verify.

The DNS label gives the group a fully qualified domain name that your browser can reach.

Select the Networking page.
Enter your regionally unique DNS name label as the DNS name label.
Set DNS name label scope reuse to Tenant.
Select Review + create.
Select Create after validation passes.
Keep the deployment page open until provisioning finishes.

You should see the container group reach a Running status.

Container Not Reaching Running?

Choose a different DNS name label if Azure reports that the current one is unavailable.
Confirm that the selected image exactly matches mcr.microsoft.com/azuredocs/aci-helloworld:latest.

Help me troubleshoot the container deployment.

Prove the container can serve traffic

Opening the FQDN sends an HTTP request to the container. The Logs provide evidence that the workload received that browser request.

Select Go to resource from the completed deployment page.
Select the link shown under FQDN on the container group Overview page.

You should see the public sample page in your browser. That is your second live hosting model working.

Switch back to the az900-container resource tab.
Select Containers under Settings.
Select Logs.

You should see the browser's HTTP GET request in the Logs. This proves that traffic reached the running container.

Browser Request Missing from Logs?

Refresh the public sample page to generate another request.
Return to Logs after refreshing the page.
Confirm that you are viewing the container inside az900-container.

Help me find the browser request in the container Logs.

Record the limits and stop the group

The sample page proves that the standalone container can serve traffic. The remaining decision depends on its built-in operational support.

Before you check the comparison, do you think this service includes autoscaling and a built-in load balancer?

Open the official Azure compute comparison.
Locate Container Instances in the compute comparison.

You will see autoscaling listed as Not supported. You will see its load balancer listed as No built-in support.

The Scaling Gap Is Real

Azure Container Instances delivers the standalone container you just tested. Its scaling and load-balancing limits make it a poor fit when demand must trigger automatic growth or built-in traffic distribution.

Your dashboard can now preserve the working result beside the limitation it revealed.

Return to the AZ-900 Compute Service Selector dashboard from earlier.
Select Edit.
Locate Markdown in the Tile Gallery.
Select Add.
Choose Inline editing.

The empty Markdown tile is ready for your Container Instances decision evidence.

Enter Container Instances as the tile title.
Describe rapid standalone container deployment as the service strength.
Record autoscaling as Not supported.
Record load balancing as No built-in support.
Select Done.
Select Save.

Your dashboard now captures both sides of the container decision. It shows rapid deployment alongside the exact operational limits.

Stop the Running Charges

Azure Container Instances bills running container groups by the second. Stopping the group recycles its containers and deallocates their resources.

The container group remains available in the portal after billing stops.

Switch back to the az900-container resource.
Select Overview in the left menu.
Select Stop at the top of the Overview page.

Before you check the result, which status do you expect to confirm that the container group is no longer running?

Wait for the Status value to update on the Overview page.

You should see the Status change to Stopped. The runtime billing for this container group has now stopped.

Status Not Changing to Stopped?

Refresh the Overview page after the stop operation has had time to finish.
Confirm that the selected resource is az900-container.

Help me troubleshoot a container group that is not reaching Stopped.

You have now tested a live container and documented its scaling gap. Next up, you will match that gap to purpose-built Azure compute services.

Match Workloads to Scaling Services

Your stopped Azure Container Instances group proved that a standalone container can serve a public page. Its missing autoscaling capability now needs a service-selection answer.

Managed web applications fit Azure App Service because Azure manages the hosting platform. Trigger-driven execution fits Azure Functions because Azure manages serverless execution.

OS-controlled horizontal scaling fits Azure Virtual Machine Scale Sets. You keep responsibility for the operating systems.

In this step, get ready to:

Inspect the Azure Function App creation wizard without deploying a resource.
Compare three workload signals with their management trade-offs.
Add a Scaling Fix tile to your compute decision dashboard.

Inspect the Function App wizard

Azure Functions provides managed FaaS for code that runs in response to triggers. Its serverless model removes server management from the execution path.

You stay in inspection mode here. Leaving before the final deployment action keeps rg-az900-compute-lab unchanged.

Return to the Azure portal tab from earlier.
Select Create a resource.

You should see the page for choosing an Azure service to create.

Select Get started.
Under Function App, select Create.

You should see the plan choices for a new Function App.

Choose Flex Consumption.
Select Select.

You should see the Basics page for a Function App using Flex Consumption.

Why Flex Consumption?

Flex Consumption is the recommended Azure plan for hosting serverless compute resources. It provides rapid horizontal scaling for trigger-driven workloads.

The wizard also reveals how much configuration Azure manages before any application code exists.

Inspect the Basics page to identify the core app details requested by the wizard.
Inspect the Storage page to identify the storage choices shown for your subscription.

The first two pages cover the application identity plus its backing storage choices.

Inspect the Monitoring page to identify the available monitoring choices.
Inspect the Authentication page to identify the available access choices.

The remaining pages show how observability plus access controls fit into the managed service.

Before you check, predict whether a Function App now exists in the resource group.

Leave the wizard by using your browser's back control.
Return to rg-az900-compute-lab from earlier.
Inspect the resource list for a Function App.

You should see no Function App in the resource group. Your existing App Service web app remains unchanged.

The az900-container container group also remains Stopped.

Seeing a Function App resource?

A Function App only appears if the deployment completed. Open the unexpected resource to confirm its resource group before taking further action.

Ask for help before deleting anything from a shared subscription: Help me check whether this Function App came from the wizard inspection.

Compare the three scaling patterns

A scaling decision starts with the workload signal. The management boundary shows what Azure handles for you.

How does the management boundary change?

Azure App Service is managed PaaS. Azure manages the web hosting platform while you focus on the application.

Azure Functions runs code from triggers. Azure manages the execution environment plus its scaling behavior.

Azure Virtual Machine Scale Sets use an IaaS model. Azure manages the VM group mechanics while you manage each VM operating system.

Match managed web applications to Azure App Service.
Match trigger-driven event execution to Azure Functions.
Match OS-controlled VM group scaling to Azure Virtual Machine Scale Sets.

You now have one service for each scaling pattern. Each choice reflects a different level of operational responsibility.

Build the Scaling Fix tile

Your dashboard turns the comparison into a reusable decision rule. A Markdown tile keeps each workload signal beside its management trade-off.

Return to the AZ-900 Compute Service Selector dashboard from earlier.
Select Edit.

The dashboard should now show its editing controls plus the Tile Gallery.

Locate Markdown in the Tile Gallery.
Select Add.

You should see a new Markdown tile on the dashboard.

Choose Inline editing.
Enter Scaling Fix as the tile title.

The tile editor now has a clear label for the decision model.

Add the managed web application signal with Azure App Service as its service.
Add Azure-managed hosting as the trade-off for that mapping.

The tile now contains its first complete workload decision.

Add the trigger-driven execution signal with Azure Functions as its service.
Add Azure-managed execution plus scaling as the trade-off for that mapping.

The tile now separates managed web hosting from event-driven execution.

Add the OS-controlled horizontal scaling signal with Azure Virtual Machine Scale Sets as its service.
Add customer-managed operating systems plus applications as the trade-off for that mapping.

The editor now contains all three workload signals. Each signal has a service plus its management trade-off.

Select Done.
Select Save.

Before you review the saved tile, predict the service that belongs beside each workload signal.

Review the Scaling Fix tile from top to bottom.

You should see managed web applications mapped to Azure App Service. You should see trigger-driven execution mapped to Azure Functions.

You should see OS-controlled horizontal scaling mapped to Azure Virtual Machine Scale Sets. Every mapping should include its management trade-off.

Confirm that the existing App Service content remains on the dashboard.
Confirm that the existing Container Instances note remains on the dashboard.

The App Service content should remain visible. The Container Instances note should still show Not supported for autoscaling.

It should also show No built-in support for load balancing.

Missing the Scaling Fix tile?

Return to the AZ-900 Compute Service Selector dashboard from earlier.
Select Edit to restore the Markdown tile.
Select Save after restoring the tile.

Need another pair of eyes: Help me troubleshoot my missing Scaling Fix tile.

Strong work. Your Scaling Fix tile now turns three workload signals into defensible compute choices.

Next up, you will separate individual VMs from scalable VM groups. You will also map failure isolation plus virtual desktop delivery.

Map the VM Family and Desktop Option

Your scaling comparison is now saved in the Azure portal dashboard. Next, you will complete the selector with server control options.

Compute questions become easier when each option maps to one clear need. This step separates one controllable server from a scalable group.

You will also map failure isolation. Windows desktop delivery completes the picture.

In this step, get ready to:

Inspect a server creation form without deploying a resource.
Distinguish the four server control and desktop workload patterns.
Complete the dashboard with seven distinct compute choices.

Inspect the Virtual machine creation experience

Azure Virtual Machines give you full control over the operating system. They also give you full control over the applications running on that system.

This wizard can create a billed VM: your walkthrough stops before deployment.

Enter virtual machines in the Azure portal search bar.
Select Virtual machines from the search results.
Select Create.
Select Virtual machine.
Locate Virtual machine name to identify where the server receives its resource name.
Locate Image to identify where you choose the operating system.
Locate Administrator account to identify where you configure administrative access.

What do these choices reveal?

A virtual machine uses an IaaS model. Azure manages the physical infrastructure.

You manage the guest operating system. The image plus administrator settings show how much control stays with you.

Locate Inbound port rules to identify where network access is configured.
Locate Auto-shutdown to identify where scheduled shutdown can be configured.
Return to the Azure portal home page without selecting Create.

Can't find a VM field?

Azure portal layouts can vary by subscription. Check the available creation pages for the field name shown above.

Keep the wizard unsubmitted while you search. Help me locate the VM creation fields

Compare the VM family and desktop roles

The VM family separates server control from capacity management. It also separates capacity management from failure isolation.

Return to Dashboard in the Azure portal.
Select AZ-900 Compute Service Selector.
Select Edit.
Locate Markdown in the Tile Gallery.
Select Add.
Choose Inline editing.

Build the four-way map

Azure Virtual Machines provide full OS and application control.
Azure Virtual Machine Scale Sets manage scalable groups of VMs.
Availability sets isolate related VMs across fault domains.
Azure Virtual Desktop delivers full Windows desktops or individual applications.

Add the four comparisons above to the Markdown tile.
Select Done.
Select Save.

Good progress. Your dashboard now separates individual VM control from scalable VM groups.

You should also see distinct choices for fault-domain isolation and Windows desktop delivery.

Missing the comparison tile?

Confirm that you selected Done before saving the dashboard. Unsaved inline edits do not remain on the tile.

Check that all four options have their own labeled entry. Help me fix my Azure dashboard comparison tile

Complete the seven-option selector

A complete decision dashboard needs application hosting choices beside the VM family. Each option should point to a distinct workload signal.

Select Edit on the dashboard.
Locate Markdown in the Tile Gallery.
Select Add.
Choose Inline editing.

Complete the hosting side

Azure App Service fits managed web hosting.
Azure Container Instances fits standalone containers.
Azure Functions fits event-driven execution.

Add the three hosting comparisons above to the Markdown tile.
Select Done.
Select Save.

Pause for a prediction about whether the VM wizard created a resource. Also predict how many service choices your dashboard now covers.

Return to the rg-az900-compute-lab resource group.
Review its resource list for any Virtual Machine, Virtual Machine Scale Set, availability set, Azure Virtual Desktop resource, or Function App.

You should see the existing App Service web app plus the stopped az900-container group. You should see no VM, scale set, availability set, Azure Virtual Desktop resource, or Function App.

Return to Dashboard.
Select AZ-900 Compute Service Selector.
Review the saved tiles for seven distinct service choices.

What should you see?

Azure Virtual Machines provide full OS and application control.
Azure Virtual Machine Scale Sets manage scalable VM groups.
Availability sets isolate related VMs across fault domains.
Azure Virtual Desktop delivers full Windows desktops or individual applications.
Azure App Service provides managed web hosting.
Azure Container Instances runs standalone containers.
Azure Functions handles event-driven execution.

That completes your decision map. You can now separate all seven compute options without creating paid VM or desktop resources.

Secret mission

Defend a Multi-Workload Compute Design

A retailer needs several compute models across one architecture. Build a Retail Compute Recommendation tile that selects and defends the right Azure service for each workload.

Clean Up Your Resources

Your container workload is currently paused without active billing. Decide whether to keep the lab available, leave it paused, or delete it entirely.

Cost warning

The stopped Azure Container Instances group is no longer billed. Restarting it resumes billing by the second.

The Free F1 Azure App Service app has no ongoing Azure resource charge.

The private AZ-900 Compute Service Selector dashboard in the Azure portal also has no resource charge unless you publish it as a shared dashboard.

The Pause and Delete options prevent future container charges.

Resources you used:

The private AZ-900 Compute Service Selector dashboard.
The rg-az900-compute-lab Azure resource group.
The az900-compute-<your-initials>-<four-digits> Azure App Service web app.
The Linux App Service plan using Free F1.
The stopped az900-container Azure Container Instances container group.

Keep everything running

No action is needed. Choose this option if you want to keep the dashboard available for revision or future demonstrations.

Leave the AZ-900 Compute Service Selector dashboard saved.
Leave the Free F1 web app running.
Keep az900-container stopped between demonstrations.
Start the container group again only when you want to demonstrate its sample page.

A running container group resumes per-second billing.

Pause - I'll come back to this later

Your project is already in its paused state because the container group is stopped.

Return to the az900-container container group from earlier.
Confirm that its Status remains Stopped.
Leave the Free F1 web app unchanged.
Leave the AZ-900 Compute Service Selector dashboard saved.

Your study aid stays available for revision. The container remains free of active runtime billing.

Delete - I don't want to use this again

Deleting the resource group and dashboard is permanent. The cleanup is contained to the lab resources listed above.

Return to rg-az900-compute-lab from earlier.
Select Delete resource group.
Enter rg-az900-compute-lab.
Select Delete.
Return to your resource group list.

You should no longer see rg-az900-compute-lab. Its web app, App Service plan, and container group have been removed.

Return to the AZ-900 Compute Service Selector dashboard from earlier.
Select Delete.
Select OK in the confirmation dialog.
Return to Dashboard in the Azure portal.

You should no longer see AZ-900 Compute Service Selector in your dashboards.

Nice Work!

Mission accomplished! Your AZ-900 Compute Service Selector now pairs two live hosting examples with a seven-service decision model.

You've learned how to:

Deployed a live Azure App Service endpoint on Free F1. You used its placeholder page to demonstrate managed PaaS web hosting.
Ran a public sample page with Azure Container Instances. You found the browser's HTTP request in its container logs. You stopped the container group to stop billing.
Built a reusable seven-service decision dashboard for AZ-900 scenarios. It maps trigger-driven work to Azure Functions. It maps OS-controlled scaling to Azure Virtual Machine Scale Sets. It distinguishes individual server control with Azure Virtual Machines. It records failure isolation with availability sets. It records desktop delivery with Azure Virtual Desktop.
Completed the Secret Mission by defending a four-service retail design. You chose Azure Virtual Machines for the legacy Windows application. You chose Azure App Service for the campaign website. You chose Azure Functions for upload-triggered image processing. You chose Azure Virtual Desktop for remote contractor access. Each recommendation includes a rejected alternative. Each recommendation explains the management trade-off.

Ready to quiz yourself?