Ideally, updates are idempotent (if you run the same update multiple times, you get the same result as if you'd run it once) and resilient (if an update is interrupted by a reboot, you can resume the udpate after the reboot). But updates are not atomic (there are half-updated system states).
In practice, idempotence really works. If
yum update is interrupted (by an error, by pressing Ctrl+C, by a scheduled reboot, by a power failure, …), just run
yum update again after the system restarts, and wait for it to complete.
In practice, resilience usually works. The package manager takes care to first unpack the files of the new version under a temporary name, then replace the old files with the new one. If the update is interrupted during the longest phase (the unpacking, which requires a lot of disk writes), the system state hasn't change meaningfully, so no harm is done. If the update is interrupted during the replacement phase, things get more complicated. The software that is being updated may be unusable due to a version mismatch between its different files.
Most critical packages can be updated on a file-by-file basis, or have configuration steps that are performed in the appropriate order to ensure that the system remains operational. For example
rpm consists of a single binary, so you either get the old one or the new one. Same thing with the kernel. However, with thousands of packages, hundreds of thousands of files, and a large potential for write reordering at the filesystem level, the combinatorics is very, very high, and it's impossible to test everything. So it's possible to end up with a system that doesn't boot cleanly if it was interrupted in the middle of an update. But the probability is very small (barring bugs, of course).