ARA-C01 Question 138
Single answerSharing between different Snowflake accountsA central data platform team maintains a Snowflake account in AWS us-east-1 and needs to provide a curated SALES database to two separate business units that each have their own Snowflake accounts in the same region. The business units must query the shared data without copying it, and the platform team must be able to revoke access quickly if needed. In addition, the platform team wants to ensure that only intended objects are exposed and that consumers cannot modify the shared data. Which approach should the architect recommend?
- A
Create a secure data share in the provider account, grant USAGE on the database and schema plus SELECT on the required tables/views to the share, add the two consumer account identifiers to the share, and have each consumer create a database from the share.
- B
Clone the SALES database into each consumer account so the data remains synchronized without requiring any additional configuration, and revoke access later by dropping the clones.
- C
Create database roles in the provider account, grant the roles to users in the consumer accounts, and allow the consumers to query the provider database directly.
- D
Unload the curated tables to an internal stage and grant the consumer accounts READ access to the stage so they can create external tables over the shared files.
Show answer and explanation
Correct answer: A
Explanation
For sharing data between different Snowflake accounts in the same region and cloud, Snowflake's secure data sharing is the recommended architecture. It allows the provider to share specific database objects such as tables, secure views, and certain secure UDF-supported constructs without physically copying the data. The provider creates a SHARE object, grants privileges like USAGE on the database and schema and SELECT on the intended objects, then adds the target consumer accounts. Consumers create a database from the share and can query the shared objects as read-only data. This aligns with the requirements for no-copy access, controlled object exposure, and rapid revocation.
This is consistent with Snowflake documentation and best practices around Secure Data Sharing: providers control exactly which objects are in the share, consumers cannot modify shared objects, and revocation is centrally managed by the provider. Cloning and staged file exchange are common misconceptions because they may seem to enable data access, but they do not provide the same governed, no-copy, read-only, cross-account sharing model.
- A. Correct.
Correct. Secure data sharing is the native Snowflake mechanism for sharing data between different Snowflake accounts without copying the underlying data. The provider creates a share, grants the necessary privileges on specific objects to that share, and adds one or more consumer accounts. Each consumer then creates a database from the share in its own account. This approach supports fast revocation by removing the account from the share or adjusting grants, and consumers get read-only access to only the objects explicitly granted.
- B. Incorrect.
Incorrect. Zero-copy cloning does not create a live shared object across independent Snowflake accounts in the way data sharing does. Cloning is used within an account and, in some supported scenarios, across databases under the same account context, but it is not the standard mechanism for cross-account governed sharing to separate organizations. It also creates an independent object namespace rather than a provider-controlled read-only share for consumers.
- C. Incorrect.
Incorrect. Database roles can be granted within Snowflake's role-based access control model, but they are not used to directly grant provider-account database access to users in separate consumer accounts for cross-account sharing. For different Snowflake accounts, the supported pattern is to expose objects through a share and let the consumer create a database from that share.
- D. Incorrect.
Incorrect. Internal stages are not the appropriate mechanism for governed cross-account sharing of queryable Snowflake tables without copying. Unloading data to files introduces data movement and operational overhead, and consumers would not be querying the provider's curated tables directly. This also weakens the provider's ability to centrally control exactly which relational objects are exposed through standard Snowflake sharing semantics.