What you hand over, and what you keep
Part A bought the machines; this part runs code on them. App Service is Azure's managed home for web apps and APIs: you deploy your application — a container image or a build in .NET, Node, Python, Java or PHP — and the platform runs it on the plan's instances, patches the operating system and runtime beneath it, and load-balances requests across however many instances the plan holds. You never open a shell on the server to install a security update, because the server is not yours to patch. That is the PaaS bargain from Class Four, spent on the most common workload there is.
What you keep is exactly the half that was always yours: the application code, its configuration, and the rules for how it scales. The platform will run whatever you give it, but it cannot decide your connection string, your custom domain, or when an instance should be added — those are judgements only you hold, and the rest of this part is about making them well. The App Service blog note "what is Azure App Service" covers the same ground from the practitioner's chair if you want a second pass.
Deployment slots — a warm copy you swap in
A deployment slot is a second, fully-running copy of your app on the same plan, with its own hostname. You deploy the new version to a staging slot, let it warm up, click through it against production data, and then swap — Azure exchanges the two slots' running instances so the version you just verified becomes production, and the old production becomes staging. The switch is a routing change on already-warm instances, so users see no cold start and no downtime, and if the new version misbehaves you swap back in seconds. Slots begin at Standard, which is precisely why the hub sent the storefront there.
The subtlety that trips people is which settings travel with the swap and which stay pinned to the slot. By default an app setting or connection string swaps along with the code. Mark it as a slot setting ("deployment slot setting" in the portal) and it stays put — so the staging slot keeps pointing at the staging database, and production keeps pointing at production, even as the code swaps between them. Forget to pin a slot setting and a swap can quietly point production at the staging database; remember it, and the swap is the safe, reversible release the whole feature promises. The App Service blog note on deployment slots walks a real swap step by step.
A swap is a routing change on a warm copy — reversible in seconds.
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.
Here App Service removes a chore that used to be an annual ritual. A free App Service Managed Certificate issues and, crucially, auto-renews TLS for your custom domain, so the certificate that used to lapse at the worst possible moment simply does not. You can still bring your own certificate or a wildcard when you need one, but the default path is free, automatic, and one fewer thing to be paged about. Turn on HTTPS Only and the platform redirects any plain-HTTP request to the secure version, closing the gap where a first request travels in the clear.1
Configuration — settings and secrets outside the code
The last thing App Service holds for you is configuration. App settings are key–value pairs the platform injects into your app as environment variables at start-up; connection strings are the same idea with a little extra handling for databases. Both live in the app's configuration, not in your repository, which is the whole point: the same build runs in staging and production, and only the settings differ. This is the Class Four line between code and configuration, enforced by the platform.
It is also where secrets stop being hard-coded. A database password does not belong in your source; it belongs in an app setting, and better still in a Key Vault reference — an app setting whose value is a pointer to a secret in Azure Key Vault, resolved at runtime using the app's managed identity from Class Nine. The code reads an ordinary environment variable; the actual secret never touches the repository, the pipeline logs, or the portal in plaintext. The Key Vault references blog note shows the exact syntax. Combine this with slot settings from §2 and configuration becomes something you reason about deliberately: what swaps, what stays, and what is a secret that should never have been a literal.
The storefront ships without a maintenance window
The storefront now runs on the Standard plan Part A sized. You add a staging deployment slot, and the six-person team's release becomes a routine: deploy to staging, warm it, click through checkout against a copy of production, then swap. What used to be a midnight maintenance window with the site down is now a swap at lunchtime that customers never notice — and when a release once broke the basket page, the team swapped back before the support queue moved.
The domain moves from azurewebsites.net to the real shop.campux name with a free managed certificate that renews itself, and HTTPS Only is on so no request ever travels in the clear. The database password that used to sit in a config file becomes a Key Vault reference resolved by the app's managed identity; the connection string to the staging database is marked a slot setting, so a swap can never point production at staging data. Two workloads, two rungs — and this rung, chosen well, costs the team almost no operational attention. Part 11c asks the one question that would push this app off shared hardware, and usually answers "not yet".
Why this is the rung to reach for first
Stand back and count what App Service carried in this part: the operating system and its patches, the load balancer, TLS and its renewals, the machinery of a zero-downtime release. Each of those is a chore that on a virtual machine you would own, script, monitor and be paged about. App Service does them so completely that a small team can run a real production web app and spend its attention on the product instead of the plumbing. That is not a beginner compromise; it is the senior instinct the hub named — the fewest chores that do the job.
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 deployment slot is a warm, running copy you verify and then swap into production; the swap is a routing change on already-running instances, so there is no downtime and no cold start, and a bad release is undone by swapping back in seconds. A changes machine size and does nothing for release safety. C and D are real and worth doing, but they secure and name the app — they have nothing to do with how a new version goes live. The tell in the question is "no downtime" and "roll back in seconds": that is the slot-and-swap feature by design.
C. App settings are injected as environment variables outside the code, and a Key Vault reference goes one better — the setting is a pointer, and the real secret is fetched at runtime using the app's managed identity from Class Nine, so it never touches the repository, the build logs, or the portal in plaintext. A and B put the secret exactly where a leaked repository or a decompiled build hands it to an attacker; hard-coding is how a password ends up in Git history forever. D exposes it in URLs and logs. The rule is simple: secrets are configuration, resolved at runtime — never literals in code.
OS and runtime patching, managed TLS, and load balancing. Those are the chores the PaaS bargain takes off your plate — the server you never shell into, the certificate that renews itself, the load balancer you never wire. The two you keep are the two that were always judgements, not plumbing: your application code, and the configuration decisions like which settings should pin to a slot. Mistaking "App Service manages TLS" for "App Service decides my slot settings" is how a swap silently points production at the staging database — the platform runs the machinery, but the intent is still yours.
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. A plain app setting swaps along with the code. So when staging swaps into production, staging's database connection string rides with it — and production is suddenly reading and writing the staging database. The connection string that differs between slots must be marked a slot setting so it stays pinned to its slot through the swap. Lines one, three and four describe a healthy slot workflow.
Consider the consequence. Shipped as written, the very first swap succeeds visibly — the site is up — while quietly serving customers from the staging database: orders written to the wrong place, production data going stale, and no error to alert on because nothing "failed." The bug surfaces days later as missing orders, and the swap that caused it looks like the safe operation it usually is. Knowing which settings travel with a swap is the difference between a slot that protects you and one that betrays you.
Correct the cost premise first. A deployment slot runs on the same plan you already pay for — it is capacity you have bought, not a second bill, on Standard and above. So "save the cost of a second copy" is answering a cost that does not exist. The staging slot is roughly free; the thing that would genuinely cost extra is a whole separate plan, which is exactly what a slot lets you avoid.
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.
Frame the slot as buying reversibility, not just uptime. The swap lets you verify the new version on real infrastructure before it takes traffic, and undo it in seconds if it misbehaves. That reversibility is the point: it turns a release from a one-way gamble into a routine you can walk back. Simpler-looking is not simpler when the failure mode is "site down, no rollback." The slot is the simplest thing that is actually safe.
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.
Close on the correct fix and the general lesson. The secret moves to a Key Vault reference resolved by managed identity, the exposed credential is rotated, and the history is scrubbed. The lesson is the one the whole bootcamp keeps returning to: managed services relocate the line of responsibility to your advantage, but the half they never take — your code, your config, your secrets — is precisely the half you are paid to hold. Mistaking "managed" for "not my problem" is how a convenience becomes a breach.
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 deployment slot is a warm copy on the same plan. Swap verifies and promotes with no downtime; swap back undoes a bad release in seconds.
- 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.
- Custom domain plus a free App Service Managed Certificate gives auto-renewing TLS; HTTPS Only closes the plain-HTTP gap. The annual cert fire drill ends.
- Secrets are configuration resolved at runtime — an app setting, ideally a Key Vault reference by managed identity — never a literal in code.
- The free App Service Managed Certificate is genuinely free and auto-renewing, but it has real limits worth knowing before you depend on it: historically it did not cover naked apex domains in every configuration, and it does not do wildcards. For those you bring your own certificate or use an App Service Certificate. Treat "free managed TLS" as the right default for a standard custom subdomain and check the current coverage rules before betting an apex or wildcard domain on it. ↩
- "Swap" sounds instantaneous, and to users it nearly is, but under the hood App Service warms the target instances and applies the swapped settings before flipping the routing — which is why a slot with a slow-starting app should use warm-up so the swap does not expose a cold instance. The mental model to keep is not "copy files over" but "exchange two already-running apps," because that is what makes it both downtime-free and reversible. ↩