ARA-C01 Question 200
Single answerStreamlitA retail company has built a Streamlit in Snowflake application for regional managers to review sales performance and approve promotional discounts. The app is published to multiple business units, and the security team requires that users only see rows for stores they are authorized to manage. The data already resides in Snowflake tables, and different managers may have different access rights depending on their role. The architect wants to enforce the restriction centrally so that it applies consistently even if the underlying tables are queried outside the app in the future. Which approach should the architect choose?
- A
Implement the filtering logic in Streamlit code by reading the logged-in user's name and applying a WHERE clause before displaying the dataframe
- B
Create a secure view for the sales data and apply a row access policy based on the current user or role, then have the Streamlit app query that protected object
- C
Grant all managers access to the base sales tables and rely on Streamlit page navigation to prevent unauthorized users from reaching sensitive reports
- D
Use a masking policy on the store_id column so unauthorized rows are hidden automatically when the Streamlit app runs queries
Show answer and explanation
Correct answer: B
Explanation
The key design requirement is centralized enforcement of row-level security so that controls apply consistently across Streamlit in Snowflake and any future access path. Snowflake best practice is to implement data governance in Snowflake itself, not in the application layer. Row access policies are designed specifically for filtering rows based on context such as CURRENT_USER, CURRENT_ROLE, or mapping tables that relate users/roles to allowed business entities. A secure view is often used to present a governed interface to the app while limiting exposure of raw tables. By contrast, Streamlit code-based filtering is useful for user experience but should not be the primary security mechanism. Masking policies solve a different problem: protecting column values rather than suppressing rows. This aligns with Snowflake documentation and architecture guidance on row-level security, secure views, and policy-based governance.
- A. Incorrect.
This is not the best architectural choice for centralized enforcement. Although Streamlit code can inspect the session context and add filters, application-layer filtering is easier to bypass, harder to govern consistently, and does not protect direct access to the underlying data objects outside the app. The requirement explicitly states that the restriction must still apply if the data is queried elsewhere in the future, which points to Snowflake-native policy enforcement rather than UI logic.
- B. Correct.
This is the correct answer. Row-level security in Snowflake should be enforced in the data platform using a row access policy, often attached to a table or a view used by consumers. Using a secure view can further encapsulate the logic and expose only approved columns and rows. This design satisfies the requirement for centralized, reusable enforcement across Streamlit and any other consuming workload. Policies based on CURRENT_USER or role context are a standard way to implement row-level entitlements in Snowflake.
- C. Incorrect.
This is incorrect because Streamlit navigation and UI controls are not a security boundary for Snowflake data access. If users have direct privileges on the base tables, they may still query unrestricted data through other SQL interfaces or app code paths. This option reflects a common misconception that application structure alone can enforce authorization. In Snowflake, least-privilege grants combined with row-level policies are the stronger pattern.
- D. Incorrect.
This is incorrect because masking policies protect sensitive column values, not row visibility. A masking policy could obscure the value of store_id or other columns, but it would not remove unauthorized rows from query results. The requirement is to restrict which store records users can see, which is a row-level security problem and is addressed by row access policies rather than masking policies.