What you will be able to do
- Choose between SSO, password with MFA, OAuth, key-pair, PATs and workload identity federation for a given user or application
- Use authentication policies and security integrations to limit how users sign in
- Apply Snowflake's access control model: securable objects, privileges, roles and ownership
- Provision users and roles from an identity provider with a SCIM security integration
1.People signing in: SSO, federated authentication and MFA
Network controls decide where a request may come from. Authentication proves who is making it. For people signing in to Snowsight (user TYPE = PERSON), Snowflake prefers single sign-on. With SSO, the user authenticates with a third-party identity provider (IdP), which sends proof back to Snowflake. That proof is a SAML assertion or an OIDC ID token, depending on how federated authentication is configured. Snowflake accepts the proof because it has an established trust relationship with the IdP. SSO lets the organization manage authentication centrally, and its main cost is configuring the IdP.
The alternative is a Snowflake-managed password. Snowflake now requires multi-factor authentication for every password user: after the password, the user confirms their identity with a second factor, such as a passkey. Passwords are simpler to set up, but the organization then has to repeat authentication setup for each of its applications.
Checkpoint 1 of 8· Check yourself
An organization already provides SSO to all its applications through one IdP. How does Snowflake documentation position SSO for Snowsight?
The comparison table marks SSO as the preferred option. It is ideal for organizations that already run an IdP.
“Lets an organization centrally manage authentication.”Source: docs.snowflake.com
Checkpoint 2 of 8· Exam question
A financial services firm wants a key management design where Snowflake cannot decrypt customer data unless the customer's own cloud KMS key is also available, giving the customer the ability to revoke Snowflake's access to their data by revoking their key. Which Snowflake capability satisfies this requirement?
Correct answer: A — Tri-Secret Secure, combining a customer-managed key from AWS KMS, Azure Key Vault, or GCP KMS with a Snowflake-maintained key into one composite master key.
- A. This is correct because Tri-Secret Secure specifically creates a composite master key from a customer-held key and a Snowflake-managed key, so revoking the customer key removes Snowflake's ability to decrypt the data.
- B. This is incorrect because automatic key rotation manages the lifecycle of Snowflake's internal keys on a 30-day cadence but gives the customer no separate key to revoke.
- C. This is incorrect because periodic rekeying re-encrypts data with fresh Snowflake-generated material after a year but does not introduce any customer-controlled revocation point.
- D. This is incorrect because the hierarchical key model describes how keys wrap one another for isolation between accounts and tables, not a mechanism for customer-held revocation.
Sources1
2.Applications: OAuth, key-pair, PATs and workload identity federation
Applications fall into two groups. Interactive applications, such as a BI tool, act on behalf of a person. Service-to-service applications, such as a CI/CD pipeline, act as themselves. Which authentication method fits depends on which kind you have.
| Method | How it works | Suitable for |
|---|---|---|
| Workload identity federation | Uses the cloud provider's native identity, or OIDC federation, so there are no secrets to rotate | Service-to-service |
| Snowflake OAuth | Snowflake is both authorization server and resource server; uses the authorization code grant | Interactive |
| External OAuth | A third-party IdP issues the token and Snowflake accepts it as the resource server | Interactive and service-to-service |
| Key-pair | The app proves it holds the private key; the public key is stored on the Snowflake user | Interactive and service-to-service |
| Programmatic access token (PAT) | Time-limited credential that can be scoped to a role | Interactive and service-to-service |
The main OAuth question is who acts as the authorization server. With Snowflake OAuth, Snowflake issues the token, and the user signs in through Snowflake with SSO or a password. With External OAuth, the organization's own IdP issues the token. A service can use the client credentials grant to reach its own data. Key-pair authentication means no password is ever sent or stored. A PAT is meant to replace a single-factor password where MFA or stronger methods will not work.
Checkpoint 3 of 8· Match them up
Match each method to what defines it
Tap a term, then the definition that fits it.
What separates the two OAuth variants is which party acts as the authorization server. Key-pair authentication and WIF both avoid passwords, but in different ways.
“a third-party IdP, not Snowflake, acts as the authorization server.”Source: docs.snowflake.com
Checkpoint 4 of 8· Exam question
A healthcare analytics company stores patient records in Snowflake and must demonstrate that data at rest is protected without any manual key management effort from the platform team. Which statement accurately describes Snowflake's default encryption-at-rest behavior?
Correct answer: A — Snowflake encrypts all customer data at rest using strong AES encryption by default, with no manual key setup needed from the administrator.
- A. This is correct because Snowflake applies strong AES encryption to all customer data at rest by default across every edition, with the platform handling key management transparently.
- B. This is incorrect because encryption at rest is not opt-in or configured per database; it is always on and cannot be disabled by an administrator.
- C. This is incorrect because encryption at rest applies uniformly to all customer data regardless of tagging, not selectively based on sensitivity classification.
- D. This is incorrect because baseline encryption at rest is included in every Snowflake edition; only advanced features like Tri-Secret Secure require Business Critical Edition or higher.
Checkpoint 5 of 8· Exam question
An architect designing a Business Critical account wants to understand the consequences of enabling Tri-Secret Secure with a customer-managed key (CMK) hosted in the customer's own AWS KMS. Which outcomes should the architect plan for? (Select 2)(Select 2)
Correct answers: A, B — The organization becomes responsible for the CMK's availability, and operations can fail once the key stays unreachable past the documented timeout.; The organization must keep the CMK confidential and free of unauthorized changes, since losing or exposing it can make protected data permanently unreadable.
- A. This is correct because Snowflake documents an availability requirement for the CMK, and requests can fail if the key cannot be reached within the defined timeout window.
- B. This is correct because Tri-Secret Secure places confidentiality and integrity obligations on the customer, and violating them can result in unrecoverable data loss since Snowflake alone cannot decrypt the composite key.
- C. This is incorrect because cross-region replication of a customer-managed key is not an automatic Snowflake behavior; the customer is responsible for their own KMS key management and any regional considerations.
- D. This is incorrect because Tri-Secret Secure combines the customer key with Snowflake's own key material into a composite master key rather than eliminating Snowflake-side encryption.
- E. This is incorrect because the CMK is wrapped together with a Snowflake-managed key to form a composite key; it does not replace the account master key on its own.
Sources1
3.Authentication policies and security integrations
Once you know the methods, an authentication policy decides which ones a user may actually use. A policy can require MFA enrollment, specify which methods require MFA, and list the allowed methods: SAML, OIDC, passwords, OAuth, key pair and PATs. It can also limit users to particular SAML2 and OIDC security integrations, which is how you choose between several IdPs. You can narrow that further with the integrations' ALLOWED_USER_DOMAINS and ALLOWED_EMAIL_PATTERNS properties. Finally, it can restrict client types and minimum client versions, and set PAT expiration and network policy requirements.
Authentication policies resolve in the same direction as network policies: a policy on a user overrides the policy on the account. Treat the CLIENT_TYPES restriction with care. It is best effort, it does not restrict the Snowflake REST APIs, and it should never be your only security boundary. Security integrations also appear in other parts of this design. You can activate a network policy on one, SAML2 and OIDC integrations define the IdPs, and SCIM integrations handle provisioning, covered at the end of this page.
Checkpoint 6 of 8· Check yourself
The account's authentication policy allows only SAML. A service user also has its own authentication policy that allows only key-pair authentication. Which policy governs that user?
When both levels have a policy, the user-level authentication policy takes precedence.
“If you set an authentication policy on both an account and a user, then the user-level authentication policy overrides the account-level authentication policy.”Source: docs.snowflake.com
Sources2
4.Access control privileges: roles, ownership and inheritance
After a user is authenticated, authorization decides what they can do. Snowflake combines three models. In discretionary access control (DAC), every object has an owner who can grant access. In role-based access control (RBAC), privileges go to roles and roles go to users. In user-based access control (UBAC), privileges go directly to users, but those only count when secondary roles are set to ALL. Access to a securable object is denied unless a grant allows it. Granting one role to another builds a hierarchy, and privileges are inherited upward.
Each object is owned by exactly one role, by default the role that created it. In a managed access schema, object owners can no longer grant privileges. Only the schema owner, or a role with MANAGE GRANTS, can. Database roles limit privileges to one database and cannot be activated directly; you grant them to account roles. ACCOUNTADMIN should be granted only to a small, controlled set of users. Snowflake also advises against adding privileges to system-defined roles. Put the privileges on a custom role and grant that role to the system role, so account-management and object privileges stay separate.
Checkpoint 7 of 8· Check yourself
Role R_ADMIN owns role R_ANALYST but is not above it in the role hierarchy. Can a user whose active role is R_ADMIN query tables that R_ANALYST can read?
Privileges are inherited only through the role hierarchy, never through owning a role.
“A role owner (the role that has the OWNERSHIP privilege on the role) does not inherit the privileges of the owned role.”Source: docs.snowflake.com
Sources3
5.User, role and grants provisioning with SCIM
Creating users and roles by hand does not scale when the IdP already defines them. A SCIM security integration lets the IdP provision users and roles in Snowflake. Those objects are owned by a dedicated provisioner role, which holds CREATE USER and CREATE ROLE on the account.
use role accountadmin;
create role if not exists generic_scim_provisioner;
grant create user on account to role generic_scim_provisioner;
grant create role on account to role generic_scim_provisioner;
grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
type=scim
scim_client='generic'
run_as_role='GENERIC_SCIM_PROVISIONER';The example uses ACCOUNTADMIN, but you can use a less-privileged role, which helps with least-privilege compliance. Provisioning also depends on the network layer: the network policy must allow the IdP's IP ranges before any users or groups can be provisioned. Password synchronization through SYNC_PASSWORD is supported only for Okta SCIM integrations.
Checkpoint 8 of 8· Check yourself
SCIM provisioning from a custom IdP fails, even though the integration and provisioner role exist. What should you check first, according to the setup guidance?
The SCIM guide says to confirm that the network policy allows the organization's IP ranges before provisioning. SYNC_PASSWORD is supported only for Okta.
“Before provisioning users or groups, ensure that the network policy in Snowflake allows access from the IP ranges that correspond to your organization.”Source: docs.snowflake.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Restricting CLIENT_TYPES in an authentication policy reliably locks users out of every client except the allowed ones.Why is that wrong?
CLIENT_TYPES is best effort, does not restrict the REST APIs, and must not be the only security boundary.
Covered in Authentication policies and security integrations
2.In a managed access schema, the role that owns a table can still grant SELECT on it.Why is that wrong?
Managed access takes grant decisions away from object owners and gives them to the schema owner or a role with MANAGE GRANTS.
Covered in Access control privileges: roles, ownership and inheritance
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“this proof is either a Security Assertion Markup Language (SAML) assertion or an OpenID Connect (OIDC) ID token”
↩︎ People signing in: SSO, federated authentication and MFA“Snowflake requires MFA for all password users.”
↩︎ People signing in: SSO, federated authentication and MFA“With Snowflake OAuth, Snowflake is both the authorization server that authenticates a Snowflake user and the resource server”
↩︎ Applications: OAuth, key-pair, PATs and workload identity federation“The private key is a secret kept by the application, while the public key is associated with a Snowflake user object.”
↩︎ Applications: OAuth, key-pair, PATs and workload identity federation“A PAT can be used as a drop-in replacement for a single-factor password”
↩︎ Applications: OAuth, key-pair, PATs and workload identity federation“Lets an organization centrally manage authentication.”
↩︎ Checkpoint“a third-party IdP, not Snowflake, acts as the authorization server.”
↩︎ Checkpoint - 2.
“The SAML2 and OIDC security integrations that are available to users during the login experience.”
↩︎ Authentication policies and security integrations“It should not be used as the sole control to establish a security boundary.”
↩︎ Exam trap 1“If you set an authentication policy on both an account and a user, then the user-level authentication policy overrides the account-level authentication policy.”
↩︎ Checkpoint - 3.
“Securable object: An entity to which access can be granted. Unless allowed by a grant, access is denied.”
↩︎ Access control privileges: roles, ownership and inheritance“it is not recommended to mix account-management privileges and entity-specific privileges in the same role.”
↩︎ Access control privileges: roles, ownership and inheritance“in a managed access schema, object owners lose the ability to make grant decisions.”
↩︎ Exam trap 2“A role owner (the role that has the OWNERSHIP privilege on the role) does not inherit the privileges of the owned role.”
↩︎ Checkpoint - 4.https://docs.snowflake.com/en/user-guide/scim-customOfficial docs
“creates a SCIM security integration to allow users and roles created in the identity provider to be owned by the GENERIC_SCIM_PROVISIONER SCIM role”
↩︎ User, role and grants provisioning with SCIM“Using a less-privileged role can help to address compliance concerns relating to least-privileged access”
↩︎ User, role and grants provisioning with SCIM“Before provisioning users or groups, ensure that the network policy in Snowflake allows access from the IP ranges that correspond to your organization.”
↩︎ Checkpoint