ARA-C01 Question 65
Single answerData lineage and dependenciesA Snowflake architect is asked to assess the downstream impact of changing a shared conformed dimension table, PROD.CORE.DIM_CUSTOMER. The table is referenced by several secure views, dynamic tables, and data products used by multiple business units. The architect needs a reliable way to identify which Snowflake objects currently depend on DIM_CUSTOMER so the team can plan testing before making the change. Which approach provides the most accurate object dependency analysis within Snowflake?
- A
Query ACCOUNT_USAGE.OBJECT_DEPENDENCIES for references to PROD.CORE.DIM_CUSTOMER to identify dependent Snowflake objects
- B
Query ACCOUNT_USAGE.ACCESS_HISTORY for all statements that referenced PROD.CORE.DIM_CUSTOMER and treat those objects as dependencies
- C
Use SHOW TERSE OBJECTS and filter object names containing DIM_CUSTOMER to find downstream dependencies
- D
Review TASK_HISTORY and DYNAMIC_TABLE_GRAPH_HISTORY only, because secure views and tables are not included in dependency tracking
Show answer and explanation
Correct answer: A
Explanation
For Snowflake impact analysis and lineage of object definitions, ACCOUNT_USAGE.OBJECT_DEPENDENCIES is the primary metadata source for identifying object-to-object dependencies. This is the best fit when an architect must determine what downstream Snowflake objects are affected by a planned schema or logic change to a source object. By contrast, ACCESS_HISTORY is query-centric and useful for understanding who accessed what data and for certain lineage investigations, but it does not represent the same thing as persisted dependency metadata. Operational history views such as TASK_HISTORY or feature-specific views such as DYNAMIC_TABLE_GRAPH_HISTORY are complementary, not substitutes for dependency analysis. Snowflake documentation on Account Usage views and lineage/dependency metadata supports using OBJECT_DEPENDENCIES for dependency mapping and impact assessment.
- A. Correct.
Correct. ACCOUNT_USAGE.OBJECT_DEPENDENCIES is the Snowflake metadata view specifically designed to expose dependency relationships between supported Snowflake objects such as tables and views. For impact analysis, this is the most appropriate source because it tracks object-to-object dependencies rather than just query activity. This helps the architect identify downstream objects that directly rely on PROD.CORE.DIM_CUSTOMER and supports change planning.
- B. Incorrect.
Incorrect. ACCESS_HISTORY is useful for understanding data access patterns and lineage-like query behavior, but it is not the authoritative source for object dependency analysis. It shows which queries accessed an object and may include base objects touched during execution, but that is different from maintained dependency metadata between Snowflake objects. Using it alone can overstate impact by mixing ad hoc usage with true dependent object definitions.
- C. Incorrect.
Incorrect. SHOW commands and object name filtering do not provide dependency lineage. Filtering for object names containing DIM_CUSTOMER only finds naming matches, not actual references in object definitions. This is a common operational shortcut, but it is unreliable and misses dependencies where naming conventions differ.
- D. Incorrect.
Incorrect. TASK_HISTORY and DYNAMIC_TABLE_GRAPH_HISTORY can help analyze execution and refresh relationships for specific features, especially dynamic tables, but they do not replace general dependency metadata across views, tables, and other dependent objects. The statement that secure views and tables are not included in dependency tracking is inaccurate.