ADA-C02 SnowPro Advanced: Administrator Questions and Answers

Snowflake identifies accounts within an organization using an account name combined with an organization identifier. The CREATE ACCOUNT statement requires the account name as part of its syntax.

Option C is correct because administrators must specify an account name when creating an account.

Option E is correct because account names must be unique within their respective Snowflake organization. This restriction applies across the organization's supported cloud platforms and regions.

Option A is not an account-creation naming requirement. The original wording assumes the legacy ORGADMIN administration model, whereas Snowflake also supports GLOBALORGADMIN in a dedicated organization account.

Option B is incorrect because Snowflake allows organization administrators to rename accounts through ALTER ACCOUNT or the supported administration interface.

Option D is incorrect because account names are not required to be globally unique across unrelated Snowflake organizations. Instead, the combination of organization name and account name provides the globally distinguishable identifier.

Account renaming changes the preferred account URL, but Snowflake supports preservation of the previous URL when appropriate.

For production account provisioning, administrators should choose account names that reflect business purpose, environment, and regional requirements while complying with Snowflake's identifier restrictions.

Official Snowflake references: CREATE ACCOUNT; Account Identifiers; Renaming an Account.

Snowflake supports database replication between accounts in the same organization, including accounts deployed in different regions and cloud platforms.

Option A is correct because the administrator enables replication on the source database from the account containing that primary database. The ALTER DATABASE ... ENABLE REPLICATION TO ACCOUNTS statement identifies the destination accounts authorized to create replicas.

Option C is correct because replication refreshes are initiated from the account containing the secondary database, using ALTER DATABASE < secondary_database > REFRESH.

Option F is supported by Snowflake's database-replication documentation, which permits any number of primary databases in an account and allows a primary database to be replicated to any number of accounts within the organization. Practical resource limits and applicable account restrictions must still be considered.

Option B is incorrect because REPLICATIONADMIN is not a required predefined system role for the legacy database-replication workflow. ACCOUNTADMIN performs the relevant operations.

Option D is incorrect because cross-cloud replication is supported.

Option E is incorrect because databases created from incoming shares cannot be replicated using this database-replication mechanism.

Current-version warning: This question describes legacy database replication. Snowflake now strongly recommends replication and failover groups under its account-replication architecture. The selected answers remain valid for the specific commands named in the question.

Official Snowflake references: Introduction to Database Replication Across Multiple Accounts; ALTER DATABASE; Database Replication Considerations.

Snowflake provides temporary MFA bypass functionality to recover user access when an enrolled authentication device becomes unavailable. The appropriate administrative action is to configure the MINS_TO_BYPASS_MFA property on the affected user.

For example:

ALTER USER user1

SET MINS_TO_BYPASS_MFA = 30;

This command permits the user to authenticate temporarily without completing MFA for the configured 30-minute period. Importantly, the operation does not revoke the user's existing MFA enrollment or permanently disable the authentication requirement.

Option B is unsuitable because DISABLE_MFA is a Boolean setting and does not automatically provide a 24-hour expiration period. It is not equivalent to a controlled, time-limited bypass.

Option C is incorrect because Snowflake supports MFA authentication through SnowSQL and other supported clients. Changing the connection client does not inherently eliminate MFA enforcement.

Option D proposes an unsupported URL-based authentication bypass.

From a security-administration perspective, the administrator should first validate the user's identity through an approved recovery procedure, establish the shortest practical bypass interval, and guide the user through registration of a replacement MFA method.

Current Snowflake documentation also describes ALTER USER ... ENROLL MFA as a recovery mechanism for users who must register a new authenticator.

Official Snowflake references: Multi-factor Authentication; Recovering a User Who Is Locked Out; ALTER USER.

Snowflake network policies control inbound authentication requests by evaluating their originating network locations against configured allowed and blocked entries.

In this scenario, two network policies are activated. The FOO_POLICY is assigned at the account level, while BAR_POLICY is assigned specifically to user1.

Snowflake applies user-level network policies in preference to account-level policies. Therefore, BAR_POLICY determines whether user1 can authenticate.

Within BAR_POLICY, the ALLOWED_IP_LIST contains the 3.3.3.0/24 subnet, which includes the attempted source address 3.3.3.10.

However, the BLOCKED_IP_LIST explicitly identifies 3.3.3.10. Snowflake documents that blocked entries take precedence over allowed entries when an address matches both.

Consequently, user1's authentication request is rejected, making option B correct.

Option A ignores blocked-list precedence. Options C and D incorrectly evaluate the account-level policy rather than the applicable user-level policy.

Current documentation qualification: Although the original SQL remains representative of the legacy IP-list configuration, Snowflake recommends using network rules with ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST for newly configured network policies. This improves administrative consistency and supports additional network identifier types.

Official Snowflake references: Controlling Network Traffic with Network Policies; ALTER NETWORK POLICY.

Snowflake resource monitors provide administrative controls for tracking virtual warehouse credit consumption and responding when configured thresholds are reached.

Option C is correct because resource monitors track consumption through Snowflake's account-management infrastructure rather than executing monitoring queries on the assigned virtual warehouses. Consequently, their monitoring activity does not impose additional workload on warehouse compute.

Option D is correct because a resource monitor supports multiple configurable triggers. Administrators can specify percentage thresholds that initiate notifications, suspend warehouses after running statements complete, or immediately suspend warehouses and cancel executing statements.

Option F is correct because a warehouse-level resource monitor can be assigned to multiple virtual warehouses. Their combined credit consumption is evaluated against the monitor's quota.

Option A is incorrect because Snowflake does not define the claimed daily monitoring charge.

Option B is incorrect because an individual virtual warehouse can be assigned to only one warehouse-level resource monitor.

Option E is incorrect as written. Although resource-monitor creation is restricted to ACCOUNTADMIN, Snowflake does not document the proposed CREATE MONITOR privilege as an alternative authorization mechanism for creating resource monitors. MONITOR and MODIFY are separate privileges that can be granted on existing resource monitors.

Official Snowflake references: Working with Resource Monitors; CREATE RESOURCE MONITOR.

Snowflake external tables provide a relational interface for querying structured and semi-structured data files stored outside Snowflake, typically in cloud object storage such as Amazon S3, Azure Blob Storage, or Google Cloud Storage.

An external table references files through an external stage. Snowflake maintains file-level metadata and exposes the external data through a table-like abstraction, allowing SQL queries without requiring an initial COPY INTO operation to populate an internal Snowflake table.

This simplifies data pipelines when source files must remain in cloud storage, particularly for data lakes, historical archives, and externally managed datasets.

Option A describes accessing Snowflake from another relational database, which is not the purpose of an external table.

Option B similarly concerns external database connectivity rather than querying files stored in an external stage.

Option C describes exporting data from Snowflake to external storage, a process generally implemented through unloading operations such as COPY INTO a storage location.

Option D correctly identifies the external-table use case.

External tables are read-only and do not support conventional INSERT, UPDATE, or DELETE operations. Query performance may also be lower than native Snowflake tables because the underlying data remains externally stored.

Official Snowflake references: Introduction to External Tables; Creating External Tables; Querying External Tables.

Snowflake multi-cluster warehouses are designed to address fluctuating query concurrency by adding and removing compute clusters according to workload demand.

Option D creates a Medium-sized warehouse with a maximum of ten clusters and the STANDARD scaling policy. Because MIN_CLUSTER_COUNT is not explicitly specified, Snowflake uses its default value of one.

The resulting configuration operates in auto-scale mode, allowing Snowflake to increase the number of running clusters when concurrency rises and decrease it when demand subsides.

AUTO_SUSPEND=600 configures the warehouse to suspend after approximately ten minutes of inactivity. AUTO_RESUME=TRUE allows Snowflake to restart it automatically when eligible queries arrive.

Option A provides automatic suspension and resumption but creates only a single-cluster warehouse.

Option B configures multiple clusters but disables automatic resumption and assigns an unnecessarily large cluster size.

Option C also uses a large single-cluster configuration without horizontal concurrency scaling.

Therefore, D most closely meets the requirements.

Technical qualification: Multi-cluster warehouses require Enterprise Edition or higher. Additionally, STANDARD scaling prioritizes reducing query queues, while ECONOMY scaling more aggressively conserves credits. Therefore, D is the best available answer, but it is not necessarily the minimum-cost configuration for every workload.

Official Snowflake references: Multi-cluster Warehouses; CREATE WAREHOUSE; Warehouse Considerations.

Snowflake associates an account-level network policy through the NETWORK_POLICY account parameter. Administrators can inspect this parameter using SHOW PARAMETERS.

Option B is clearly intended to retrieve the account-level policy assignment, but its SQL contains a substantive error.

The source specifies NETWORK POLICY with a space. Snowflake's actual account parameter is NETWORK_POLICY, with an underscore.

The correct command is:

SHOW PARAMETERS LIKE 'NETWORK_POLICY'

IN ACCOUNT;

Snowflake uses SQL-style pattern matching for the LIKE filter. A space is not interchangeable with an underscore, so the original option B does not match the intended parameter.

Option A is not valid SHOW NETWORK POLICIES syntax for identifying the active account assignment.

Option C lists existing network policies but does not, by itself, identify the one assigned to the account.

Option D describes a specified network policy rather than retrieving the current account-level assignment.

The correct operational approach is to query the NETWORK_POLICY parameter or inspect the applicable policy references through Snowflake's supported administrative views and functions.

Mandatory correction: The supplied question has no fully correct SQL answer as written. Replace the space in option B with an underscore before publishing the item.

Official Snowflake references: Controlling Network Traffic with Network Policies; SHOW PARAMETERS; Parameter Management.

Snowflake future grants automatically assign specified privileges to qualifying objects created after the grants are configured. Administrators can define future grants at either the database level or the schema level.

When future grants exist at both levels for the same object type, Snowflake gives precedence to the schema-level grants. The corresponding database-level future grants are ignored for that object type within the affected schema.

Consider the following configuration:

GRANT SELECT

ON FUTURE TABLES IN DATABASE PROD

TO ROLE ANALYST;

GRANT INSERT

ON FUTURE TABLES IN SCHEMA PROD.WORKING

TO ROLE DEVELOPER;

```

When a new table is created in PROD.WORKING, the schema-level future grant takes precedence. The DEVELOPER role receives INSERT, while the database-level future SELECT grant to ANALYST is not applied to that new table.

This behavior is not a combination of permissions based on whichever grant is more permissive or restrictive. It is an explicit precedence rule.

Option A incorrectly prioritizes the broader database scope. Options C and D incorrectly describe a merged policy-evaluation process.

The rule applies when both future grants concern the same object type. Future grants on different object types can coexist without this particular conflict.

Official Snowflake references: Configuring Access Control: Future Grants; GRANT Privileges to Roles.

Snowflake provides the MINS_TO_BYPASS_MFA user property to support temporary authentication recovery when an enrolled user cannot complete multi-factor authentication.

This property specifies the number of minutes during which the affected user may authenticate without providing the normally required second authentication factor.

The requested duration is 24 hours, equivalent to 1,440 minutes:

ALTER USER user1

SET MINS_TO_BYPASS_MFA = 1440;

An authorized administrator can execute this command to establish a temporary MFA bypass for user1. The bypass expires after the configured duration, allowing normal MFA enforcement to resume without permanently removing the user's enrollment.

Option B is incorrect because DISABLE_MFA is a Boolean user property, not a numeric duration setting. Assigning 1440 does not express the intended temporary bypass. Options C and D reference properties that are not supported by Snowflake's ALTER USER syntax.

The administrator should use the minimum bypass duration necessary to restore access because authentication without a second factor increases exposure to compromised credentials.

Snowflake also supports ALTER USER ... ENROLL MFA to help locked-out users register a replacement authentication method. That approach may be preferable when the original device has been lost.

Official Snowflake references: ALTER USER; CREATE USER; Multi-factor Authentication: Recovering a User Who Is Locked Out.

Snowflake warehouses maintain a local cache of frequently accessed table data on their compute resources. This cache can reduce repeated remote storage reads when subsequent queries access the same micro-partitions.

Setting AUTO_SUSPEND to 0 or NULL disables automatic warehouse suspension. Consequently, the warehouse remains running and its local data cache remains available, assuming the underlying compute resources are retained.

Option C is correct because this can benefit dashboard workloads that repeatedly query overlapping datasets, particularly when different reports access similar table partitions.

Option D incorrectly associates warehouse suspension with the persisted query result cache. Snowflake maintains persisted query results independently of warehouse-local storage. Eligible results can be reused even after a warehouse has been suspended.

Option B contradicts the proposed configuration because disabling suspension causes the warehouse to remain active during idle periods.

Option A is not the primary caching rationale and is misleading as a general cost-saving claim.

Operational qualification: Snowflake explicitly cautions against disabling automatic suspension unless a continuously running warehouse is justified. A warehouse consumes credits while running, even without active queries. Snowflake recommends evaluating cache benefits against idle compute costs and generally suggests an auto-suspend interval of at least ten minutes for applicable BI workloads.

Official Snowflake references: Optimizing the Warehouse Cache; CREATE WAREHOUSE; Warehouse Considerations.

Snowflake network policies are account-level security objects that control inbound connectivity through permitted and blocked network locations.

Creating a network policy requires the account-level CREATE NETWORK POLICY privilege. Snowflake assigns this privilege to SECURITYADMIN and higher roles by default.

Therefore, SECURITYADMIN can create network policies through its predefined security-administration capabilities. ACCOUNTADMIN can also create them because its role hierarchy includes the necessary administrative privileges.

Additionally, Snowflake permits authorized administrators to delegate the global CREATE NETWORK POLICY privilege to custom roles. Such a custom role can create network policies without requiring the complete privileges associated with SECURITYADMIN or ACCOUNTADMIN.

An example is:

GRANT CREATE NETWORK POLICY

ON ACCOUNT

TO ROLE NETWORK_SECURITY_ADMIN;

Option A is incorrect because SYSADMIN does not possess this privilege by default. Option D is incorrect because ORGADMIN focuses on organization-level administration rather than automatically inheriting account-level network-policy privileges.

Option F is incorrect because network policies are not database objects. Ownership of an individual database does not confer authority to create account-level network policies.

Following creation, policy assignment and modification remain subject to the appropriate access-control requirements. Administrators should delegate only those privileges necessary to support the intended security operations.

Official Snowflake references: CREATE NETWORK POLICY; Controlling Network Traffic with Network Policies; Access Control Privileges.

Snowflake configures OAuth 2.0 authentication through a security integration created using the CREATE SECURITY INTEGRATION statement. The integration defines the relevant OAuth authentication and authorization settings, depending on whether Snowflake OAuth or External OAuth is implemented.

Creating an OAuth security integration requires the global CREATE INTEGRATION privilege on the Snowflake account.

The ACCOUNTADMIN system role possesses this privilege by default. Therefore, ACCOUNTADMIN is the appropriate selection when evaluating the standard system-role configuration without additional privilege delegation.

Option A is incorrect because USAGE on an existing security integration does not provide authority to create a new integration.

Options B and C are incorrect because neither SYSADMIN nor SECURITYADMIN is inherently required to participate in creation. These roles also do not receive the required CREATE INTEGRATION privilege merely through their default administrative responsibilities.

The following statement illustrates the intended administrative context:

USE ROLE ACCOUNTADMIN;

CREATE SECURITY INTEGRATION oauth_integration

TYPE = OAUTH

ENABLED = TRUE

OAUTH_CLIENT = CUSTOM;

```

Additional integration parameters may be required depending on the OAuth implementation.

Verification qualification: The phrase "ACCOUNTADMIN only" is technically too restrictive. Snowflake explicitly permits the CREATE INTEGRATION privilege to be granted to other roles. Thus, D is the intended answer for default system-role privileges, but not an absolute authorization rule.

Official Snowflake references: CREATE SECURITY INTEGRATION (Snowflake OAuth); CREATE SECURITY INTEGRATION (External OAuth); Configure Snowflake OAuth for Partner Applications.

Snowflake supports secure sharing of unstructured data files through secure views that expose appropriately authorized file-access URLs.

Option B is correct because a secure view can use the GET_PRESIGNED_URL function to generate temporary URLs allowing consumers to retrieve staged files without requiring direct privileges on the provider's underlying stage.

For example:

CREATE SECURE VIEW AUDIO_SHARE_V AS

SELECT

GET_PRESIGNED_URL(

@AUDIO_STAGE,

RELATIVE_PATH,

300

) AS AUDIO_URL

FROM DIRECTORY(@AUDIO_STAGE);

The provider can add this secure view to the share, allowing Company B to retrieve the corresponding audio files.

Option A is ambiguous in ordinary language but technically incorrect when file URL means Snowflake's distinct permanent stage-file URL type. That URL type requires stage-level authorization and is not supported for accessing unstructured files through a consumer's shared secure view.

Option C exposes filenames rather than authenticated or authorized file contents.

Option D identifies file locations but does not provide the consumer with a usable file-access authorization mechanism.

Security qualification: Snowflake also supports scoped URLs using BUILD_SCOPED_FILE_URL. These are generally preferable when consumers can authenticate to Snowflake because they provide more restrictive access. Pre-signed URLs can be accessed by anyone possessing the URL until expiration.

The question should distinguish scoped URLs from pre-signed URLs in a modern examination.

Official Snowflake references: Share Unstructured Data with a Secure View; Introduction to Unstructured Data; GET_PRESIGNED_URL.

Snowflake resource monitors enforce credit-consumption controls through configurable quotas, reset intervals, start timestamps, and threshold-triggered actions.

Option B is the intended configuration because it specifies a 3,000-credit quota, a YEARLY reset frequency, an explicit January 1 start timestamp, and the three required actions.

At 80%, the NOTIFY action generates alerts for administrators who have enabled resource-monitor notifications without suspending the warehouse.

At 100%, SUSPEND prevents new query execution while allowing statements already running to complete. Snowflake also generates the associated suspension notifications.

At 120%, SUSPEND_IMMEDIATE cancels executing statements and suspends the assigned warehouse immediately, generating additional notifications.

Option A omits FREQUENCY despite defining START_TIMESTAMP. Snowflake requires the two scheduling parameters to be specified together for a customized schedule.

Option C omits FREQUENCY and uses unsupported combined actions such as DO NOTIFY AND SUSPEND.

Option D specifies YEARLY but omits the required START_TIMESTAMP.

The ALTER WAREHOUSE statement is necessary because creating a resource monitor does not automatically assign it to a warehouse.

Outdated exhibit warning: The January 1, 2022 timestamp is historical. For deployment in a current environment, the administrator should use an appropriate valid calendar-year start date rather than execute the sample unchanged. Notification delivery must also be enabled for the relevant administrators.

Official Snowflake references: CREATE RESOURCE MONITOR; Working with Resource Monitors — Schedules, Actions, and Notifications.