One machine, more of everything
Scaling up means giving one machine more of everything: more cores, more memory, faster disks.
It goes further than most engineers assume, because the ceiling is higher than most engineers assume. You can start on an instance with a gigabyte of memory and climb to one with 96 processors and 192 gigabytes. The memory-optimised range reaches 24 terabytes, for databases that hold everything in memory. The climb needs no changes to your code at all. Same architecture, same deploy scripts, more headroom.
That is the entire appeal. No distributed state to reason about, no load balancer to configure, no questions about which copy is right. One large machine running your application and another running your database is a legitimate architecture. Plenty of profitable companies run exactly that, and dismissing it in an interview reads as inexperience rather than sophistication.
Where it stops working
Expect the problems to arrive from three directions. Price stops scaling linearly, because doubling from 8 processors to 16 roughly doubles your bill while the largest instances charge a premium for being largest.
The ceiling is real. When the biggest machine your provider sells is no longer enough, there is no next size, and you do the horizontal migration anyway, now under pressure.
And you still have one machine. A hardware fault, a kernel panic or a botched resize takes down everything at once, and resizing usually means a restart, which for your database means a maintenance window.
It buys time and simplicity, both of which are worth real money. Databases in particular reward it, because a single well-tuned database holding its working set in memory outruns a badly sharded cluster every day of the week. Just know which rung you are standing on and what the next one costs.
Worked example
Diego runs a recipe site on Django with Postgres, a relational database, on a managed instance with 2 processors and 8 GB of RAM, about 125 dollars a month. A TikTok mention triples traffic and the machine is pinned busy at 95 percent every evening, with query times climbing from 8 ms to 300 ms. He clicks resize to a db.m5.2xlarge, 8 vCPUs and 32 GB, and eats about 90 seconds of failover downtime at 2 am. Cost goes to roughly 500 dollars a month, and the working set now fits in RAM, so queries drop back to 6 ms. No code changed, no architecture meeting happened. The upgrade bought him around 18 months, which he spent adding caching before touching anything harder.