AZ-DEV-100: Building Web Applications with Azure App Service

Note: This lab pre-provisions an empty resource group at start — allow up to 3 minutes for it to become ready before beginning the exercises.

Provision the Anchorline storefront's baseline yourself: a Standard S1 Linux App Service Plan and a .NET 10 Web App with the storefront's required site config (HTTPS-only, TLS 1.3, HTTP/2, FTPS disabled, Always On, /health probe, System-Assigned Managed Identity). Then deploy the ASP.NET Core 10 starter scaffold, verify it's live over HTTPS, and observe what changes when you scale the plan from S1 to Premium V3 and back. By the end you will have deployed a real running workload — and can defend every configuration choice you made.

Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.

Wire the Anchorline Outdoors storefront to real secrets and centralized configuration. You will inspect the pre-provisioned Key Vault and App Configuration store, deploy the starter app so it reads the Stripe API key via a Key Vault reference (managed-identity-authenticated, no code path), toggle the Beta.FallDiscount feature flag in App Configuration and watch the app pick it up live via the sentinel-key refresh pattern, and add a new secret + cascade it through both surfaces. By the end you will have a defensible answer for where every Anchorline config value should live and how it flows from Azure to your process.

Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.

Ship the Anchorline Outdoors storefront from GitHub with OIDC federated identity — zero publish-profile secrets in the repo. You will inspect the pre-provisioned user-assigned managed identity (which holds Website Contributor on the Web App), sign in to Azure and GitHub, create a fresh GitHub repo of your own, push the starter to it, configure a federated credential on the UAMI that trusts your fork's main branch, watch your first push deploy the app, then introduce a bad commit and roll back via a workflow re-run on the prior tag. By the end you will have muscle memory for the entire OIDC deploy pipeline pattern.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Add a staging slot to the Anchorline storefront and use it to ship a change safely. You will inspect the pre-provisioned Web App + staging slot, deploy the starter to the staging slot, warm it up + smoke-test its /version endpoint, swap it to production with a single command, then introduce a deliberately broken change and reverse-swap in 30 seconds to recover. Same App Service Plan compute; dramatically different risk profile.

Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.

Watch autoscale react to real load on the Anchorline storefront. You will inspect the pre-provisioned PremiumV3 plan + autoscale settings + Service Bus queue, deploy the starter, load-test with hey to drive CpuPercentage above 70% and watch instance count climb from 2 to 4, run the producer script to push 500 messages into the queue and watch the ActiveMessageCount rule fire, then let both metrics settle and observe scale-in.

Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.

Wire the Anchorline storefront to a private-endpoint SQL database. You will inspect the pre-provisioned VNet + private endpoint + private DNS zone, seed a Products table via sqlcmd from the container, deploy the starter and confirm /products returns rows over the private path, verify /dns shows a private IP for the SQL hostname, then add an access restriction that blocks direct hits on the app's public hostname.

Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.

Wire the Anchorline storefront to four Azure services using a single system-assigned managed identity. You will inspect the identity's role assignments across Storage, Key Vault, SQL (Entra admin), and Cosmos DB; deploy the app; verify each endpoint reads its target service without any connection string in code; then break one role assignment and observe the exact 401/403 signature so you can recognize it in production.

Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.

Harden the Anchorline storefront's TLS posture on its default *.azurewebsites.net hostname. You will inspect the intentionally-weak baseline (TLS 1.2, no HSTS, no HTTP/3), raise minTlsVersion to 1.3 and verify with openssl, disable FTPS, add UseHsts() middleware to Program.cs and confirm the header is emitted, and turn on HTTP/3 with az CLI + verify with curl --http3.

Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.

Instrument the Anchorline storefront with Application Insights auto-instrumentation, then layer code-based OpenTelemetry for custom metrics and traces. Run a load generator, then use KQL against the Log Analytics workspace to find slow endpoints, correlate exceptions with request IDs, and calculate P95 latency. Finally, wire a metric alert on P95 latency with an Action Group that would page an on-call engineer.