If you use a cloud service and they have an encryption at rest feature that you enable, the default is for them to control the key. Or, for Azure, put a "customer controlled" key in Key Vault. But again, that's their service. In this scenario you're only protected against people physically in the data centers not their DevOps folks. But, that feature gives you a checkmark for SOC2 or other regulations...
The problem protecting against DevOps folks at a cloud is: 1. You are burdened with putting a key somewhere outside of their cloud. If you do something at the filesystem level like enable bitlocker on a VM you're going to experience pain during reboots and it's not possible on a root volume if you're not given a console. 2. You can't do this on a cloud service like RDS. You'd have to do row level encryption with your application doing the decryption/encryption. But, your application has to have the key and now your back to #1. The VM with the key needs the root disk encrypted or the drive where the key is store encrypted. And again, you're not able to use a cloud service like EKS or App Service you're stuck with VMs.
Generally, I tend to just stick with regulation requirements which protect against the physical hard disk.
But secondly, the idea that anyone who actually has a say in if the data is turned over (the legal team, executives) give a flying fork about how a random sysadmin in their data center feels about it is wildly off base. The data is going out or not according to legals instructions. Either sysadmin Bob does it, or he takes a principled stand, gets fired, and Bob 2 takes care of it.
Most of my colleagues (at least those I've met) tend to be conscientious about data access and privacy. I host several E2EE services for friends/family because I believe in privacy and data sovereignty. But if my company's legal department says "give access to <these guys>," as a sibling commenter said, if I refuse then I'm fired and those guys will still get access. So I do what legal says and keep my job, TYVM.