DAA-C01 Question 40
Select 2A retail analytics team wants to enrich its internal sales tables with third-party demographic data that is updated daily by an external provider. The team needs the provider to manage updates without copying files into the retailer's environment, and analysts must be able to query the external data alongside internal tables with minimal operational overhead. The retailer also wants to evaluate the data first, then make it available to multiple internal business units after procurement approval. Which TWO actions best meet these requirements?
- A
Subscribe to the provider's Listing from Snowflake Marketplace or a Private Listing so the retailer receives a shared database that the provider maintains.
- B
Ask the provider to export daily files to an external stage in the retailer account, then load them into internal tables with Snowpipe for near-real-time enrichment.
- C
After evaluation, publish the approved enriched dataset internally through the Internal Marketplace so other business units can discover and use it.
- D
Create a database from a data share, then update the provider's shared tables directly so the retailer can standardize the schema for all business units.
- E
Replicate the provider's shared database into writable retailer-managed tables immediately, because secure sharing does not support joining shared data with local tables.
Show answer and explanation
Correct answers: A, C
Explanation
The best solution is to use Snowflake Secure Data Sharing through a Listing, such as Snowflake Marketplace or a Private Listing, to access provider-maintained data without ETL or file movement. This gives the retailer a shared database that updates as the provider publishes changes. Analysts can query the shared data directly and join it with internal tables, which is a common enrichment pattern in Snowflake. After evaluation and procurement approval, the retailer can operationalize the enriched result and distribute it internally using the Internal Marketplace, which supports governed internal discovery and reuse of data products across business units. Key Snowflake best practices and documented behaviors relevant here include: shared data is accessed read-only by consumers; providers maintain the source data; consumers can create their own derived objects in local databases; and listings, including Marketplace, Private Listings, and internal listings, are standard distribution mechanisms for secure sharing and governed reuse.
- A. Correct.
Correct. Listings in Snowflake Marketplace and Private Listings are designed for secure data sharing without copying data into the consumer's environment. The provider continues to own and maintain the shared data, including updates, while the consumer accesses it as a database in their account. This satisfies the requirement for provider-managed daily updates and low operational overhead.
- B. Incorrect.
Incorrect. Exporting files to stages and ingesting them with Snowpipe is a valid ingestion pattern, but it does not meet the stated goal of minimizing operational overhead when secure data sharing is available. It also reintroduces data movement and pipeline management, which the scenario explicitly wants to avoid.
- C. Correct.
Correct. The Internal Marketplace is appropriate for distributing approved data products within an organization. After the retailer evaluates and approves the third-party data, it can expose the enriched dataset internally so multiple business units can discover and consume it in a governed way.
- D. Incorrect.
Incorrect. Consumer accounts cannot directly modify objects in a provider's shared database. Shared databases created from shares or listings are read-only to the consumer. If the retailer needs standardized derived objects, it should create its own views, secure views, or tables in its own database that reference the shared data, not update the provider's objects.
- E. Incorrect.
Incorrect. Shared data can be queried directly and joined with local tables in the consumer account. Immediate replication into writable retailer-managed tables is not required just to perform joins. This option reflects a common misconception that secure shares are isolated from local analysis workflows.