Through the startup code, not by magic. Consider int x = 42;, the value 42 can't simply "be in RAM" at power-on, because SRAM is volatile and powers up undefined. So the compiler/linker store the initializer (42) in flash as part of the .data load image, and the startup code copies the entire .data section from that flash location into the variables' run-time home in SRAM during boot. For int count; or int count = 0; (uninitialized or zero-initialized statics, which go in .bss), the C standard guarantees they read as zero, and the startup code delivers that guarantee by zeroing the whole .bss region. The linker script provides the boundary symbols (start/end of .data in flash and SRAM, start/end of .bss) that the startup loop uses. The practical consequence: any code that reads a global before this runs, like a constructor for a global C++ object that executes during init, or a very early boot hook, can see uninitialized values, so you can't rely on globals until the runtime is up.
Embedded Systems Fundamentals · Interview question
How does a global variable get its initial value?
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
Boot Sequence & Startup Code
Everything that runs before main(): the reset vector, copying .data and zeroing .bss, the vector table, and how a bootloader hands off via VTOR.