Atomic rollback with occasional local packages: DNF transactions or image-based updates

For Rocky Linux hosts that must recover quickly after a failed update while still supporting occasional ad-hoc local RPMs, the documented update models present a trade-off. Traditional DNF transactions allow per-package installs and third-party RPMs built for the matching RHEL minor release, but dnf history rollback does not reliably restore a prior kernel, bootloader entry, or coherent userspace state. Image-based updates using bootable container images provide atomic staging with reboot-into-previous-deployment rollback, yet locally layered packages persist across base-image updates and can drift out of sync with base-image libraries. Out-of-tree kernel modules add another variable: under image mode they must match the exact base-image kernel and trust chain, while the DNF path handles them through akmods or dkms at update time. Rocky Linux tracks RHEL minors but is not byte-identical, so image-mode tooling defaults and module handling need confirmation against Rocky's own release notes for the target release rather than assumed RHEL behavior. Secure Boot, disk encryption, and hardware driver behavior may only surface on real hardware, not in disposable VMs.

Which approach better serves a fleet with short maintenance windows and intermittent local packages? Is there a documented Rocky Linux policy for when to layer an RPM into an image versus rebuilding the base image? How should out-of-tree modules be managed under image mode without breaking the rollback guarantee?