What you will be able to do
- Compare SSO with federated authentication, password with MFA, Snowflake OAuth, External OAuth, and key-pair authentication
- Build a network policy from network rules and predict which policy wins when account, user and security integration policies overlap
- Recognize the preferred format for account identifiers and the rules for account names
- Describe how logging and tracing send telemetry to an event table
1.Signing in people: SSO, federated authentication, and MFA
Snowflake has two sign-in options for people using Snowsight. Single sign-on (SSO) is the preferred one. The user signs in with a third-party identity provider (IdP) instead of with Snowflake directly. The IdP confirms who the user is and sends proof to Snowflake. Snowflake accepts that proof because the two have an established trust relationship.
SSO is built on federated authentication, which separates authenticating a user from granting that user access. In this setup, Snowflake is the *service provider (SP)*. The IdP creates and maintains user credentials and authenticates users. Okta and Microsoft Entra ID support Snowflake natively. For any other IdP, you must define a custom application for Snowflake in that IdP.
The second option is password with MFA. It is simpler to set up, but Snowflake requires MFA for every password user. After the password, the user confirms their identity with a second factor, such as a passkey stored on their computer.
| Aspect | OIDC | SAML 2.0 |
|---|---|---|
| Token format | JWT (JSON Web Token) | XML assertion |
| Integration type | TYPE = OIDC | TYPE = SAML2 |
| Managed providers | Google, Microsoft | None |
| Credential type | Client ID + Client Secret | X.509 certificate |
| Driver SSO with authenticator=externalbrowser | Not supported | Supported |
Signing out works differently from signing in. With standard logout, the user has to sign out of the IdP and of Snowflake separately. Some IdPs support global logout, which signs the user out of all their Snowflake sessions at once, but only when the logout starts at the IdP. Signing out inside Snowflake ends only that one session. The user's other Snowflake sessions and their IdP session stay open.
Checkpoint 1 of 6· Check yourself
A user who signed in through Okta clicks log out in one Snowflake session. Okta supports global logout. What happens?
Global logout cannot be started from inside Snowflake. A logout there ends only the current session.
“Global logout is not supported from within Snowflake, regardless of whether the IdP supports it.”Source: docs.snowflake.com
2.Authenticating applications: OAuth and key-pair
Applications, meaning anything that accesses Snowflake programmatically, use their own set of methods. Two of these are OAuth 2.0 variants:
- Snowflake OAuth: Snowflake is both the authorization server and the resource server. The client uses the authorization code grant type, and the user authenticates through Snowflake with SSO or a password. It suits *interactive* applications, such as a BI tool acting for an analyst. - External OAuth: a third-party IdP is the authorization server. The application gets an access token from the IdP and presents it to Snowflake. It suits interactive applications, which use the authorization code grant, and also service-to-service applications, which can use the client credentials grant.
Key-pair authentication uses a private key that the application keeps secret and a public key attached to the Snowflake user object. The application proves it holds the private key, and Snowflake checks that against the stored public key. No password is ever sent or stored. Because the key is a long-lived credential, it should be protected with measures such as network policies and a storage and rotation strategy.
Checkpoint 2 of 6· Match them up
Match each authentication method to how it works
Tap a term, then the definition that fits it.
The real difference between the two OAuth variants is who acts as the authorization server. Key-pair authentication involves no token or IdP at all.
“External OAuth also provides the security of OAuth 2.0, but a third-party IdP, not Snowflake, acts as the authorization server.”Source: docs.snowflake.com
Sources1
3.Network policies and network rules
By default, Snowflake accepts connections to the service and the internal stage from any computer or device. A network policy limits *inbound* access based on where a request comes from, and a security administrator or higher role can create one. A policy does not list IP addresses itself. Instead, it adds network rules to an allowed list and a blocked list. Network rules are schema-level objects, and each one groups identifiers of a single type, such as IPv4 addresses or private endpoint IDs. A rule does not say whether its identifiers are allowed or blocked. The policy decides that. To restrict access to the Snowflake service, set the rule's MODE to INGRESS.
CREATE NETWORK RULE allow_access_rule
MODE = INGRESS
TYPE = IPV4
VALUE_LIST = ('192.168.1.0/24');
CREATE NETWORK RULE block_access_rule
MODE = INGRESS
TYPE = IPV4
VALUE_LIST = ('192.168.1.99');
CREATE NETWORK POLICY public_network_policy
ALLOWED_NETWORK_RULE_LIST = ('allow_access_rule')
BLOCKED_NETWORK_RULE_LIST=('block_access_rule');An allowed list blocks everything it does not include. In the example above, every address outside 192.168.1.0/24 is already blocked, so the blocked list only has to exclude 192.168.1.99. When the same value appears in both lists, the blocked list is applied first. For private connectivity, a rule of type AWSVPCEID or AZURELINKID in the allowed list takes precedence over IPV4 and IPV6 rules.
Checkpoint 3 of 6· Fill the gap
This rule should allow traffic from one AWS private endpoint. Which TYPE completes it?
CREATE NETWORK RULE allow_vpceid_access
MODE = INGRESS
TYPE = ?
VALUE_LIST = ('vpce-0fa383eb170331202');AWS VPC endpoint IDs use the AWSVPCEID type. INGRESS is a MODE value, and AZURELINKID is for Azure Private Link.
Source: docs.snowflake.comYou can activate a policy for an account, a user, or a security integration, and nothing is restricted until a policy is activated. When policies exist at more than one level, the most specific one wins. Snowflake recommends scoping policies narrowly, to a group of users or to one security integration, rather than to the whole account.
Checkpoint 4 of 6· Put it in order
Put the network policy workflow in order
- 1.Create a network policy that adds those rules to its allowed and blocked lists
- 2.Activate the policy for an account, user, or security integration
- 3.Create network rules grouped by purpose and identifier type
The rules have to exist before a policy can reference them, and the policy has no effect until it is activated.
“Activate the network policy for an account, user, or security integration.”Source: docs.snowflake.com
Sources3
4.Account identifiers
An account identifier uniquely identifies a Snowflake account within your organization and across every cloud platform and region Snowflake supports. You need it in account URLs, in clients and drivers, in third-party tools, in security features, and in global features such as Secure Data Sharing and replication and failover.
The preferred format is the organization name followed by the account name, for example myorg-account123. The Snowflake-assigned account locator also works, but it is a legacy format and not recommended. An account name is unique within its organization and can be changed, but on its own it does not identify the account across organizations. Account names can contain underscores but not hyphens. If an account name has underscores, Snowflake also accepts the same identifier with each underscore replaced by a hyphen. Use that hyphen form for features that do not accept underscores, such as Okta SSO and SCIM.
Checkpoint 5 of 6· Check yourself
An administrator is setting up a new client connection. Which account identifier format does Snowflake recommend?
The organization-prefixed account name is the preferred format. The locator is legacy, and an account name alone is unique only within one organization.
“The preferred account identifier consists of the name of the account prefixed by its organization; for example, myorg-account123.”Source: docs.snowflake.com
Sources4
5.Logging and tracing
Snowflake's observability features include logging and tracing. They record what your function and procedure handler code does while it runs, including code written with Snowpark APIs. The data follows a structure based on the OpenTelemetry standard and is stored in an event table. An account has a default event table that is active out of the box, or you can create your own and make it the active one. Telemetry levels control which data is collected and how much of it.
| Characteristic | Log entries | Trace events |
|---|---|---|
| Structure | None. A log entry is just a string | Key-value attributes that are easy to query with SQL |
| Grouping | None. Each entry is an independent event | Organized into spans, which can have their own attributes |
| Quantity limits | Unlimited | At most 128 trace events per span |
| Query complexity | Relatively high, because each entry must be parsed | Relatively low, because the data is already structured |
Checkpoint 6 of 6· Put it in order
Put the steps for capturing log and trace data in order
- 1.Set telemetry levels so data is collected
- 2.Ensure there is an active event table
- 3.Emit log or trace data from handler code
- 4.Query the event table to analyze the data
Data needs somewhere to go and levels that let it be captured before handler code emits anything. Querying the event table comes last.
“Ensure that you have an active event table.”Source: docs.snowflake.com
Sources5
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A user-level network policy always beats every other network policy.Why is that wrong?
A user policy overrides the account policy, but a policy on a security integration is more specific still and overrides both.
Covered in Network policies and network rules
2.If an IP address is in both the allowed list and the blocked list, the allowed list wins.Why is that wrong?
Snowflake applies the blocked list first, so the address is blocked.
Covered in Network policies and network rules
3.The account locator is the recommended account identifier.Why is that wrong?
The locator still works, but it is a legacy format. The preferred identifier is the organization name followed by the account name.
Covered in Account identifiers
Practise it for real
Limit inbound access to an approved IPv4 range, minus one address, using network rules and a network policy
1.Run the CREATE NETWORK RULE statement for allow_access_rule with MODE = INGRESS, TYPE = IPV4 and VALUE_LIST = ('192.168.1.0/24').
Why: Network rules group identifiers of one type. MODE = INGRESS targets access to the Snowflake service.
You should see: The rule is created as a schema-level object. It allows or blocks nothing by itself.
2.Run the CREATE NETWORK RULE statement for block_access_rule with VALUE_LIST = ('192.168.1.99').
Why: A separate rule is needed for the single address you want to exclude from the allowed range.
You should see: A second rule exists in the schema.
3.Create public_network_policy with allow_access_rule in ALLOWED_NETWORK_RULE_LIST and block_access_rule in BLOCKED_NETWORK_RULE_LIST.
Why: The policy, not the rules, decides what is allowed and what is blocked.
You should see: The policy exists but restricts nothing until it is activated.
4.Activate the policy for one user or a security integration, not for the whole account.
Why: Snowflake recommends scoping network policies narrowly where possible.
You should see: Requests from that user or integration are allowed only from 192.168.1.0/24, except 192.168.1.99.
Stuck? Get a nudge
If you test with an address that is in both lists, remember that the blocked list is applied first.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“users authenticate with a third-party identity provider (IdP) rather than authenticating with Snowflake directly.”
↩︎ Signing in people: SSO, federated authentication, and MFA“Snowflake requires MFA for all password users.”
↩︎ Signing in people: SSO, federated authentication, and MFA“For example, a user might use a passkey stored on their computer as the second factor of authentication.”
↩︎ Signing in people: SSO, federated authentication, and MFA“With Snowflake OAuth, Snowflake is both the authorization server that authenticates a Snowflake user and the resource server”
↩︎ Authenticating applications: OAuth and key-pair“A service-to-service application could use the client credentials grant type to access its own Snowflake data.”
↩︎ Authenticating applications: OAuth and key-pair“The private key is a secret kept by the application, while the public key is associated with a Snowflake user object.”
↩︎ Authenticating applications: OAuth and key-pair“This authentication method eliminates the need to transmit or store passwords, reducing the risk of credential theft.”
↩︎ Authenticating applications: OAuth and key-pair“External OAuth also provides the security of OAuth 2.0, but a third-party IdP, not Snowflake, acts as the authorization server.”
↩︎ Checkpoint - 2.
“In a federated environment, user authentication is separated from user access through the use of one or more external entities”
↩︎ Signing in people: SSO, federated authentication, and MFA“Service provider (SP): In a Snowflake federated environment, Snowflake serves as the SP.”
↩︎ Signing in people: SSO, federated authentication, and MFA“To use an IdP other than Okta or Entra ID, you must define a custom application for Snowflake in the IdP.”
↩︎ Signing in people: SSO, federated authentication, and MFA“Global logout is not supported from within Snowflake, regardless of whether the IdP supports it.”
↩︎ Checkpoint - 3.
“You can use network policies to control inbound access to the Snowflake service and internal stage.”
↩︎ Network policies and network rules“A network rule, however, does not specify whether it is allowing or blocking the origin of a request.”
↩︎ Network policies and network rules“To restrict access to the Snowflake service, set the MODE property of the network rule to INGRESS.”
↩︎ Network policies and network rules“Whenever possible, narrowly scope a network policy to a group of users or a security integration rather than an entire account.”
↩︎ Network policies and network rules“Network policies applied to a user override network policies applied to the account”
↩︎ Exam trap 1“Snowflake applies the values in the BLOCKED_IP_LIST parameter first.”
↩︎ Exam trap 2“Network policies applied to a security integration are the most specific network policies. They override both accounts and users.”
↩︎ Prediction“Activate the network policy for an account, user, or security integration.”
↩︎ Checkpoint - 4.
“While an account name uniquely identifies an account within your organization, it is not a unique identifier of an account across Snowflake organizations.”
↩︎ Account identifiers“If an account name includes underscores, Snowflake automatically accepts the same identifier with each underscore replaced by a hyphen.”
↩︎ Account identifiers“You can also use the Snowflake-assigned locator as the account identifier; however, the use of this legacy format is not recommended.”
↩︎ Exam trap 3“The preferred account identifier consists of the name of the account prefixed by its organization; for example, myorg-account123.”
↩︎ Checkpoint - 5.
“Snowflake captures observability data in a structure based on the OpenTelemetry standard.”
↩︎ Logging and tracing“Snowflake collects telemetry data from your code in the event table.”
↩︎ Logging and tracing“The number of trace events per span is capped at 128.”
↩︎ Logging and tracing“Ensure that you have an active event table.”
↩︎ Checkpoint