ARA-C01 Question 340
Single answerBenefits, limitations, propertiesA global financial services company is redesigning its Snowflake data sharing strategy. It wants to distribute near-real-time position and risk data to several external partners without copying data into each partner environment. The architecture team is considering Secure Data Sharing. However, some partners want to create their own transformed summary tables from the shared data inside the provider's account, and another partner asks whether they can use Time Travel on the shared objects if a report is generated incorrectly. Which statement best describes the benefits and limitations of Secure Data Sharing in this scenario?
- A
Secure Data Sharing lets consumers query the provider's live data without data copying, but consumers cannot create persistent tables in the provider account from shared data and do not get independent Time Travel on the shared objects.
- B
Secure Data Sharing copies the provider's data into each consumer account to enable isolation, which allows each consumer to use Fail-safe and Time Travel independently on the shared tables.
- C
Secure Data Sharing allows consumers to update shared tables as long as the provider grants OWNERSHIP on the shared database, making it suitable for collaborative write-back use cases.
- D
Secure Data Sharing supports zero-copy access to live data, and consumers can create their own databases from the share with read-only objects; however, shared data cannot be cloned by the consumer into writable objects in the consumer account.
Show answer and explanation
Correct answer: A
Explanation
Secure Data Sharing is commonly used when an organization wants to expose live Snowflake data to internal or external consumers without ETL duplication. Its major benefit is zero-copy sharing of current data, which reduces latency and storage duplication while allowing the provider to centrally manage source data. The consumer creates a database from the share and can query shared objects as read-only objects.
Key limitations and properties relevant to this scenario:
- Shared objects are read-only for the consumer; Secure Data Sharing is not a collaborative write-back mechanism.
- The consumer does not own the shared tables/views, so lifecycle properties such as retention and object management remain under provider control.
- Consumers do not get independent Time Travel semantics on the shared objects as though they owned them; access is governed by the provider's source objects and sharing configuration.
- If consumers need writable derived data, they can create their own tables in their own account from the shared data (for example, using CREATE TABLE AS SELECT), but that is distinct from modifying the shared objects themselves.
These points align with Snowflake documentation on Secure Data Sharing, which emphasizes live read-only access, no data copy for the shared objects, and provider-controlled management of the shared source data.
- A. Correct.
Correct. Secure Data Sharing provides live, read-only access to data without physically copying the underlying data into the consumer account. This is a key benefit for near-real-time distribution. However, consumers cannot create persistent tables inside the provider's account from shared data because they only receive read-only access through a shared database in their own account. In addition, Time Travel behavior is tied to the provider-managed source objects rather than giving consumers independent ownership-based Time Travel controls over the shared objects.
- B. Incorrect.
Incorrect. This describes a common misconception. Secure Data Sharing is specifically designed to avoid copying data between accounts. Consumers access the provider's current data through metadata pointers and permissions, not replicated physical copies for standard sharing. Because the consumer does not own the shared objects, they do not independently control retention, Fail-safe, or Time Travel settings for those shared tables.
- C. Incorrect.
Incorrect. Shared objects are read-only to consumers. Secure Data Sharing is not intended for bidirectional collaboration or write-back workflows. Granting OWNERSHIP on a shared database to a consumer is not how data sharing works; providers create shares and grant access to database objects, but consumers cannot update the provider's underlying shared tables.
- D. Incorrect.
Incorrect. The first part is true: Secure Data Sharing provides zero-copy, read-only access and consumers create a database from the share in their own account. The incorrect part is the claim that shared data cannot be cloned into writable objects in the consumer account. A consumer can use CTAS or similar patterns to materialize data from a share into its own tables, subject to privileges and costs, creating writable objects in the consumer account. The limitation is that the shared objects themselves remain read-only.