ADA-C01 Question 432
Single answerDomain 5.0: Data Sharing and Snowflake Marketplace (7%)A data provider publishes a Snowflake Marketplace listing that contains a secure view over several base tables in a provider-managed database. After a consumer installs the listing, the provider wants to release a schema change that adds a new sensitive column to one of the base tables. The provider must ensure existing consumers do not unexpectedly see the new column until the provider has validated the secure view definition and intentionally republishes the updated data product. Which action should the administrator take?
- A
Add the new column to the base table and rely on the consumer account's role-based access control to hide it until consumers grant themselves access.
- B
Add the new column to the base table, because changes to base tables are never visible through an existing secure view unless the consumer reinstalls the listing.
- C
Keep the secure view definition explicit instead of using SELECT *, validate the view output after the table change, and republish the listing only when the exposed columns are correct.
- D
Create a reader account for each consumer and apply masking policies there so Marketplace consumers cannot see newly added columns.
Show answer and explanation
Correct answer: C
Explanation
The key administrative concern is that Snowflake Marketplace listings are built on secure data sharing constructs, and consumers typically see provider-side changes to shared objects without needing to reload or reinstall data. Therefore, providers must design shared objects carefully. A secure view should explicitly project approved columns rather than using SELECT *, especially when the underlying tables may evolve. This lets the provider add columns to base tables for internal use or future releases without unintentionally exposing them to existing consumers. After validating the view and the data product, the provider can update or republish the listing intentionally. This follows Snowflake best practices for secure views, data sharing, and Marketplace publishing, where providers control exposure through the shared object definitions rather than consumer-side permissions.
- A. Incorrect.
Incorrect. In Marketplace and data sharing scenarios, consumers access only the objects exposed by the provider through shares/listings. RBAC in the consumer account does not govern whether a newly exposed column appears in a shared secure view; if the provider exposes it, consumers with access to the shared object can query it. This option reflects a common misconception that consumer-side role grants can be used to suppress provider-exposed shared columns.
- B. Incorrect.
Incorrect. This is factually wrong and dangerous operationally. If a secure view is defined with a pattern such as SELECT *, changes in underlying tables can affect the columns surfaced by the view, depending on how the view was defined and maintained. Consumers do not need to reinstall a listing for provider updates to shared data to become visible. Marketplace listings distribute live shared data products, so provider-side changes can affect consumers once published.
- C. Correct.
Correct. Best practice for provider-managed shares and Marketplace listings is to avoid SELECT * in secure views and instead explicitly enumerate columns. That allows the provider to control schema exposure when base tables change. After adding the sensitive column to the base table, the provider should validate that the secure view still exposes only intended fields, then republish the listing when ready. This approach prevents accidental disclosure and aligns with secure data sharing design principles.
- D. Incorrect.
Incorrect. Reader accounts are used to provide access to parties that do not already have their own Snowflake accounts, but they are not required for Snowflake Marketplace consumers and do not solve the core issue of accidental schema exposure through provider-defined shared objects. Masking policies can be useful in some designs, but creating reader accounts per consumer is not the appropriate control for this Marketplace publishing scenario.