Back to SnowPro Core Certification (COF-C02)

Data Protection and Data Sharing

Implement data protection strategies and configure secure data sharing between Snowflake accounts (12% of exam).

This domain covers implementing data protection strategies including Time Travel, Fail-safe, and data cloning. It also covers using data masking policies, row access policies, and object tagging for data governance. Understanding and configuring secure data sharing among different Snowflake accounts, using listings and data exchanges, and meeting compliance requirements are also key topics.
5 minutes 5 Questions

Data Protection and Data Sharing are fundamental concepts in Snowflake that every SnowPro Core certification candidate must understand thoroughly. **Data Protection:** Snowflake provides comprehensive data protection through multiple layers of security. Time Travel allows users to access historica…

Concepts covered: Time Travel feature, Fail-safe period, Data retention settings, UNDROP command, Zero-copy cloning, Cloning databases, schemas, and tables, Clone inheritance, Dynamic data masking, Row access policies, Object tagging, Column-level security, Data classification, Secure data sharing between accounts, Reader accounts, Shares and share objects, Snowflake Marketplace, Data Exchange, Listings

Test mode:
Start practice test
COF-C02 - Data Protection and Data Sharing Example Questions

Test your knowledge of Data Protection and Data Sharing

Question 1

A telecommunications company uses Snowflake to store customer call records. During a schema restructuring project, an engineer dropped a table named 'CALL_LOGS' from the 'TELEMETRY' schema at 8:00 AM. At 10:00 AM, they ran UNDROP TABLE TELEMETRY.CALL_LOGS successfully. At 11:00 AM, another team member, unaware of the recovery, dropped the same table again. At 3:00 PM, the original engineer discovered the table was missing again and needs to restore it. The Time Travel retention is configured at 14 days. When the engineer runs UNDROP TABLE TELEMETRY.CALL_LOGS at 3:00 PM, which version of the table will be restored?

Correct Answer: The version of the table that was dropped at 11:00 AM, as UNDROP restores the most recently dropped version of an object with that name

The UNDROP command in Snowflake always restores the most recently dropped version of an object with that name. This is a key concept for the SnowPro Core Certification.

In this scenario:
- 8:00 AM: CALL_LOGS was dropped (first drop)
- 10:00 AM: UNDROP restored the table from the 8:00 AM drop
- 11:00 AM: The table was dropped again (second drop)
- 3:00 PM: Engineer runs UNDROP

When UNDROP is executed at 3:00 PM, Snowflake will restore the version that was dropped at 11:00 AM because that is the most recent drop operation. The 8:00 AM dropped version was already consumed by the first UNDROP at 10:00 AM.

The other answers are incorrect because:

  • UNDROP does not prioritize based on original creation timestamp. It simply uses a last-in-first-out (LIFO) approach, always restoring the most recently dropped version.

  • UNDROP does not merge or consolidate data from multiple dropped versions. Each dropped version is maintained separately in Time Travel, and UNDROP restores exactly one version at a time.

  • UNDROP does not use data freshness or modification timestamps to determine which version to restore. The determining factor is solely which version was dropped most recently.

This behavior is important to understand because if you need to access an earlier dropped version after undropping a more recent one, you would need to use the AT or BEFORE clause with Time Travel queries or CREATE TABLE ... CLONE ... AT syntax instead.

Question 2

A data engineering team at a retail bank uses Snowflake Enterprise Edition. Their 'account_transactions' table has DATA_RETENTION_TIME_IN_DAYS set to 30 days and receives millions of transactions daily. On November 5th at 3:00 PM, the team needs to audit transaction patterns by comparing current data against the table state from October 10th at 9:00 AM. They also want to clone the October 10th version for extended analysis in a separate schema. The senior engineer proposes creating a clone using Time Travel syntax: CREATE TABLE audit_schema.transactions_oct10 CLONE account_transactions AT(TIMESTAMP => '2024-10-10 09:00:00'::TIMESTAMP). After creating the clone, the team plans to run complex analytical queries on the cloned table over the next several weeks. What storage consideration should the team understand about this Time Travel clone operation?

Correct Answer: The clone initially shares storage with the source table's historical data, but modifications to either table will consume additional storage for changed micro-partitions

The correct answer describes Snowflake's zero-copy cloning behavior accurately. When you create a clone using Time Travel (with AT or BEFORE clause), Snowflake uses its zero-copy cloning technology. This means:

  1. The clone initially shares the same underlying micro-partitions with the source table's historical data at the specified timestamp
  2. No additional storage is consumed at the time of clone creation
  3. As either the source table or the clone is modified (inserts, updates, deletes), the changed micro-partitions are stored separately, and only these changes consume additional storage

This is a fundamental concept of Snowflake's architecture where cloning is metadata-only initially, making it fast and storage-efficient.

The second answer is incorrect because it describes traditional copying behavior, not Snowflake's zero-copy cloning. Creating a clone does NOT create a complete independent copy that consumes full table storage immediately.

The third answer is incorrect because while the clone does share storage initially, modifications to the clone do NOT affect the source table or its historical data. Clones are independent objects - changes to one do not impact the other.

The fourth answer, while partially true about inheritance of certain properties, doesn't address the storage consideration being asked. Also, the clone's Time Travel history starts from when the clone was created (November 5th), not from the October 10th timestamp - the clone is simply a snapshot of data as it existed on October 10th.

Question 3

Scenario: Continental Insurance Group operates multiple Snowflake accounts across different business units. The Corporate Analytics team in Account A has developed a comprehensive risk scoring model stored in a database called RISK_MODELS_DB. The Underwriting team in Account B needs to query this risk model data for their daily operations. After the Corporate Analytics team creates a share named 'RISK_MODEL_SHARE' and grants access to Account B, the Underwriting team creates a database from the share using CREATE DATABASE UNDERWRITING_RISK FROM SHARE CORPORATE_ANALYTICS.RISK_MODEL_SHARE. Three months later, the Corporate Analytics team decides to rename the source database from RISK_MODELS_DB to ENTERPRISE_RISK_DB and also renames several tables within it to align with new naming conventions. The Underwriting team reports that their existing queries and dashboards are still functioning correctly after these changes. What explains why the consumer's access remains unaffected despite the provider's object renaming activities?

Correct Answer: Share references maintain object bindings through internal identifiers rather than object names, so renaming source objects does not break consumer access as long as the objects remain in the share

The correct answer explains that Snowflake's Secure Data Sharing uses internal object identifiers (not names) to maintain the relationship between shared objects and consumers. When a provider grants access to objects in a share, Snowflake tracks these objects by their internal unique identifiers rather than their display names.

This is a fundamental aspect of how Snowflake's sharing architecture works:

  1. When objects are added to a share, Snowflake binds them using internal IDs
  2. Renaming an object only changes its display name, not its internal identifier
  3. As long as the object remains part of the share (hasn't been removed), consumers can continue to access it
  4. The consumer's database from share references the original objects through these stable internal bindings

The other answers are incorrect for these reasons:

  • The answer suggesting automatic synchronization of name changes is wrong because consumer databases created from shares do NOT automatically rename their objects when the provider renames source objects. The consumer still sees and uses the original names they created.

  • The answer about snapshot caching is incorrect because Secure Data Sharing provides live, real-time access to the provider's data - there is no cached copy or snapshot. The data is accessed directly from the provider's storage.

  • The answer about name alias mapping tables is incorrect because Snowflake does not maintain any such translation table for shared objects. The mechanism is simpler - it's based on internal object identifiers that remain constant regardless of name changes.

More Data Protection and Data Sharing questions
537 questions (total)
Start 100 question test