ARA-C01 Question 218
Single answerViewsA financial services company has a secure data-sharing requirement between its producer account and several consumer accounts. The producer exposes customer transaction data through a SECURE VIEW that masks a proprietary risk-scoring formula embedded in the view definition. The underlying base tables are expected to evolve over time as new columns are added and some columns are renamed during controlled releases. Architects want to minimize downstream breakage in consumer queries while preserving the confidentiality guarantees of the shared object. Which approach should the architect recommend?
- A
Create the SECURE VIEW with an explicit column list and explicitly reference base table columns in the SELECT; manage schema changes through versioned view updates instead of using SELECT *.
- B
Create a non-secure view using SELECT * so that new columns automatically appear for consumers without requiring any maintenance.
- C
Replace the SECURE VIEW with a materialized view so consumers cannot infer the underlying logic and schema changes will automatically propagate.
- D
Create the SECURE VIEW with SELECT * so the view dynamically tracks base table schema changes while keeping the definition hidden from consumers.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a SECURE VIEW with an explicit, curated projection and treat the view as a stable contract for consumers. In Snowflake, secure views are specifically intended to limit exposure of underlying table structures and view logic, which is important when sharing data externally or across account boundaries. From an architecture perspective, explicit column definitions are preferred over SELECT * for governed interfaces because they reduce unintended impact from schema drift and make release management predictable. This aligns with Snowflake best practices around secure data sharing, secure views, and view design hygiene. Relevant Snowflake documentation includes guidance on CREATE VIEW / secure views and general recommendations to avoid SELECT * in durable interfaces where schema evolution must be controlled.
- A. Correct.
Correct. In Snowflake, secure views are designed to protect underlying logic and are appropriate for data sharing when the provider must prevent exposure of sensitive implementation details. Using an explicit column list and explicit projections is the recommended design when schema stability matters. Views should not rely on SELECT * in production architectures because schema evolution in base tables can introduce unexpected behavior, break downstream assumptions, or fail when referenced columns are renamed or dropped. Managing change through controlled, versioned view updates provides predictability for consumers.
- B. Incorrect.
Incorrect. A non-secure view does not provide the same confidentiality guarantees as a secure view, which is a key requirement in this scenario. In addition, using SELECT * is not a robust strategy for shared interfaces. Even if new columns are desired, automatic propagation can create compatibility issues for consuming applications and does not protect the proprietary risk-scoring logic as well as a secure view.
- C. Incorrect.
Incorrect. Materialized views are intended primarily for query performance optimization on precomputed results, not as a replacement for secure views in data sharing designs that require hiding implementation details. They also have functional restrictions and are not the correct architectural control for protecting embedded business logic. Schema changes do not simply become a maintenance-free interface by using a materialized view.
- D. Incorrect.
Incorrect. Although a secure view helps hide implementation details, using SELECT * is still a poor architectural choice for a stable shared contract. Snowflake resolves the view definition at creation time rather than treating it as an endlessly self-updating contract for arbitrary schema changes. Renaming or dropping underlying columns can still invalidate the view or require maintenance, and automatic inclusion of new columns is not an appropriate guarantee to design around for consumer-facing interfaces.