I don't think it's a lie; just a pain in the arse. I've worked in, and defined, secure environments where your only option is you need to raise another PR. Fo

I don't think it's a lie; just a pain in the arse. I've worked in, and defined, secure environments where your only option is you need to raise another PR. For me this often degenerates into the PR spinning up a copy in another account, and the PR history being "test, test, test, ffs, test". Like this: https://github.com/secureweb/homelab/commits/parca https://github.com/secureweb/homelab/commits/parca The more practical way around the problem is to have non-production accounts where you can delegate admin, without the risk of the production and tooling accounts, and use that to make sure your code works before you actually raise the PR and merge. It's prudent to remember that such security should be risk based, so whilst there's risk that you leak non-prod credentials to a crypto farmer, the risk of your teams being non-productive is greater. Largely agree with you though. I usually just run k8s environments and make concession to use the cloud stuff when it makes sense. Not being able to run locally is akin to punching yourself in the nuts. Creating a namespace in k8s and deploying ephemeral tests either locally or in a dev cluster is better experience in my opinion. But you do have a lot of folks who treat their cloud provider like their favourite sports team.