Data protection and sharing: free practice questions

On Snowflake Standard edition, the maximum configurable Time Travel retention period for permanent tables is 1 day. Enterprise edition and above support up to 90 days of Time Travel. Option A (0 days) would disable Time Travel entirely. Option C (7 days) and Option D (90 days) are only available on Enterprise edition or higher, not on Standard edition. This is a frequently tested distinction in the COF-C02 exam.

Snowflake allows SQL, JavaScript, Java, and Python UDFs to be included in a share as long as they are created as SECURE UDFs (using the SECURE keyword). The SECURE designation hides the UDF body from consumers while still allowing them to call it. Option A is incorrect because non-SQL UDFs (JavaScript, Python, Java) can be shared if marked SECURE. Option B is partially correct in spirit but overstates the restriction — UDFs do not strictly need to reference ONLY objects within the shared database; the key requirement is that they are SECURE. Option D is incorrect: shared UDFs execute using the provider's serverless compute model or the consumer's warehouse depending on the UDF type; for most shared UDFs, the consumer's warehouse processes the call, but this is not a 'constraint' that prevents sharing — it is normal behavior and does not restrict which UDF languages can be shared.

The correct answer is A. The standard Snowflake pattern for multi-tenant data sharing is to create a secure view that uses CURRENT_ACCOUNT() (or CURRENT_ACCOUNT() mapped through a policy table) to dynamically filter rows to only the consumer's own data. You then grant this single secure view to a share, and each consumer account is added to its own share. This is scalable and secure. B is wrong because you cannot impose Snowflake policies in the consumer account from the provider side; the consumer controls their own account's policies and could potentially see all rows. C is wrong because a single Marketplace listing is public (or privately shared as one unit) and column masking does not provide row-level isolation between different consumer accounts. D is wrong because Replication Groups are for internal organizational DR/failover, not for distributing isolated customer data to external parties, and direct database access would not enforce per-customer row filtering.

Option B is correct: permanent tables include a 7-day Fail-Safe period charged at standard storage rates (included in Snowflake's storage pricing model). Option C is correct: transient tables have a maximum of 1 day of Time Travel and zero days of Fail-Safe, which significantly reduces storage costs for large, short-lived datasets. Option A is wrong: transient tables have NO Fail-Safe period. Option D is partially misleading: Fail-Safe is charged at the same storage rate, but framing it as 'additional' is incorrect since it is simply storage consumption — however this option is marked wrong primarily because the key differentiator question is about transient vs permanent costs, and option D does not accurately reflect a true difference statement. Option E is wrong: transient tables DO support Time Travel (up to 1 day) and CAN use AT/BEFORE clauses. Option F is wrong: Fail-Safe is always 7 days for permanent tables, not 90 days; 90 days is the max Time Travel on Enterprise edition.

The correct answer is B. In Snowflake, standard views expose their definition (the underlying SQL query) to users who have access to them. When shared with a consumer account, this means the consumer can use SHOW VIEWS or GET_DDL() to inspect the view definition, revealing table names, column names, and business logic applied to PII data. A is wrong because views (including standard views) can technically be added to a share, though it is not recommended for sensitive data. C is wrong because reader accounts are one type of consumer, but full Snowflake accounts can also consume shares—there is no restriction to reader accounts only. D is wrong because sharing a view does not grant SELECT on the base table itself; the consumer can only query the view, not the underlying table directly.