Data Collaboration practice questions

The provider must enable 'Global Sharing' on the specific share object and provide the consumer's account locator.

Why it fails: Snowflake does not feature a single-click 'Global Sharing' toggle that bypasses regional boundaries for direct shares. Data sharing is fundamentally a region-locked operation. Providers must utilize Snowflake's database replication features to move the data into a secondary account located in the target region before the share can be successfully created and consumed.

The partner must create a Reader Account within the provider's US-East region to access the data without replication.

Why it fails: While a Reader Account can be created in the provider's region, it does not solve the consumer's need to have data integrated into their own EU-West account environment. The consumer would be forced to work in a separate account, which often contradicts data governance and consolidation policies. Regional replication remains the standard practice for seamless cross-region integration.

The provider should use the Snowflake Marketplace to list the data as 'Private' which automatically handles cross-region movement.

Why it fails: The Snowflake Marketplace does not automatically move or replicate data across regions upon a consumer request. Even with private listings, the underlying data must be physically present in the consumer's region. Providers still need to manage the replication of the data to the appropriate regions to fulfill requests from consumers outside their home region.

Marketplace listings require consumers to pay for the data using Snowflake credits directly from their account balance.

Why it fails: While Snowflake supports paid listings, it does not force all transactions to occur via Snowflake credits. Many listings are free, and for paid ones, providers can choose different billing models. The acquisition of data is separate from the compute credits used to query it, and financial arrangements are often handled via the Marketplace's monetization framework.

Marketplace listings provide automatic data replication to all regions where Snowflake has a presence.

Why it fails: Listing data on the Marketplace does not trigger automatic replication to all global regions. Providers must still proactively replicate their data to specific regions where they wish to offer their listings. Snowflake provides the platform for discovery, but the physical movement of data across cloud boundaries remains a managed task for the data provider.

Marketplace listings are the only way to share Secure User-Defined Functions (UDFs) with external accounts.

Why it fails: Secure User-Defined Functions can be shared using Direct Sharing, Private Exchanges, or the Marketplace. There is no technical limitation that restricts the sharing of Secure UDFs solely to the Marketplace. As long as the function is marked as secure and the necessary grants are applied to the share, any sharing method will work.

The provider must create a single database and move both tables into it before sharing, as Snowflake shares cannot span databases.

Why it fails: Snowflake shares are capable of including objects from multiple databases. There is no requirement to consolidate tables into a single database. The provider simply needs to grant the appropriate usage privileges on every database and schema that contributes to the objects included in the share, ensuring a functional dependency chain for the consumer.

The provider must grant the consumer account the 'ACCOUNTADMIN' role to resolve cross-database permission conflicts.

Why it fails: Granting ACCOUNTADMIN to an external consumer is impossible and would be a catastrophic security failure. Sharing is designed to be highly granular and secure. Cross-database permissions are handled by the provider's grants to the share object itself, not by elevating the consumer's privileges within the provider's own account or vice versa.

The provider must disable the 'Data Optimization' flag on the consumer's account to allow the cross-database join to execute.

Why it fails: There is no 'Data Optimization' flag that controls cross-database joins in the context of sharing. Performance and optimization are handled automatically by Snowflake's query engine. The constraints around sharing views are strictly related to security (Secure Views) and object availability (ensuring all referenced schemas are granted to the share).

Internal Stages

Why it fails: Internal stages cannot be added to a Snowflake share. Sharing is designed for structured data access via SQL, not for direct file system access. To share files, a provider would typically load the data into a table or use an external stage with appropriate cloud provider permissions, rather than sharing a Snowflake internal stage.

Virtual Warehouses

Why it fails: Virtual Warehouses are compute resources and cannot be shared between accounts. Each account (provider and consumer) must use its own virtual warehouses to process data. When a consumer queries shared data, they use their own credits and warehouse, ensuring that the provider does not pay for the consumer's compute activity.

The consumer will see the updates after the provider manually executes a 'REFRESH SHARE' command.

Why it fails: There is no 'REFRESH SHARE' command required to propagate data changes. The synchronization is handled automatically by Snowflake's global metadata layer. The only time a provider needs to act is if they are adding new tables or schemas to the share, which requires new GRANT statements, but existing data updates are automatic.

The updates will be visible after the next scheduled metadata synchronization, which occurs every 24 hours.

Why it fails: Snowflake sharing does not rely on a periodic synchronization or polling mechanism. It is a real-time data access feature. The 24-hour delay concept does not exist in Snowflake's sharing model, as the architecture is designed to provide immediate access to the provider's current state of data without latency.

The consumer must drop and recreate the shared database to see any new data changes.

Why it fails: Dropping and recreating the shared database is unnecessary and would disrupt consumer operations. The link between the provider's share and the consumer's database remains active and dynamic. As the provider's data evolves, the consumer's queries will automatically include the most recent committed data without any intervention required.

SYSADMIN

Why it fails: While SYSADMIN is a powerful role for managing databases and warehouses, it does not have the inherent ability to create shares by default. In the Snowflake hierarchy, sharing is considered an account-level security function rather than a standard system administration task, though a SYSADMIN can be granted the privilege if necessary.

USERADMIN

Why it fails: The USERADMIN role is focused strictly on the creation and management of users and roles within the account. It does not have privileges related to data objects or account-level sharing configurations. Its scope is limited to identity management and does not extend to the data collaboration features of Snowflake.

PUBLIC

Why it fails: The PUBLIC role is the lowest-level role and is automatically granted to every user. It has no administrative privileges and certainly cannot create or manage shares. Allowing the PUBLIC role to share data would represent a massive security risk, as any user could potentially expose internal data to external accounts.

Configure a Snowpipe instance to push data to the consumer's account.

Why it fails: Snowpipe is designed for loading data into internal stages, not for pushing data to external accounts. Data sharing in Snowflake is based on a metadata pointer mechanism, meaning the provider does not push data but instead exposes access to their own storage, rendering Snowpipe unnecessary for this purpose.

Use a Data Marketplace listing with a scheduled replication task.

Why it fails: Marketplace listings do not require scheduled replication tasks to update data. Snowflake's architecture handles updates via a metadata layer, ensuring that the consumer sees the latest committed state of the data automatically without needing background replication jobs that would consume unnecessary compute and storage resources.

Export data to a cloud bucket and share the bucket URI.

Why it fails: Exporting data to a cloud bucket breaks the live connection model of Snowflake sharing. This process introduces latency, security risks associated with managing bucket access keys, and the need for consumers to manually import or query the external data, which contradicts the goal of seamless, live collaboration.

The consumer must provide their cloud storage credentials to the provider.

Why it fails: Snowflake data sharing does not require cloud storage credentials to be exchanged. The architecture relies on Snowflake's internal metadata sharing, which keeps data in the provider's storage. Sharing credentials would be a significant security risk and is completely unnecessary for the operation of the platform's sharing features.

The consumer must run a replication job to copy the data locally.

Why it fails: Data sharing in Snowflake is designed to avoid copying data. Running a replication job to import data locally is unnecessary and counterproductive, as it defeats the benefit of live, real-time data access. The consumer queries the provider's data directly via the established share and local database reference.

Apply a masking policy to the PII column that returns NULL for the consumer's role.

Why it fails: Masking policies can mask data based on the querying role, but in a share, the consumer accesses data using a role in their own account. Masking policies are applied in the provider's account, but the consumer's role is not recognized in the provider's account. Therefore, a masking policy cannot be used to selectively hide data from a specific consumer in a share. This approach does not work for shares.

Use column-level security by granting SELECT on only the non-PII columns to the share.

Why it fails: Snowflake does not support granting SELECT on individual columns to a share. Privileges are granted at the table level. While column-level security can be achieved with masking policies or secure views, you cannot grant SELECT on a subset of columns directly to a share. This option is incorrect because the privilege model does not allow column-specific grants to shares.

Revoke SELECT on the table from the share and re-grant SELECT on all columns except the PII column.

Why it fails: As with option A, Snowflake does not support granting SELECT on individual columns. The GRANT SELECT statement applies to the entire table. You cannot specify a column list in a grant to a share. Therefore, this approach is not valid. The correct method is to use a secure view to project only the allowed columns.

Create a database role in the provider account, grant it to the consumer, and add the database role to the share.

Why it fails: Database roles are internal to a provider account and cannot be granted directly to a consumer account. The supported path is to grant the share the needed privileges and add the view. Adding a database role to a share is not a valid operation and does not expose the base table to the view's execution context in the required way.

Enable the share to use the provider's account-level privileges by setting the share to 'privileged mode'.

Why it fails: Snowflake has no 'privileged mode' setting for shares. Shares are always accessed with the provider-defined privileges that were explicitly granted to the share. Secure views are the supported mechanism for indirect access to base tables. Inventing a privileged mode would bypass the need for careful privilege grants and is not a real Snowflake feature.

Grant the consumer account's role the SELECT privilege on the underlying table.

Why it fails: Granting SELECT on the underlying table to the consumer's role is unnecessary and would violate the security goal of sharing through a secure view. The consumer never references the base tables directly, and the share is account-to-account, not role-to-role. Privileges flow through the share's granted objects, so this approach does not help the consumer query the view.

Add the underlying table to the share.

Why it fails: Adding the underlying table to the share would allow the consumer to query it directly, which is not the intent. Secure views are designed to provide filtered or transformed access without exposing the base table. Including the table would grant unnecessary access and potentially leak sensitive data, so this is not the correct minimal step.

Grant the consumer's role SELECT on the underlying table.

Why it fails: Granting the consumer's role direct SELECT on the underlying table would violate the principle of least privilege and is not required for a secure view. The view owner's privileges are used for the view's underlying objects, so the consumer does not need direct access. This approach would also expose the raw table data, defeating the purpose of the secure view.

Create a database role that owns the view and grant it to the consumer.

Why it fails: Creating a database role and granting it to the consumer would give the consumer the ability to manage the view, which is excessive. The consumer only needs to query the view. The view owner's privileges are sufficient for accessing the base table. This step is unnecessary and could introduce security risks by granting ownership privileges.

Create a secure view and grant SELECT on the underlying table to the consumer's role.

Why it fails: Granting SELECT on the underlying table would allow the consumer to access all rows, not just a subset. The provider should not grant direct access to the table; instead, the view should be added to the share, and the consumer accesses only the view. This option defeats the purpose of row-level filtering and is insecure.

Create a secure view that uses a mapping table to map account names to regions, and add the view to the share.

Why it fails: While a mapping table could work, it requires the provider to maintain a separate table that maps accounts to regions. This is more complex and less dynamic than using CURRENT_ACCOUNT() directly in the view. The scenario does not mention a mapping table, and using CURRENT_ACCOUNT() is the standard, simpler approach for account-based filtering.

Create a regular view with a WHERE clause that uses CURRENT_ACCOUNT() to filter rows, and add the view to the share.

Why it fails: A regular view is not allowed in a share because it exposes the underlying table definition and can leak information. Snowflake requires secure views for sharing to protect the provider's data. Even if a regular view could be added, it would not provide the necessary security and would be rejected. Secure views are mandatory for sharing views.

Grant SELECT on the secure view to the share.

Why it fails: Granting SELECT on the secure view to the share is indeed necessary for the consumer to query the view. However, the question states that the provider has already added the secure view to the share, which implicitly includes the necessary grants. But in practice, adding an object to a share does not automatically grant privileges; the provider must explicitly grant SELECT. Since the question says 'added a secure view to it,' it implies the view is in the share but privileges may not be granted. However, the two additional steps are granting USAGE on the database/schema and adding the consumer account. Granting SELECT is also required, but it is not one of the two additional steps because it is part of adding the object to the share? Actually, in Snowflake, when you add an object to a share, you must also grant privileges on that object to the share. The question says 'added a database and a secure view to it' — that means the objects are in the share, but privileges are separate. So granting SELECT is necessary. But the question asks for two additional steps; granting USAGE on the database/schema and adding the consumer account are two, but granting SELECT is also necessary. However, the question implies that the provider has already added the database and secure view, which typically includes granting the necessary privileges? In Snowflake, you cannot add an object to a share without also granting the required privileges? Actually, you can add a database to a share using ALTER SHARE ... ADD DATABASE, but that does not grant USAGE on the database. You must separately grant USAGE on the database and schema, and SELECT on the objects. So granting SELECT is also required. But the question says 'added a database and a secure view to it' — that means the objects are in the share, but privileges are not automatically granted. So the provider must grant USAGE on database and schema, and SELECT on the view, and add the consumer account. That's three steps. But the question asks for two. So perhaps the intended answer is A and B, assuming that adding the view to the share already includes the SELECT grant? That is not accurate. Let's check: In Snowflake, to share a view, you must grant SELECT on the view to the share. You cannot add a view to a share without granting SELECT? Actually, you can add a view to a share using ALTER SHARE ... ADD VIEW, but that does not grant SELECT. You must separately grant SELECT. So granting SELECT is a required step. The question says 'added a database and a secure view to it' — that might mean the objects are in the share, but privileges are not granted. So the two additional steps could be: grant USAGE on database/schema, and grant SELECT on the view. But then adding the consumer account is also required. That's three. The question asks for two. To resolve, I need to ensure the question is unambiguous. Let's rephrase: The provider has created the share and added a database and a secure view to it. Which two additional steps must the provider perform? The steps are: grant USAGE on database and schema to the share, grant SELECT on the view to the share, and add the consumer account. That's three. So the question is flawed. I need to adjust the scenario to have exactly two additional steps. Perhaps the provider has already granted USAGE on the database and schema, and added the consumer account, but forgot to grant SELECT on the view. Then the two steps would be? No. Let's redesign: The provider has created the share, added the database and view, and granted USAGE on database and schema, and granted SELECT on the view. Now they need to add the consumer account. That's one step. Not two. Alternatively, the provider has created the share, added the database and view, but has not granted any privileges. Then the two steps could be: grant USAGE on database and schema, and add the consumer account. But granting SELECT is also required. So it's three. To make it two, I can say the provider has already granted SELECT on the view to the share. Then the two steps are: grant USAGE on database and schema, and add the consumer account. That works. So I'll modify the stem: 'The provider has created the share, added a database and a secure view to it, and granted SELECT on the secure view to the share.' Then the two additional steps are A and B. I'll adjust the stem accordingly.

Grant USAGE on the share to the consumer's role.

Why it fails: The consumer does not need to be granted USAGE on the share by the provider. Instead, the consumer grants IMPORTED PRIVILEGES on the shared database to their own roles. The provider's responsibility is to add the consumer account to the share and grant the necessary privileges on the shared objects. Granting USAGE on the share to a consumer role is not a valid step in the provider's process.

Create a reader account for the consumer.

Why it fails: Reader accounts are used when the consumer does not have a Snowflake account. In a direct share with an existing Snowflake consumer, a reader account is not required. The provider would only create a reader account if the consumer lacks a Snowflake account. This step is unnecessary here.

GRANT IMPORTED PRIVILEGES ON DATABASE shared_db TO ROLE analyst_role;

Why it fails: IMPORTED PRIVILEGES is a privilege that can be granted on a shared database to allow a role to use the privileges granted by the provider, but it is not the only step. In practice, consumers typically grant USAGE on the database and schema, and SELECT on objects. IMPORTED PRIVILEGES is often used when the provider has granted specific privileges to the share. However, the fundamental privilege for visibility is USAGE.

GRANT SELECT ON DATABASE shared_db TO ROLE analyst_role;

Why it fails: SELECT cannot be granted at the database level in Snowflake. Privileges like SELECT apply to tables, views, and other specific objects. Granting SELECT on a database is invalid syntax. The consumer must grant USAGE on the database and schema, then SELECT on the specific tables or views they want the role to query.

GRANT OWNERSHIP ON DATABASE shared_db TO ROLE analyst_role;

Why it fails: Ownership of a shared database cannot be transferred to a role in the consumer account. The database is created from a share and remains owned by the consumer account's share mechanism. Granting ownership is not possible and would not be the correct way to provide query access. The consumer grants USAGE and SELECT as needed.

Grant REFERENCES on the view to the share, then grant SELECT on the view to the share.

Why it fails: REFERENCES is used to allow a role to create a foreign key referencing a table or view, not to enable data access through a share. Granting REFERENCES does not make the view's data available to consumers. The correct privilege to include a view in a share is SELECT, not REFERENCES. This step would be unnecessary and would not achieve the goal.

Grant USAGE on the database and schema to the share, then grant SELECT on the view to the share.

Why it fails: Granting SELECT on the view to the share is necessary, but the provider has already granted USAGE on the database and schema. Repeating that step does not address the core requirement: the share must be granted SELECT on the specific view. Without that grant, the view is not accessible to consumers even if database and schema usage are in place.

Grant USAGE on the view to the share. Views do not require SELECT privileges to be shared.

Why it fails: USAGE is a privilege applicable to databases, schemas, and other objects, but not to views for the purpose of granting query access. Views require SELECT to be queried. Granting USAGE on a view is not valid or sufficient. Consumers would be unable to query the view if only USAGE were granted, so this option fails to provide the necessary access.

SELECT on the underlying base table.

Why it fails: Granting SELECT on the base table would expose all rows, including those outside the approved region, defeating the purpose of the secure view. The provider should share only the view so the region filter is enforced and the base table remains hidden from the consumer.

REFERENCES on the lookup table.

Why it fails: REFERENCES is used to create foreign keys, not to enable view execution or reading data. It does not grant query access and would not help the consumer run the secure view. This distractor confuses a constraint-related privilege with the read privileges required for sharing.

OWNERSHIP on the secure view.

Why it fails: OWNERSHIP transfers control of the view and would let the consumer alter or drop it, which is inappropriate for a sharing relationship. The provider must retain ownership to keep managing the view and its filters. Consumers only need SELECT to query, never ownership of shared objects.

Add the database and schema to the share.

Why it fails: Adding the database and schema to the share is not a valid operation; shares contain privileges, not objects like databases or schemas. The provider must grant USAGE on the database and schema to the share. Simply adding the table is insufficient. This option misinterprets how shares are configured.

Grant SELECT on the table to the consumer's role.

Why it fails: The consumer's role cannot be granted direct privileges on the provider's table. Sharing is done via the share object, not by granting privileges to consumer roles. The provider cannot grant SELECT to a role in another account. The correct approach is to ensure the share includes the necessary USAGE privileges on the database and schema.

Recreate the share and add the table again.

Why it fails: Recreating the share and adding the table again would not solve the missing USAGE privileges on the database and schema. The table might be listed, but without USAGE on the parent objects, the consumer cannot access it. This action is unnecessary and disruptive. The provider should instead grant the required privileges to the share.

Add the consumer account to the share using ALTER SHARE ... ADD ACCOUNT.

Why it fails: Adding the consumer account to the share is necessary for the consumer to mount and access the shared database, but the question asks specifically about actions required to share the secure view while hiding its definition and base tables. Adding the account is a separate step from object-level grants and secure view creation. Without the account, the share cannot be consumed, but the hiding requirement depends on the secure view and grants.

Grant REFERENCES on the base tables to the share so the view can be validated.

Why it fails: REFERENCES is used for foreign key constraints, not for view resolution in shares. A shared view executes with the view owner's privileges, so the consumer does not need REFERENCES or SELECT on base tables. Granting REFERENCES to a share would not enable queries against the view and could inadvertently expose metadata about the base tables, which contradicts the requirement to hide them.

Grant SELECT on the base tables orders and customers to the share so the view can resolve.

Why it fails: Consumers do not need privileges on base tables referenced by a shared view. Privileges are checked against the view owner's rights at view execution time, not the consumer's. Granting SELECT on the base tables to the share would actually expose those tables directly to the consumer, defeating the goal of hiding underlying data and making the secure view encapsulation pointless.

Grant USAGE on the database and schema to the share.

Why it fails: Granting USAGE on the database and schema to the share is necessary for the consumer to see the database and schema, but it is not one of the two steps asked here if the focus is on adding the table and account. However, in practice, it is often required. The question specifies the provider has already granted SELECT on the table, but not that they added the table or account. The two essential steps are adding the table and adding the account.

Create a database from the share in the consumer account.

Why it fails: Creating a database from the share is a consumer-side action, not a provider step. The provider cannot perform this in the consumer account. This option confuses the roles of provider and consumer. The provider's responsibility ends with making the share available; the consumer then creates a database from it.

Grant the SHARE object the USAGE privilege on the consumer account.

Why it fails: There is no USAGE privilege on an account that can be granted to a share. This option invents a privilege and a direction of grant that does not exist. Shares are added to accounts, not granted USAGE on accounts. This would not be a valid step in the sharing process.

A share with the GRANT OPTION disabled.

Why it fails: The GRANT OPTION is not a valid parameter for shares. Shares are configured by granting privileges to the share object, and consumers cannot re-share unless they have the CREATE SHARE privilege and the provider has granted them the ability to do so. There is no GRANT OPTION on shares. This option is technically incorrect.

Secure Data Sharing with a direct share.

Why it fails: Direct shares provide read-only access but do not inherently prevent the consumer from re-sharing if they have the necessary privileges. By default, consumers cannot re-share, but if they are granted the ability to create shares, they might. The provider should use a feature that explicitly restricts re-sharing. Direct shares alone do not enforce this.

A read-only database created from a share.

Why it fails: A read-only database is what the consumer creates from a share, but it does not prevent re-sharing. The consumer could potentially create a new share from that database if they have the necessary privileges. The provider needs to ensure the consumer lacks the ability to re-share. This option describes the consumer's view, not the provider's control.