SnowPro Advanced: Security Engineer Question 106
Single answerImplement, configure, and manage the customer-managed key component of Tri-Secret SecureA financial services company uses Snowflake Business Critical Edition with Tri-Secret Secure enabled in AWS. The security team must ensure that Snowflake data becomes inaccessible if the company disables its own encryption key, without deleting Snowflake metadata or changing account objects. During a quarterly key-management drill, they want to test the customer-managed key component with minimal operational change and a predictable recovery path. Which action should the security engineer take?
- A
Disable the customer-managed key in AWS KMS that is associated with the Snowflake account, then re-enable it after validation
- B
Rotate the customer-managed key material in AWS KMS and verify that all existing Snowflake data is immediately unreadable
- C
Revoke the Snowflake-generated key in the Snowflake account so that Tri-Secret Secure relies only on the customer-managed key
- D
Disable the cloud storage bucket encryption key used by the internal stage so that all account data is blocked
Show answer and explanation
Correct answer: A
Explanation
Tri-Secret Secure adds a customer-managed key component from the cloud provider's KMS to Snowflake's encryption architecture so that the customer has an additional cryptographic control point. In AWS, the practical way to test this control is to disable the AWS KMS key associated with the Snowflake account and then re-enable it after validation. This creates a reversible, controlled denial of access without requiring deletion of account objects or changes to Snowflake metadata. Rotating a KMS key is not equivalent to disabling it; rotation maintains decryptability of previously encrypted data. Likewise, customers do not manage Snowflake's own internal key hierarchy directly. Best practice is to validate recovery procedures, confirm the correct CMK association, and coordinate such drills carefully because disabling the CMK can impact data availability. This aligns with Snowflake guidance for customer-managed keys and Tri-Secret Secure in Business Critical environments.
- A. Correct.
Correct. In Tri-Secret Secure, Snowflake data protection depends on multiple key components, including the customer-managed key (CMK) in the cloud provider's key management service. Disabling the CMK in AWS KMS is the appropriate way to test the customer-controlled access boundary. When the CMK is disabled, Snowflake cannot use that key component to decrypt protected data, which makes the data inaccessible until the key is re-enabled. This is the standard operational control for validating the customer-managed key portion of Tri-Secret Secure.
- B. Incorrect.
Incorrect. Rotating key material in AWS KMS is a normal cryptographic hygiene practice, but rotation does not make existing Snowflake data immediately unreadable. Key rotation is designed to preserve access continuity while using new key versions for future encryption operations. It is not the correct method for simulating a customer-deny scenario in Tri-Secret Secure.
- C. Incorrect.
Incorrect. Customers do not revoke or replace Snowflake's internal key components to force Tri-Secret Secure behavior. Tri-Secret Secure is designed so that Snowflake-managed and customer-managed key components work together. The customer's operational control is over the cloud-provider CMK, not over Snowflake's internal keys. This option reflects a misunderstanding of the shared responsibility model.
- D. Incorrect.
Incorrect. Internal stage or bucket-level encryption settings are not the mechanism used to validate the customer-managed key component of Tri-Secret Secure for the Snowflake account. Disabling a storage encryption key for a specific stage or bucket would target a narrower storage path and would not represent the account-level customer-managed key control used by Tri-Secret Secure.