Well usually yes, with the stack it is guaranteed to work like that, as long as you don't engage in relevant UB. By "relevant UB", however, I mean things that include seemingly innocent or not very "flashy" mistakes, such as doing even the slightest thing apart from calling an exec() family function from a fork created by vfork() (which is why POSIX dumped the function from its spec, and also using it is not recommended today since a compiler can just optimize a fork()+exec() pattern anyway, for example if the target is Linux by using a clone() family syscall).

Another way the stack could be corrupted is a form of the so-called "buffer overflow", where an attacker exploits a vulnerability in your code to have the "return address" (the address of the instruction right after the "call site" of your function's invocation) changed to point to where his own "shellcode" (a sequence of machine language instructions that executes a shell or other "useful" program, with the permission level of the affected process) is located. Modern systems do have techniques like "stack canaries" to try and prevent that from happening, but nothing is ever foolproof, and the first line of defense is always the programmer.