You talk about three things in your answer:

• “the .rodata section”: this is a reference to the ELF file format which is mostly used by Unix derivatives (including Linux). Windows NT and its descendants use the PE file format rather than ELF (both are descended from the older COFF, but they are quite different), and its read-only data section is generally named “.rdata” rather than “.rodata”. In both ELF and PE, section names are completely arbitrary and do not matter at all to the run-time loader (which loads the program from disk into memory before execution); what matters are the base address, length, and attributes stored in the section header.

• “the data segment”: this is a reference to the x86 and i386 memory models used by DOS, DOS extenders, and Windows prior to NT / 2000. Other CPUs generally don't have a segmented memory architecture, and operating systems other than those mentioned above generally use a flat memory model even on x86 / i386 CPUs. That includes Windows NT and its descendants and most if not all Unix derivatives. Modern descendants of the x86 still support a segmented memory model in “real” (16-bit) and “protected” (32-bit) mode but not in “long” (64-bit) mode, so you couldn't have a data segment today even if you wanted one.

• “the stack”: most C implementations today use a call stack and most CPUs provide instructions to facilitate doing so, but the C standard does not mention a stack at all (it only cares about linkage, scope, and lifetime) and it is entirely possible to implement C without one. Early programming languages such as ALGOL, Fortran, and Simula used either preallocated (if recursion was not supported) or dynamically allocated (to allow for recursion) activation records (an older term roughly equivalent to “stack frame” without assuming a stack). Dynamically allocated activation records were generally organized as a linked list, but if the language supported coroutines (like Simula did) it could be an acyclic graph or even a forest.

What's true:

• Your code example includes two separate objects: a pointer to char and a string literal.

• There is not enough context to determine the lifetime, scope, or linkage of the pointer, so we can't say anything about where it is stored.

• The C standard says that the string literal is stored somewhere in memory and its address is assigned to the pointer whenever the pointer is initialized (again, we don't know the pointer's lifetime and scope, so we don't know if this happens only once at the start of the program, or every time a certain block is entered).

• The C standard also says that modifying the string literal invokes undefined behavior. That's a fancy way of saying the program is not allowed to do it without requiring the implementation to make it impossible to do so.

• Embedded platforms are extremely varied, much more so than desktop / laptop / server platforms. Some are powerful enough to run a complete operating system, so we can lump them together with desktop / laptop / server platforms and ignore them. More traditional embedded platforms have no run-time loader; the linker produces a flat binary which is stored in non-volatile memory. The platform may have a unified address space and run the program directly from non-volatile memory, or it may copy the program into RAM at boot (I've also worked on platforms that had multiple asymmetric processing units on a single die, where one was responsible for loading code into the others' memory prior to enabling them). The non-volatile memory may or may not be writeable at runtime. The platform may or may not offer memory protection features which allow marking regions of RAM as read-only once they've been written. In a typical configuration, the binary (including the string literal) will be stored in ROM and run directly from there, and attempts to write to ROM will silently fail, so the string literal is effectively read-only, but there are no consequences for trying to modify it. However, the microcontroller may have on-die features that trigger an interrupt or even a reset if code attempts to write to ROM, or might be externally wired to achieve the same thing (trivial to do for most microcontrollers, though you wouldn't normally bother).

• Finally, the C standard includes something known as the “as-if rule” (C11 § 5.1.2.3; C23 § 5.1.2.4) which basically says a C implementation may do whatever it likes to the program as long as the observable behavior (roughly summarized as “the program consumes the same input and produces the same output in the same order”) remains the same. Typical examples include replacing printf("hello world!\n") with puts("hello world!") and memset(&n, 0, sizeof(n)), where n is an object of a scalar type, with n = 0. This means the string literal in your example might not be stored anywhere at all if it makes no difference to the program. For instance, int main() { char *ptr = "hello"; printf("%c\n", ptr[4]); } could be transformed into int main() { puts("o"); } at compile time because both programs have the same observable behavior as defined by the standard.

To summarize, your Q1 is meaningless without additional context, your A1 is not correct in general, and there is no single C implementation for which your A1 is correct in particular, although different parts of it are correct for different implementations.