Clone inheritance in Snowflake refers to how cloned objects inherit properties and privileges from their source objects. When you create a clone of a database, schema, or table, the clone inherits certain characteristics while maintaining independence from the original object.
Key aspects of clone…Clone inheritance in Snowflake refers to how cloned objects inherit properties and privileges from their source objects. When you create a clone of a database, schema, or table, the clone inherits certain characteristics while maintaining independence from the original object.
Key aspects of clone inheritance include:
1. **Data Inheritance**: Clones initially share the same underlying data storage as the source object through Snowflake's zero-copy cloning feature. This means no additional storage is consumed at clone creation time. Data divergence occurs only when modifications are made to either the source or the clone.
2. **Structural Inheritance**: The clone inherits the complete structure of the source object, including column definitions, clustering keys, constraints, and other metadata properties.
3. **Privilege Inheritance**: When cloning databases or schemas, the clone inherits the privileges granted on contained objects. However, privileges granted on the container itself (the database or schema being cloned) are not inherited by the clone. The user creating the clone becomes the owner of the cloned object.
4. **Child Object Inheritance**: When cloning a database, all schemas and objects within are cloned. When cloning a schema, all tables, views, and other objects within are cloned. This creates a complete hierarchical copy.
5. **Time Travel Inheritance**: Clones can be created from historical data using Time Travel, allowing you to clone objects as they existed at a specific point in time.
6. **Data Sharing Considerations**: Clones of shared databases behave as independent objects. The cloned data is no longer tied to the data sharing relationship.
7. **Independence After Creation**: Once created, clones are fully independent objects. Changes to the source do not affect the clone, and changes to the clone do not affect the source.
Understanding clone inheritance is essential for managing data protection strategies, creating development environments, and implementing effective testing scenarios in Snowflake.
Clone Inheritance in Snowflake
Why Clone Inheritance is Important
Clone inheritance is a critical concept for the SnowPro Core certification because it determines how security policies, access controls, and other metadata are transferred when you create clones of database objects. Understanding this behavior is essential for maintaining data governance, security compliance, and proper access management in production environments.
What is Clone Inheritance?
When you create a zero-copy clone in Snowflake, the cloned object inherits certain properties from the source object. Clone inheritance refers to which privileges, policies, and settings are copied to the new cloned object versus which must be explicitly granted or configured.
How Clone Inheritance Works
What IS Inherited: - Structure and metadata of the object - Data (as a zero-copy snapshot at clone time) - Clustering keys - Comments on objects - Column defaults and sequences - Masking policies and row access policies (for tables) - Tags assigned to the object
What is NOT Inherited: - Privileges granted on the source object (grants are NOT cloned) - Future grants defined on schemas - Pipes, streams, and tasks that reference the cloned objects - Stage references in external tables
Key Rules to Remember
1. Privileges Must Be Re-granted: When you clone a database, schema, or table, the privileges on the source do not transfer to the clone. The clone owner must explicitly grant access.
2. Ownership: The user or role that executes the CLONE command becomes the owner of the cloned object.
3. Child Objects: When cloning a database or schema, all child objects (schemas, tables, views) are also cloned with their structure but require new privilege grants.
4. Data Sharing: Cloned objects are independent and do not maintain any connection to data shares from the source.
Exam Tips: Answering Questions on Clone Inheritance
1. Remember the Privilege Rule: The most common exam topic is that privileges do NOT transfer to cloned objects. If a question asks about user access after cloning, the answer typically involves re-granting privileges.
2. Ownership Focus: Questions often test who owns the cloned object - it is always the role that performed the clone operation.
3. Policy Inheritance: Masking policies and row access policies ARE inherited by cloned tables. This is a frequent exam topic.
4. Watch for Tricky Scenarios: Questions may describe a scenario where a user had access to the source but cannot access the clone - this tests your understanding that grants are not inherited.
5. Time Travel Consideration: Clones can be created from a point in time using Time Travel. The clone reflects data as it existed at that moment.
6. Eliminate Wrong Answers: If an answer suggests that all security settings transfer automatically to clones, it is likely incorrect for privilege-related settings.
7. Database vs Table Clones: Both follow the same inheritance rules for privileges - neither inherits grants from the source.