Ah yes, just magically know that the command in the playbook isn't safe and refuse to use it during an incident. I want to meet your principal engineers who ca

Ah yes, just magically know that the command in the playbook isn't safe and refuse to use it during an incident. I want to meet your principal engineers who can fully understand a command's complete set of side effects solely from a bash snippet telling you how to invoke it! Like yes, it is the principal's (well really everyone's, but sure insofar as someone is ultimately responsible, we can make the principal engineer responsible) responsibility to ensure processes are safe. But you can't do that by magically "refusing to engage in an unsafe process". Because it's difficult to know a priori if a process is inherently unsafe. Usually you figure this out when something goes wrong, and then you take that learning from a postmortem/incident report and try to apply it to other similar tools. But no, I wouldn't blame anyone, not even a principal engineer whose job it is to ensure safe systems for accidentally fat fingering a dangerous command that they didn't know about. They perhaps bear some responsibility for not having previously fixed it, but they bear approximately none for misusing a tool that makes itself easy to misuse.