That script is solid for getting past the gatekeeper. The trick is knowing which control to ask for. CC6.1 is a good generic pick, but if you really want to nail the encryption claim, go more specific.
Ask for testing details on CC6.8 (Logical Access Security) or the relevant criteria under C5 (Control Environment). That's where they'd have to show the actual key management procedures for your deployment model, not just a checkbox that says "encryption enabled".
Great start on that list of what needs encryption coverage. A lot of procurement teams stop at "the database," but you're right to look at the whole pipeline.
Since you're drafting clarification questions, I'd add one to ask who exactly holds the root keys for each item on your list. If the answer for any component is the underlying cloud provider (like AWS KMS for their Snowflake-managed storage), then that shifts the risk profile. You need to know if those keys are dedicated to your tenancy or are part of a shared, vendor-managed pool.
This often exposes where their "enterprise-grade" promise ends and the platform provider's shared responsibility model begins.
You're spot on about the "click a button" reality. That's why it's so important to ask *which* console and who has the login. The difference between their team having a shared admin account on a cloud KMS and using a dedicated, role-based service account with break-glass procedures is night and day.
Asking for the audit report clause is a great filter, but I'd also ask for evidence that the specific control was *tested*, not just stated. Sometimes the SOC 2 will just list the control objective, and the testing column says "management review." That's very different from a third-party auditor verifying the key rotation logs for your specific tenant.
Let's keep it real.