SnowflakeProfessional levelARA-C01

ARA-C01 exam dumps: 434 free SnowPro Advanced: Architect practice questions

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

Question bank last updated April 2026

Start timed practice exam Browse all 434 questions

Free ARA-C01 practice questions

Questions 1 to 10 of 434

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

ARA-C01 Question 1

Single answerDomain 1.0: Account and Security (25%)

A global financial services company uses a Snowflake organization with separate PROD, DEV, and TEST accounts. The security team must allow a central identity provider (IdP) group called FINANCE_ANALYSTS to access only the PROD account through SSO, while ensuring that user and role administration remains centralized and auditable. The company also wants to minimize manual user lifecycle management inside individual accounts. Which approach best meets these requirements?

A
Configure SAML2 security integration separately in each Snowflake account, create local users in PROD for each analyst, and grant account roles directly to those users.
B
Use SCIM provisioning from the IdP into the PROD account only, map the FINANCE_ANALYSTS IdP group to Snowflake account roles, and manage users independently in each account.
C
Set up federated authentication with the central IdP, provision users and groups through SCIM where supported, and use account-level access controls in PROD so only the FINANCE_ANALYSTS group is assigned roles in that account.
D
Create users manually in the organization account, grant them organization-level roles for PROD data access, and rely on those organization roles to enforce schema-level permissions inside the PROD account.

Show answer and explanation

Correct answer: C

Explanation

The best answer is to centralize authentication and lifecycle management in the enterprise IdP and use Snowflake account-level RBAC to restrict access to the PROD account. In practice, Snowflake supports federated authentication using SAML 2.0 and user provisioning through SCIM integrations, which helps reduce manual creation, deactivation, and group maintenance of users. For authorization, access to data objects remains governed by account roles inside the target Snowflake account; organization-level constructs do not replace account-level privileges for database objects. This design supports least privilege, centralized auditability, and cleaner identity governance in multi-account architectures. Relevant Snowflake guidance includes documentation on federated authentication, SCIM provisioning, and the distinction between organization-level administration and account-level access control.

A. Incorrect.
Incorrect. While separate SAML integrations per account can work technically, this approach does not minimize manual lifecycle management because it depends on local user creation in PROD. Granting account roles directly to manually managed users also increases administrative overhead and audit complexity. In a multi-account environment, Snowflake best practices favor centralized identity management with federation and automated provisioning rather than per-account manual user administration.
B. Incorrect.
Incorrect. SCIM provisioning can reduce manual lifecycle work, but this option still frames identity management as independent in each account and does not address centralized, auditable administration across the environment as effectively as a broader federated model. It is also incomplete because simply provisioning into PROD only does not fully align with the stated requirement for centralized administration patterns across the organization. The key architectural goal is to centralize authentication and user lifecycle with the enterprise IdP, while assigning access only in the target account.
C. Correct.
Correct. This approach aligns with Snowflake security best practices for enterprise identity management: use federated authentication with a central IdP for SSO, automate user and group lifecycle through SCIM where supported, and keep authorization scoped to the PROD account by assigning only the FINANCE_ANALYSTS group to the relevant account roles there. This minimizes manual user management inside Snowflake accounts, keeps administration centralized and auditable through the IdP, and ensures users can access only the intended account based on role assignments and account configuration.
D. Incorrect.
Incorrect. Organization-level roles do not replace account-level RBAC for database, schema, and object permissions within a Snowflake account. They are used for organization-scoped administration tasks, not for enforcing schema-level data access in PROD. Manually creating users also conflicts with the requirement to minimize manual lifecycle management.

ARA-C01 Question 2

Single answerDomain 1.0: Account and Security (25%)

A global company is designing access controls for its Snowflake environment. The security team wants to ensure that application service accounts used by ETL tools can load data into specific schemas but cannot create users, modify network policies, or grant privileges to other roles. At the same time, the company wants to simplify long-term administration by separating user and role management from object privilege management. Which approach best meets these requirements?

A
Grant the ACCOUNTADMIN role to the ETL service accounts, then restrict object access through future grants on the target schemas.
B
Use a single custom role for both user administration and schema object privileges, and grant that role to the ETL service accounts.
C
Create custom functional roles for data loading privileges on the required schemas, and keep user/role administration in separate roles managed by a higher-level administrative role.
D
Grant SECURITYADMIN to the ETL service accounts so they can inherit only the privileges required for loading data through role hierarchy.

Show answer and explanation

Correct answer: C

Explanation

The best answer is to separate functional data-access roles from administrative roles. In Snowflake, a common best practice is to design access using custom roles aligned to business or technical functions, then grant only the minimum privileges required. ETL service accounts typically need limited object privileges such as USAGE on warehouses, databases, and schemas, plus privileges needed to load data into specific objects. They should not receive powerful system roles like ACCOUNTADMIN or SECURITYADMIN.

This scenario also highlights separation of duties. Snowflake administrative responsibilities are commonly split so that security administration (for example, user and role management) is kept distinct from object-level access design and operational data access. This reduces the blast radius of credential compromise and simplifies auditing and governance. These practices are consistent with Snowflake guidance around role-based access control, least privilege, and minimizing use of high-level system roles except for a small number of trusted administrators.

A. Incorrect.
Incorrect. ACCOUNTADMIN is the most powerful system role in a Snowflake account and is not appropriate for ETL service accounts that only need limited data-loading access. Even if schema-level privileges are configured, ACCOUNTADMIN retains broad administrative capabilities, including actions far beyond the stated requirements. This violates least-privilege design and increases operational and security risk.
B. Incorrect.
Incorrect. Combining user/role administration with object privilege management in a single custom role works against separation of duties and makes long-term administration harder, not simpler. Snowflake best practice is to separate access control responsibilities, typically distinguishing who manages users and roles from who manages object privileges. Giving ETL service accounts such a combined role would also exceed their required scope.
C. Correct.
Correct. This approach aligns with least privilege and role-based access control best practices in Snowflake. ETL service accounts should receive narrowly scoped custom roles that allow only the required privileges for loading data, such as USAGE on database/schema and appropriate table or stage privileges. Separately, user and role administration should be handled through dedicated administrative roles rather than bundled with data access roles. This separation improves governance, reduces risk, and supports scalable administration.
D. Incorrect.
Incorrect. SECURITYADMIN is intended for managing grants and security-related configuration, not for service accounts performing ETL loads. Granting SECURITYADMIN would allow the service accounts to manage roles and privileges, which directly conflicts with the requirement that they must not grant privileges to other roles. Role hierarchy does not make this safe if the parent role itself contains excessive authority.

ARA-C01 Question 3

Single answer1.1 Design a Snowflake account and database strategy, based on business requirements.

A global retailer is designing its Snowflake deployment for three business units: North America, Europe, and Asia-Pacific. Each business unit has its own data engineering team, separate billing ownership, and region-specific regulatory requirements. Corporate leadership also wants a centralized analytics layer for global reporting, while minimizing operational overhead and avoiding unnecessary data movement. The company expects frequent schema changes in source systems and wants each business unit to manage its own development lifecycle independently. Which design approach best meets these requirements?

A
Create a single Snowflake account with one shared database for all business units, and use schemas plus role-based access control to isolate each region's objects and workloads.
B
Create separate Snowflake accounts for each business unit in the required cloud regions, allow each unit to manage its own databases and lifecycle, and share curated data to a centralized analytics account using Secure Data Sharing or replication features as needed.
C
Create one Snowflake account per business unit, but keep all databases for every region in a single primary account and expose them to the other accounts through database roles only.
D
Create separate databases for each business unit inside one Snowflake account, then use virtual warehouses to satisfy regional regulatory requirements and chargeback reporting.

Show answer and explanation

Correct answer: B

Explanation

For Snowflake account and database strategy, architects should align design boundaries with business ownership, regulatory constraints, operational autonomy, and data-sharing patterns. When business units require separate billing ownership, independent administration, and deployment in different regions, separate Snowflake accounts are typically the most appropriate boundary. Databases and schemas are useful for organizing objects within an account, but they do not provide the same level of administrative and regional separation.

A centralized analytics layer can still be achieved without heavy ETL duplication. Snowflake Secure Data Sharing is the preferred mechanism for near real-time sharing without copying data when accounts are compatible for sharing. For broader cross-region or business continuity use cases, Snowflake replication/failover features can support synchronized copies where needed. This pattern allows decentralized data ownership with centralized consumption.

This reflects Snowflake best practices documented around multi-account strategies, data sharing, organization-level governance, and region/account deployment decisions: use accounts when you need stronger isolation, separate administration, cost ownership, or regional deployment; use databases/schemas when the need is primarily logical organization within a shared administrative boundary.

A. Incorrect.
This approach provides logical isolation through schemas and roles, but it does not best satisfy the stated requirements for separate billing ownership, region-specific regulatory constraints, and independent lifecycle management at the account boundary. A single account can support object isolation, but account-level separation is typically preferred when business units need stronger administrative autonomy, clearer cost ownership, and deployment into different cloud regions. It also creates more coordination overhead when multiple teams independently evolve environments within one account.
B. Correct.
This is the best answer. Separate accounts allow each business unit to operate independently, including its own RBAC administration, warehouses, resource monitors, and release processes. Placing accounts in the required regions supports data residency and regulatory needs. A centralized analytics account can consume curated datasets using Secure Data Sharing when accounts are in the same region/cloud, or use replication and related cross-region/cross-cloud capabilities when consolidation across regions is required. This approach aligns with Snowflake best practices for organizational isolation, regional compliance, and centralized consumption with minimal unnecessary data movement.
C. Incorrect.
This option mixes account separation with centralized database ownership in a way that undermines the requirement for each business unit to manage its own lifecycle independently. Database roles help with access delegation inside and across shared databases, but they do not solve the need for regional deployment, separate billing ownership, or decentralized administration of data platforms. Keeping all regional databases in one primary account also creates a governance and operational bottleneck.
D. Incorrect.
Separate databases and warehouses within one account can help with workload and some cost attribution, but warehouses do not address regional regulatory requirements because data residency is determined by where the Snowflake account is deployed, not by warehouse configuration. This option also falls short on separate billing ownership and strong business-unit autonomy. It is a common misconception that warehouse isolation can substitute for account or regional isolation.

ARA-C01 Question 4

Single answer1.1 Design a Snowflake account and database strategy, based on business requirements.

A global company is redesigning its Snowflake environment after several acquisitions. It has three business units: Retail, Healthcare, and Financial Services. Each business unit has its own data engineering team, separate chargeback requirements, and distinct security policies. Healthcare data is subject to strict regulatory controls, and the company wants to minimize the risk of accidental cross-unit access. At the same time, the enterprise analytics team needs to consume curated data from all three business units for corporate reporting. The company wants an architecture that supports strong isolation, delegated administration, and clear cost attribution while still enabling governed data sharing across the enterprise. Which design approach best meets these requirements?

A
Create a single Snowflake account with one database per business unit, and use database roles plus schemas to separate administration, security, and chargeback across units.
B
Create separate Snowflake accounts for each business unit, and use Secure Data Sharing or shares to publish approved datasets to a central enterprise analytics account.
C
Create one Snowflake account for Retail and Financial Services, and a separate account for Healthcare only, because only regulated data requires account-level isolation.
D
Create separate virtual warehouses for each business unit in a single account, and use warehouse-level resource monitors as the primary mechanism for security isolation and cost attribution.

Show answer and explanation

Correct answer: B

Explanation

For SnowPro Advanced Architect, candidates should recognize when business requirements justify a multi-account strategy instead of only using databases and schemas inside a single account. Snowflake best practices generally favor separate accounts when organizations need stronger isolation, decentralized administration, distinct security postures, clearer billing/chargeback boundaries, or regional/compliance separation. In this scenario, each business unit has its own team, policies, and cost accountability, and the company wants to reduce accidental cross-unit exposure. A multi-account design addresses those needs more effectively than a single-account model. To still enable enterprise-wide analytics, Snowflake Secure Data Sharing is an appropriate mechanism to publish curated datasets from producer accounts to a consumer analytics account. This approach supports governed sharing without relying on broad cross-unit privileges in one shared account. Relevant Snowflake documentation and architecture guidance include account strategy considerations, organization/account design, and Secure Data Sharing for cross-account data access.

A. Incorrect.
This approach provides logical separation at the database level, but it does not best satisfy the stated need for strong isolation, delegated administration by independent business units, and minimized risk of accidental cross-unit access. In a single account, some administration and governance boundaries remain shared at the account level. Although database roles, schemas, masking policies, and row access policies can help with internal separation, they are not the strongest design choice when business units require distinct security policies, separate administration, and clear chargeback with reduced blast radius.
B. Correct.
This is the best answer. Separate Snowflake accounts per business unit provide stronger isolation boundaries, support delegated administration, and simplify cost attribution at the account level. This model is well aligned to organizations with separate business entities, compliance differences, and autonomous platform teams. Secure Data Sharing enables the enterprise analytics account to consume governed datasets without copying data unnecessarily, preserving producer control while supporting enterprise reporting. This design is commonly recommended when isolation, administrative autonomy, and controlled sharing are key requirements.
C. Incorrect.
This option is partially attractive because Healthcare has strict regulatory requirements, but it does not fully meet the broader business requirement that all three units have separate chargeback, distinct security policies, and independent data engineering teams. Retail and Financial Services would still share account-level administrative boundaries and a larger accidental access surface. The scenario explicitly calls for strong isolation and delegated administration across all business units, not only the regulated one.
D. Incorrect.
Warehouses are compute constructs, not security or governance boundaries for data isolation. Separate warehouses can help with workload isolation and cost tracking, but they do not prevent cross-unit access to data in the same account if privileges are granted incorrectly. Resource monitors help control or observe credit consumption, but they are not a substitute for account and data-domain design. This option addresses compute management more than account and database strategy.

ARA-C01 Question 5

Single answerCreate and configure Snowflake parameters based on a central account and any additional accounts.

A global enterprise is implementing a Snowflake multi-account strategy. One central account is used to define organization-wide standards, and three additional accounts are used for regional workloads. The security team requires that all users authenticate with SSO, and the data platform team wants to minimize manual configuration drift when new accounts are added. Which approach should the architect recommend to meet these requirements with the least ongoing administrative effort?

A
Configure the SSO-related account parameters and security integration separately in each regional account, because account parameters cannot be standardized from a central account.
B
Define the authentication-related settings at the organization level from the central account so that they can be inherited by the additional accounts, and override them only when a regional exception is required.
C
Create all users in the central account and share them to the regional accounts so that account-level authentication parameters only need to be maintained once.
D
Set the required authentication behavior as user-level parameters in the central account, because user parameters automatically propagate across all accounts in the organization.

Show answer and explanation

Correct answer: B

Explanation

The best recommendation is to use the central organization context to define supported authentication-related standards for member accounts, rather than manually repeating configuration in every account. In Snowflake, architects should prefer centralized governance mechanisms when the requirement is to reduce configuration drift and simplify onboarding of additional accounts. This is especially relevant in organizations operating multiple Snowflake accounts for regional, business-unit, or environment isolation.

A key design principle is understanding parameter scope and inheritance. Snowflake supports parameters at multiple levels, such as organization, account, user, session, and object levels depending on the parameter type. For a multi-account architecture, settings that can be controlled centrally should be managed from the organization account when possible, while exceptions should be limited and intentional. By contrast, user-level settings are not a substitute for organization-wide account governance, and users themselves are not global objects shared across accounts.

This aligns with Snowflake best practices around centralized administration, minimizing manual per-account configuration, and using the highest appropriate scope for governance. Candidates should recognize the difference between account-scoped objects and organization-level controls, and should avoid designs that depend on repetitive configuration in each account unless no centralized option exists.

A. Incorrect.
Incorrect. While administrators can configure settings independently in each account, this increases operational overhead and creates configuration drift risk. Snowflake supports organization-level parameter management for certain settings from the organization account, which is specifically intended to help standardize behavior across accounts. Choosing per-account configuration ignores the requirement to minimize manual administration.
B. Correct.
Correct. In a multi-account Snowflake environment, the organization account can be used as the central place to manage certain organization-scoped settings and parameters that apply to accounts in the organization. Using central governance and inheritance is the best fit when the goal is consistent authentication behavior across multiple accounts with reduced drift. Regional accounts can still diverge only where explicitly necessary, which aligns with least-effort governance.
C. Incorrect.
Incorrect. Snowflake users are account-scoped, not shared objects that can be created once in one account and then reused across other accounts. This option reflects a common misconception that identity objects behave like data shares or replicated objects. Authentication and user administration must still be handled within each account context, even when central governance features are used for supported parameters.
D. Incorrect.
Incorrect. User-level parameters do not automatically propagate across multiple accounts in an organization. Users and their parameters exist within the scope of an individual account. This option confuses parameter hierarchy within an account with organization-level governance across accounts.

ARA-C01 Question 6

Single answerCreate and configure Snowflake parameters based on a central account and any additional accounts.

A global enterprise is deploying a hub-and-spoke Snowflake architecture with one central account used for security and governance administration and several additional business-unit accounts for workloads. The lead architect must standardize account behavior so that all new sessions in every account use UTC for timestamps, enforce a 15-minute statement timeout for ad hoc workloads, and ensure object identifiers are not case-sensitive when users omit quotes. The company also wants each business unit to retain the ability to override some defaults later for specific roles or sessions if needed. Which approach should the architect take to meet these requirements with the least operational overhead?

A
In each Snowflake account, configure the required values as ACCOUNT parameters, then allow lower-level overrides through USER, SESSION, or object-level parameter settings where supported.
B
Configure the required values once in the central account; because account parameters automatically propagate to all linked Snowflake accounts in the organization, no further action is needed.
C
Create a database in the central account containing parameter templates, and grant imported privileges to the additional accounts so they inherit those parameter values automatically.
D
Set the required values only at the session level through client connection properties in each tool, because session parameters cannot be overridden by users after login.

Show answer and explanation

Correct answer: A

Explanation

The best practice is to set baseline behavior using ACCOUNT parameters in each Snowflake account and then use Snowflake's parameter hierarchy to permit more specific overrides where appropriate. For this scenario, the architect should configure parameters such as TIMEZONE = UTC, STATEMENT_TIMEOUT_IN_SECONDS = 900, and QUOTED_IDENTIFIERS_IGNORE_CASE as account defaults separately in the central account and in each additional business-unit account. Snowflake parameters are scoped and inherited by level; they are not automatically replicated from one account to another simply because those accounts belong to the same organization. In real-world multi-account designs, architects typically use infrastructure-as-code, SQL deployment scripts, or orchestration pipelines to keep parameter settings consistent across accounts while still allowing controlled lower-level exceptions. This aligns with Snowflake documentation on parameter hierarchy and account parameter management.

A. Correct.
Correct. Parameters such as TIMEZONE, STATEMENT_TIMEOUT_IN_SECONDS, and QUOTED_IDENTIFIERS_IGNORE_CASE can be configured at the account level within each individual Snowflake account. Snowflake parameter inheritance allows more specific scopes, such as user or session, to override broader defaults where applicable. This matches the requirement to establish standardized defaults while preserving flexibility for business units to override certain settings later. Because parameters are not centrally pushed from one account to other accounts, the architect must apply them per account, typically using automation to reduce operational effort.
B. Incorrect.
Incorrect. A common misconception is that a central or governance account can directly propagate account parameters across all other accounts in the organization. Snowflake Organizations provide centralized visibility and some cross-account administration capabilities, but account parameters remain scoped to each Snowflake account. The architect must configure those parameters separately in every account.
C. Incorrect.
Incorrect. Snowflake does not support inheriting account parameter values through a shared database, imported privileges, or template objects stored in another account. Databases and shares control access to data and certain metadata, not account-level behavioral defaults like session/account parameters. This option confuses data-sharing mechanisms with account configuration.
D. Incorrect.
Incorrect. Session-level settings can be useful for specific tools or workloads, but relying only on client-side session properties increases operational overhead and does not provide a consistent default across all users and tools. In addition, users or applications may still alter session parameters depending on privileges and connection behavior. The requirement calls for standardized defaults with optional overrides, which is better addressed using account-level parameters in each account.

ARA-C01 Question 7

Single answerParameters (all levels)

A Snowflake architect is standardizing how query execution time limits are enforced across a multi-tenant environment. The company wants these behaviors: all users should inherit a 10-minute statement timeout by default, the FINANCE role should use a stricter 5-minute timeout for its sessions, and one critical ETL user should be allowed up to 30 minutes regardless of the role they are using. The architect wants to implement this using the minimum number of changes while respecting Snowflake parameter precedence. Which configuration will meet the requirement?

A
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 on the FINANCE role, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 on the ETL user.
B
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 on all FINANCE warehouses, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 on the ETL user's default warehouse.
C
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 on the FINANCE database, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 on the ETL schema.
D
Set STATEMENT_TIMEOUT_IN_SECONDS = 600 at the account level, set STATEMENT_TIMEOUT_IN_SECONDS = 300 in the FINANCE users' session initialization SQL, and set STATEMENT_TIMEOUT_IN_SECONDS = 1800 at the account level during ETL windows.

Show answer and explanation

Correct answer: A

Explanation

Snowflake supports parameters at different levels, and the effective value is determined by parameter hierarchy and object applicability. For session-related behavior such as STATEMENT_TIMEOUT_IN_SECONDS, architects should prefer centralized configuration at the highest practical level, then override only where business requirements justify it. In this scenario, the account-level parameter provides the organization-wide default, the role-level parameter tightens behavior for FINANCE sessions, and the user-level parameter gives the ETL user a more specific exception. This aligns with Snowflake best practices for using account, role, user, and session parameter scopes rather than relying on less-governable client-side session SQL or unrelated object scopes such as databases and schemas. Refer to Snowflake documentation on parameter hierarchy and the STATEMENT_TIMEOUT_IN_SECONDS parameter for the supported levels and precedence behavior.

A. Correct.
Correct. STATEMENT_TIMEOUT_IN_SECONDS can be set at multiple levels, including account, user, and session, and Snowflake applies parameter precedence so more specific settings override broader defaults. Setting 600 at the account level establishes the default for everyone. Setting 300 on the FINANCE role provides a stricter limit for sessions using that role. Setting 1800 on the ETL user gives that user a more specific override than the role-level setting, allowing the ETL user to run longer statements regardless of which role is active. This satisfies the requirement with minimal administrative changes.
B. Incorrect.
Incorrect. Although warehouse-level parameters exist for some settings, using warehouses here does not reliably implement a role-based timeout policy. The requirement is tied to users and roles, not to where workloads happen to run. If FINANCE users run on multiple warehouses, or if non-FINANCE users share those warehouses, the behavior would not match the intended policy. In addition, setting a longer timeout only on the ETL user's default warehouse would not guarantee the override if that user executes statements on another warehouse.
C. Incorrect.
Incorrect. Database and schema parameters are used for parameters that apply to objects within those scopes, but statement timeout is not managed to enforce role-specific session behavior via database or schema settings. The requirement is about session/query execution limits by principal context, so account, role, user, or session scopes are the relevant mechanisms. Choosing database and schema scopes reflects a misunderstanding of parameter applicability.
D. Incorrect.
Incorrect. Using session initialization SQL for FINANCE users is operationally fragile and not the minimum-change approach, because it depends on consistent client behavior and user configuration rather than centralized governance. Temporarily changing the account-level timeout during ETL windows is also risky because it affects all sessions that inherit the account default at that time, not just the ETL user. This approach does not provide a clean, deterministic override model.

ARA-C01 Question 8

Single answerParameters (all levels)

A global Snowflake deployment uses a shared ETL service user to load data into multiple databases and schemas. The architecture team wants all newly created sessions for this ETL user to use the UTC timezone and to enforce a 45-minute statement timeout, without changing behavior for analysts who use the same warehouses. During testing, an engineer runs these commands:

ALTER ACCOUNT SET TIMEZONE = 'America/Los_Angeles';
ALTER USER ETL_SVC SET TIMEZONE = 'UTC';
ALTER WAREHOUSE ETL_WH SET STATEMENT_TIMEOUT_IN_SECONDS = 2700;
ALTER USER ETL_SVC SET STATEMENT_TIMEOUT_IN_SECONDS = 1800;

The ETL service user then connects using warehouse ETL_WH and does not issue any ALTER SESSION commands. Which settings will apply to the ETL user's new session by default?

A
TIMEZONE = 'America/Los_Angeles' and STATEMENT_TIMEOUT_IN_SECONDS = 2700 because account and warehouse settings override user settings
B
TIMEZONE = 'UTC' and STATEMENT_TIMEOUT_IN_SECONDS = 1800 because user-level parameters override account-level and warehouse-level defaults for the session
C
TIMEZONE = 'UTC' and STATEMENT_TIMEOUT_IN_SECONDS = 2700 because user-level parameters apply only to localization settings, while execution controls come from the warehouse
D
TIMEZONE = 'America/Los_Angeles' and STATEMENT_TIMEOUT_IN_SECONDS = 1800 because account-level parameters control session initialization, but user-level timeout overrides warehouse timeout

Show answer and explanation

Correct answer: B

Explanation

Snowflake parameters can be set at multiple levels, including account, user, session, warehouse, database, schema, and object levels depending on the parameter. The effective value is determined by parameter type and scope, with more specific settings generally overriding broader defaults. In this scenario, the team wants only the ETL service user's sessions to change, so user-level settings are the correct approach. The account TIMEZONE acts as a default, but ALTER USER ETL_SVC SET TIMEZONE = 'UTC' overrides it for that user's new sessions. Similarly, a user-level STATEMENT_TIMEOUT_IN_SECONDS becomes the default for sessions started by that user unless explicitly changed at the session level. This is a practical best practice because it targets the ETL principal directly and avoids affecting analysts who may use the same warehouse. See Snowflake documentation on parameters, parameter hierarchy, and setting parameters at the account, user, session, and warehouse levels.

A. Incorrect.
Incorrect. For session parameters such as TIMEZONE and STATEMENT_TIMEOUT_IN_SECONDS, Snowflake uses parameter precedence where the more specific level overrides the more general one. User-level settings override account-level defaults for sessions created by that user. Warehouse parameters do not take precedence over a user-level session parameter in this scenario.
B. Correct.
Correct. TIMEZONE set at the user level overrides the account-level TIMEZONE for new sessions created by ETL_SVC. Likewise, STATEMENT_TIMEOUT_IN_SECONDS set at the user level overrides broader defaults for that user's session if no session-level override is issued. This meets the requirement of changing behavior for the ETL service user without affecting analysts using the same warehouse.
C. Incorrect.
Incorrect. This reflects a common misconception that warehouse parameters universally control execution-related behavior for any session using that warehouse. In Snowflake, parameter resolution is based on object and session hierarchy, and user-level session defaults can override broader settings. Execution-related parameters are not limited to warehouse control only.
D. Incorrect.
Incorrect. While user-level parameters can override account-level defaults, the account-level TIMEZONE does not remain in effect when a more specific user-level TIMEZONE is defined. The user-level TIMEZONE = 'UTC' is the effective default for new ETL_SVC sessions.

ARA-C01 Question 9

Single answerAccount parameters

A Snowflake architect is reviewing security settings after an internal audit. The auditors found that some users can still authenticate with only a password, even though the company policy now requires multi-factor authentication (MFA) for all human users. The company also has several service accounts used by ETL tools that must continue to connect non-interactively. The architect wants to enforce the requirement centrally with the least operational overhead while avoiding disruption to service accounts. Which action should the architect take?

A
Set the account parameter REQUIRE_MULTI_FACTOR_AUTHENTICATION = TRUE, and move all service accounts to key pair authentication or another non-human authentication method as needed.
B
Set the account parameter SSO_LOGIN_PAGE = TRUE, because redirecting users to SSO automatically enforces MFA for all users and service accounts.
C
Set the account parameter NETWORK_POLICY = strict_mfa_policy, because network policies can require MFA based on user type.
D
Set the account parameter CLIENT_SESSION_KEEP_ALIVE = FALSE, because reducing session duration forces users to reauthenticate with MFA more frequently.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use the account parameter REQUIRE_MULTI_FACTOR_AUTHENTICATION to centrally enforce MFA for user logins. This is the most direct account-parameter-based control for the stated requirement. In practice, architects must also account for non-human service accounts, which typically should not depend on interactive MFA challenges. A common best practice is to migrate those accounts to an appropriate non-interactive authentication mechanism, such as key pair authentication, and to review whether those accounts truly require direct user credentials at all.

The other options confuse related but distinct controls. SSO-related parameters influence login flow but do not inherently enforce MFA across all scenarios; MFA in SSO is often governed at the identity provider. Network policies govern where connections can originate, not how users authenticate. Session keep-alive settings affect usability and session lifecycle, not authentication strength.

This aligns with Snowflake best practices around centralized security controls, least operational overhead, and separating human interactive authentication requirements from service-to-service authentication design.

A. Correct.
Correct. The account-level parameter REQUIRE_MULTI_FACTOR_AUTHENTICATION is the central control used to require MFA for user authentications. In a real environment, this should be paired with an authentication approach for non-interactive service accounts that does not rely on human MFA prompts, such as key pair authentication where appropriate. This meets the audit requirement with centralized governance while minimizing manual per-user administration.
B. Incorrect.
Incorrect. SSO_LOGIN_PAGE controls whether users are directed to the SSO login experience, but it does not itself guarantee MFA enforcement. MFA enforcement in federated environments is typically handled by the identity provider, and this setting does not solve the requirement for all authentication paths. It also does not address how non-interactive service accounts should authenticate.
C. Incorrect.
Incorrect. NETWORK_POLICY is used to restrict access by IP address, CIDR block, or related network conditions. It is not an MFA control and cannot require MFA based on whether an account is human or service-based. This is a plausible distractor because both are account-level security controls, but they govern different concerns.
D. Incorrect.
Incorrect. CLIENT_SESSION_KEEP_ALIVE affects session persistence behavior for supported clients and can influence how long sessions remain active, but it does not enforce MFA. Shorter-lived sessions are not a substitute for an MFA requirement and would not satisfy the audit finding.

ARA-C01 Question 10

Single answerAccount parameters

A global enterprise is standardizing Snowflake session behavior across hundreds of users and service accounts. Security requires all new sessions in the account to use UTC unless a workload explicitly overrides it, and the architecture team also wants to minimize per-user administration. An architect proposes changing an account parameter rather than updating every user individually. Which action best meets these requirements?

A
Execute ALTER ACCOUNT SET TIMEZONE = 'UTC'; so UTC becomes the default for new sessions unless a lower-level setting overrides it
B
Execute ALTER SESSION SET TIMEZONE = 'UTC'; so all future sessions in the account inherit UTC automatically
C
Execute ALTER USER SET TIMEZONE = 'UTC'; once at the account level so every existing and future user inherits UTC
D
Execute ALTER WAREHOUSE SET TIMEZONE = 'UTC'; because session defaults are inherited from the virtual warehouse used
E
Execute ALTER DATABASE SET TIMEZONE = 'UTC'; because object-level parameters take precedence over users and sessions

Show answer and explanation

Correct answer: A

Explanation

The best solution is to set the TIMEZONE account parameter using ALTER ACCOUNT SET TIMEZONE = 'UTC'. Snowflake parameters are scoped and inherited based on the parameter type. For session-related parameters such as TIMEZONE, the effective value is typically determined from the most specific level available, with session-level settings overriding user-level settings, and user-level settings overriding account-level defaults. This makes the account parameter the right place to establish a broad standard while preserving flexibility for exceptional workloads that explicitly need a different timezone. This approach also reduces administrative effort compared to configuring each user individually. In Snowflake documentation, this behavior is described under account, user, and session parameters, including the use of ALTER ACCOUNT, ALTER USER, and ALTER SESSION to manage parameter defaults and overrides.

A. Correct.
Correct. TIMEZONE is a parameter that can be set at the account, user, and session levels. Setting it with ALTER ACCOUNT establishes the account-wide default for sessions, which is the most scalable approach when the goal is to standardize behavior across many users while still allowing explicit overrides at lower levels such as user or session.
B. Incorrect.
Incorrect. ALTER SESSION affects only the current session in which the command is executed. It does not change the default for other current or future sessions created by other users or services, so it does not satisfy the enterprise-wide requirement.
C. Incorrect.
Incorrect. ALTER USER is valid only for a specific user, not for all users collectively in a single command. While user-level settings can override the account default, using ALTER USER for every user would increase administrative overhead and does not help with future users unless additional automation is built.
D. Incorrect.
Incorrect. TIMEZONE is not inherited from a warehouse. Warehouses control compute resources and certain warehouse-specific behaviors, but session parameters such as TIMEZONE are governed by parameter hierarchy like account, user, and session levels, not warehouse defaults.
E. Incorrect.
Incorrect. TIMEZONE is not established as a database-level default for user sessions. Databases have their own applicable parameters, but session behavior like TIMEZONE is not managed through ALTER DATABASE in the way described here. This option reflects a common misconception that all parameters can be set on any object.

Timed practice exam

Take a ARA-C01 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 ARA-C01 exam covers

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

Snowflake CLI
4 questions
Functions
4 questions
Streams and tasks
4 questions
Snowpipe
4 questions
Python
4 questions
Impact of costs
4 questions
Domain 1.0: Account and Security (25%)
2 questions
1.1 Design a Snowflake account and database strategy, based on business requirements.
2 questions

All 434 ARA-C01 practice questions

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

ARA-C01 exam dumps FAQ

Are these ARA-C01 dumps real exam questions?

No. These are original practice questions written to the SnowPro® Advanced: Architect 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 ARA-C01 practice questions are there?

434 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 ARA-C01 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 ARA-C01 practice test?

Sign in and start the SnowPro® Advanced: Architect 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 ARA-C01 exam cover?

The questions in this bank are grouped under: Snowflake CLI; Functions; Streams and tasks; Snowpipe; Python; Impact of costs; Domain 1.0: Account and Security (25%); 1.1 Design a Snowflake account and database strategy, based on business requirements..