Module 01 · Questions 1–9

App Service & Hosting

Where your .NET app actually runs in Azure, and the load balancing and scaling around it.

What is Azure App Service?

In one line

A managed platform for web apps and APIs — you deploy the application, and Azure runs the OS, patching, load balancing, TLS and scaling.

YOU MANAGE AZURE MANAGES your application │ OS + patching configuration │ web server scaling rules │ load balancing across instances the database schema │ TLS certificates, health, restarts

What comes built in	Detail
Deployment slots	Staging + swap for zero-downtime releases (Module 02)
Autoscale	Out to more instances on a metric or a schedule
Managed identity	Authenticate to Key Vault and SQL with no stored secret (Module 06)
App Settings	Environment configuration that overrides `appsettings.json`
Free TLS + custom domains	Certificates managed for you
Diagnostics	Log streaming, Application Insights integration (Module 07)

30-second interview answer

App Service is Azure's managed hosting for web applications and APIs — a PaaS offering, so Microsoft runs the operating system, patching, load balancing and certificates, and I just deploy the application. For an ASP.NET Core API it gives me deployment slots for zero-downtime releases, autoscaling, managed identity so there are no credentials in config, and built-in Application Insights. I'd only move to a VM or containers if I needed OS-level control or a dependency App Service can't host.

App Service vs an Azure VM

	App Service (PaaS)	Virtual Machine (IaaS)
OS patching	Azure	You
Time to first deploy	Minutes	Hours — provision, configure, harden
Scaling	Built-in autoscale	Scale sets, configured by you
Control	No OS access, restricted runtimes	Total — any software, any config
Deployment slots	✅ Built in	Build it yourself
Cost model	Per plan, per instance	Per VM, running or not
Right for	Web apps and APIs — the default	Legacy dependencies, custom services, specific OS needs

The judgement to show

"I'd default to App Service and only take a VM when there's a concrete reason — a Windows service, a COM component, custom software installs, or licensing that requires it. Choosing a VM by habit means inheriting patching, hardening and high availability as your own problem."

Q3What is PaaS?

you manage ──────────────────────► Azure manages IaaS app · runtime · OS │ virtualisation · hardware PaaS app · configuration │ runtime · OS · hardware FaaS just the function code │ everything else SaaS nothing — you use the product │ everything

Model	Azure example
IaaS	Virtual Machines
PaaS	App Service, Azure SQL Database, Service Bus
FaaS	Azure Functions
SaaS	Microsoft 365

Q4How do you deploy ASP.NET Core to App Service?

# the answer they want: from a pipeline, not from a laptop
dotnet publish -c Release -o ./publish
# → Azure Pipelines / GitHub Actions task deploys the artefact to a SLOT
# → smoke test the slot → swap into production

Method	Use
CI/CD pipeline	The production answer — repeatable, audited, approvals
ZIP deploy / `az webapp deploy`	Scripted or one-off deployments
Visual Studio publish	Dev and demos only
Container	When you need a custom runtime or the same image everywhere

Configuration goes in App Settings, not in appsettings.json — they arrive as environment variables and override the file, which is how one artefact runs in every environment.

App Service vs Azure Functions

	App Service	Azure Functions
Model	Continuously hosted application	Event-driven, per-execution
Billing	Per instance, per hour — even when idle	Per execution + memory (Consumption); scales to zero
Cold start	None	Yes, on Consumption
Execution time	Unlimited	Limited (5–10 min default on Consumption)
Best for	APIs and sites with steady traffic, rich middleware	Webhooks, timers, queue processing, spiky load

A realistic architecture answer

"I'd host the main API on App Service because traffic is steady and it needs the full ASP.NET Core pipeline, and use Functions for the event-driven edges — the webhook receiver, the nightly report, the queue consumer that resizes images. They're complementary rather than alternatives."

Horizontal vs vertical scaling

In one line

Vertical = a bigger machine. Horizontal = more machines. In the cloud you prefer horizontal, because it has no ceiling and no restart.

VERTICAL (scale up) HORIZONTAL (scale out) ┌────┐ ┌────────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ S1 │ → │ S3 │ │ S1 │ → │ S1 │ │ S1 │ │ S1 │ └────┘ └────────┘ └────┘ └────┘ └────┘ └────┘ 2 cores 8 cores 1 instance → 3 instances simple, has a hard ceiling, near-unlimited, needs a STATELESS app, usually restarts the app no restart, finer-grained cost

	Scale up (vertical)	Scale out (horizontal)
In App Service	Change the plan tier/size	Increase the instance count, or autoscale
Downtime	Usually a brief restart	None
Limit	The largest available SKU	Effectively none
Requires	Nothing	A stateless app — no in-process session, no local files
Resilience	Still a single instance	Survives losing an instance

The follow-up: what stops you scaling out?

In-process session state, files written to local disk, an in-memory cache that must be consistent, background jobs that would run on every instance, and unshared Data Protection keys. Fix those first — then remember that scaling the app usually just moves the bottleneck to the database.

Q7What is Azure Load Balancer?

A layer-4 load balancer: it distributes TCP/UDP traffic across VMs or instances in a region using IP and port, with health probes removing unhealthy targets. It knows nothing about HTTP, URLs or cookies.

You rarely configure one for App Service — App Service already load-balances across its instances. It matters for VMs, scale sets and AKS node traffic.

Load Balancer vs Application Gateway (and Front Door)

	Load Balancer	Application Gateway	Front Door
Layer	4 (TCP/UDP)	7 (HTTP)	7 (HTTP), global
Scope	Regional	Regional	Worldwide
Routes by	IP + port	URL path, hostname, headers	Same, plus nearest region
TLS termination	❌	✅	✅
WAF	❌	✅	✅
Session affinity	By IP hash	Cookie-based	Cookie-based
CDN / caching	❌	❌	✅

Users worldwide │ Front Door global routing, WAF, caching, regional failover │ App Gateway /api/* → API backend · /* → web frontend · WAF │ Load Balancer spreads TCP traffic across the VMs behind it │ VMs / instances

The one-line distinction to remember: Load Balancer moves packets; Application Gateway understands requests. If you need to route /api somewhere different from /images, you need layer 7. Traffic Manager is the fourth option and works at DNS level — global, but it can't inspect the request at all.

Q9What is an App Service Plan?

The set of VMs your apps run on — it defines the pricing tier, the instance size and the instance count. It's what you're actually billed for; the apps themselves are free.

Tier	Gets you
Free / Shared	Testing only — quotas, no custom domain SSL, no slots
Basic	Dedicated compute, custom domains, manual scale, no slots
Standard	Deployment slots, autoscale, daily backups — the realistic minimum for production
Premium	More slots, more instances, faster hardware, VNet integration

The trap worth knowing: several apps in one plan share its CPU and memory. A runaway background job in one app slows every other app on the same plan — so keep production and test workloads on separate plans.