ARA-C01 Question 258
Single answerData at restA financial services company stores highly sensitive customer data in Snowflake and must meet an internal security requirement stating that encryption keys for data at rest must be managed and revocable by the company, not solely by Snowflake. The architecture team wants to minimize application changes and continue using standard Snowflake storage and table features. Which solution best meets this requirement?
- A
Enable Tri-Secret Secure so Snowflake data at rest is protected by a customer-managed key in addition to Snowflake-managed keys
- B
Use dynamic data masking on sensitive columns so the underlying encrypted data can only be decrypted by authorized roles
- C
Store all sensitive data in transient tables to reduce persistence of encrypted data files at rest
- D
Use client-side encryption before loading data so Snowflake no longer stores customer data at rest
- E
Replicate the database to another Snowflake region and rely on failover/failback to protect encrypted copies
Show answer and explanation
Correct answer: A
Explanation
The key requirement is customer control over encryption keys for Snowflake data at rest while preserving standard platform functionality. Snowflake encrypts data at rest by default, but when an organization specifically needs customer-managed and customer-revocable key participation, the appropriate solution is Tri-Secret Secure. This feature is intended for stricter compliance and security programs where the customer must maintain control of an additional key in the encryption process. Features such as masking policies, transient tables, and replication are important for data governance, retention, and resilience, but they do not satisfy the core requirement of customer-managed key control for data at rest. Relevant Snowflake guidance includes documentation on Snowflake encryption for data at rest and Tri-Secret Secure, which describes how customer-managed keys integrate with Snowflake's encryption architecture.
- A. Correct.
Correct. Tri-Secret Secure is designed for organizations that require customer control over a key used in Snowflake's encryption hierarchy for data at rest. It adds a customer-managed key, typically through a supported cloud key management service, to Snowflake's existing key model. This helps satisfy requirements for customer-controlled and customer-revocable encryption while allowing continued use of standard Snowflake storage and table capabilities with minimal application change.
- B. Incorrect.
Incorrect. Dynamic data masking controls query-time visibility of column values based on policy and role context, but it does not change how Snowflake encrypts data at rest or introduce a customer-managed encryption key for stored data. A team might choose this option because it is a security feature for sensitive data, but it addresses access control and presentation, not at-rest encryption key ownership.
- C. Incorrect.
Incorrect. Transient tables reduce or eliminate Fail-safe retention compared with permanent tables, but they do not provide customer-managed encryption keys or materially change Snowflake's fundamental encryption-at-rest model. This is a common misconception because reduced data retention is sometimes confused with stronger key control.
- D. Incorrect.
Incorrect. Client-side encryption can protect files before loading, but once data is loaded into Snowflake tables, Snowflake stores and manages the table data using its platform encryption architecture. In addition, broad use of client-side encryption would typically increase operational complexity and can conflict with the goal of continuing to use standard Snowflake table features with minimal application changes.
- E. Incorrect.
Incorrect. Cross-region replication improves business continuity and disaster recovery posture, but it does not address the requirement for customer-managed and customer-revocable encryption keys for data at rest. Replicated data remains subject to Snowflake's encryption mechanisms rather than introducing customer key control by itself.