What you will be able to do
- Place any Snowflake object at the right level: organization, account, database or schema
- Tell account objects (users, roles, warehouses, databases) apart from schema objects (tables, views, stages, file formats, UDFs, stored procedures)
- Explain what pipes, shares and sequences are for
- Describe how ML models and Snowflake Native Apps fit into the hierarchy
Key concept
Container hierarchy — Every Snowflake object sits inside a parent container. The organization holds accounts, an account holds databases, a database holds schemas, and a schema holds the objects you work with day to day. An object's level decides where its name must be unique and how you write its fully-qualified name.
1.The top of the tree: organizations and accounts
The organization is at the top of the hierarchy. Snowflake describes it as a first-class object that links all the accounts your business entity owns. From it, organization administrators can view, create and manage accounts across regions and cloud platforms. It also makes billing, replication and failover, and cross-region data sharing simpler.
You never create an organization yourself. If you sign up through self-service, Snowflake creates one automatically with a system-generated name. If you set up accounts with Snowflake personnel, Snowflake creates it with a custom name. In both cases you can add more accounts later. If you want to rename it, you contact Snowflake Support. Any role can call CURRENT_ORGANIZATION_NAME to see which organization the current account belongs to. An organization administrator can list all accounts with SHOW ACCOUNTS.
An organization can hold several kinds of account:
- an organization account, a special account that organization administrators use to manage a multi-account organization and to read the premium ORGANIZATION_USAGE views;
- regular Snowflake accounts, including trial accounts;
- Snowflake Open Catalog accounts, used to manage catalogs in Snowflake Open Catalog.
The account-level DDL also includes CREATE MANAGED ACCOUNT. Snowflake currently uses it to create *reader accounts*, so a provider can share data with consumers who aren't Snowflake customers.
The next level down is the account object. Users, roles, warehouses and databases are account objects, so each of their names must be unique across the whole account. A warehouse doesn't belong to any database or schema.
Checkpoint 1 of 6· Check yourself
An administrator wants to create a virtual warehouse called ETL_WH in an account that already has a warehouse with that name in a different team's database. What happens?
Warehouses don't live inside databases. They are account objects, so their identifiers must be unique account-wide. That also means the premise is wrong: a warehouse can't sit 'in' a database.
“Identifiers for account objects (users, roles, warehouses, databases, etc.) must be unique across the entire account.”Source: docs.snowflake.com
2.Databases and schemas as containers
Every database in your account lives inside the account object. Each database holds schemas, and a schema name only has to be unique within its own database. That's why two databases can each have a schema called STAGING. To tell them apart, you write the schema name fully qualified as <database_name>.<schema_name>.
The schema is where most of your work happens. A schema object's name has to be unique only inside that schema, and its fully-qualified name has three parts: <database_name>.<schema_name>.<object_name>. Below the schema there's one more level: column names must be unique within their table.
| Container | Objects it holds | Uniqueness scope |
|---|---|---|
| Account | Users, roles, warehouses, databases | Unique across the entire account |
| Database | Schemas | Unique within the database; qualify as <database_name>.<schema_name> |
| Schema | Tables, views, file formats, stages, UDFs, stored procedures | Unique within the schema; qualify as <database_name>.<schema_name>.<object_name> |
| Table | Columns | Unique within the table |
Checkpoint 2 of 6· Match them up
Match each object to the container that holds it
Tap a term, then the definition that fits it.
Databases are account objects, schemas live in a database, stages (like tables, views and file formats) are schema objects, and columns belong to a table.
“Identifiers for schema objects (tables, views, file formats, stages, etc.) must be unique within the schema.”Source: docs.snowflake.com
3.Schema objects: tables, views, stages, file formats, UDFs and stored procedures
Most of the database objects listed in the exam guide are schema objects. That includes tables, views, stages and file formats, plus code objects: user-defined functions (UDFs) and stored procedures. Every schema object follows the same rule: its name is unique within its schema, and you refer to it as database.schema.object from anywhere else.
UDFs and stored procedures are the one exception. Snowflake lets several of them share an identifier in the same schema, which it calls *overloading*. So if a question asks whether two functions with the same name can sit in one schema, the answer is yes. The same question about two tables gets a no.
The access-control model follows the same layout. Tables, views, functions and stages are securable objects inside a schema, the schema is inside a database, and all databases are inside the account. Since every schema object also has an owner, privileges are granted object by object, within these containers.
These objects can also carry their own settings. In Snowflake's object-parameter list, REPLACE_INVALID_CHARACTERS can be set on a file format, and LOG_LEVEL and TRACE_LEVEL can be set on stored procedures and functions. In other words, a schema object is a configurable entity with settings of its own, not only a name.
Checkpoint 3 of 6· Check yourself
Which statement about the placement of objects in the Snowflake hierarchy is correct?
Stages and file formats are schema objects, like tables and views. Stored procedures are schema objects too. Warehouses are account objects.
“Identifiers for schema objects (tables, views, file formats, stages, etc.) must be unique within the schema.”Source: docs.snowflake.com
4.Pipes, shares and sequences
Three more object types each do one specific job.
A pipe is a named, first-class object that contains a COPY INTO statement. Snowpipe uses that statement to load data from an ingestion queue into tables. The example below shows how the hierarchy fits together: the pipe lives in a schema (my_db.my_schema), and its COPY INTO reads from a stage (@mystage) with a file format specification (TYPE = 'JSON').
from snowflake.core.pipe import Pipe
my_pipe = Pipe(
name="my_pipe",
comment="creating my pipe",
copy_statement="COPY INTO my_table FROM @mystage FILE_FORMAT = (TYPE = 'JSON')",
)A share is a named object that holds everything needed to share a database. The provider adds objects to it, such as databases, schemas, tables and secure views. They can grant privileges through a database role, directly to the share, or both. The provider then adds the consumer accounts that may use the share. A consumer creates a database from the share, and the imported objects become available to users in that consumer account. The provider controls the share completely. New objects and updates appear for consumers right away, and access can be revoked at any time.
A sequence generates unique numbers across sessions and statements, including concurrent statements. It's typically used for primary-key values. Two concurrent queries never get the same value from a sequence. But uniqueness is not the same as being contiguous: Snowflake doesn't guarantee that sequence numbers have no gaps. And if you flip the interval's sign, for example from 1 to -1, you can get duplicates.
Checkpoint 4 of 6· Check yourself
A team uses a sequence to generate order IDs and finds that the IDs go 1, 2, 3, then 7. What explains this?
Sequence values are unique, even across concurrent queries, but Snowflake explicitly doesn't promise that they are gap-free.
“Snowflake does not guarantee generating sequence numbers without gaps.”Source: docs.snowflake.com
5.ML models and applications
Two newer object types sit alongside the familiar ones.
ML models. The Snowflake Model Registry stores machine learning models as first-class *schema-level* objects. That means a model sits next to tables and views and follows the same naming and access rules. The registry stores and manages model versions, metrics and metadata, and it uses role-based access control to manage who can reach each model. Not every model appears there, though. Models trained with Snowflake ML Functions, such as FORECAST, don't show up in the model registry.
Applications. The Snowflake Native App Framework separates what the provider builds from what the consumer runs. The provider develops and tests an application package. To share it, they publish a listing, either on Snowflake Marketplace or as a private listing, with the application package as the listing's data product. Consumers find the listing and install the application. Installing it runs the package's setup script, the SQL that runs whenever a consumer installs or upgrades an application. So the provider's application package and the application installed in the consumer's account are two different objects.
Checkpoint 5 of 6· Exam question
Which statement correctly describes how organizations and accounts relate to each other in Snowflake's object hierarchy?
Correct answer: A — An organization is a top-level container that groups one or more accounts for shared management, while each account still owns its own databases, warehouses, and users independently.
- A. An organization sits above the account level in Snowflake's hierarchy and groups several accounts for consolidated administration and reporting, while each account retains its own independent databases, warehouses, and users. This matches the object hierarchy taught for the exam: organization, then account, then database and below.
- B. Describing an organization as a role confuses it with RBAC constructs like ACCOUNTADMIN, which grant privileges inside a single account rather than group multiple accounts together. Roles never sit above the account in the hierarchy.
- C. An organization is not a schema-level object and does not need to be recreated per region; it is a hierarchy-level container above accounts, not metadata stored inside one account's schema.
- D. An organization does not pool or share compute resources across accounts; each account keeps its own virtual warehouses and consumes its own credits, even inside a shared organization.
Checkpoint 6 of 6· Check yourself
Where does a model logged in the Snowflake Model Registry live in the object hierarchy?
The registry stores models as first-class schema-level objects. They follow the same container and naming rules as other schema objects.
“The model registry stores machine learning models as first-class schema-level objects in Snowflake.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The application package a provider publishes and the application a consumer installs are the same object.Why is that wrong?
The provider builds and publishes an application package through a listing. The consumer then installs an application from that listing, which creates its own instance in the consumer's account.
Covered in ML models and applications
2.Because sequence values are unique, they must also be consecutive with no gaps.Why is that wrong?
Sequences guarantee unique values across sessions and concurrent statements, but not contiguous ones. Gaps are normal.
Covered in Pipes, shares and sequences
3.Two schema objects with the same name can never exist in one schema.Why is that wrong?
UDFs and stored procedures can be overloaded, so several of them can share an identifier in the same schema.
Covered in Schema objects: tables, views, stages, file formats, UDFs and stored procedures
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“An organization is a first-class Snowflake object that links the accounts owned by your business entity.”
↩︎ The top of the tree: organizations and accounts“Snowflake customers never directly create an organization.”
↩︎ The top of the tree: organizations and accounts“Users with any role can execute the CURRENT_ORGANIZATION_NAME function to return the organization of the current account.”
↩︎ The top of the tree: organizations and accounts - 2.
“Currently used to create reader accounts for providers who wish to share data with non-Snowflake customers.”
↩︎ The top of the tree: organizations and accounts - 3.
“The top-most container is the customer organization.”
↩︎ The top of the tree: organizations and accounts“All databases for your Snowflake account are contained in the account object.”
↩︎ Databases and schemas as containers“Securable objects such as tables, views, functions, and stages are contained in a schema object”
↩︎ Schema objects: tables, views, stages, file formats, UDFs and stored procedures“Securable objects such as tables, views, functions, and stages are contained in a schema object, which are in turn contained in a database.”
↩︎ Key concept - 4.
“Identifiers for schemas must be unique within the database.”
↩︎ Databases and schemas as containers“Identifiers for schema objects (tables, views, file formats, stages, etc.) must be unique within the schema.”
↩︎ Schema objects: tables, views, stages, file formats, UDFs and stored procedures“UDFs and stored procedures are schema objects; however Snowflake supports UDFs/stored procedures with the same identifier within the same schema”
↩︎ Exam trap 3“Identifiers for account objects (users, roles, warehouses, databases, etc.) must be unique across the entire account.”
↩︎ Checkpoint“Identifiers for schema objects (tables, views, file formats, stages, etc.) must be unique within the schema.”
↩︎ Checkpoint“UDFs and stored procedures are schema objects; however Snowflake supports UDFs/stored procedures with the same identifier within the same schema”
↩︎ Prediction - 5.https://docs.snowflake.com/en/developer-guide/snowflake-python-api/snowflake-python-managing-data-loadingOfficial docs
“named, first-class Snowflake objects that contain a COPY INTO statement used by Snowpipe to load data from an ingestion queue into tables”
↩︎ Pipes, shares and sequences - 6.
“Shares are named Snowflake objects that encapsulate all of the information required to share a database.”
↩︎ Pipes, shares and sequences“You choose which accounts can consume data from the share by adding the accounts to the share.”
↩︎ Pipes, shares and sequences - 7.
“Sequences are used to generate unique numbers across sessions and statements, including concurrent statements.”
↩︎ Pipes, shares and sequences“Snowflake does not guarantee generating sequence numbers without gaps.”
↩︎ Exam trap 2“Snowflake does not guarantee generating sequence numbers without gaps.”
↩︎ Checkpoint - 8.
“The model registry stores machine learning models as first-class schema-level objects in Snowflake.”
↩︎ ML models and applications - 9.
“a provider can share an application with consumers by publishing a listing containing the application package as the data product of a listing”
↩︎ ML models and applications“Contains SQL statements that are run when the consumer installs or upgrades an application”
↩︎ ML models and applications“consumers can discover the listing and install the application.”
↩︎ Exam trap 1