a) the query to be tested and scripted on non-production environments first, making this a non-issue;
b) user doesn't have DELETE permissions on that table and/or the rows not intended to be deleted;
c) referential integrity to kick in and prevent the deletion of interdependent records (which is most records in a database);
d) CHECK constraints, triggers, and other validation routines to prevent this clearly-excessive operation;
e) the person executing and inspecting these queries within an ad-hoc transaction to roll it back before committing;
f) if, in the event this does occur and commit, which itself means there's a big problem with your procedure, streaming binlog archives can facilitate a point-in-time backup, audit tables can be used to rebuild the data, etc.; these aren't typically included by default (streaming point-in-time backups are on AWS Aurora) but they're conventional for many professionally-run RDBMS installations.
and I'm sure there are failsafes that I'm forgetting, and since I'm not a DBA, some I'm probably not even aware of.
How many of these can I expect to help me out when a packaging bug (or, simply a mistaken "y" on the prompt asking if I want to override the package config) clobbers the Kafka config file?