ADA-C01 Question 481
Single answerBring users into the clean roomA provider has created a Snowflake Data Clean Room and needs to allow analysts from a partner company to use the clean room without giving them direct access to the provider's underlying tables. The provider wants the partner analysts to authenticate with their own Snowflake identities and only interact through the clean room's approved templates and policies. Which action should the administrator take to bring those partner users into the clean room correctly?
- A
Add the partner users directly to the provider account and grant them SELECT on the provider's source tables used by the clean room
- B
Invite the partner account to participate in the clean room and map the appropriate users or roles from that consumer account to the clean room so they can operate within the clean room boundary
- C
Create database roles on the provider side, share those roles through a standard secure data share, and have the partner users query the provider's clean room objects directly
- D
Create replicated copies of the provider's source tables in the partner account and let the partner users run their own SQL, relying on row access policies for protection
Show answer and explanation
Correct answer: B
Explanation
To bring users into a Snowflake Data Clean Room properly, the administrator should onboard the collaborating account and associate the correct users or roles from that participant account with the clean room, allowing them to authenticate with their own Snowflake identities. The clean room should mediate access through approved templates, policies, and collaboration controls rather than direct grants on source tables. In practice, this follows Snowflake clean room best practices: keep data in place, avoid direct object exposure, and use the clean room's participant management and governed execution model to control what each collaborator can do. Options that rely on direct table grants, standard data sharing, or copying data out of the clean room pattern are common misconceptions because they weaken the privacy and governance guarantees that clean rooms are intended to provide.
- A. Incorrect.
This is incorrect because adding external partner analysts as users in the provider account and granting direct SELECT on underlying tables bypasses the clean room governance model. The goal is to let the partner work through approved clean room templates, policies, and controls rather than exposing base data objects directly.
- B. Correct.
This is correct because bringing users into a clean room is done by onboarding the collaborating account into the clean room and assigning the appropriate participant users or roles from that account to work within the clean room experience. This preserves separation of identities, avoids direct exposure to provider tables, and ensures only approved analyses defined by the clean room are allowed.
- C. Incorrect.
This is incorrect because a standard secure data share is not the same as onboarding users into a Snowflake Data Clean Room. Sharing database roles and direct object access would expose objects outside the intended clean room interaction model. Clean rooms are designed to constrain how collaborators interact with data, not simply to share data objects.
- D. Incorrect.
This is incorrect because copying or replicating source tables to the partner account defeats a core clean room objective: preventing unrestricted access to underlying data. Even if row access policies are applied, the partner would still be operating on table copies outside the governed clean room workflow and approved template framework.