ADA-C01 Question 179
Single answerIdentify the impact of attaching a row access policy to an objectA Snowflake administrator attaches a row access policy to the SALES.PUBLIC.ORDERS table using the REGION column as the policy signature. Shortly afterward, analysts report that queries against ORDERS return fewer rows than expected, and a data engineer finds that a view built on top of ORDERS also shows filtered results. The administrator needs to explain the impact of attaching the row access policy to the table. Which statement is correct?
- A
The row access policy is evaluated whenever ORDERS is queried, and the filtered rows also affect downstream objects such as views that reference the table.
- B
The row access policy only affects direct SELECT statements on ORDERS; views and derived objects bypass the policy unless the policy is attached to each view separately.
- C
Attaching the row access policy encrypts restricted rows at rest, so users without the required role cannot physically access those rows in storage.
- D
The row access policy changes the ownership model of ORDERS, so object owners automatically bypass row filtering while all other roles are denied access.
Show answer and explanation
Correct answer: A
Explanation
A row access policy in Snowflake enforces row-level security by evaluating a policy expression at query time and returning only rows allowed by that expression. When a policy is attached to a table or view, its effect is seen by any query path that reads from that protected object, including downstream views built on top of it. This is why analysts may suddenly see fewer rows after the policy is attached, even if they query through an existing view. Administrators should understand that row access policies affect logical visibility of rows, not object ownership, storage encryption, or only direct table access. This aligns with Snowflake documentation on row access policies and policy-based governance, which describes row access policies as being evaluated on protected objects during query execution and propagating their filtering effect to dependent queries.
- A. Correct.
Correct. In Snowflake, a row access policy is evaluated at query time when the protected object is accessed. The policy determines which rows are visible to the querying role or session context. Because the policy is attached to the base table, queries through downstream objects such as views still see the filtered result set from that table. This is the practical impact administrators must understand when applying a row access policy to a shared source object.
- B. Incorrect.
Incorrect. This reflects a common misconception. Row access policies attached to a table are not limited to direct queries against that table. If a view references the protected table, the policy still applies because the view resolves against the underlying object, and row-level filtering is enforced there.
- C. Incorrect.
Incorrect. Row access policies provide logical row-level security, not storage-level encryption behavior. Snowflake already encrypts data at rest, but attaching a row access policy does not additionally encrypt specific rows or change physical storage access patterns. It controls query results, not storage encryption semantics.
- D. Incorrect.
Incorrect. Attaching a row access policy does not change table ownership or create an owner bypass model. Whether rows are returned depends on the policy body and the execution context used by Snowflake for policy evaluation, not on an automatic rule that owners bypass filtering. This option mixes access-control concepts in a way that does not reflect actual row access policy behavior.