SnowPro Advanced: Security Engineer Question 281
Single answerCloud provider implicationsA global company runs Snowflake in multiple regions and cloud providers to meet residency and disaster recovery requirements. The security engineer must design a data sharing approach for a finance dataset that contains highly sensitive information. The dataset must remain encrypted under customer control, and the company wants to avoid copying the data into another account whenever possible. Which approach best meets these requirements while accounting for cloud provider implications?
- A
Use Secure Data Sharing within the same cloud provider and region where possible, because the provider-specific infrastructure allows sharing without copying the underlying data while maintaining Snowflake-managed protections.
- B
Use database replication and failover groups across any cloud provider, because replication preserves a no-copy sharing model and keeps customer-controlled encryption keys attached to the shared dataset in all target accounts.
- C
Use a reader account in a different cloud provider, because reader accounts support direct cross-cloud secure sharing without data movement and inherit the provider-specific encryption keys from the source account.
- D
Use external tokenization only, because Snowflake secure sharing cannot be used for sensitive finance data on any cloud provider when customer-controlled encryption is required.
Show answer and explanation
Correct answer: A
Explanation
This question tests whether the candidate understands the practical security and architecture impact of Snowflake's cloud provider boundaries. Snowflake Secure Data Sharing provides a live, no-copy sharing model, but that model is constrained by deployment locality, especially same-region and same-cloud scenarios. When organizations need to share across clouds or certain regional boundaries, they typically must use replication-related features or other distribution patterns, which involve copying data rather than sharing a single underlying storage layer. From a security engineering perspective, this affects data residency, encryption strategy, operational risk, and compliance design. Relevant Snowflake documentation includes topics on Secure Data Sharing, cross-region/cross-cloud replication and failover groups, reader accounts, and Tri-Secret Secure/customer-managed key considerations. The best answer is the one that preserves the no-copy requirement while correctly recognizing cloud provider limitations.
- A. Correct.
Correct. Native Secure Data Sharing is designed to share live data without copying the underlying data, but this no-copy model applies within the same region and cloud platform. This is important for cloud provider implications: direct sharing behavior depends on Snowflake deployment boundaries. For highly sensitive data, this minimizes duplication and operational exposure. Snowflake security controls still apply, but customer-managed encryption key requirements must also be evaluated against supported account and cloud configurations.
- B. Incorrect.
Incorrect. Replication and failover groups do move metadata and data to another account/region/cloud as part of replication; they are not a no-copy sharing mechanism. They are used for business continuity and cross-region/cross-cloud availability scenarios, not as a substitute for native same-region secure sharing. Also, key management behavior is not simply 'attached to the shared dataset in all target accounts' in the way this option suggests.
- C. Incorrect.
Incorrect. Reader accounts are useful for sharing data with consumers who do not have their own Snowflake account, but they do not remove cloud and region constraints for native sharing. A reader account is associated with the provider/region context of the provider account and does not create direct no-copy cross-cloud sharing.
- D. Incorrect.
Incorrect. External tokenization can be part of a defense-in-depth strategy for sensitive data, but it is not true that secure sharing cannot be used for sensitive finance data. Snowflake supports secure sharing; the real design consideration is that direct no-copy sharing has region/cloud boundaries, and cross-cloud requirements typically require replication or data movement patterns rather than native no-copy sharing.