Snowflake access design has two related questions: who can use an object inside an account, and how data should be exposed to users in another account. Role-based access control answers the first question by assigning privileges to roles and then assigning roles to users or other roles. Secure Data Sharing answers the second by exposing selected Snowflake objects through shares or listings without creating a separate physical copy of the underlying data.<\/p>\n
Both concepts appear in the platform knowledge expected for SnowPro Core<\/a>, while SnowPro Advanced Architect<\/a> extends that foundation into account, sharing, and architecture decisions across the broader Snowflake certification<\/a> ecosystem. In production, they should be designed together. A technically valid share is not automatically a good security model, and a clean role hierarchy inside one account does not automatically define how external consumers should receive data.<\/p>\n Snowflake privileges are granted on securable objects such as warehouses, databases, schemas, tables, views, stages, and shares. Rather than assigning powerful account roles to ordinary users, a scalable design creates functional roles around real responsibilities. A finance analyst role might receive usage on a finance database and select access to curated views, while a pipeline role receives only the privileges needed to load and transform its target schemas.<\/p>\n Role hierarchy helps avoid repeated grants. Lower-level roles can hold focused privileges, and higher-level roles can inherit them when broader access is justified. The important design goal is clarity: an administrator should be able to explain why a role exists, which business function it supports, and which objects it can reach.<\/p>\n Ownership deserves special attention because it conveys extensive control over an object. If every application role owns the objects it uses, later delegation and governance can become difficult. Many organizations therefore separate object ownership from day-to-day usage roles and manage grants through a controlled administrative process.<\/p>\n Account roles operate at the account level and can receive privileges across multiple databases and other account objects. Database roles are scoped to a single database. They are useful for packaging access to related objects inside that database and can then be granted to account roles for internal use.<\/p>\n Database roles become especially useful in data sharing because a provider can grant one or more database roles to a share. That lets the provider segment a shared database into different access packages. A consumer can then map the shared database roles to its own local account roles, preserving separation among consumer teams rather than giving everyone the same imported access.<\/p>\n This is more flexible than a simple all-or-nothing model. If a shared database contains sales, support, and product datasets, the provider can expose different database roles to represent those subject areas. The consumer can grant the appropriate shared role to its own finance or support users according to local policy.<\/p>\n With Secure Data Sharing, the provider creates a share and adds supported database objects to it. A consumer account creates an imported database from that share and queries the shared objects. The underlying data remains in the provider\u2019s Snowflake environment; the sharing relationship exposes governed, read-only access instead of exporting and synchronizing a second dataset.<\/p>\n This changes the operational burden compared with file-based distribution. There is no nightly job whose purpose is to copy a full dataset to every consumer. Updates made by the provider become available through the share according to the sharing model, and access can be revoked by changing the provider-side share or its privileges.<\/p>\n The no-copy design is also why secure views are important. A provider rarely needs to expose every base table exactly as stored. Secure views can present only the columns and rows intended for consumers while hiding implementation details that should remain private.<\/p>\n Snowflake supports two main patterns for adding database objects to a share. One is to create database roles, grant privileges on the desired objects to those roles, and then grant the database roles to the share. The other is to grant privileges on objects directly to the share.<\/p>\n The database-role pattern provides better segmentation for a single database. Consumers can grant different shared database roles to different local roles. Direct grants are simpler in some cases and are required for certain cross-database sharing patterns where a database role cannot represent all dependencies. The correct model depends on how many databases are involved and how granular consumer access needs to be.<\/p>\n The design should be intentional. If different consumer teams need different subsets of a shared dataset, a model that exposes everything through one broad privilege can force the consumer to recreate security boundaries elsewhere. Packaging access cleanly at the provider side is often easier to govern.<\/p>\n The provider controls what is shared. That includes creating the share, granting the required database and schema usage, exposing tables or secure views, and adding or authorizing consumer accounts. The consumer controls which local users can access the imported data after the share is accepted.<\/p>\n This split is useful because each side remains responsible for its own identities. The provider does not normally manage individual users in every consumer account. Instead, it publishes a data product or share boundary. The consumer maps that boundary to its own role hierarchy.<\/p>\n For direct sharing, administrative privileges such as A direct share is appropriate when the provider knows the consumer accounts and the sharing relationship is straightforward. Listings build on Secure Data Sharing by adding metadata, discoverability, usage information, and cross-region delivery capabilities. A private listing can target specific consumers, while a public listing can be offered through the Snowflake Marketplace.<\/p>\n The important architectural point is that listings do not replace access control. The data product still needs a clear object boundary, and the provider still needs to decide which roles or objects belong in the underlying share. Listings change how the product is distributed and discovered, not the need for least privilege.<\/p>\n This is particularly relevant when a dataset is becoming a formal internal or external product. At that point, documentation, consumer onboarding, usage metrics, regional availability, and commercial terms may matter as much as the SQL grants themselves.<\/p>\n Snowflake supports sharing data that is protected by governance policies, including masking and row-access policies, when the design is built correctly. This allows a provider to expose different results according to the shared database role or policy context rather than creating separate physical copies for every audience.<\/p>\n That capability should be used carefully. The provider must test the consumer experience and validate that policy logic behaves as intended under data sharing. A policy that works for local account roles may need different conditions when shared database roles are involved.<\/p>\n Governed sharing is strongest when the published interface is narrow. Secure views, curated schemas, database roles, masking policies, and row-access policies can work together so that consumers see only the data product they need, while the provider keeps raw and administrative structures private.<\/p>\n Role activation also affects how access is experienced. Users can have several roles available but operate with a current role or secondary-role context, so troubleshooting should verify which role is active rather than assuming every granted privilege is automatically in effect for every statement. On the consumer side, access to imported data depends on how imported privileges or shared database roles are mapped into local roles. This is another reason to test with a representative consumer identity instead of validating only as an administrator.<\/p>\n Begin by classifying the data and identifying the consumer. Decide whether access is internal to one account or crosses account boundaries. For internal access, design the role hierarchy and grants first. For external or cross-business-unit access, define the share boundary and then decide whether a direct share, private listing, or public Marketplace listing is appropriate.<\/p>\n Next, choose the smallest useful object surface. Prefer curated tables or secure views over exposing an entire operational schema without review. Decide whether shared database roles are needed to segment access. Confirm who owns the objects and who is allowed to create or modify sharing relationships.<\/p>\n Finally, test from the consumer perspective. Verify that the imported database contains only the intended objects, that consumer roles can access the correct subset, and that revoking access behaves predictably. Security design is complete only when both provider and consumer behavior are understood.<\/p>\n Snowflake makes cross-account collaboration technically simple, but simplicity should not become overexposure. Strong designs combine clear role hierarchies, narrow shares, well-defined consumer mappings, and deliberate use of listings. The result is a data-sharing model that preserves the main Snowflake advantage: consumers can work with live governed data without every team maintaining another copy.<\/p>\n","protected":false},"excerpt":{"rendered":" Snowflake access design has two related questions: who can use an object inside an account, and how data should be exposed to users in another […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,168,31,66],"tags":[],"class_list":["post-3391","post","type-post","status-publish","format-standard","hentry","category-certifications","category-exam-cof-c03","category-cybersecurity","category-snowflake-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3391","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3391"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3391\/revisions"}],"predecessor-version":[{"id":3892,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3391\/revisions\/3892"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3391"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3391"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3391"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Start with least privilege inside the provider account<\/h2>\n
Account roles and database roles solve different scopes<\/h2>\n
Secure Data Sharing does not copy the provider\u2019s data<\/h2>\n
Choose between database roles and direct grants to a share<\/h2>\n
Provider and consumer responsibilities are different<\/h2>\n
CREATE SHARE<\/code> and consumer-side IMPORT SHARE<\/code> should be delegated carefully. Granting the ability to create shares can allow a role to expose objects it controls to other accounts. That is a high-impact privilege and should not be handed out merely for convenience.<\/p>\nUse listings when the sharing relationship needs more than a direct share<\/h2>\n
Policy-protected data can still be shared deliberately<\/h2>\n
A practical access-design sequence<\/h2>\n