ADA-C01 Question 496
Single answerCreate, submit, manage, and modify a data listingA data provider has already published a paid data listing in Snowflake Marketplace that uses a secure share as the fulfillment method. After a compliance review, the provider must stop exposing one sensitive table, add a new approved table, and update the listing description to reflect the schema change. The provider wants existing consumers to retain access to the listing with minimal disruption, while ensuring new subscribers only receive the approved objects. Which action should the administrator take?
- A
Create a new listing with a new share that contains the approved objects, then unpublish the original listing so consumers can migrate manually.
- B
Modify the secure share to remove the sensitive table and add the approved table, then update the existing listing metadata and submit the changes if review is required.
- C
Convert the listing from a secure-share-based listing to a native app listing so object changes can be applied without affecting subscribers.
- D
Edit only the listing description and leave the share unchanged, because object-level changes are not allowed after a listing has been published.
Show answer and explanation
Correct answer: B
Explanation
In Snowflake, a data listing is the marketplace or private exchange presentation of shared data, but the actual objects delivered in a share-based listing are governed by the underlying secure share. When a provider needs to modify what subscribers can access, the correct operational step is to manage the secure share itself by adding or removing objects as needed, then align the listing metadata with the revised contents. For published listings, certain metadata changes and listing updates may require submission or review depending on the distribution context, but replacing the listing is not the default best practice when the fulfillment mechanism remains the same. This scenario tests the distinction between listing metadata management and share object management, which is central to creating, submitting, managing, and modifying Snowflake data listings. Refer to Snowflake documentation for Provider Studio/Marketplace listings, secure shares, and managing listing revisions for the specific review workflow applicable to public Marketplace versus private sharing contexts.
- A. Incorrect.
Incorrect. Creating a brand-new listing and unpublishing the original would introduce unnecessary disruption for existing consumers and change the listing identity. When the fulfillment method remains a secure share, the provider can manage the objects exposed through the underlying share and update the listing rather than forcing a manual migration unless there is a reason to replace the listing entirely.
- B. Correct.
Correct. For a listing backed by a secure share, the data actually exposed to consumers is controlled by the share. The administrator should update the share to remove the sensitive table and add the newly approved one, then update the listing details so the business description matches the delivered data. If the listing is a Marketplace listing and the change requires provider review workflow, the updated listing can need resubmission. This approach preserves the existing listing and minimizes disruption while ensuring future access reflects the approved shared objects.
- C. Incorrect.
Incorrect. A published listing cannot simply be converted from one fulfillment model to another as an administrative shortcut. Native Apps and share-based listings are different distribution mechanisms with different packaging and lifecycle requirements. This option reflects a misunderstanding of how listings are implemented.
- D. Incorrect.
Incorrect. Listing metadata alone does not control what subscribers can access. The underlying secure share determines the database objects delivered through the listing. Leaving the share unchanged would continue exposing the sensitive table to consumers, which fails the compliance requirement.