SnowPro Advanced: Security Engineer Question 149
Select 2Understand the security implications of using secure objects, including views, functions, and proceduresA healthcare company stores PHI in PROD_DB.CLINICAL.PATIENTS. Analysts from several business units need access to a subset of columns through a shared data model, but the security team must prevent consumers from inferring sensitive filtering logic or underlying table details through query plans, object definitions, or indirect access patterns. The team is considering replacing existing standard views and UDFs with secure objects. Which TWO actions best meet this requirement while preserving controlled access to the data?
- A
Create a SECURE VIEW that exposes only approved columns and grant analysts access to the view instead of the base table.
- B
Create a SECURE FUNCTION or SECURE PROCEDURE for reusable logic so that object definitions and certain internal details are protected from unauthorized users.
- C
Keep standard views, but revoke USAGE on the database and schema from analysts; this alone prevents them from seeing view definitions and query behavior.
- D
Grant SELECT on the base table and rely on a standard view to hide the sensitive columns, because users querying through the view cannot infer anything about the underlying table.
- E
Use secure objects only for performance optimization, because their primary purpose is to speed up execution rather than limit metadata exposure.
Show answer and explanation
Correct answers: A, B
Explanation
The best answers are to use a SECURE VIEW for controlled data exposure and to use SECURE FUNCTIONs or SECURE PROCEDUREs when reusable logic must not reveal sensitive implementation details. In Snowflake, secure objects are intended to help protect underlying definitions and reduce the risk that consumers can infer sensitive logic from metadata, query profiles, or object text. This is especially important in regulated scenarios such as PHI sharing. A key best practice is to grant access to the secure abstraction layer, not the underlying table, unless direct table access is explicitly required. Standard views can help simplify access patterns, but they are not equivalent to secure views for protecting internals. Relevant Snowflake documentation includes topics on Secure Views and Secure UDFs/Procedures, which describe how secure objects limit exposure of underlying logic and support safer data sharing patterns.
- A. Correct.
Correct. A secure view is designed for scenarios where data providers want stronger privacy guarantees around the underlying query definition and execution details. Granting access to the secure view rather than the base table enforces an abstraction boundary: consumers only access the exposed columns and rows defined by the view. This is a common best practice when the goal is to share filtered or masked subsets of sensitive data without exposing base table structure or logic.
- B. Correct.
Correct. Secure UDFs and secure procedures are intended to help protect implementation details from unauthorized users. In Snowflake, secure objects reduce metadata exposure compared with standard objects, which is important when the organization does not want consumers to learn sensitive business logic, filtering rules, or implementation details. This makes them appropriate for reusable logic in regulated environments.
- C. Incorrect.
Incorrect. Revoking USAGE may block access entirely, but it does not by itself provide the security properties of a secure object. The requirement is specifically to prevent unauthorized users from inferring logic or underlying details while still allowing controlled access. Standard views do not provide the same protections as secure views regarding exposure of internals. Also, if users cannot access the schema or database, they generally cannot use the view at all, so this does not satisfy the business requirement.
- D. Incorrect.
Incorrect. Granting SELECT on the base table undermines the purpose of the view-based abstraction, because users with direct table access can bypass the view and query sensitive columns or broader data sets. In addition, standard views are not intended to provide the same level of protection against exposing underlying logic or details. This option reflects the common misconception that a view alone is a sufficient security boundary even when base-table access is still granted.
- E. Incorrect.
Incorrect. Secure objects are not primarily a performance feature. Their purpose is related to data protection and limiting exposure of sensitive logic or metadata. In some cases, secure objects may have trade-offs compared to standard objects, so describing them as a performance optimization is misleading and contrary to their security-focused use case.