A financial services company is redesigning access in Snowflake after an audit found that developers can see production customer data through inherited privileges. The company wants to enforce least privilege while still allowing developers to build and test objects using production schemas as references. The requirements are: - Developers must be able to query only approved non-sensitive objects in the PROD database. - Access to sensitive tables must be controlled centrally and consistently across multiple roles. - Future grants should minimize ongoing administration as new objects are created. - Object owners should not have to grant privileges directly to individual users. Which approach BEST meets these requirements?

B. Create a database role in PROD for read-only access to approved objects, grant object privileges including future grants to that database role, and grant the database role to the appropriate account roles assigned to developers.

A. Grant USAGE on the PROD database and schemas to a developer role, then grant SELECT on all current and future tables in the schemas to that same developer role.

B. Create a database role in PROD for read-only access to approved objects, grant object privileges including future grants to that database role, and grant the database role to the appropriate account roles assigned to developers.

C. Grant OWNERSHIP on the approved schemas to a shared developer role so developers can manage grants on objects they need, and use role hierarchy to inherit access to non-sensitive data.

D. Create one custom account role per developer, grant privileges directly on approved tables to each role, and avoid role inheritance so access remains explicit.

SnowflakeProfessional level

SnowPro Advanced: Security Engineer exam dumps: 431 free SnowPro Advanced: Security Engineer practice questions

Free SnowPro Advanced: Security Engineer practice questions for the SnowPro® Advanced: Security Engineer exam, with the correct answer and a full explanation for every option. Read the first 10 below, browse all 431 by number, or take a timed practice exam.

Question bank last updated April 2026

Start timed practice exam Browse all 431 questions

Free SnowPro Advanced: Security Engineer practice questions

Questions 1 to 10 of 431

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

SnowPro Advanced: Security Engineer Question 1

Single answerDomain 1.0: Access Control and Identity Management (22%)

A Snowflake security engineer is implementing federated authentication for employees using the company's corporate IdP. The company wants all interactive users to authenticate with SSO and MFA managed by the IdP, while service accounts used by ETL tools must continue to authenticate with key-pair authentication. During testing, some users can still sign in with a Snowflake username and password directly at the Snowflake login page, which violates the security requirement. What is the BEST action to meet the requirement without disrupting the ETL service accounts?

A
Set the account-level authentication policy to require SAML authentication for all users, and assign a separate user-level authentication policy to service accounts that allows key-pair authentication
B
Disable the PASSWORD parameter on all users, including service accounts, because key-pair authentication does not require a password
C
Configure network policies so employee logins are blocked unless they originate from the corporate office IP ranges
D
Grant the SECURITYADMIN role to the IdP integration user so the IdP can prevent direct Snowflake password logins

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use Snowflake authentication policies to explicitly govern allowed authentication methods. For this requirement, the organization should enforce federated authentication for human users at the account level and create exceptions only for ETL/service accounts that must use key-pair authentication. This is the most precise and maintainable approach because it separates human and machine identities and enforces least privilege in authentication paths. Network policies are complementary but do not enforce SSO. Likewise, password changes alone are less effective than policy-based authentication controls. This approach is consistent with Snowflake best practices for identity management: use federated authentication for workforce users, use key-pair authentication for service users where appropriate, and apply centralized authentication policies to control permitted login methods.

A. Correct.
Correct. Snowflake authentication policies can be applied at the account and user levels to control allowed authentication methods. In this scenario, the account should enforce federated/SAML-based authentication for interactive users, while specific service accounts can be exempted with a user-level policy that permits key-pair authentication. This aligns with the requirement to block direct username/password access for employees without breaking non-interactive service accounts.
B. Incorrect.
Incorrect. Removing or disabling passwords broadly is not the best solution here. While key-pair authentication does not require a password, interactive users still need controlled access through federated authentication, and password-related settings alone do not comprehensively enforce the desired authentication method strategy. Also, applying this indiscriminately to all users is operationally risky and does not leverage Snowflake's intended authentication policy controls.
C. Incorrect.
Incorrect. Network policies restrict where connections can originate, not how users authenticate. Even if network restrictions are useful as a defense-in-depth control, they do not prevent direct Snowflake password authentication from approved networks. This does not satisfy the core requirement that employees must authenticate through the IdP with SSO/MFA.
D. Incorrect.
Incorrect. SAML/SCIM or other identity integrations do not work by granting administrative roles to an 'IdP integration user' to block login methods. Authentication behavior is controlled through Snowflake security configurations such as authentication policies and federated authentication setup, not by delegating SECURITYADMIN to an integration principal for login enforcement.

SnowPro Advanced: Security Engineer Question 2

Single answerDomain 1.0: Access Control and Identity Management (22%)

A financial services company uses Snowflake with federated authentication for all employees. The security team wants to ensure that analysts can access Snowflake only through the corporate identity provider (IdP) with MFA enforced by the IdP, while a small group of break-glass administrators must still be able to sign in with Snowflake-managed credentials if the IdP is unavailable. The company also wants to reduce the risk of password-based attacks against standard employee accounts. Which configuration best meets these requirements?

A
Set the account-level authentication policy to require SAML authentication for all users, and create a network policy that allows only corporate IP ranges.
B
Configure federated authentication for the account, set SAML_IDENTITY_PROVIDER on all employee users, disable passwords for those employee users, and retain Snowflake passwords only for the designated break-glass administrator accounts.
C
Enable key-pair authentication for all users, because key-pair authentication replaces the need for federated SSO and supports IdP-enforced MFA.
D
Create a custom role for analysts that denies the USE_ANY_ROLE privilege unless they authenticate through the IdP, and leave passwords enabled for all users as a fallback.

Show answer and explanation

Correct answer: B

Explanation

The best answer is Option 2 because it uses Snowflake federation design appropriately: employees should authenticate through the external IdP, where MFA is centrally enforced, and standard employee passwords in Snowflake should be disabled to prevent local password fallback and reduce credential attack risk. At the same time, a limited set of emergency or break-glass administrator accounts can retain Snowflake-managed credentials for continuity if the IdP is unavailable. This reflects the principle of least privilege and minimizes standing risk while preserving operational resilience. In Snowflake documentation, federated authentication and user-level configuration support directing users to SSO, while Snowflake-managed passwords can be disabled for users who should not authenticate locally. Network policies are useful complementary controls, but they do not replace the need to separate federated-only users from emergency local accounts. Likewise, roles govern authorization after authentication and do not enforce the required authentication method.

A. Incorrect.
Incorrect. Requiring SAML for all users would also block the break-glass administrators from using Snowflake-managed credentials during an IdP outage, which directly conflicts with the requirement. A network policy can restrict source IPs, but it does not by itself enforce the desired separation between federated-only standard users and password-capable emergency administrators.
B. Correct.
Correct. This approach aligns with Snowflake best practices for federated authentication and access hardening. By configuring federated authentication and associating employee users with the SAML identity provider, employees authenticate through the corporate IdP where MFA can be enforced. Disabling passwords for those users reduces password attack surface because they cannot fall back to Snowflake-native passwords. Keeping Snowflake-managed passwords only for a tightly controlled set of break-glass administrator accounts preserves emergency access if the IdP is unavailable.
C. Incorrect.
Incorrect. Key-pair authentication is primarily used for programmatic access and does not replace federated SSO for interactive workforce authentication. It also does not inherently provide IdP-enforced MFA for users. Using it for all users would not satisfy the requirement that analysts authenticate through the corporate IdP with MFA.
D. Incorrect.
Incorrect. Snowflake roles control authorization, not the authentication path in the manner described here. There is no role configuration that conditionally denies privileges based on whether the user authenticated through the IdP versus a Snowflake password in this way. Leaving passwords enabled for all users also fails the goal of minimizing password-based attacks against standard employee accounts.

SnowPro Advanced: Security Engineer Question 3

Single answer1.1 Design and implement access control strategies.

A security engineer is designing access control for a Snowflake environment used by three groups: Data Engineers who build and load tables in the RAW and CURATED schemas, BI Analysts who only need to query curated reporting tables, and Security Auditors who must review grants and policies but should not be able to read business data. The company wants a least-privilege model that is easy to operate at scale as new objects are created. Which approach best meets these requirements?

A
Grant privileges directly to each user, and use ACCOUNTADMIN to create all future objects so access can be adjusted centrally.
B
Create functional roles for Data Engineers, BI Analysts, and Security Auditors; grant object privileges to those roles, use future grants where appropriate for new objects, and assign the roles to users.
C
Grant imported privileges on the SNOWFLAKE database to all three groups so they can inherit the access they need without additional role design.
D
Use a single custom role for all three groups, and rely on separate warehouses to prevent Security Auditors from seeing table data.

Show answer and explanation

Correct answer: B

Explanation

The best answer is to design role-based access using functional roles and grant privileges to roles rather than directly to users. In Snowflake, RBAC is the core access-control model, and a scalable design typically uses roles aligned to business functions, often combined with role hierarchies where appropriate. Future grants are especially useful for schemas that will receive new tables or views regularly, because they automate privilege assignment for supported object types and reduce manual maintenance. For this scenario, Data Engineers would typically receive privileges needed to create and manage objects in RAW and CURATED, BI Analysts would receive SELECT on curated reporting objects only, and Security Auditors would receive only the metadata and administrative visibility required for audit functions, not business-data read access. This aligns with Snowflake guidance on least privilege, separation of duties, and role-based grant management.

A. Incorrect.
This is incorrect because granting privileges directly to users does not scale well and is contrary to Snowflake best practice, which is to grant privileges to roles and then assign roles to users. Using ACCOUNTADMIN to create all objects is also not recommended for routine operations because it concentrates excessive privilege in one role and increases operational risk. In addition, centralized object creation by ACCOUNTADMIN does not solve least-privilege requirements for the different groups.
B. Correct.
This is correct because Snowflake access control is role-based, and best practice is to create roles aligned to job functions, grant the minimum required privileges to those roles, and then grant the roles to users. Future grants help ensure that newly created tables, views, and other supported objects in the relevant schemas automatically receive the intended privileges, reducing administrative overhead. This approach also allows Security Auditors to receive metadata and governance-related access separately from data-reading privileges, which supports least privilege and separation of duties.
C. Incorrect.
This is incorrect because imported privileges on the SNOWFLAKE database are primarily used to access account usage and other shared metadata exposed by the SNOWFLAKE database; they do not replace proper role design for business data access in customer databases and schemas. Granting imported privileges to all groups would not provide the needed RAW/CURATED object access model and would not enforce the distinct responsibilities of engineers, analysts, and auditors.
D. Incorrect.
This is incorrect because warehouses control compute usage, not data authorization. A user with the necessary object privileges can read table data regardless of which warehouse is used to run the query. Using one role for all three groups violates least privilege and separation of duties because it combines incompatible access patterns into a single entitlement set.

SnowPro Advanced: Security Engineer Question 4

Single answer1.1 Design and implement access control strategies.

A financial services company is redesigning access in Snowflake after an audit found that developers can see production customer data through inherited privileges. The company wants to enforce least privilege while still allowing developers to build and test objects using production schemas as references. The requirements are:

Developers must be able to query only approved non-sensitive objects in the PROD database.
Access to sensitive tables must be controlled centrally and consistently across multiple roles.
Future grants should minimize ongoing administration as new objects are created.
Object owners should not have to grant privileges directly to individual users.

Which approach BEST meets these requirements?

A
Grant USAGE on the PROD database and schemas to a developer role, then grant SELECT on all current and future tables in the schemas to that same developer role.
B
Create a database role in PROD for read-only access to approved objects, grant object privileges including future grants to that database role, and grant the database role to the appropriate account roles assigned to developers.
C
Grant OWNERSHIP on the approved schemas to a shared developer role so developers can manage grants on objects they need, and use role hierarchy to inherit access to non-sensitive data.
D
Create one custom account role per developer, grant privileges directly on approved tables to each role, and avoid role inheritance so access remains explicit.

Show answer and explanation

Correct answer: B

Explanation

The best design is to use database roles to encapsulate object privileges inside the PROD database, then grant those database roles to account roles used by developer groups. This supports least privilege, centralizes access control for approved objects, and reduces administrative effort. Future grants can be applied carefully to the database role for the appropriate object types and scopes, helping ensure new approved objects are automatically accessible without repeated manual grants. Snowflake recommends a role-based access control model in which privileges are granted to roles rather than directly to users. Database roles are particularly useful for managing access within a database and then exposing that access through account roles. In contrast, broad grants on all future tables can overexpose data, OWNERSHIP is too powerful for this use case, and per-user role management is operationally inefficient.

A. Incorrect.
This does not best meet the requirements because granting SELECT on all current and future tables in a schema to a developer role is too broad if some tables are sensitive. It also does not provide a centralized abstraction for managing access within the database. While future grants reduce administration, this option risks exposing newly created sensitive tables unless schemas are split perfectly by sensitivity, which the scenario does not guarantee.
B. Correct.
This is correct. Database roles are designed to manage object privileges within a database and can be granted to account roles. Using a database role for approved read-only access allows centralized control over privileges to specific non-sensitive objects, including use of future grants where appropriate. Assigning the database role to account roles used by developers supports scalable role-based access control and avoids direct grants to users. This aligns with Snowflake best practices for least privilege and manageable privilege design.
C. Incorrect.
This is incorrect because granting OWNERSHIP to a shared developer role is excessive and conflicts with least-privilege principles. OWNERSHIP is the highest level of control over an object and enables privilege management and object changes. Allowing developers to own production schemas would increase risk rather than centralize and restrict access.
D. Incorrect.
This is incorrect because creating a separate account role per developer and granting privileges individually does not scale and increases administrative overhead. It also works against the requirement to control access centrally and consistently across multiple roles. Snowflake best practice is to grant privileges to roles, then assign roles to users, rather than managing object access per user-equivalent role.

SnowPro Advanced: Security Engineer Question 5

Select 2Configure and implement Role-Based Access Control (RBAC):

A financial services company is redesigning access in Snowflake after an audit found that analysts were granted broad privileges directly and several users inherited access they no longer needed. The security engineer must implement a scalable RBAC model that supports least privilege, separates object ownership from day-to-day usage, and simplifies future onboarding. Which TWO actions should the engineer take?

A
Create functional access roles such as ANALYST_RO and ANALYST_RW, grant object privileges to those roles, and then grant the roles to business-aligned roles assigned to users.
B
Grant privileges directly to users whenever possible so access reviews can identify exactly which person has each object privilege without checking role hierarchy.
C
Use a dedicated custom role to own schemas and tables where practical, and grant required usage and DML privileges to separate consumer roles instead of making end-user roles the owners.
D
Grant the ACCOUNTADMIN role to team leads so they can manage access requests quickly without waiting for security administrators.
E
Grant future privileges broadly at the database level to PUBLIC so new objects are automatically available to all authenticated users.

Show answer and explanation

Correct answers: A, C

Explanation

The best answers are 1 and 3 because they implement core Snowflake RBAC principles: grant privileges to roles rather than users, use role hierarchies to model job functions, and separate object ownership from consumption. In Snowflake, roles are the primary mechanism for access control, and scalable designs typically use lower-level access roles for object privileges and higher-level functional or business roles for user assignment. Dedicated ownership roles help prevent overprivileged user-facing roles and support stronger operational control. The rejected options conflict with documented best practices: direct grants to users reduce manageability, ACCOUNTADMIN should be tightly limited, and PUBLIC should not receive broad data access. These patterns align with Snowflake guidance on access control, role hierarchy design, least privilege, and minimizing use of powerful system roles.

A. Correct.
Correct. This follows Snowflake RBAC best practices by assigning privileges to roles, not directly to users, and using a role hierarchy. Functional access roles encapsulate permissions such as read-only or read-write access, while higher-level business roles can aggregate those permissions for departments or job functions. This improves least privilege, simplifies onboarding/offboarding, and makes entitlement reviews more manageable.
B. Incorrect.
Incorrect. Although direct grants may appear easier to audit at first glance, Snowflake best practice is to grant privileges to roles and assign roles to users. Direct grants to users do not scale well, increase administrative overhead, and make it harder to implement consistent least-privilege patterns across teams.
C. Correct.
Correct. Separating ownership from usage is an important RBAC design principle in Snowflake. Object ownership is powerful because the OWNERSHIP privilege controls the object and is required for many administrative actions. Assigning ownership to a dedicated custom role reduces risk and avoids tying lifecycle management to individual end-user roles. Consumer roles should receive only the privileges they need, such as USAGE, SELECT, INSERT, UPDATE, or DELETE.
D. Incorrect.
Incorrect. ACCOUNTADMIN is a highly privileged administrative role and should be tightly restricted. Granting it to team leads violates least privilege and separation of duties. Access management should instead be delegated through appropriately scoped custom roles and security administration processes.
E. Incorrect.
Incorrect. PUBLIC is granted to every user and role in the account, so granting broad future privileges to PUBLIC would expose new objects too widely. This directly conflicts with the audit goal of reducing unnecessary inherited access and violates least-privilege best practices.

SnowPro Advanced: Security Engineer Question 6

Single answerConfigure and implement Role-Based Access Control (RBAC):

A security engineer is redesigning access in a Snowflake account to align with least-privilege RBAC. The company has three requirements: (1) data analysts in the ANALYST role must be able to query curated tables in the PROD_DB.ANALYTICS schema, (2) ETL developers in the ETL_DEV role must be able to create and modify objects only in the PROD_DB.STAGING schema, and (3) security administrators must manage grants without using ACCOUNTADMIN for routine operations. Which approach best meets these requirements?

A
Grant OWNERSHIP on PROD_DB to ANALYST and ETL_DEV, and grant ACCOUNTADMIN to the security administrators so they can manage all future privileges centrally.
B
Create separate functional roles for ANALYST and ETL_DEV, grant USAGE on PROD_DB and the relevant schemas, grant SELECT on curated tables in PROD_DB.ANALYTICS to ANALYST, grant CREATE and object-level privileges in PROD_DB.STAGING to ETL_DEV, and assign SECURITYADMIN or a custom role with MANAGE GRANTS to the security administrators.
C
Grant imported privileges on PROD_DB to ANALYST and ETL_DEV, then allow security administrators to manage access by granting SYSADMIN to themselves when needed.
D
Use one shared role for both analysts and ETL developers, grant ALL PRIVILEGES on both schemas to simplify operations, and rely on future grants to prevent excessive access.

Show answer and explanation

Correct answer: B

Explanation

The best answer is the role design that separates privileges by function and limits each role to the minimum required scope. In Snowflake RBAC, best practice is to grant privileges to roles, then assign roles to users, rather than granting broad object control directly to users or using highly privileged system roles for routine work. For read-only access, analysts typically need USAGE on the database and schema plus SELECT on tables or views. For development or ETL work limited to a specific schema, a role should receive only the necessary schema-level and object-level privileges in that schema, such as CREATE TABLE, CREATE VIEW, CREATE STAGE, or DML privileges as needed. For security operations, SECURITYADMIN is the built-in role intended to manage roles and grants, and Snowflake also supports grant delegation patterns through MANAGE GRANTS where appropriate. This aligns with Snowflake documentation and guidance on access control, least privilege, separation of duties, and the role hierarchy model.

A. Incorrect.
Incorrect. Granting OWNERSHIP on the entire database to end-user roles violates least privilege and gives excessive control, including the ability to transfer ownership and manage grants on owned objects. Granting ACCOUNTADMIN for routine security administration is also a poor practice because ACCOUNTADMIN is the most powerful system role and should be tightly limited.
B. Correct.
Correct. This design follows Snowflake RBAC best practices by separating access by job function and scope. ANALYST receives only the minimum required privileges to query curated data: typically USAGE on the database and schema plus SELECT on the relevant tables or views. ETL_DEV is limited to the STAGING schema with privileges such as USAGE on the database and schema and CREATE privileges appropriate to that schema, plus object-level modification privileges where needed. For grant management, SECURITYADMIN is the standard system role for managing roles and grants, and a custom role with MANAGE GRANTS can also be appropriate depending on the governance model.
C. Incorrect.
Incorrect. Imported privileges are used for specific shared resources such as privileges on the SNOWFLAKE database or other shared databases, not as a general mechanism for internal database access design. Allowing administrators to assume SYSADMIN ad hoc for security tasks mixes operational and security responsibilities and does not align with the requirement to avoid overly broad admin roles for routine grant management.
D. Incorrect.
Incorrect. A single shared role for distinct job functions undermines separation of duties and makes least-privilege enforcement difficult. Granting ALL PRIVILEGES on both schemas gives analysts more access than required and exposes production staging objects unnecessarily. Future grants can simplify privilege management, but they do not justify over-granting access.

SnowPro Advanced: Security Engineer Question 7

Single answerAutomate RBAC management programmatically

A security engineering team wants to automate RBAC provisioning for new application schemas in Snowflake. Their CI/CD pipeline must create a functional role for each application, grant the minimum required privileges on the schema and its future objects, and assign that role to a higher-level business role. The team also wants the automation to be rerunnable without causing excessive failures when objects already exist. Which approach best meets these requirements?

A
Use a role with CREATE ROLE and MANAGE GRANTS privileges to run idempotent SQL such as CREATE ROLE IF NOT EXISTS, GRANT USAGE ON DATABASE, GRANT USAGE ON SCHEMA, and GRANT SELECT/INSERT/UPDATE/DELETE ON FUTURE TABLES IN SCHEMA as needed, then GRANT ROLE to the parent role.
B
Use a role with only OWNERSHIP on the target schema to create the application role and grant all required privileges, because schema ownership implicitly allows account-level role creation and role hierarchy changes.
C
Use a role with SECURITYADMIN privileges to transfer OWNERSHIP of the schema to the application role, because ownership automatically includes all future object privileges and eliminates the need for future grants.
D
Use a role with USERADMIN privileges to create users and assign the application role directly to each service user, because direct user-role assignment is the preferred way to automate RBAC and avoids managing role hierarchies.

Show answer and explanation

Correct answer: A

Explanation

The best answer is the one that uses idempotent SQL and a role with the necessary account-level and grant-management privileges to automate RBAC safely and repeatably. In Snowflake, creating roles is separate from owning a schema or its objects. For automation, a common pattern is to create application-specific access roles, grant least-privilege access to the database, schema, and future objects, and then attach those access roles to higher-level functional or business roles. This supports separation of duties, reuse, and simpler user provisioning. Using future grants is important when the requirement includes ongoing access to newly created tables or other objects within a schema. Relevant Snowflake guidance includes documentation on access control, role hierarchies, CREATE ROLE, GRANT privileges on schemas and objects, and future grants. The key practical points are: account roles must be created with account-level privilege, future grants must be explicitly defined, and hierarchical role assignment is preferred over direct user-to-privilege management.

A. Correct.
Correct. This approach aligns with Snowflake RBAC automation best practices. Role creation is an account-level action, so the automation needs the ability to create roles, and grant management requires sufficient privilege such as MANAGE GRANTS or ownership where applicable. Using CREATE ROLE IF NOT EXISTS makes the pipeline rerunnable. Granting USAGE on the database and schema, then object privileges on future objects in the schema, is the correct way to ensure ongoing access without re-granting on each newly created table. Granting the application role to a parent business role preserves a scalable role hierarchy instead of assigning privileges directly to users.
B. Incorrect.
Incorrect. OWNERSHIP on a schema does not permit creating account roles. CREATE ROLE is an account-level privilege, typically associated with USERADMIN or a custom role that has been granted the necessary privilege. Schema ownership can help with grants on schema objects, but it does not allow creating roles or managing the account-level role hierarchy by itself. This option confuses object ownership with account-level administrative capabilities.
C. Incorrect.
Incorrect. Transferring OWNERSHIP to the application role is usually not the least-privilege approach and does not automatically grant future object privileges in the way described. Future grants are configured explicitly with GRANT ... ON FUTURE objects. Ownership is powerful and often broader than necessary for an application access role. SECURITYADMIN can manage grants and roles, but using ownership transfer here is not the best design for controlled, repeatable RBAC automation.
D. Incorrect.
Incorrect. USERADMIN is primarily responsible for users and roles, but direct assignment of access roles to users is not the preferred scalable pattern. Snowflake best practice is to assign object privileges to access roles, then grant those roles to functional or business roles, and only then assign higher-level roles to users. This option also fails to address granting minimum privileges on the schema and future objects.

SnowPro Advanced: Security Engineer Question 8

Single answerAutomate RBAC management programmatically

A security engineering team wants to automate RBAC onboarding for new analytics projects in Snowflake. Their CI/CD pipeline must create a project-specific role hierarchy, grant least-privilege access to existing schemas, and ensure every run is safe to repeat without creating inconsistent privilege states. The team also wants to avoid embedding broad administrative privileges in the automation account. Which approach best meets these requirements?

A
Create a dedicated automation role that has MANAGE GRANTS globally, and use it to issue all GRANT statements directly in every deployment because this guarantees least privilege and idempotency.
B
Implement the RBAC changes in version-controlled SQL or Snowflake Scripting, execute them through a dedicated role that owns only the managed access schemas or relevant objects, and make the deployment logic re-runnable by checking existing grants/roles before issuing DDL where needed.
C
Run the pipeline as ACCOUNTADMIN so it can create roles and grant privileges across all projects, and rely on audit history later to detect any over-granting introduced by the scripts.
D
Use future grants exclusively for all access control automation, because future grants automatically cover existing objects and remove the need to create role hierarchies programmatically.

Show answer and explanation

Correct answer: B

Explanation

The best answer is to treat RBAC as code and execute it with a narrowly scoped role rather than a broadly privileged administrative role. In Snowflake, programmatic RBAC automation commonly uses SQL, Snowflake Scripting, or API/driver-based execution from CI/CD. To satisfy least privilege, the automation role should be granted only the rights needed to create and manage the intended roles and object grants. For grant delegation, Snowflake ownership rules and managed access schemas are especially important: in managed access schemas, object owners do not control grants; the schema owner or a role with MANAGE GRANTS does. This makes managed access schemas a strong pattern for centralized, controlled privilege automation. For repeatable deployments, teams should design scripts to be idempotent or safely re-runnable by validating current state and only applying missing changes where necessary. Snowflake documentation on access control, role hierarchies, OWNERSHIP, MANAGE GRANTS, and managed access schemas supports these practices.

A. Incorrect.
Incorrect. A role with MANAGE GRANTS is highly privileged and is not the best fit when the requirement is to avoid embedding broad administrative capabilities in the automation account. While MANAGE GRANTS can centralize grant administration, it does not by itself guarantee least privilege or idempotent deployments. Idempotency must be designed in the automation logic. This option also overstates the suitability of a global grant-management privilege for project-scoped onboarding.
B. Correct.
Correct. This approach aligns with Snowflake best practices for programmatic RBAC automation: define role creation and grants as code, keep them in version control, and execute them using a narrowly scoped automation role. Where possible, the automation role should own only the relevant objects or managed access schemas so it can grant privileges without needing broad account-wide powers. Making the process re-runnable requires explicit handling in code, such as checking whether roles already exist and validating or reconciling grants before applying changes. This supports least privilege, repeatable deployments, and reduced operational drift.
C. Incorrect.
Incorrect. ACCOUNTADMIN is powerful, but using it for routine automation violates least-privilege principles and increases blast radius if credentials are misused or scripts are incorrect. Audit history is valuable for monitoring and investigation, but it is not a substitute for preventive security design. The scenario explicitly requires avoiding broad administrative privileges in the automation account.
D. Incorrect.
Incorrect. Future grants are useful for automatically granting privileges on objects created later, but they do not replace the need to handle existing objects, create role hierarchies, or manage all RBAC relationships programmatically. In fact, future grants do not automatically backfill access to existing objects; those typically require separate grants. Relying only on future grants would leave gaps in access management for current schemas and objects.

SnowPro Advanced: Security Engineer Question 9

Single answerIntegrate RBAC management with IdPs using SCIM (user group membership)

A company uses Microsoft Entra ID as its corporate identity provider and wants to reduce manual administration of Snowflake access. The security team has enabled SCIM provisioning from Entra ID to Snowflake and wants membership in Entra ID groups to control which Snowflake roles users receive. They also want access to be removed automatically when a user is removed from an Entra ID group. Which approach should the security engineer implement?

A
Provision Entra ID groups to Snowflake as SCIM-managed groups, grant the appropriate Snowflake account roles to those groups, and let SCIM update group membership in Snowflake.
B
Provision Entra ID users with SCIM, but manage role grants directly on each Snowflake user because SCIM cannot synchronize group membership to Snowflake.
C
Use SAML assertions only to pass group names during login and rely on Snowflake to create and maintain role assignments automatically from those SAML groups.
D
Create Snowflake database roles for each Entra ID group and grant those database roles directly to users through SCIM so that account-level access is removed when group membership changes.

Show answer and explanation

Correct answer: A

Explanation

The key requirement is to integrate RBAC management with the IdP so that user access follows corporate group membership and is removed automatically when membership changes. In Snowflake, SCIM is the provisioning mechanism used with supported identity providers to create and manage users and groups, including group membership updates. The recommended operational model is to provision groups from the IdP into Snowflake and then grant Snowflake roles to those groups. This lets the IdP remain the source of truth for membership while Snowflake enforces authorization through role grants. SAML is primarily for authentication and federation, not object provisioning and lifecycle management. Best practice is to avoid direct user-by-user grants when group-based access can be managed through SCIM-provisioned groups. This aligns with Snowflake documentation on SCIM-based user and group provisioning and with RBAC best practices that favor assigning privileges to roles and roles to groups rather than directly to individual users.

A. Correct.
Correct. For centralized RBAC lifecycle management with an IdP, the practical pattern is to provision groups from the IdP into Snowflake using SCIM, then grant Snowflake roles to those groups. SCIM manages the group membership, so when a user is added to or removed from the IdP group, Snowflake group membership is updated accordingly. This reduces manual user-by-user grant maintenance and supports automatic removal of access when membership changes.
B. Incorrect.
Incorrect. This reflects a common misconception. SCIM integration with supported IdPs is specifically used to provision users and groups, including group membership changes. Managing grants directly on each user would reintroduce manual administration and would not align with the requirement to automate access changes based on IdP group membership.
C. Incorrect.
Incorrect. SAML handles authentication and can support some role selection or federation patterns at login, but it is not the mechanism Snowflake uses to provision and continuously maintain user and group objects. Relying only on SAML group claims does not provide SCIM-based lifecycle management of group membership in Snowflake.
D. Incorrect.
Incorrect. Database roles are scoped to database objects and are not the direct construct to map corporate groups for broad account-level RBAC administration. The requirement is to control Snowflake role assignment from IdP group membership; the common and supported pattern is to grant account roles to SCIM-provisioned groups, not to grant database roles directly to users through SCIM.

SnowPro Advanced: Security Engineer Question 10

Single answerIntegrate RBAC management with IdPs using SCIM (user group membership)

A company uses Microsoft Entra ID as its identity provider and wants to reduce manual administration of Snowflake access. The security team has enabled SCIM provisioning so that Entra ID groups are synchronized into Snowflake and used to drive role assignments. They want users added to the Entra ID group DATA_ANALYSTS to automatically receive the appropriate Snowflake privileges through a Snowflake role, and they want group membership changes in the IdP to be reflected in Snowflake without manually updating users. Which approach should the security engineer implement?

A
Create a Snowflake role for analyst access, grant the required privileges to that role, map the SCIM-provisioned Snowflake group representing DATA_ANALYSTS to the role, and allow SCIM to manage user membership in that group.
B
Create individual Snowflake users manually, grant privileges directly to each user, and use SCIM only for password synchronization from Entra ID.
C
Use SCIM to provision Snowflake roles directly from Entra ID, so users are added to roles without any Snowflake group objects or grants.
D
Configure Entra ID for SAML SSO only, and rely on JUST-IN-TIME user creation so that Entra ID group membership automatically grants Snowflake object privileges at login.

Show answer and explanation

Correct answer: A

Explanation

The correct design is to use the IdP as the source of truth for user and group membership through SCIM, while continuing to use Snowflake RBAC for authorization. In practice, the security engineer should create Snowflake roles that contain the required privileges, then connect IdP-managed group membership to those roles through Snowflake’s access model. This ensures that when users are added to or removed from the DATA_ANALYSTS group in Entra ID, their effective access can be updated centrally without direct user-by-user privilege administration. Snowflake documentation distinguishes authentication federation such as SAML from provisioning via SCIM, and Snowflake best practices consistently recommend assigning privileges to roles rather than directly to users. SCIM helps automate identity and group lifecycle management; Snowflake roles remain the core mechanism for object privilege assignment.

A. Correct.
Correct. In Snowflake, SCIM integration is used to provision and manage users and groups from the IdP. A common best-practice pattern is to let the IdP manage group membership, have those groups represented in Snowflake, and then associate access through Snowflake RBAC by granting roles appropriately. This supports centralized lifecycle management in the IdP while keeping authorization aligned with Snowflake roles and privilege grants.
B. Incorrect.
Incorrect. Directly granting privileges to users is contrary to Snowflake RBAC best practices, which recommend granting privileges to roles and assigning roles to users. Also, SCIM is not used for password synchronization into Snowflake. With federated authentication, password management remains with the IdP, and SCIM is used for identity and group provisioning rather than password sync.
C. Incorrect.
Incorrect. SCIM in Snowflake is used for provisioning users and groups, not for provisioning Snowflake roles directly from the IdP as RBAC objects with privileges. Roles remain Snowflake authorization objects that must be created and managed in Snowflake. The misconception is assuming IdP groups and Snowflake roles are the same object type; in practice, groups from SCIM are mapped into Snowflake access design rather than replacing Snowflake roles.
D. Incorrect.
Incorrect. SAML SSO handles authentication, not authorization provisioning of object privileges. Just-in-time user creation can reduce manual user creation in some identity patterns, but it does not make IdP group membership automatically grant Snowflake object privileges unless RBAC grants are configured in Snowflake. The misconception is confusing login federation with full lifecycle and entitlement management.

Timed practice exam

Take a SnowPro Advanced: Security Engineer practice test under exam conditions

65 questions in 115 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

What the SnowPro Advanced: Security Engineer exam covers

The objectives this question bank covers most, by number of questions.

Domain 1.0: Access Control and Identity Management (22%)
2 questions
1.1 Design and implement access control strategies.
2 questions
Configure and implement Role-Based Access Control (RBAC):
2 questions
Automate RBAC management programmatically
2 questions
Integrate RBAC management with IdPs using SCIM (user group membership)
2 questions
Manage hierarchical RBAC models
2 questions
Define and manage custom roles and least-privilege role hierarchies:
2 questions
Understand best practices for role design (functional vs. access roles):
2 questions

All 431 SnowPro Advanced: Security Engineer practice questions

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them.

SnowPro Advanced: Security Engineer exam dumps FAQ

Are these SnowPro Advanced: Security Engineer dumps real exam questions?

No. These are original practice questions written to the SnowPro® Advanced: Security Engineer exam objectives, not questions copied from a live exam. Memorising leaked questions violates Snowflake's candidate agreement and stops working the moment the question pool rotates. Use this bank to check your understanding of each domain and to find the topics you still need to study.

How many SnowPro Advanced: Security Engineer practice questions are there?

431 questions, each with the correct answer, an explanation of the answer, and a note on why every other option is wrong. The first 10 are on this page and every question has its own page linked below.

Are the SnowPro Advanced: Security Engineer exam dumps free?

Yes. Every question, answer and explanation on this page and the linked question pages is free to read without an account. A free HydraNode account adds timed practice exams, scoring and progress tracking across attempts.

How do I take a timed SnowPro Advanced: Security Engineer practice test?

Sign in and start the SnowPro® Advanced: Security Engineer exam on HydraNode. A session gives you 65 questions drawn from this bank in 115 minutes, then a score report with a per-question review.

What topics does the SnowPro Advanced: Security Engineer exam cover?

The questions in this bank are grouped under: Domain 1.0: Access Control and Identity Management (22%); 1.1 Design and implement access control strategies.; Configure and implement Role-Based Access Control (RBAC):; Automate RBAC management programmatically; Integrate RBAC management with IdPs using SCIM (user group membership); Manage hierarchical RBAC models; Define and manage custom roles and least-privilege role hierarchies:; Understand best practices for role design (functional vs. access roles):.