What you will be able to do
- Decide whether a task belongs to an organization administrator (GLOBALORGADMIN or ORGADMIN) or an account administrator (ACCOUNTADMIN)
- Explain why ORGADMIN is being phased out in favour of GLOBALORGADMIN in the organization account
- Delegate specific organization-level privileges instead of handing out the GLOBALORGADMIN role
- Apply Snowflake's recommended precautions for assigning and using ACCOUNTADMIN
- Predict how organization-level changes such as renaming or dropping an account, or importing organization users, affect objects inside an account
Key concept
Organization scope vs account scope — Snowflake has two tiers of administration. Organization administrators work across every account in the organization: they create and drop accounts and see usage for the whole organization. ACCOUNTADMIN is the top role inside a single account and has no authority over the other accounts.
1.Two ways to act at the organization level
An organization is a first-class Snowflake object that links all the accounts your business owns, across regions and cloud platforms. Some tasks only make sense at this level: creating accounts, dropping accounts and viewing usage for the whole organization. No single account's administrator can do them. Snowflake currently offers two ways to do this work. The recommended way is the GLOBALORGADMIN role, used from the special organization account. The older way is the ORGADMIN role, used from any regular account that has the role enabled. A user who holds GLOBALORGADMIN is called the global organization administrator.
For multi-account organizations, Snowflake is phasing out the ORGADMIN approach and strongly recommends GLOBALORGADMIN in the organization account instead. Customers get a notification email at least three months before ORGADMIN is retired. (The exam guide's note that ORGADMIN "will be replaced" refers to this change.) Until then, ORGADMIN still works, with a few rules. The first account in an organization has ORGADMIN enabled. From that account you can enable the role in other accounts by setting the IS_ORG_ADMIN property.
USE ROLE ORGADMIN;
ALTER ACCOUNT my_account1 SET IS_ORG_ADMIN = TRUE;| Aspect | GLOBALORGADMIN | ORGADMIN |
|---|---|---|
| Where you sign in | The organization account | An ORGADMIN-enabled account |
| Status for multi-account organizations | Recommended way to perform organization-level tasks | Being phased out, with at least three months' notice by email |
| How many accounts can use it | Used from the organization account | Up to eight accounts by default; contact Snowflake Support for more |
| Restrictions | Switch the active role with USE ROLE GLOBALORGADMIN | Cannot be enabled for a reader account; cannot be disabled in the last account that has it |
There is a precise limit on ALTER ACCOUNT here: it accepts only the account name form of the account identifier, not the account locator. To stop an account from being used for organization tasks, sign in to a different ORGADMIN-enabled account and set IS_ORG_ADMIN = FALSE on it. You cannot remove the role from the last account that has it; for that you must contact Snowflake Support.
Checkpoint 1 of 8· Check yourself
An administrator runs ALTER ACCOUNT ... SET IS_ORG_ADMIN = TRUE and identifies the target account by its account locator. What happens?
When enabling or disabling ORGADMIN, ALTER ACCOUNT requires the account name. A locator is rejected.
“You cannot use the account locator to specify the account.”Source: docs.snowflake.com
Use cases and best practice, in short. Organization administrators handle the account lifecycle (create, rename, change edition, drop) and organization-wide usage. ACCOUNTADMIN handles setup and account-level objects inside one account. Do organization-level work as GLOBALORGADMIN in the organization account rather than as ORGADMIN, and delegate individual privileges instead of sharing the role. Keep ACCOUNTADMIN for work inside a single account.
Organization-level changes reach account-level objects, so analyze the impact before you make them. Renaming an account gives it a new account URL. By default the original URL is saved, so users can keep using it; if you clear that option, users must switch to the new URL. Dropping an account is the most far-reaching change. The account is locked during a grace period of 3 to 90 days, and when it is dropped, any shares it provides stop working, so consumers lose access to the shared data. Reader accounts it created are dropped and deleted along with it. You must also delete its listings and drop the associated shares before the drop is allowed. A dropped account can be restored with UNDROP ACCOUNT inside the grace period.
Organization users work in the other direction: objects defined once at the organization level appear in accounts. When an account administrator imports an organization user group, Snowflake creates user objects in that account and an access control role named after the group, which is granted to each imported user. The account's own administrators can then grant privileges to that role, and can grant it to account-specific roles only if the group was created with IS_GRANTABLE = TRUE. Changes to an account's organization (a rename, a merge, or a move to another organization) also give the account a new URL. The old organization URL works for 90 days if it was saved.
Checkpoint 2 of 8· Check yourself
An organization administrator drops an account that provides shares to consumers. What is the effect on those shares?
Dropping the provider account takes effect on its shares immediately, even though the account itself can be undropped during the grace period.
“Shares stop working. Consumers lose access to data shared by the account.”Source: docs.snowflake.com
2.The organization account and delegating organization privileges
There is only one organization account per organization. Administrators use it for tasks that affect the whole organization. They can view organization-level data collected from every account, including each account's query history. They can manage organization-level objects such as organization users, manage the lifecycle of accounts, enable replication for an account, and accept Snowflake Marketplace terms for the entire organization. Its ORGANIZATION_USAGE schema also contains premium views that a regular account does not have.
Creating the organization account starts from an existing account that has ORGADMIN enabled. You sign in to it, switch to ORGADMIN and run CREATE ORGANIZATION ACCOUNT. Before you do, plan for two things. First, the ORGANIZATION_USAGE schema starts filling with data, which adds cost. Second, if the organization has an account in a U.S. SnowGov Region, Snowflake recommends creating the organization account in that regulated region.
CREATE ORGANIZATION ACCOUNT myorgaccount ADMIN_NAME = admin ADMIN_PASSWORD = 'TestPassword1' EMAIL = 'myemail@myorg.org' MUST_CHANGE_PASSWORD = true EDITION = enterprise;Checkpoint 3 of 8· Put it in order
Put the steps for creating the organization account in order
- 1.Choose an existing account that has the ORGADMIN role enabled
- 2.Execute CREATE ORGANIZATION ACCOUNT
- 3.Sign in to that account
- 4.Switch to the ORGADMIN role
The organization account is created from an ORGADMIN-enabled account, using the ORGADMIN role, with CREATE ORGANIZATION ACCOUNT.
“Choose an existing account from which you will create the organization account. This existing account must have the ORGADMIN role enabled.”Source: docs.snowflake.com
Least privilege applies at the organization level too. Not everyone who creates accounts or accepts Marketplace terms needs to be a global organization administrator. In the organization account, GLOBALORGADMIN can grant individual privileges to other roles: APPLY TAG, MANAGE ACCOUNTS, MANAGE LISTING AUTO FULFILLMENT, MANAGE ORGANIZATION CONTACTS, MANAGE ORGANIZATION TERMS and PURCHASE DATA EXCHANGE LISTING. These privileges are granted ON ACCOUNT.
Checkpoint 4 of 8· Fill the gap
In the organization account, which role grants MANAGE ACCOUNTS to a custom role?
USE ROLE ? ;
GRANT MANAGE ACCOUNTS ON ACCOUNT TO ROLE custom_role;In the organization account, GLOBALORGADMIN is the role that hands out organization-level privileges such as MANAGE ACCOUNTS.
Source: docs.snowflake.comSources5
3.What ACCOUNTADMIN is for, and what it is not
Inside one account, ACCOUNTADMIN is the top role. It contains the SYSADMIN and SECURITYADMIN system roles. It is the only role that configures account-level parameters, and it can view and manage billing and credit data and stop any running SQL statement. Its intended use is narrow: initial setup, plus day-to-day management of account-level objects and tasks.
ACCOUNTADMIN is not a superuser. It can see and manage an object only if it, or a role below it in the hierarchy, has enough privileges on that object. This is why a custom role has to be granted upward, preferably into a hierarchy under SYSADMIN, which ACCOUNTADMIN in turn manages. Two practical rules follow from ACCOUNTADMIN's narrow purpose. First, do not use it to create objects unless they truly need the highest level of secure access. If you do, you must explicitly grant privileges on them before anyone else can use them. Second, use a role other than ACCOUNTADMIN for automated scripts. With a role hierarchy under SYSADMIN, warehouse and database work can run at SYSADMIN or lower. Creating or modifying users and roles needs SECURITYADMIN or another role with enough privileges.
Checkpoint 5 of 8· Check yourself
Which statement about ACCOUNTADMIN matches Snowflake's guidance?
ACCOUNTADMIN alone sets account-level parameters, yet it reaches objects only through privileges in its role hierarchy.
“Note that ACCOUNTADMIN is not a superuser role.”Source: docs.snowflake.com
Checkpoint 6 of 8· Exam question
A company is opening a subsidiary in the Frankfurt region and wants a new Snowflake account inside its existing organization. The platform team wants the standard, supported SQL approach. What should the administrator do?
Correct answer: A — Switch to the ORGADMIN role and run CREATE ACCOUNT with the admin user name, edition, and region, then hand the initial credentials to the subsidiary.
- A. Correct. Account creation is an organization-level task, and the ORGADMIN role runs CREATE ACCOUNT with ADMIN_NAME, EDITION, and REGION parameters to add the account to the organization.
- B. Incorrect. ACCOUNTADMIN governs objects inside a single account, and it does not carry organization-level privileges such as creating new accounts in the organization.
- C. Incorrect. Customers can self-provision additional accounts with CREATE ACCOUNT through ORGADMIN, so a support case is not required for a new region.
- D. Incorrect. SECURITYADMIN manages grants and users within one account; it has no privilege to create accounts, in any region, in the organization.
Sources6
4.Assigning ACCOUNTADMIN safely
When an account is provisioned, the first user gets ACCOUNTADMIN. That user should create one or more USERADMIN users, and those users create everyone else. After that, the question becomes who holds ACCOUNTADMIN and how they log in. Snowflake recommends these precautions:
| Precaution | Reason |
|---|---|
| Grant ACCOUNTADMIN to only a select, limited number of people | It is the most powerful role in the account |
| Require MFA for every ACCOUNTADMIN user | Protects the login of the most powerful role |
| Assign ACCOUNTADMIN to at least two users | Resetting a lost ACCOUNTADMIN password through Snowflake can take up to two business days; two admins can reset each other's passwords |
| Never make ACCOUNTADMIN a user's default role | Admins must switch to it explicitly each time they log in |
| Give ACCOUNTADMIN users current employee email addresses | Snowflake Support knows who to contact in an urgent situation |
A non-ACCOUNTADMIN default role does not technically stop anyone from creating objects as ACCOUNTADMIN. What it does is make each use deliberate: every session starts in an ordinary role, and the administrator has to choose to switch.
Checkpoint 7 of 8· Match them up
Match each ACCOUNTADMIN precaution to the problem it addresses
Tap a term, then the definition that fits it.
Each precaution targets a specific risk: getting locked out, using the role casually, a compromised password, or Support being unable to reach anyone.
“it forces them to explicitly change their role to ACCOUNTADMIN each time they log in.”Source: docs.snowflake.com
Checkpoint 8 of 8· Exam question
A cloud governance engineer holding only the ORGADMIN role runs SELECT * FROM sales.public.orders in one of the organization's accounts and receives an authorization error. Which explanation is correct?
Correct answer: C — ORGADMIN manages the organization and its accounts but carries no privileges on objects inside an account, so access must come from roles in that account.
- A. Incorrect. Secondary roles only aggregate privileges from roles already granted within the account; ORGADMIN has no object privileges for them to add.
- B. Incorrect. ORGADMIN does not carry data privileges in any edition, so edition is not the cause of the authorization error.
- C. Correct. ORGADMIN is scoped to organization tasks such as managing accounts; it holds no grants on databases, schemas, or tables, so the account's own RBAC must grant access.
- D. Incorrect. There is no read-only metadata mode for ORGADMIN on account objects, and query tags have no effect on authorization.
Sources6
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.ACCOUNTADMIN is a superuser, so it can modify or drop any object in the account.Why is that wrong?
ACCOUNTADMIN only reaches objects through privileges held by itself or by roles below it. Objects owned by a custom role that was never granted into its hierarchy are out of its reach.
Covered in What ACCOUNTADMIN is for, and what it is not
2.An existing ORGADMIN-enabled account can be promoted to be the organization account.Why is that wrong?
You create a new organization account from an ORGADMIN-enabled account. Converting an existing one is not supported.
Covered in The organization account and delegating organization privileges
3.Dropping an account only affects that account, because shares and reader accounts belong to other parties.Why is that wrong?
Shares from the dropped account stop working and its reader accounts are dropped and deleted with it, so consumers are affected at once.
Covered in Two ways to act at the organization level
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Using the ORGADMIN role in an ORGADMIN-enabled account is being phased out for multi-account organizations.”
↩︎ Two ways to act at the organization level“By default, the ORGADMIN role can be enabled in a maximum of eight accounts.”
↩︎ Two ways to act at the organization level“Currently, you cannot disable the ORGADMIN role if it is the last account that has the role enabled.”
↩︎ Two ways to act at the organization level“Organization administrators perform organization-level tasks such as managing accounts and viewing organization-level usage information.”
↩︎ Key concept“You cannot use the account locator to specify the account.”
↩︎ Checkpoint - 2.
“Shares stop working. Consumers lose access to data shared by the account.”
↩︎ Two ways to act at the organization level“Reader accounts are dropped and then deleted at the same time as the provider account.”
↩︎ Two ways to act at the organization level“Shares stop working. Consumers lose access to data shared by the account.”
↩︎ Exam trap 3 - 3.
“When an account is renamed, Snowflake creates a new account URL that is used to access the account.”
↩︎ Two ways to act at the organization level - 4.
“Snowflake creates an access control role of the same name.”
↩︎ Two ways to act at the organization level - 5.
“There is only one organization account for an organization.”
↩︎ The organization account and delegating organization privileges“The GLOBALORGADMIN role can assign privileges to other roles to let other users perform organization-level tasks.”
↩︎ The organization account and delegating organization privileges“Creating the organization account results in the ORGANIZATION_USAGE schema being populated with data, which incurs additional costs for your organization.”
↩︎ The organization account and delegating organization privileges“You can’t convert an existing ORGADMIN-enabled account to be the organization account.”
↩︎ Exam trap 2“You can’t convert an existing ORGADMIN-enabled account to be the organization account.”
↩︎ Prediction“Choose an existing account from which you will create the organization account. This existing account must have the ORGADMIN role enabled.”
↩︎ Checkpoint - 6.
“This role alone is responsible for configuring parameters at the account level.”
↩︎ What ACCOUNTADMIN is for, and what it is not“The ACCOUNTADMIN role is intended for performing initial setup tasks in the system and managing account-level objects and tasks on a day-to-day basis.”
↩︎ What ACCOUNTADMIN is for, and what it is not“Snowflake recommends using a role other than ACCOUNTADMIN for automated scripts.”
↩︎ What ACCOUNTADMIN is for, and what it is not“Assign this role only to a select/limited number of people in your organization.”
↩︎ Assigning ACCOUNTADMIN safely“Assign this role to at least two users.”
↩︎ Assigning ACCOUNTADMIN safely“do not make ACCOUNTADMIN the default role for any users in the system”
↩︎ Assigning ACCOUNTADMIN safely“This role only allows viewing and managing objects in the account if this role, or a role lower in a role hierarchy, has sufficient privileges”
↩︎ Exam trap 1“By default, not even the ACCOUNTADMIN role can modify or drop objects created by a custom role.”
↩︎ Prediction“Note that ACCOUNTADMIN is not a superuser role.”
↩︎ Checkpoint“it forces them to explicitly change their role to ACCOUNTADMIN each time they log in.”
↩︎ Checkpoint