Loading…
Choose a Cloud Compute Model for a New Service is a easy cloud architecture interview question covering cloud architecture, serverless, containers, compute, autoscaling — the kind asked at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies like Anthropic, OpenAI, and Nvidia.
A team of four is about to build a new internal reporting API. Traffic is near zero overnight, heavy for two hours each morning, and spikes hard at month end. Most requests finish in under a second, but one month-end report runs for about eight minutes and holds several gigabytes in memory. Decide how it should run: virtual machines, containers on a managed orchestrator, or serverless. Justify the choice from the requirements and say what would make you change it.
That's it. No further details. This is intentional — your first job is to scope the problem by asking the right clarifying questions.
The opening question of most cloud architecture loops, and the one candidates most often answer with a preference instead of a decision. A team is about to build a new backend service and has to pick between virtual machines, containers on a managed orchestrator, and serverless functions. There is no correct answer independent of the requirements, which is the entire point: the interviewer wants to see which requirements you go looking for before choosing. Strong candidates ask about traffic shape, startup latency tolerance, and how much operational capacity the team actually has, then pick one model and name the condition that would make them switch. Weak answers open with a favourite technology and reverse-engineer justifications for it.
Work through the Clarify phase by asking questions one at a time — just like a real interview.
Each answer reveals why that question matters and how it changes your design decisions.
Once you've clarified enough, unlock the full architecture, the managed-versus-self-run reasoning, and the trade-off analysis.
Design rounds are decided on capacity estimates. Both tools are free.
There is no single correct model, and the assessment is which requirements you gather before choosing. The four that decide it: traffic shape (spiky and mostly idle favours scale-to-zero over reserved always-on capacity), latency tolerance (cold starts of one to two seconds are fine for an internal dashboard and fatal for a public checkout path), runtime constraints (an eight-minute job with several gigabytes of memory sits at or beyond many function platforms limits), and the team operational capacity (standing up an orchestrator for one service is rarely justified, joining one that already exists is nearly free). The strongest answer is that the workload is not uniform so the compute model need not be either: short requests run on serverless containers, which scale to zero overnight and autoscale through the morning peak, while the long report runs as a container job on the existing orchestrator where an eight-minute runtime is unremarkable. Both run the same container image with different entry points, which keeps the split cheap and preserves one build. The enabling constraint to state explicitly is that all state must live outside compute - a managed database and object storage, never instance-local disk or in-process sessions - because that is what makes instances disposable, and no compute model fixes a service that keeps sessions in process memory. Common weak answers: opening with a favourite technology and reverse-engineering justifications, pricing operational cost at zero, and forcing the long job into a request-response tier with timeout workarounds.
A full interview loop is more than one round. These are the others, each with what is on the site for it.