In practice, you manually bootstrap your CI/CD, and if you really want to be secret squirrel secure, you can audit that.
Everything going forward gets to be commited via code, peer review, least privledged access, and is automatically deployed by the robot.
At that point, you might hand out some break glass credentials for a few items, or when your CI/CD goes down, but usage of that should alert and be manually reviewed.
You now have a pretty decent setup, as everything is checked.
Fully driving a cloud via code is a complete lie.
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
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.