Automated checks. For example, in this case, confirming that the other containers are quiescent (as they are supposed to be) and locking them down before the potentially conflicting operation.
I'd be willing to bet that it's extremely rare for a fully automated process to have absolutely no guardrails/checks/tests, and it's also extremely rare for a fully automated process to have 100% test coverage.
If this check existed and the system failed in some other way, it would be characterized as "fully automated with no guardrails" (for the scenario which caused the failure). "We had tests but missed an edge case" usually doesn't get you any sympathy.
So what's left? Formally proving correctness is overkill for most things. The "end-to-end" argument [1] might be able to detect when something goes wrong at the end to rollback or alert, but what if the intermediate steps have already caused damage or prevent the "end" from being reached entirely? If a run is taking longer than usual, how do you differentiate between harmless delays in the intermediate steps, and the run being entirely broken somehow?
