Mark the correct Statements with respect to Secure views & its creation in the SnowFlake Account?

Mark the correct Statements with respect to Secure views & its creation in the SnowFlake Account?

A. For a secure view, internal optimizations can indirectly expose data & the view definition is visible to other users.

B. Secure views should not be used for views that are defined solely for query convenience, such as views created to simplify queries for which users do not need to under-stand the underlying data representation.

C. To convert an existing view to a secure view and back to a regular view, set/unset the SECURE keyword in the ALTER VIEW or ALTER MATERIALIZED VIEW command.

D. For non-materialized views, the IS_SECURE column in the Information Schema and Account Usage views identifies whether a view is secure.

E. The internals of a secure view are not exposed in Query Profile (in the web interface). This is the case even for the owner of the secure view, because non-owners might have access to an owner’s Query Profile.

View Answer

Answer: B, D, E

Explanation:

Let’s evaluate each of the statements regarding Secure views in Snowflake:

A. For a secure view, internal optimizations can indirectly expose data & the view definition is visible to other users.

Incorrect. One of the main points of a secure view is to ensure that internal optimizations don’t indirectly expose data. Additionally, the view definition of a secure view is not visible to other users.

B. Secure views should not be used for views that are defined solely for query convenience, such as views created to simplify queries for which users do not need to understand the underlying data representation.

Correct. Secure views have some overhead and are designed primarily for security purposes. If you’re creating views simply for query convenience without any security concerns, regular views would suffice.

C. To convert an existing view to a secure view and back to a regular view, set/unset the SECURE keyword in the ALTER VIEW or ALTER MATERIALIZED VIEW command.

Incorrect. As of my last knowledge update in January 2022, you cannot simply convert an existing regular view to a secure view using the ALTER VIEW command. Instead, you would drop the existing view and recreate it using the CREATE VIEW command with the SECURE keyword.

D. For non-materialized views, the IS_SECURE column in the Information Schema and Account Usage views identifies whether a view is secure.

Correct. The IS_SECURE column indicates whether the view is a secure view or not.

E. The internals of a secure view are not exposed in Query Profile (in the web interface). This is the case even for the owner of the secure view, because non-owners might have access to an owner ’ s Query Profile.

Correct. Secure views are designed to hide the underlying logic and data from unauthorized users. This includes the owner when viewing Query Profiles because of the potential for others to access the owner’s Query Profile.

Based on the evaluation, the correct statements are:

B. Secure views should not be used for views that are defined solely for query convenience, such as views created to simplify queries for which users do not need to understand the underlying data representation.

D. For non-materialized views, the IS_SECURE column in the Information Schema and Account Usage views identifies whether a view is secure.

E. The internals of a secure view are not exposed in Query Profile (in the web interface). This is the case even for the owner of the secure view, because non-owners might have access to an owner ’ s Query Profile.