Short, honest write-ups of the ideas that come up in interviews and on the job. Each one teaches the concept properly, cites the Microsoft documentation, and points back to the class that drills it until it sticks.
All three run the same upstream Kubernetes, so your manifests, kubectl, and Helm charts move unchanged. What differs is the wrapper — control-plane cost, node management, and cluster identity.
Same idea — upload code, pick a trigger, the platform scales it — but the mental models differ. Function Apps, bindings, and hosting plans are the Azure-specific parts that trip people crossing over.
Both run your app; the difference is how much of the stack underneath becomes your problem. Where the responsibility line sits, a side-by-side, and a decision rule.
Azure VM or App Service? Choose App Service when you just want to run a web app and let Microsoft handle the OS, patching and scaling. Choose a VM when you need full control — custom runtimes, background services, ports, or software App Service can't host. The IaaS-vs-PaaS decision, with a table.
Azure Functions vs AWS Lambda for a small project: both have effectively-free hobby tiers, so price isn't the deciding factor. Pick the one whose ecosystem your app already lives in. A short, opinionated decision list keyed on language, triggers, and how you deploy.
An image is a reusable template for spinning up new, identical VMs; a snapshot is a point-in-time copy of one disk. Here's when to use each, and the exact az CLI and portal steps for both paths.
Nested virtualization is running a hypervisor inside an Azure VM so you can spin up Hyper-V, Windows Sandbox, WSL2, or nested Kubernetes on it. It only works on VM sizes that expose the virtualization extensions — pick the wrong series and it silently won't. Here's what it is, which sizes support it, and how to turn it on.
AWS Lambda vs Google Cloud Functions on price: both bill per request plus compute per GB-second and both hand you a large perpetual free grant (~1–2M requests, ~400k GB-seconds). At real scale the bill is a wash — the choice comes down to cold starts, runtimes, and ecosystem.
AWS EC2 vs Azure Virtual Machines vs GCP Compute Engine: all three rent you the same thing — a VM billed by the second or hour. The real decision is ecosystem, not a few cents an hour. Terminology, sizing families, and pricing models compared.
AWS Lambda vs Azure Functions on price: both hand you roughly 1M requests and 400,000 GB-seconds free every month, so hobby workloads are effectively free on either. The real gap is billing granularity — Lambda bills 1ms, Azure's Consumption plan rounds to 100ms.
Azure VM vs AWS EC2, compared honestly: same idea, different names and knobs. A side-by-side table on terminology, pricing models, sizing, free tier, and billing — plus the part that actually decides cost.
Microsoft’s container-optimised distro (formerly CBL-Mariner): a small, hardened host OS for AKS nodes. Why it exists, how to choose it, and Ubuntu-vs-Azure-Linux.
The 30-second az webapp up, a static-vs-dynamic decision, custom domain plus free HTTPS, and what it actually costs per month.
What each tier is for, and the feature cliffs — Always On, slots, VNet — that force an upgrade. F1 to P1v3, side by side.
ACI runs a container; Container Apps runs a container service. Burst jobs versus scale-to-zero, cost, and the AKS off-ramp.
Three real options with real monthly-dollar math — and the places where "free" quietly bites you later.
Static and JAMstack go to Static Web Apps; server-rendered apps and backends go to App Service. The full cost and feature split.
Why Free and Shared tiers can't do it, the DNS and verification steps, the free managed cert, and the apex-domain traps.
Kubernetes is a demanding machine to keep alive; AKS is the deal where Azure runs the demanding part for free and you pay only for the boxes your containers actually land on.
Both spread your VMs so one failure doesn't take the whole application down — but a set spreads them across racks inside one building, and a zone spreads them across separate buildings, and that difference is the whole point.
The size picker has hundreds of options with names like Standard_D4s_v5, and most people scroll until something looks big enough — which is how you end up paying for RAM you never touch, or throttling a database that needed it.
A Spot VM can cost a fraction of the standard price for the exact same hardware — but Azure can take it back with 30 seconds notice, mid-job, whenever it wants the capacity. Whether that trade is worth it comes down to one question about your workload.
The default *.azurewebsites.net URL never goes away and lands visitors on the raw app behind your custom domain. You can't delete it and going private breaks the domain — redirect it with one URL Rewrite rule, minding the patternSyntax gotcha.
500.30 means the ASP.NET Core Module launched your app and it crashed during startup. Here's how to tell it apart from 500.31–500.38 and pull the real underlying exception with stdout logging, Log stream, and dotnet App.dll.
Running one VM is easy; running forty identical ones that add and remove themselves with demand is a job you do not want to do by hand. A scale set is Azure doing it from a single image — the building block under autoscale and AKS node pools.
The scariest moment in running a web app is the deploy. Slots turn it into a non-event: push to a warm staging copy, swap it into production with nothing dropped, and swap straight back if the new build misbehaves.
Sizing a server for your worst hour means paying for that hour all day. Autoscale flips it: the app grows instances when the crowd arrives and gives them back when it leaves — the elasticity you moved to the cloud for.
Hosting a web app used to mean owning a server — patching an OS, praying on release night. App Service takes all of that off your plate and leaves the one thing that matters: your code.
Most cloud code spends its life waiting — a server billed by the hour to work for a few seconds a day. Functions flips that: your code sleeps for free, wakes on an event, does its job, and goes back to sleep.
Azure has a shelf of places to run your code, and the beginner mistake is reaching for the most powerful one. The real question is not what can run this, but how much platform your team can actually operate.
One short, honest Azure note at a time — plus the occasional hiring signal. No spam, no card, unsubscribe in one click.