COF-C02 Data Protection and Data Sharing

Data Protection and Data Sharing Detailed Explanation

Snowflake provides multiple layers of protection for data, including:

• Continuous data protection

• High durability and high availability

• End-to-end encryption

• Fine-grained governance features

• Zero-copy secure data sharing

These mechanisms ensure the platform is safe, resilient, compliant, and collaborative.

1. Continuous Data Protection: Time Travel & Fail-safe

Snowflake provides two powerful mechanisms that allow data recovery even after accidental changes or deletion: Time Travel and Fail-safe.

1.1 Time Travel

Time Travel allows you to query, clone, or restore data as it existed at a specific point in the past.

1.1.1 What You Can Do with Time Travel

• Undo accidental DELETE, UPDATE, or DROP

• Recover old versions of tables, schemas, or databases

• Audit historical changes

• Run analyses on historical states

• Create point-in-time clones

Examples:

SELECT * FROM orders AT (TIMESTAMP => '2024-01-10 10:00:00');

UNDROP TABLE customers;

1.1.2 Retention Periods

Depends on the edition:

• Standard Edition → 1 day

• Enterprise Edition → up to 90 days

1.1.3 Storage Cost Impact

Longer retention → more physical storage used for historical versions.
Snowflake automatically manages historical micro-partitions, but customers pay for extended retention.

1.2 Fail-safe

Fail-safe is a 7-day recovery period after Time Travel expires.

1.2.1 Important Characteristics

• Only Snowflake can access Fail-safe

• Customers cannot query Fail-safe data

• Used strictly for disaster recovery

• Not a substitute for backup or Time Travel

1.2.2 Exam Expectation

You must know the difference:

• Time Travel → user-accessible recovery

• Fail-safe → Snowflake-only recovery for emergencies

2. Data Durability & Availability

Snowflake ensures that data is protected against hardware failures, availability zone outages, and regional disruptions.

2.1 Data Durability

Multi-AZ Replication

Within an account’s region:

• All data is automatically stored redundantly

• Across multiple availability zones

• With built-in fault tolerance

Users do not configure redundancy — Snowflake handles it.

2.2 Cross-Region / Cross-Cloud Replication

For higher resilience:

• Databases, shares, and account metadata can be replicated to:

  • Other regions

  • Other cloud providers (AWS ↔ Azure ↔ GCP)

2.2.1 Use Cases

• Multi-region disaster recovery

• Low-latency access for global teams

• Business continuity planning

• Cross-cloud flexibility

2.2.2 Failover / Failback

Snowflake supports:

• Failover: switch to a replica during outage

• Failback: return to primary after recovery

This is commonly tested on the exam.

3. Data Encryption

Snowflake uses end-to-end encryption for all data at rest and in transit.

3.1 Encryption at Rest & In Transit

• Data in micro-partitions is encrypted

• Stage files are encrypted

• Backups for Time Travel and Fail-safe are encrypted

• Network traffic is encrypted with TLS

Users cannot disable encryption — it is always enabled.

3.2 Hierarchical Key Model

Keys are organized in layers:

• Account master key

• Database keys

• Table keys

• Micro-partition (file) keys

Each level encrypts the level below it.

Benefits

• Strong compartmentalization

• Regular automatic key rotation

• Easy/manageable security lifecycle

3.3 Customer-Managed Keys (Optional)

Snowflake supports customer-managed keys via cloud KMS:

• AWS KMS

• Azure Key Vault

• GCP KMS

This is used by organizations with strict compliance policies like:

• Financial services

• Healthcare

• Government

4. Data Governance & Privacy Protection

Snowflake has advanced governance tools for fine-grained, policy-driven access control.

These features help with compliance: GDPR, HIPAA, PCI, etc.

4.1 Row Access Policies (Row-Level Security)

What They Do

Row Access Policies restrict which rows a user is allowed to see based on conditions.

Example:

• Analysts only see rows from their assigned region

• Managers can see all rows

Snowflake evaluates the policy automatically during queries.

4.2 Masking Policies (Column-Level Security)

Masking policies are applied to columns to:

• Hide PII

• Obfuscate sensitive values

• Show different data depending on user role

Example:

• Mask phone number except last four digits

• Mask email username but show domain

• Mask fully for non-privileged roles

Masking is applied at query time, dynamically.

4.3 Tags (Metadata-Based Governance)

Tags allow classification of objects and columns:

• PII

• Financial

• Confidential

• Regulatory categories

Tags can be tied to:

• Masking policies

• Governance rules

• Data cataloging tools

This enables automated, scalable governance rules.

4.4 Secure Views & Secure UDFs

4.4.1 Secure Views

Secure views hide:

• Underlying SQL logic

• Column lineage

• Table structures

Used to prevent users from inferring sensitive information.

4.4.2 Secure UDFs

Secure UDFs hide the implementation details of functions, preventing exposure of sensitive logic or data patterns.

5. Secure Data Sharing

Secure Data Sharing is one of Snowflake’s signature features.
It enables organizations to share live data safely and efficiently.

5.1 How Secure Data Sharing Works

5.1.1 Provider Side

The provider:

1. Creates a share

2. Adds:

   • Databases

   • Schemas

   • Tables

   • Views

   • Secure views

   • Secure UDFs

3. Grants the share to a consumer account

5.1.2 Consumer Side

The consumer:

• Creates a database from the share

• Queries shared objects as if they were local

No data movement required.

5.2 Key Characteristics

5.2.1 Zero-Copy Architecture

Data is not copied.
Consumers read from the provider’s storage.

Benefits:

• No ETL

• Real-time data sharing

• Very cost-efficient

• No synchronization issues

5.2.2 Read-Only for Consumers

Consumers cannot mutate (INSERT/UPDATE/DELETE) shared objects.

5.3 Use Cases

5.3.1 Internal Sharing

Between business units:

• Finance → Analytics

• Marketing → Sales

• Operational systems → BI

5.3.2 External Sharing

Share with:

• Partners

• Vendors

• Customers

Useful for:

• Data products

• Operational collaboration

• Supply chain visibility

5.3.3 Marketplace Monetization

On Snowflake Marketplace, providers can:

• Sell data

• Offer free public datasets

• Publish data applications

Consumers subscribe with no physical data movement.

Data Protection and Data Sharing (Additional Content)

1. Snowgrid (Global Cross-Cloud Governance Layer)

Snowgrid is Snowflake’s global metadata and orchestration layer that operates across all Snowflake-supported cloud regions and providers. It is the foundation that allows Snowflake to function as a unified multi-cloud platform rather than isolated deployments.

1.1 Purpose and Architecture

Snowgrid ensures that Snowflake behaves consistently across AWS, Azure, and GCP by coordinating metadata, governance, and replication operations.

Snowgrid enables:

• Cross-region and cross-cloud replication

• Coordinated failover and failback of replicated environments

• Global secure data sharing

• Marketplace product distribution across multiple regions

1.2 Governance Consistency

Because Snowgrid orchestrates replication and metadata operations, it ensures that:

• Policies behave uniformly across regions

• Privileges and roles are synchronized as required

• Shared objects maintain consistent visibility and security properties

Snowgrid is essential for enterprise deployments that span geography or multiple cloud providers.

2. Replication Types and Characteristics

Replication ensures redundancy, disaster recovery readiness, and global availability of data.

2.1 Database Replication

Replicates both data and metadata for selected databases to another Snowflake region or cloud.
Supports:

• Cross-region analytics

• Disaster recovery

• Low-latency access for distributed teams

2.2 Share Replication

Used specifically for cross-region secure data sharing.
Replicates the underlying share definitions and metadata so that consumers in other regions can access data.

2.3 Account Replication

An organization-level feature that replicates selected account-level objects, such as:

• Databases

• Shares

• Users

• Roles

• Account metadata

Enables coordinated account-level failover.

2.4 Asynchronous Behavior

Replication is asynchronous and follows Snowflake-managed schedules.
There is no guarantee of zero-lag replication, though delays are typically small.

2.5 Replication Eligibility

Certain object types cannot be replicated, such as:

• Temporary tables

• Some transient objects

• Certain non-durable metadata types

Understanding replication eligibility is important for DR planning.

3. Failover Groups

Failover Groups simplify cross-region disaster recovery by grouping multiple objects under a single failover unit.

3.1 Purpose

A Failover Group is a logical container that includes:

• Databases

• Secure shares

• Roles and grants associated with those databases and shares

This group can be failed over as a single atomic unit.

3.2 Behavior

Failover Groups support both:

• Failover (switching active region)

• Failback (returning to original region)

Snowgrid orchestrates replication and state transitions.

3.3 Required Privileges

Executing a failover requires explicit privileges.
Failover cannot occur unless:

• The role initiating the failover has been granted appropriate access

• The failover group is fully synchronized

This prevents accidental DR events.

4. Reader Accounts (Critical Sharing Feature)

Reader Accounts are a central part of Snowflake’s data-sharing ecosystem, enabling providers to share data with consumers who do not operate Snowflake accounts.

4.1 Purpose and Behavior

The provider creates and fully manages the Reader Account.
Use cases include:

• Sharing data with customers

• Monetizing data products

• Providing limited, controlled environments for external partners

4.2 Compute Billing

The provider pays for all compute used by the Reader Account, including:

• Query execution

• Materialized view maintenance

• Other Snowflake operations

This lowers friction for consumers, especially those who do not want to become Snowflake customers.

4.3 Isolation

Reader Accounts are isolated from the provider’s environment and can only see explicitly shared objects.

5. Secure Data Sharing Limitations

Secure data sharing is powerful but has important constraints.

5.1 Unsupported Objects

The following objects cannot be shared:

• Temporary tables

• Transient objects in certain scenarios

• Non-secure UDFs

• Internal stages

These limitations exist because shared objects must have durable metadata and predictable behavior.

5.2 Read-Only Access

Consumers cannot:

• INSERT

• UPDATE

• DELETE

• MERGE

on shared objects.
Sharing provides access to live data, but not the ability to mutate it.

5.3 Cloning Restrictions

Consumers cannot clone shared objects unless:

• The provider enables replication, or

• Special configurations are used for cross-region replication

Cross-region sharing implicitly uses replication behind the scenes.

6. Data Retention, Cloning, and Historical Data Behavior

Understanding how cloning interacts with Time Travel and Fail-safe is crucial for data protection planning.

6.1 Retention Inheritance

Cloned objects inherit the Time Travel retention from the source object.
Retention does not reset during cloning.

6.2 Fail-safe Behavior

Fail-safe is not extended or duplicated during cloning.
A clone does not receive additional Fail-safe windows beyond what the source object has already accumulated.

6.3 Historical Data Pruning

When a clone is dropped:

• Historical micro-partitions referenced only by the clone may be removed

• This can reduce Time Travel recoverability

• Storage consumption may decrease

Retention planning must account for cloning lifecycle.

7. Customer-Managed Key Behavior in Encryption

Customer-Managed Keys (CMK) extend Snowflake’s encryption model by giving customers control over master-level encryption keys.

7.1 How CMK Works

CMK is implemented through cloud provider KMS services:

• AWS KMS

• Azure Key Vault

• Google Cloud KMS

The customer manages the root key; Snowflake uses it to encrypt account-level data keys.

7.2 Key Rotation

Customers may rotate CMKs manually according to security policy or compliance frameworks.
Snowflake automatically re-encrypts necessary metadata or keys as required.

7.3 Access Requirements

Snowflake must have continuous access to the CMK.
If access is revoked:

• Snowflake cannot decrypt data

• Affected data becomes inaccessible until permissions are restored

This behavior is critical in regulated industries.

7.4 Compliance Usage

CMK is commonly used in:

• Financial institutions

• Government organizations

• Healthcare environments

• Any environment requiring customer-owned encryption keys

CMK ensures organizations maintain full control over their encryption lifecycle.