Section 13: The Judges' Table - Final Summary & Candidate Scorecard

Executive Summary: This closing section turns the module into a way to grade yourself. We replay the arc as signal, lay out a 100-point scorecard weighted toward architecture and data model (where the split between durable truth and soft state is won or lost), name two common ways to lose the hour, map score bands to remediation, list the prompts that are this one in disguise, and restate Section 1's four hard problems as the four signals the panel was listening for.

The interviewer wasn't grading the box labelled "Firecracker." They were grading whether you saw that a function is an untrusted program that must start in about 100 ms, whether memory-seconds rather than requests decided your fleet, and whether you could say what "async" actually promises without reaching for "exactly-once."

The Arc, Replayed as Signal

No signal is "knows Lambda." Section 3 earned credit not for ~1M invokes/s but for what followed: Little's law to ~420K concurrent executions, ~1.26M resident sandboxes, and ~430 TB of 645 TB (two-thirds of memory) sitting warm-idle, which made keep-alive the main cost lever. Sections 3 and 8 earned credit the same way: ~10.4K new sandboxes/s is only ~3.3 per host, so cold starts are a latency problem, and a pre-booted pool cuts ~230 ms to ~110 ms.

Key Insight: At 401 the panel assumes you know the parts and tests whether you know which promise each part keeps. Answer "Tidewater's flash sale starts at 09:00, what happens?" with "provisioned concurrency of 3,000 on checkout-api:live warmed at 08:55, the account limit raised to 5,000 beforehand; without it the +1,000-per-10-seconds rule takes ~27–30 s to grow from 300 and the excess gets 429 with Retry-After," and you've shown placement, scaling, limits and the API contract in one reply.