When the set of objects is known and bounded at build time, which covers a large fraction of firmware. You declare the worst-case array (static Task tasks[MAX_TASKS], static uint8_t rx_buf[256]) and never allocate at runtime at all. The benefits are maximal: memory use is known at link time (you can verify it fits RAM before flashing), there's nothing to fragment, no allocation can fail at runtime, timing is fully deterministic, and it satisfies MISRA-style prohibitions on dynamic allocation. The costs are that you always pay for the worst case (the RAM is reserved even when unused) and you must actually know that worst case. For a system with a fixed number of tasks, a fixed set of peripherals, and bounded buffers, static allocation is not a fallback, it's the preferred, safest design, and dynamic schemes are introduced only where the static approach genuinely can't express the need.
Data Structures & Algorithms · Interview question
When is plain static allocation the right answer?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Static vs Dynamic Allocation
How to give data structures memory on a constrained device: static arrays, fixed-block pools, and arena allocators, the O(1), fragmentation-free alternatives to general malloc.