ARA-C01 Question 68
Single answerObject taggingA healthcare company uses Snowflake across multiple business units and must enforce a consistent data governance program. The architecture team wants every new and existing table and view in the PROD database to be labeled with a data classification tag such as PUBLIC, INTERNAL, or PHI. They also want the process to minimize manual effort and support centralized reporting on which objects carry which classifications. Which approach should the architect recommend?
- A
Create a tag in Snowflake, grant the appropriate tag privileges to the governance role, apply the tag to schemas or individual objects as needed, and use ACCOUNT_USAGE views to report on tag references.
- B
Create masking policies named PUBLIC, INTERNAL, and PHI, attach them to the PROD database, and query QUERY_HISTORY to determine which tables inherited each classification.
- C
Store classification values in a control table and rely on object comments to manually document each table and view, because tags cannot be reported centrally.
- D
Create a network policy for each classification level and assign the policy to tables and views so that classification metadata can be inherited and audited centrally.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake object tagging. Tags are intended to label Snowflake objects with governance metadata such as sensitivity, owner, cost center, or regulatory classification. In a realistic enterprise architecture, the architect should create controlled tags, delegate tag administration through appropriate privileges, and standardize application of those tags to relevant objects. Snowflake also provides metadata surfaces for auditing and reporting on tag usage, making it suitable for centralized governance. This aligns with Snowflake best practices for data governance and classification. Relevant Snowflake documentation includes sections on object tags, tag privileges such as APPLY TAG, and metadata/reporting views like ACCOUNT_USAGE.TAG_REFERENCES.
- A. Correct.
Correct. Snowflake object tags are designed for attaching business metadata such as data classification to supported objects, including tables and views. A centralized governance role can be granted privileges such as CREATE TAG on a schema and APPLY TAG on accounts, databases, schemas, or objects as appropriate. Tags can then be set directly on objects, and centralized reporting is supported through metadata views such as ACCOUNT_USAGE.TAG_REFERENCES (and related metadata interfaces). This is the standard Snowflake-native approach for classification and governance reporting.
- B. Incorrect.
Incorrect. Masking policies are used to control data visibility at query time, not to act as object classification labels. They are attached to columns rather than used as generic metadata labels for tables and views. QUERY_HISTORY also does not provide authoritative metadata about classification inheritance. This option confuses governance metadata tagging with dynamic data protection controls.
- C. Incorrect.
Incorrect. While a control table and comments might be used as a custom workaround, this is not the recommended Snowflake-native solution. Snowflake tags exist specifically to provide governed, centrally manageable metadata. Comments are free-text and not a reliable substitute for structured classification metadata, and the statement that tags cannot be reported centrally is false.
- D. Incorrect.
Incorrect. Network policies control allowed client network access for users and security integrations, not object metadata for tables or views. They cannot be assigned to tables and views for classification or inheritance. This distractor reflects a misunderstanding of Snowflake security features.