What you will be able to do
- Explain how an organization links accounts and which role administers it
- Compare one Snowflake account with multiple accounts and say what a separate account isolates
- Identify the features that work across accounts, and the edition each one needs
- List the real constraints on an account strategy and pick a fitting use case for multiple accounts
- Segment workloads inside one account using databases, schemas and object parameters
Key concept
Organization — The Snowflake object above every account your business owns. Creating accounts, replicating and failing over between them, sharing across regions and tracking usage all happen at this level, so every account strategy is designed here.
1.The organization: the container for every account
Every account strategy happens inside an organization. You never create one yourself. If you sign up through self-service, Snowflake creates it automatically with a system-generated name. If you set up accounts with Snowflake personnel, Snowflake creates it with a custom name. Either way, you can add more accounts once the organization exists with its first account. To rename the organization, you contact Snowflake Support.
An organization can hold three kinds of account. The organization account is a special account where organization administrators manage a multi-account organization and read the premium views in the ORGANIZATION_USAGE schema. Regular Snowflake accounts, including trial accounts, run your workloads. Snowflake Open Catalog accounts are for managing Open Catalog catalogs.
The organization administrator manages each account from start to finish: creating it, listing accounts, renaming them, managing account URLs, viewing or changing an account's edition, and dropping it.
Which role does this work has changed. Organization administrators now use the GLOBALORGADMIN role in the organization account. The older approach, the ORGADMIN role in an ORGADMIN-enabled account, is being phased out, and you can't convert an existing ORGADMIN-enabled account into the organization account. The organization account also costs money: creating it fills the ORGANIZATION_USAGE schema with data, and that adds cost for the organization.
Checkpoint 1 of 7· Check yourself
An architect is writing the runbook for organization-level administration. Which role and account should it name for organization-level tasks from now on?
Organization-level tasks, including running the organization account itself, belong to GLOBALORGADMIN in the organization account. ORGADMIN in an ORGADMIN-enabled account is being phased out.
“Organization administrators use the GLOBALORGADMIN role in the organization account to perform all organization-level tasks”Source: docs.snowflake.com
Use cases that call for an account strategy. An organization exists to link several accounts, so the appropriate use cases are the ones where a single account cannot meet the requirement:
- Separating environments. Snowflake generally recommends setting up each environment (for example development and production) as a separate account. This keeps production infrastructure apart from experimental development and restricts developer access to production data. The same pattern lets you attribute network traffic and cost by account type, such as production versus development. - Serving consumers in other regions or clouds. The organization lets you create accounts in different regions and on different cloud platforms, and replicate data to them. Data providers need only one copy of the dataset per region, not one per consumer. - Disaster recovery. Replication and failover between accounts in the same organization give you data availability and durability. - Regulated workloads. A regulated region, such as a U.S. SnowGov Region, can sit alongside commercial accounts in a hybrid organization. - People or services that work in several accounts. Organization users let the organization administrator define a person or service once and import it into many accounts.
The opposite case is also valid. With careful access management you can run several environments in one account, and the benefit is that you can easily clone production infrastructure and data for testing. This is easiest when databases are clearly separated, and harder when account-level objects and integrations are involved. Copying data to a different account, for example through org-internal data shares, can cost more. Pick multiple accounts when you need hard isolation, a different region or edition, or cross-region sharing and failover. Pick one account when cloning and simple administration matter more.
2.One account or many: what a separate account isolates
An account is a hard boundary. Each account in an organization can have its own users, roles, databases and warehouses. When you create an account, you choose its cloud platform, its region and its Snowflake edition. Account parameters can be set only at the account level, so an account-wide setting such as REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION applies to everyone in that account.
That gives you the trade-off. With one account, you have one role hierarchy and one set of account parameters to maintain, and every database is reachable without moving data between accounts. The cost is that everyone shares one region, one edition and one set of account-wide settings. With multiple accounts, you can isolate or segment work: production apart from development, a subsidiary apart from the parent, or a regulated workload in a regulated region. Each segment can have its own edition and security settings. The cost is that users, roles and parameters are administered per account, and data has to cross between accounts through replication or sharing.
The use cases that justify more than one account follow from this. You need another account to serve data consumers in another region, to keep a standby account for failover, to put one workload on Business Critical without upgrading everything, or to run a regulated workload, such as one in a U.S. SnowGov Region, alongside commercial accounts. These are called hybrid organizations.
| Design aspect | One account | Multiple accounts |
|---|---|---|
| Users, roles, databases, warehouses | One shared set for all teams | Each account can have its own set |
| Cloud platform, region, edition | One choice for every workload | Specified separately when each account is created |
| Account parameters (ALTER ACCOUNT) | One value applies account-wide | Can differ per account, but must be set or replicated to each one |
| Billing | One account bill | All accounts on a single bill; tracked with Organization Usage views |
Checkpoint 2 of 7· Check yourself
A company runs everything in one Enterprise Edition account. A newly acquired unit must run on Business Critical Edition. The rest of the company should stay on Enterprise. What does this requirement point to?
Edition is chosen per account when the account is created. It is not a database, schema or warehouse setting, so the only way to give one unit a different edition is a separate account.
“When creating an account, you can specify a cloud platform, a region, and a Snowflake edition.”Source: docs.snowflake.com
3.Capabilities that span accounts
Several capabilities exist specifically to connect accounts. The organization gives you a central view of every account, self-service account creation, replication and failover, data sharing with consumers across regions, and the ability to monitor usage across all accounts.
Replication copies objects from a source account to one or more target accounts in the same organization, including across regions and across cloud platforms. A replication group is a set of objects that replicates as a unit and gives read-only access in the target. A failover group is a replication group that can also fail over: when you promote a secondary failover group to primary, its objects become read-write. Both kinds of group give point-in-time consistency.
Governance objects travel too, which is how one control design can extend to several accounts. If you replicate roles, you also get the privileges granted to them and the role hierarchies. Masking policies, row access policies, tag-based masking policies and tags are replicated database objects. Which of these features you can use depends on edition:
| Feature | Standard | Enterprise | Business Critical / VPS |
|---|---|---|---|
| Database replication | Yes | Yes | Yes |
| Share replication | Yes | Yes | Yes |
| Replication Group | Yes | Yes | Yes |
| Account object (other than database and share) replication | No | No | Yes |
| Failover Group | No | No | Yes |
| Data protected with Tri-Secret Secure | No | No | Yes |
Cross-region data sharing combines these pieces. To share with consumers in another region, you first need an account of your own in that region. You then replicate databases and shares to it, and share locally from there.
Checkpoint 3 of 7· Put it in order
Put the steps for sharing data with consumers in a different region in order.
- 1.Replicate the group to the region where the consumers are
- 2.Add the consumer accounts to the replicated secondary shares
- 3.Have an organization administrator enable replication for the source and target accounts
- 4.Create a replication group and add the databases and shares
- 5.Create an account in the consumers' region and link it to your local account
The target-region account has to exist before replication can be set up. Replication is then enabled, the group is created and replicated, and local sharing from the secondary shares comes last.
“Before configuring data replication, you must create an account in a region where you wish to share data”Source: docs.snowflake.com
Checkpoint 4 of 7· Exam question
An architect sets `STATEMENT_TIMEOUT_IN_SECONDS` at the account level to enforce a global query runtime limit. A team lead then runs `ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 600` for their own session because a nightly batch job legitimately needs longer to complete. No object-level override exists for this warehouse. Which statement correctly describes the effective timeout for that team lead's session?
Correct answer: A — The session-level value of 600 seconds applies to that session because session parameters set at a more specific level override the account-level default.
- A. This is correct because session parameters resolve from account down to user to session, and the most specific level set wins. Setting the value with `ALTER SESSION` overrides the account-level default for that session only, leaving the account default unchanged for everyone else.
- B. This misstates the hierarchy: account-level parameter defaults are exactly what session-level overrides are designed to supersede for an individual session, so the account setting does not block a valid session override.
- C. Snowflake parameters do not average or blend values across hierarchy levels; the resolution model always takes the most specific single value that was explicitly set, never a computed combination.
- D. Any user can set session parameters for their own session with `ALTER SESSION`; no elevated role such as SECURITYADMIN is required to override a default for one's own session.
4.Constraints to design around
A multi-account design has to fit within some fixed limits.
Account count. By default, an organization can have at most 25 On Demand accounts. With a capacity contract, the default maximum is 100. Snowflake Support can raise either limit.
Regions. You can create an account only in a region that is enabled for your organization. Replication works across all regions within a region group. Replicating between region groups, for example from a commercial region to a government or Virtual Private Snowflake region, requires contacting Snowflake Support.
Edition. Database replication and share replication work on every edition. Replicating other account objects, and using failover groups, requires Business Critical or higher. After you upgrade an account to Business Critical, failover capabilities can take up to 12 hours to become available.
What replication does not carry. Inbound shares, meaning shares you receive from providers, cannot be replicated. Objects that are not supported for replication are skipped and won't exist in the target account after failover.
Hybrid organizations. Organization-level features can move metadata between regions. In an organization that has both regulated and commercial accounts, that metadata might move between a regulated region and a non-regulated one. Snowflake recommends creating the organization account in the regulated region.
Checkpoint 5 of 7· Check yourself
Which item belongs on an architect's list of real constraints for a Snowflake account strategy?
The 25 On Demand account default is a real limit, which Support can raise. Failover groups need Business Critical, replication works across cloud platforms, and inbound shares are not replicated.
“By default, the maximum number of On Demand accounts in an organization is 25.”Source: docs.snowflake.com
5.Segmenting inside one account with databases and schemas
When the requirements don't justify a new account, databases and schemas become the boundaries. They can carry different behaviour because many object parameters are set on the container itself. For example, DATA_RETENTION_TIME_IN_DAYS can be set on a database, a schema or a table, so two data owners in the same account can keep different Time Travel retention. The account parameter MIN_DATA_RETENTION_TIME_IN_DAYS sets the minimum retention period for the whole account.
How you draw database boundaries also matters later, because the database is the unit of replication. If a view references an object in another database, both databases must be replicated. A table constraint is not replicated when a foreign key references a key in a different database. Failover groups give you finer control: you can choose which schemas within a database to replicate. A database split that keeps related objects together makes it easier to move to multiple accounts later. The sources for this lesson do not prescribe naming conventions for databases or schemas.
Checkpoint 6 of 7· Check yourself
A view in database SALES selects from a table in database REFDATA. The team adds only SALES to a failover group. What does the design need?
A view that references an object in another database can only work in the target if both databases are replicated. Cross-database references therefore become a replication constraint.
“If a view references any object in another database (for example, table columns, other views, UDFs, or stages), both databases must be replicated.”Source: docs.snowflake.com
Checkpoint 7 of 7· Exam question
An architect wants every table created in the `RAW` schema of the `ANALYTICS` database to inherit `DATA_RETENTION_TIME_IN_DAYS = 3` by default, without requiring engineers to set the parameter on each `CREATE TABLE` statement. Which approach correctly uses the object parameter hierarchy to achieve this?
Correct answer: A — Run `ALTER SCHEMA analytics.raw SET DATA_RETENTION_TIME_IN_DAYS = 3` so every table created afterward in that schema inherits the value unless a table-level override is set.
- A. This is correct because object parameters resolve from account to database to schema to table, and setting the value at the schema level makes it the default for every table created in that schema, while still allowing an individual table to override it.
- B. This is unnecessary and contradicts how object parameters work: setting the value at the schema level is exactly the mechanism that lets child tables inherit it, so per-table configuration is not required.
- C. `DATA_RETENTION_TIME_IN_DAYS` is an object parameter, not a session parameter, so setting it in a session has no effect on the retention behavior of tables created during that session.
- D. Masking policies govern column-level data visibility, not Time Travel retention windows; retention is controlled purely through the object parameter hierarchy, not through Horizon governance policies.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.ORGADMIN in an ORGADMIN-enabled account is the long-term role for organization administration.Why is that wrong?
That model is being phased out. Organization-level tasks move to the GLOBALORGADMIN role in the organization account.
Covered in The organization: the container for every account
2.Separating environments always requires a separate account for each one.Why is that wrong?
Separate accounts are the general recommendation, but one account can host several environments with careful access management, and it makes cloning production for testing easy.
Covered in The organization: the container for every account
3.Accounts in the same organization automatically share users and roles.Why is that wrong?
Each account has its own users, roles, databases and warehouses. Roles reach another account only if you replicate them, which requires Business Critical.
Covered in One account or many: what a separate account isolates
4.Database replication works on every edition, so failover groups must too.Why is that wrong?
Database replication, share replication and replication groups work on every edition. Failover groups and replication of other account objects require Business Critical or higher.
Covered in Constraints to design around
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Snowflake customers never directly create an organization.”
↩︎ The organization: the container for every account“Ability to monitor and understand usage across all accounts in the organization.”
↩︎ Capabilities that span accounts“An organization is a first-class Snowflake object that links the accounts owned by your business entity.”
↩︎ Key concept - 2.
“Creating the organization account results in the ORGANIZATION_USAGE schema being populated with data, which incurs additional costs for your organization.”
↩︎ The organization: the container for every account“metadata might move between a regulated region and a non-regulated region.”
↩︎ One account or many: what a separate account isolates“Using the ORGADMIN role in an ORGADMIN-enabled account is being phased out.”
↩︎ Exam trap 1“Organization administrators use the GLOBALORGADMIN role in the organization account to perform all organization-level tasks”
↩︎ Checkpoint - 3.
“Snowflake generally recommends setting up each environment as a separate Snowflake account.”
↩︎ The organization: the container for every account“The benefit of a single-account setup is the ability to easily clone production infrastructure and data for testing”
↩︎ The organization: the container for every account“However, with careful access management, you can successfully manage multiple environments on one Snowflake account.”
↩︎ Exam trap 2 - 4.
“Companies can isolate network traffic based on the type of account (for example, production vs. development)”
↩︎ The organization: the container for every account - 5.
“Data providers only need to create one copy of the dataset per region; and not a copy per consumer.”
↩︎ The organization: the container for every account“Before configuring data replication, you must create an account in a region where you wish to share data”
↩︎ Checkpoint - 6.
“the organization administrator can create an organization user in the organization account.”
↩︎ The organization: the container for every account - 7.
“Each account in your organization can have its own set of users, roles, databases, and warehouses.”
↩︎ One account or many: what a separate account isolates“You can only create an account in a region that is enabled for your organization.”
↩︎ Constraints to design around“Each account in your organization can have its own set of users, roles, databases, and warehouses.”
↩︎ Exam trap 3“You will be billed for usage in all of your accounts on a single bill.”
↩︎ Prediction“When creating an account, you can specify a cloud platform, a region, and a Snowflake edition.”
↩︎ Checkpoint“By default, the maximum number of On Demand accounts in an organization is 25.”
↩︎ Checkpoint - 8.
“You can only set account parameters at the account level”
↩︎ One account or many: what a separate account isolates“DATA_RETENTION_TIME_IN_DAYS | Database, Schema, Table”
↩︎ Segmenting inside one account with databases and schemas - 9.
“Replication is supported across regions and across cloud platforms.”
↩︎ Capabilities that span accounts“When a secondary failover group is promoted to become the primary failover group, read-write access is available.”
↩︎ Capabilities that span accounts“Includes privileges granted to roles, as well as roles granted to roles (that is, hierarchies of roles).”
↩︎ Capabilities that span accounts“Customers can replicate across all regions within a region group.”
↩︎ Constraints to design around“Replication of inbound shares (shares from providers) is not supported.”
↩︎ Constraints to design around“If you use failover groups, you can choose which schemas within a database are replicated.”
↩︎ Segmenting inside one account with databases and schemas“Note that some replication features are only available for Business Critical Edition (or higher).”
↩︎ Exam trap 4“If a view references any object in another database (for example, table columns, other views, UDFs, or stages), both databases must be replicated.”
↩︎ Checkpoint - 10.
“it might take up to 12 hours for failover capabilities to become available.”
↩︎ Constraints to design around