What you will be able to do
- Tell account, session and object parameters apart, and name the levels where each can be set
- Predict which value applies when a parameter is set at more than one level
- View, set and reset parameters with SHOW PARAMETERS and ALTER ACCOUNT
- Plan how parameters reach additional accounts beyond a central account
1.Three parameter types
Parameters control how a Snowflake account, its user sessions and its objects behave. Every parameter has a default value. What you can override, and where, depends on which of three types the parameter is:
- Account parameters affect the entire account. You can set them only at the account level, with ALTER ACCOUNT, using a role that has been granted the privilege to set that parameter. - Session parameters supply defaults for users and their sessions. Most parameters are of this type. - Object parameters supply defaults for objects such as warehouses, databases, schemas and tables.
Overriding any default at the account level takes an account administrator, meaning a user granted the ACCOUNTADMIN role. NETWORK_POLICY is the one account parameter that SECURITYADMIN can also set. Several account parameters are security or governance controls an architect would set on purpose:
| Account parameter | What it controls |
|---|---|
| MIN_DATA_RETENTION_TIME_IN_DAYS | Minimum data retention period for Time Travel |
| DISABLE_USER_PRIVILEGE_GRANTS | Stops privileges from being granted directly to users |
| REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION | Whether creating a stage requires a storage integration |
| NETWORK_POLICY | The only account parameter that either ACCOUNTADMIN or SECURITYADMIN can set |
| CORTEX_ENABLED_CROSS_REGION | Whether Cortex calls can be processed in another region |
Checkpoint 1 of 5· Check yourself
A governance standard requires a minimum Time Travel retention for every object in the account. Which command sets MIN_DATA_RETENTION_TIME_IN_DAYS?
MIN_DATA_RETENTION_TIME_IN_DAYS is an account parameter. Account parameters exist only at the account level and are set with ALTER ACCOUNT.
“To set an account parameter, you run the ALTER ACCOUNT command.”Source: docs.snowflake.com
2.How the hierarchy resolves a value
Session parameters pass through three levels. An account administrator's ALTER ACCOUNT value becomes the default for every user and session. An ALTER USER value replaces that default for one user and applies to every session that user starts. ALTER USER can be run by an administrator with the right privileges, usually SECURITYADMIN, or by users for themselves. ALTER SESSION overrides both for the current session only.
Object parameters have two levels. A value set with ALTER ACCOUNT becomes the default for objects created in the account. A user with the right privileges can override it on a single object with CREATE <object> or ALTER <object>. Some parameters are both types. STATEMENT_TIMEOUT_IN_SECONDS is an object parameter on warehouses and is also a session parameter.
NETWORK_POLICY follows the same override logic. If it is set on both the account and a user, the user-level policy overrides the account-level one for that user.
| Parameter type | Levels | Commands |
|---|---|---|
| Account | Account only | ALTER ACCOUNT |
| Session | Account, then user, then session | ALTER ACCOUNT, ALTER USER, ALTER SESSION |
| Object | Account, then object | ALTER ACCOUNT, CREATE <object> or ALTER <object> |
Checkpoint 2 of 5· Match them up
Match each parameter to where it can be set
Tap a term, then the definition that fits it.
Each type has a fixed set of levels. A parameter that is both an object and a session parameter can be set wherever either type allows.
“Object parameters can be set at the account and object level.”Source: docs.snowflake.com
3.Viewing, setting and resetting parameters
What SHOW PARAMETERS returns depends on its scope. With no IN clause, the scope is SESSION, so you see only session parameters. IN ACCOUNT lists the account, session and object parameters that can be set at the account level. IN USER, IN WAREHOUSE, IN DATABASE, IN SCHEMA, IN TASK and IN TABLE show the parameters for that user or object.
The output has a level column that shows where the current value comes from. If it is empty, nobody has set the parameter explicitly and the default applies. After an account-level change, the column reads ACCOUNT:
ALTER ACCOUNT SET DATE_OUTPUT_FORMAT = 'DD/MM/YYYY'; SHOW PARAMETERS LIKE 'DATE_OUTPUT%' IN ACCOUNT;The new value is still only a default, and any user or session can override it. To return the account to the system default, unset the parameter. Setting it again to the default value is not the same thing.
Checkpoint 3 of 5· Fill the gap
Which keyword returns DATE_OUTPUT_FORMAT to its default value for the account?
ALTER ACCOUNT ? DATE_OUTPUT_FORMAT;ALTER ACCOUNT UNSET <param> removes the account-level setting, and the parameter goes back to its default.
Source: docs.snowflake.comSources2
4.Parameters in a central account and additional accounts
Account parameters belong to one account, so an organization with several accounts has several independent sets of them. That is useful when accounts need different security settings and a burden when they need the same ones. There are two ways to keep a central account's settings and its additional accounts consistent.
The first is to run ALTER ACCOUNT in each account and check the result with SHOW PARAMETERS IN ACCOUNT. Every edition can do this. The second is to replicate them. Account-level parameters are one of the account objects a replication or failover group can include, along with network policies, roles and users. Replicating any account object other than databases and shares requires Business Critical Edition or higher. Session parameters set at the user level, and object parameters set on a database or schema, depend on those users and databases being replicated as well.
Checkpoint 4 of 5· Check yourself
A central account on Enterprise Edition has carefully tuned account parameters. The architect wants three new accounts to receive them automatically through a replication group. What blocks this plan?
Replication groups exist on every edition, but on Standard and Enterprise they replicate only databases and shares. Account-level parameters are an account object, so they need Business Critical or higher. Without it, each account is set with ALTER ACCOUNT.
“Replication of all other objects is only available for Business Critical Edition (or higher).”Source: docs.snowflake.com
Checkpoint 5 of 5· Exam question
A retail company operates in the EU and the US. EU regulators require that EU customer data never leave EU cloud regions, and the compliance team wants demonstrably separate administrative boundaries for EU and US data rather than relying on row-level filtering within one account. Which account strategy best satisfies this requirement?
Correct answer: A — Provision a separate Snowflake account in an EU region for EU customer data and a separate account in a US region for US customer data, linked under a single organization for centralized oversight.
- A. This is correct because a Snowflake account is physically deployed in a specific cloud region, so a dedicated EU account is the mechanism that guarantees EU data is stored and processed within EU infrastructure, while organizations let both accounts still be centrally governed.
- B. Row access policies restrict which rows a role can see within a single account, but the underlying data still physically resides wherever that one account's region is deployed, which does not satisfy a hard EU data residency requirement if the account itself is in the US.
- C. Warehouses are compute resources and do not determine where the underlying table data is stored; data residency is governed by the region the account and its databases are deployed in, not by warehouse placement.
- D. Network policies restrict which IP addresses can connect to the account, but they do not change the physical region where the account's data is stored, so this does not address data residency at all.
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Running SHOW PARAMETERS with no IN clause lists account and object parameters as well.Why is that wrong?
The default scope is SESSION, so only session parameters appear. Use IN ACCOUNT, or an object scope, to see the others.
Covered in Viewing, setting and resetting parameters
2.An account-level NETWORK_POLICY always wins over one assigned to a user.Why is that wrong?
When NETWORK_POLICY is set on both the account and a user, the user-level policy applies to that user.
Covered in How the hierarchy resolves a value
Practise it for real
Watch the parameter hierarchy at work by setting, inspecting and resetting a session parameter at the account level
1.As ACCOUNTADMIN, run: SHOW PARAMETERS LIKE 'DATE_OUTPUT%' IN ACCOUNT
Why: Shows the starting value before you change anything
You should see: DATE_OUTPUT_FORMAT shows YYYY-MM-DD with an empty level column, meaning the default applies
2.Run: ALTER ACCOUNT SET DATE_OUTPUT_FORMAT = 'DD/MM/YYYY';
Why: Changes the account-wide default for every user and session
You should see: The statement succeeds
3.Run the SHOW PARAMETERS command from step 1 again
Why: The level column shows where the value now comes from
You should see: The value is DD/MM/YYYY and the level is ACCOUNT
4.Run: ALTER SESSION SET DATE_OUTPUT_FORMAT = 'YYYY-MM-DD'; then SHOW PARAMETERS LIKE 'DATE_OUTPUT%'
Why: Shows a session override taking precedence over the account default
You should see: With the default SESSION scope, the value is YYYY-MM-DD and the level is SESSION
5.Run: ALTER ACCOUNT UNSET DATE_OUTPUT_FORMAT;
Why: Removes the account-level setting so the default applies again
You should see: SHOW PARAMETERS LIKE 'DATE_OUTPUT%' IN ACCOUNT shows the default with an empty level column
Stuck? Get a nudge
If the level column surprises you, check which scope you used. With no IN clause, SHOW PARAMETERS reports the session view.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Account parameters can only be set at the account level.”
↩︎ Three parameter types“Session parameters can be set at the account, user, and session level.”
↩︎ How the hierarchy resolves a value“Object parameters can be set at the account and object level.”
↩︎ Checkpoint - 2.
“To override default values at the account level, you must be an account administrator”
↩︎ Three parameter types“If the level column is empty for a parameter, the parameter is not explicitly set and the current value is the default value.”
↩︎ Viewing, setting and resetting parameters - 3.
“The values that you set for a user become the default values in any session started by that user.”
↩︎ How the hierarchy resolves a value“The values that you set at this level become the default values for individual objects created in the account.”
↩︎ How the hierarchy resolves a value“By default, only session parameters are displayed in the output of SHOW PARAMETERS.”
↩︎ Exam trap 1“the user-level network policy overrides the account-level network policy”
↩︎ Exam trap 2“To set an account parameter, you run the ALTER ACCOUNT command.”
↩︎ Checkpoint“Users can run the ALTER SESSION command to override session parameters for the current session.”
↩︎ Prediction - 4.
“Database replication and share replication are available on all editions.”
↩︎ Parameters in a central account and additional accounts“Replication of all other objects is only available for Business Critical Edition (or higher).”
↩︎ Checkpoint