Snowflake DEA-C02: Data Governance Practice Questions

Option E is correct: GRANT FUTURE PRIVILEGES is designed exactly for this forward-looking use case — all tables created in the specified schema after the grant is issued will automatically inherit the privilege for the specified role, eliminating the need for manual per-object grants. Option C is correct: explicit object-level grants override future grants for that specific object; this is important for exceptions to the default pattern (e.g., restricting a sensitive table that would otherwise be covered by a future grant). Option D is false and is a very common misconception — future grants are NOT retroactive; they only apply to objects created after the GRANT FUTURE statement is executed. Existing objects require separate grants. Option B is incorrect — future grants CAN be defined at both the database level (applying to all schemas in the database) AND the schema level. Option A is false — future grants are not automatically revoked upon ownership transfer; ownership changes affect OWNERSHIP privilege, not future grant assignments.

Client Credentials flow is the correct OAuth 2.0 flow for machine-to-machine (server-to-server) access because it does not require human interaction — the client authenticates directly using its own credentials and receives an access token. In Snowflake, this requires creating a Security Integration of type OAUTH with OAUTH_CLIENT = CUSTOM. Authorization Code flow (C) requires user interaction to obtain an authorization code, making it unsuitable for automated pipelines. Implicit flow (A) is a browser-based flow deprecated for security reasons and uses a SAML2 integration for SSO, not OAuth programmatic access. Resource Owner Password Credentials flow (B) requires passing user credentials directly, which defeats the purpose of OAuth and is also deprecated; OAUTH_CLIENT = LOOKER is a partner-specific preset, not a general custom integration.

QUERY_HISTORY (option E) records every query executed, including the SQL text, user name, role, and timestamp—essential for showing what queries were run. ACCESS_HISTORY (option C) records which base objects (tables, views, columns) were accessed by which user in each query, making it the definitive source for proving table-level access. Together they provide both the query content and the confirmed object-level access. Option A (LOGIN_HISTORY) records only authentication events (logins), not table access. Option D (STAGE_USAGE_HISTORY) tracks file stage usage, not table reads. Option B (INFORMATION_SCHEMA.TABLE_PRIVILEGES) shows current privilege grants, not historical access events—it cannot show who accessed the table in the past.

Option A is correct: Snowflake intentionally restricts the query optimizer for Secure Views to prevent inference of underlying data through execution plan metadata or statistics leakage — this is a documented trade-off of using Secure Views. Option C is correct: the DDL/SQL definition of a Secure View is hidden from all users except the owner (or users granted the ACCOUNTADMIN role), which prevents logic and schema reverse-engineering. Option B is wrong: Secure Views have nothing to do with encryption at rest or customer-managed keys (Tri-Secret Secure is a separate feature); data encryption is managed at the storage layer regardless of view type. Option D is wrong: Secure Views do not automatically apply masking policies; masking policies must be explicitly attached to columns. Option E contains a partial truth (Secure Views can be shared), but the statement is slightly misleading — in data sharing contexts the recipient cannot see the definition, but this is a consequence of C, not an independent property; however, more critically, Option E alone is not listed as correct because the stronger, more precise correct answers are A and C as core properties of Secure Views.

Option A (row access policy on the underlying table) limits the input data the UDF can process per caller, reducing the ability to probe arbitrary values. Option C (scoped USAGE grants) limits which roles can invoke the UDF at all, reducing the attack surface. Option F (IS_ROLE_IN_SESSION logic inside the UDF) adds an explicit authorization check so unauthorized roles receive NULL or a generic output instead of meaningful values. Together these form a defense-in-depth approach. Option B (network policy IP restriction) reduces the network attack surface but does not prevent authorized analysts at those workstations from probing the UDF—it addresses a different threat. Option D is incorrect and counterproductive: replacing a Secure UDF with a standard UDF would expose the UDF definition and make inference easier, not harder. Option E (query result caching) does not prevent inference attacks; it only avoids re-execution of identical queries, which a probing attacker would naturally vary anyway.