ADA-C01 Question 155
Single answerManage encryption keys in SnowflakeA financial services company uses Tri-Secret Secure with a customer-managed key hosted in its cloud provider's key management service. During a planned key rotation, the security team disables the old customer-managed key version before confirming that Snowflake has rewrapped account metadata with the new key version. Shortly afterward, administrators report failures when attempting to access data in the Snowflake account. Which action should the Snowflake administrator recommend to restore access with the LEAST disruption while maintaining the Tri-Secret Secure design?
- A
Re-enable the previously disabled customer-managed key version so Snowflake can access existing encrypted metadata, then complete rotation only after Snowflake confirms use of the new key version
- B
Disable Snowflake's internal encryption so that only the cloud provider key protects the data until rotation is complete
- C
Create a new Snowflake account and replicate all databases into it using the new customer-managed key
- D
Rotate the Snowflake internal master key from SQL to force immediate re-encryption of all data with the new customer-managed key
- E
Drop and recreate the affected databases because table data remains encrypted with old key material that cannot be recovered
Show answer and explanation
Correct answer: A
Explanation
This question tests applied knowledge of managing encryption keys in Snowflake when using Tri-Secret Secure. Snowflake always encrypts data at rest using its own key hierarchy. With Tri-Secret Secure, a customer-managed key in the cloud provider KMS is added as an additional control layer. A common operational risk during key rotation is disabling or deleting the prior key version before Snowflake has fully transitioned to the new version. If that occurs, Snowflake may be unable to decrypt account metadata or other protected material, leading to access failures. The correct recovery approach is to re-enable the old key version, restore service, validate that Snowflake has updated to the new key version, and only then retire the old version. This reflects Snowflake best practices for customer-managed key lifecycle management: rotate carefully, validate dependency cutover, and avoid prematurely disabling old key material. Relevant Snowflake documentation includes guidance for Tri-Secret Secure and customer-managed keys, especially around key rotation, key availability, and the impact of disabling key versions used by Snowflake.
- A. Correct.
Correct. In a Tri-Secret Secure configuration, Snowflake combines its own key hierarchy with the customer's cloud KMS key. If the customer-managed key version that Snowflake still needs is disabled too early, Snowflake may be unable to decrypt required metadata, causing access failures. The least disruptive recovery is to re-enable the prior key version, restore access, and only then complete rotation after validating Snowflake is using the new key version. This aligns with operational best practice for CMK rotation: do not retire or disable the old key material until dependent services have fully transitioned.
- B. Incorrect.
Incorrect. Customers cannot disable Snowflake's platform encryption, and Tri-Secret Secure is specifically designed to add customer control on top of Snowflake-managed encryption, not replace it. Snowflake encryption at rest is foundational and not an optional setting administrators can turn off during key rotation.
- C. Incorrect.
Incorrect. Although creating a new account may sound like a recovery path, it is unnecessary and highly disruptive for this scenario. The issue is access to encrypted metadata because the required customer-managed key version was disabled prematurely. Restoring that key version is the appropriate and least disruptive remediation. Replication also would not solve the immediate decryption problem in the affected account.
- D. Incorrect.
Incorrect. Snowflake administrators do not rotate Snowflake's internal master encryption keys through SQL commands, and there is no supported action that forces immediate re-encryption of all account data in this manner. This option reflects a common misconception that account encryption internals are directly customer-operated inside Snowflake.
- E. Incorrect.
Incorrect. The problem is not that the data is permanently unrecoverable; it is that Snowflake currently cannot access necessary encrypted components while the required customer-managed key version is disabled. Re-enabling the old key version typically restores access. Dropping and recreating databases would cause needless data loss and does not address the root cause.