ADA-C01 Question 178
Single answerIdentify the impact of attaching a row access policy to an objectA Snowflake administrator is asked to restrict access to a SALES table so that regional managers only see rows for their own region. The administrator creates a row access policy that evaluates CURRENT_ROLE() and then attaches the policy to the REGION column of the SALES table. After deployment, analysts report that some existing queries against SALES are slower, even though no warehouse sizes or clustering settings were changed. Which statement best explains the impact of attaching the row access policy to the table?
- A
Attaching the row access policy rewrites the table data physically by creating region-specific micro-partitions, which can increase storage and slow queries.
- B
Attaching the row access policy causes Snowflake to evaluate the policy expression at query time for rows in the protected object, which can add overhead depending on the complexity of the policy logic.
- C
Attaching the row access policy automatically disables result caching for all queries against the SALES table, so every query must rescan the base table.
- D
Attaching the row access policy changes object ownership to the policy owner, which can affect role resolution and lead to slower execution plans.
Show answer and explanation
Correct answer: B
Explanation
The key impact of attaching a row access policy to an object is that Snowflake enforces row-level visibility dynamically during query execution. The policy is associated with a column on a table or view, and Snowflake evaluates the policy expression to decide which rows are returned to the user. In practice, this means administrators should consider both security outcomes and performance implications, especially when the policy logic is complex or references mapping tables or context functions. Best practice is to keep policy expressions as efficient and maintainable as possible, and to test query patterns after deployment. This aligns with Snowflake documentation on row access policies, which describes them as schema-level objects used to determine visible rows at query time rather than storage-layer transformations.
- A. Incorrect.
Incorrect. A row access policy does not physically reorganize or rewrite table storage into separate micro-partitions for each access group. Snowflake row access policies are logical security controls evaluated during query processing. While performance can be affected, it is not because Snowflake creates new region-specific storage structures when the policy is attached.
- B. Correct.
Correct. Row access policies are evaluated dynamically during query execution to determine which rows are visible to the querying role or context. If the policy expression includes complex logic, mapping table lookups, or functions that must be evaluated per row or per query context, some additional processing overhead can occur. This is the most accurate explanation for why queries may slow after the policy is attached.
- C. Incorrect.
Incorrect. Result cache behavior is not universally disabled simply because a row access policy is attached. Snowflake applies security semantics when serving results, and secure objects and policies can affect optimization and reuse in some scenarios, but the statement is too broad and inaccurate. The main impact to understand is policy evaluation at query time, not blanket cache disablement.
- D. Incorrect.
Incorrect. Attaching a row access policy does not transfer ownership of the protected table to the policy owner. Ownership and policy attachment are separate governance concepts in Snowflake. Slower queries are not explained by an ownership change caused by policy attachment.