ARA-C01 Question 79
Single answerEncryptionA financial services company is migrating highly sensitive customer data to Snowflake. Its security policy requires that encryption keys be controlled by the company rather than solely by the cloud provider, and that the company must be able to immediately render encrypted Snowflake data unreadable if a key compromise is suspected. The architecture team wants the solution with the least operational complexity while still meeting this requirement. Which approach should the Snowflake architect recommend?
- A
Use Tri-Secret Secure so Snowflake encryption depends on both Snowflake-managed keys and a customer-managed key in the cloud provider's key management service.
- B
Create masking policies on all sensitive columns so that if a compromise occurs, Snowflake can prevent unauthorized users from reading the data.
- C
Encrypt files with client-side encryption before loading them into Snowflake stages, because this gives the company sole control of all encryption keys for data at rest in Snowflake.
- D
Use network policies and private connectivity so that if a compromise occurs, access can be cut off and the encrypted data becomes unreadable.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Tri-Secret Secure. Snowflake encrypts customer data at rest and in transit by default, but organizations with stringent regulatory or internal security requirements may need customer participation in key control. Tri-Secret Secure addresses this by requiring a customer-managed key from the cloud provider's key management service in addition to Snowflake-managed key material. This gives the customer a practical way to revoke key access and render data inaccessible while avoiding the complexity and limitations of trying to rely on masking, network controls, or file-level encryption alone. Snowflake documentation on data encryption and Tri-Secret Secure emphasizes that standard Snowflake encryption is always on, while Tri-Secret Secure is the feature specifically intended for customer-managed key involvement in protecting Snowflake data at rest.
- A. Correct.
Correct. Tri-Secret Secure is designed for customers who require additional control over encryption keys. Snowflake already encrypts data using hierarchical key management, and with Tri-Secret Secure, access to encrypted data also depends on a customer-managed key stored in the cloud provider's key management service. If needed, the customer can disable or revoke that key, which prevents Snowflake from using it to access protected data. This satisfies the requirement for customer-controlled key involvement with lower operational overhead than trying to redesign application-level encryption patterns.
- B. Incorrect.
Incorrect. Dynamic data masking helps restrict query-time visibility of sensitive values based on roles and policies, but it is not a substitute for encryption key control. Masking policies do not change how underlying data is encrypted at rest, and they do not provide a mechanism to render all encrypted data unreadable by revoking a cryptographic key.
- C. Incorrect.
Incorrect. Client-side encryption can protect files before they are uploaded, but once data is loaded into Snowflake tables, Snowflake manages storage encryption for table data. This option reflects a common misconception that stage/file encryption controls table storage encryption inside Snowflake. It also introduces significantly more operational complexity and does not directly address customer control over Snowflake's internal at-rest encryption keys for stored table data.
- D. Incorrect.
Incorrect. Network policies and private connectivity improve network security by limiting where connections can originate and reducing exposure over public internet paths, but they do not affect cryptographic key usage for Snowflake storage encryption. Blocking network access can reduce access pathways, but it does not make stored encrypted data unreadable through key revocation.