COF-C03 Question 189
Single answerEncryption key managementA financial services company uses Snowflake to store regulated customer data. Its security team requires the company to control the root encryption key material and be able to revoke Snowflake's access to encrypted data immediately if a key compromise is suspected. The company also wants to minimize changes to application code and continue using standard Snowflake features. Which approach best meets these requirements?
- A
Use Tri-Secret Secure so that Snowflake encryption requires both the Snowflake-managed key and a customer-managed key from an external key management service
- B
Use client-side encryption for all data loaded into Snowflake so Snowflake never encrypts data at rest
- C
Rotate the Snowflake-managed account master key on demand through SQL commands whenever a compromise is suspected
- D
Store encryption keys in a Snowflake table protected by role-based access control so security administrators can revoke access immediately
Show answer and explanation
Correct answer: A
Explanation
The best answer is Tri-Secret Secure. Snowflake encrypts data at rest by default using a hierarchy of keys managed by Snowflake. For organizations with stricter compliance or sovereignty requirements, Tri-Secret Secure adds a customer-managed key stored in an external key management service, creating an additional independent control over decryption. This is the Snowflake feature specifically intended to give customers control over key material and the ability to revoke access if needed, while still using normal Snowflake capabilities.
Why the other options are weaker: client-side encryption can be useful for protecting staged files, but it is not the primary Snowflake feature for customer-controlled account-level encryption key management and usually increases implementation complexity. Snowflake-managed keys are not customer-rotated through SQL commands as described. Finally, storing keys in Snowflake is not a valid external key management strategy.
Relevant Snowflake documentation and best practices include Snowflake's documentation on data encryption, key hierarchy, and Tri-Secret Secure, which explains how Snowflake combines its own key management with a customer-managed key from a supported external KMS to provide additional control over encrypted data.
- A. Correct.
Correct. Tri-Secret Secure is designed for customers that need additional control over key management. Snowflake already encrypts data using hierarchical key management, and Tri-Secret Secure adds a customer-managed key from an external key management service so access to data depends on both Snowflake-controlled and customer-controlled key material. If the customer disables or revokes the external key, Snowflake cannot use that key to decrypt the protected account data. This meets the requirement to control root key material while preserving standard Snowflake usage patterns with minimal application changes.
- B. Incorrect.
Incorrect. Client-side encryption protects files before they are loaded, but it does not replace Snowflake's platform encryption at rest. Also, making all applications handle encryption and key management themselves increases operational complexity and typically requires application and pipeline changes. This does not best satisfy the requirement to continue using standard Snowflake features with minimal code changes.
- C. Incorrect.
Incorrect. Customers do not directly manage or rotate Snowflake-managed account master keys through SQL in the way described. Snowflake manages its native encryption hierarchy. This option reflects a common misconception that Snowflake exposes low-level key lifecycle operations for customer control similar to some infrastructure platforms.
- D. Incorrect.
Incorrect. Storing encryption keys inside Snowflake defeats the purpose of externalized key control for data-at-rest protection. If the keys needed to decrypt Snowflake data were stored in Snowflake tables, they would not provide an independent control point. Role-based access control governs object access, not the external root of trust required for customer-controlled encryption key revocation.