What you hand over, and what you keep
Part A chose a paid plan: the workers and features. Now create an App Service app on that plan. The app is the website or API you deploy; the plan supplies its compute. Azure maintains the underlying host and can distribute requests across plan instances. Your team still owns the code, dependencies, data, identities, settings, and tests.
Follow one storefront release through this class. First put a new build in a staging slot. Then check how it reaches the database, bind a domain and TLS certificate, and keep secrets out of source code. These are four different decisions, and each has a failure mode you can test.
Deployment slots — a warm copy you swap in
A deployment slot is another running version of the app, with its own address, on the same plan workers. Standard and higher support slots. Deploy the new code to staging, use safe test data, check checkout and health, then swap to promote it. App Service warms the source under the target slot's configuration before it changes routing. The former production version remains available in the other slot for a swap-back if needed.1 Slots reduce release interruption; you still monitor production after promotion.
An app setting normally moves with the swapped app. A slot setting stays with its environment. Mark each environment's database connection as a slot setting so production keeps its production destination and staging keeps its test destination. Verify both settings before and after the swap. A slot swap reverses application versions; it cannot reverse a database migration or transactions already written. Plan those changes separately.
Stage and verify. Pin environment settings. Swap and observe.
Play it through
This simulation asks you to choose a release path for a store that is serving shoppers. It models the slot swap; it does not measure a live application's availability.
Practice later: App Service plan and slot swap uses the same small sample app as Class 11 Part A, so there is no new code to write. It creates billable Azure resources. Review its cleanup, deploy to staging, check the application, swap, verify production, and test the swap-back path.
Custom domains and TLS you did not have to buy
An app is born with an azurewebsites.net hostname, which is fine for a demo and wrong for a storefront. Adding a custom domain is a two-step proof: you add a DNS record at your registrar that shows you control the name, and App Service verifies it. Once verified, the app answers on your own domain — and then it needs a certificate, because a storefront on plain HTTP is a storefront a browser flags as unsafe.
For a supported custom domain, a free App Service Managed Certificate can provide and automatically renew the TLS certificate while its DNS and other prerequisites remain valid. It does not support wildcards and has other limitations.2 Bind the certificate, enable HTTPS Only, and test both the secure address and an HTTP redirect. A redirect still starts with an HTTP request; use HSTS where appropriate so returning browsers use HTTPS directly. Monitor certificate status rather than assuming renewal can never fail.
Configuration — settings and secrets outside the code
App settings are named values delivered to the running app as environment variables; a connection string tells it how to reach a database or another service. Keep environment-specific values out of the code so the same build can run in staging and production. Settings alone are not a substitute for access control: people with sufficient app permissions may be able to change them, and your code could accidentally log their values.
Prefer passwordless managed identity when the database supports it. If a secret is needed, a Key Vault reference puts a pointer in the app setting; App Service resolves it using an identity that must have permission to read the secret. The secret remains available to the running process, so do not log it. References can be cached and may take up to 24 hours to pick up a rotated version unless refreshed. Mark environment-specific references as slot settings and test that each slot resolves its own value.
The storefront ships without a maintenance window
The storefront runs on the Standard plan from Part A. The team deploys a new version to a staging slot, checks checkout with safe test data, confirms the database target, and warms it. Then they swap and watch production health. If the app version fails, a swap-back is available; database and message changes need their own recovery plan.
The team verifies its domain, binds a supported TLS certificate, enables HTTPS Only, and tests the redirect. Its database credential, if one is still required, becomes a Key Vault reference. Production and staging each keep their own connection reference as a slot setting. The team verifies both after every release instead of assuming a marked setting eliminates all release risk.
Why this is the rung to reach for first
App Service maintains the hosting platform and supplies features such as slots and managed certificates. Your team still chooses the plan, tests the application, controls identities and secrets, verifies domain and TLS configuration, and monitors releases. That division of work is why a managed web platform can be a strong fit for a small team.
The honest limits come next. When shared hardware is not private enough, Part 11c gives you App Service on machines that are yours alone. When you have many containerised services that need real orchestration, Class Twenty-Seven's AKS is the heavier tool that earns its cost. And when the work is short and event-driven rather than a continuously served site, Class Forty-One's Functions is the lighter rung. App Service is the default you reach for first and leave only when a specific requirement — not a fashion — pushes you off it. Part 11f turns "which requirement, and to where" into a framework.
The certificate that used to expire on a Sunday
You take over an app whose TLS certificate was renewed by hand once a year, and had lapsed twice — each time on a weekend, each time a scramble. You move it to App Service, add the custom domain, and switch on a free managed certificate that renews itself. The annual fire drill simply ends. The secret that lived in a config file becomes a Key Vault reference. Nothing about the app got more clever; a whole class of 3am pages just stopped existing, because the platform now owns the chores a person used to forget.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. A staging slot lets the team validate and warm the build before promotion, then swap back to the previous app version if needed. It is designed to reduce deployment interruption. Check live health after the swap; application faults and data changes still need separate recovery.
C. A Key Vault reference avoids putting a literal secret in source or a deployment artifact. App Service resolves the value through a managed identity with permission to read it. The running app can still expose that value if it logs or transmits it, so code and access controls remain your responsibility. A secret already committed to Git must be rotated.
Underlying host patching, supported managed TLS renewal, and platform load distribution. Those are managed platform jobs. Your team still writes and patches its own app and dependencies, decides which settings stay with a slot, and monitors certificate and release health.
RELEASE NOTES — storefront
1. Deploy new build to the staging slot; warm it up.
2. Staging DB connection string: plain app setting, not a slot setting.
3. Click through checkout on staging, then swap staging into production.
4. If the release misbehaves, swap back immediately.
Line two. An ordinary app setting can travel with the swapped application. A database connection that must remain tied to an environment should be marked as a slot setting. Verify the production and staging values before and after the swap; the label alone does not test the app's actual connection.
If production points at test data, the release may appear healthy while orders go to the wrong destination. Include a safe post-swap check that identifies the active database without exposing credentials.
Correct the cost premise. There is no separate fee for a deployment slot on a supported plan, but staging uses the same workers as production. If it makes those workers too busy, the team may need more paid plan capacity. A separate plan creates its own standing compute charge.
Then price the "just deploy off-hours" plan honestly. Deploying straight to production means downtime while the app restarts, a cold start for the first users, and — the real cost — no way back if the new version is broken except to redeploy the old one under pressure while the site is down. "Off-hours" shrinks the audience for the outage; it does not remove the outage, and problems that only appear under real traffic will surface when the crowd returns, with no verified-good version to swap to.
Explain the safer workflow. Validate the staged code and settings, warm it, swap, and observe production. If the app version fails, swap back and verify recovery. A slot does not undo schema changes, transactions, or messages produced after promotion, so the release plan must cover those too.
Name what "managed" actually moved. App Service does take real responsibility off you — the operating system, the runtime, the host patching. That is genuine, and the speaker is right that those are now Microsoft's job. But this is the shared-responsibility line from Class One, and it moved; it did not vanish. Everything above the platform — your code, your configuration, your secrets — is still entirely yours.
Point at where this breach actually lived. A secret hard-coded into the application source is on your side of the line by any reading of the model. No amount of platform patching touches what you wrote into your own code and committed to your own repository. Calling this "Azure's fault" is comforting and wrong, and the danger of the comfort is that it aims the fix at the wrong target — you cannot ask Microsoft to patch your source.
Fix the exposure. Revoke or rotate the leaked credential promptly, remove it from current code and deployment artifacts, assess where it was used, and replace it with managed identity or a Key Vault reference if a secret remains necessary. Cleaning repository history may reduce future discovery, but it does not make the already exposed credential safe again.
Five things worth carrying out of Part B
- App Service runs the machines, OS, runtime and load balancer; you keep the code, the configuration, and the scaling rules. No server to patch.
- A staging slot runs another app version on the same plan workers. Validate and warm it, swap, then monitor live health; a swap-back restores code, not external data.
- Settings swap with the code by default. Mark the ones that must stay put — like a staging database string — as slot settings, or a swap will misroute production.
- A supported custom domain can use a free managed certificate. Check its prerequisites and renewal status; HTTPS Only redirects HTTP, while HSTS can help returning browsers avoid an HTTP first request.
- Secrets are configuration resolved at runtime — an app setting, ideally a Key Vault reference by managed identity — never a literal in code.
- Microsoft's slot guide describes warm-up, which settings swap, which stay, and how to swap back. Slots share plan capacity. A code swap does not roll back a database migration or transactions. ↩
- Microsoft's managed-certificate guide lists current domain, DNS, renewal, wildcard, and private-DNS limits. Apex domains can be supported when their prerequisites are met. Key Vault references require access permission and can cache resolved values for up to 24 hours. ↩
Deploy an app to App Service with a custom domain, a slot and the right settings, and know what the platform does for you.
Play the lesson above to stamp this class.