Free COF-C03 Practice Test

The correct answer is D. To allow different authentication methods for multiple user groups. Multiple identity providers allow an organization to support different authentication configurations for different users, departments, partners, or applications. This is useful when separate user groups authenticate through different SSO providers or require different authentication flows. Why D is correct: Configuring multiple IdPs allows Snowflake to support multiple federated authentication integrations and assign appropriate authentication behavior to different users or groups. Why the other options are incorrect:
A . Complex password rules are controlled by password policies, not by configuring multiple IdPs.
B . Identity providers affect authentication, not query performance.
C . Encryption key management is handled by Snowflake encryption features and key management options, not IdP configuration. Official Snowflake documentation reference: Snowflake documentation describes federated authentication and multiple identity provider support as a way to configure different SSO/authentication integrations for different users.
Reference: Snowflake Documentation — Federated authentication; Multiple identity providers; Authentication policies; SnowPro Core Study Guide — Security and Access Control. ========================

The MINDATARETENTIONTIMEINDAYS parameter is an account-level setting available for Enterprise Edition (and higher) accounts. Its purpose is to enforce a minimum Time Travel retention period for all databases, schemas, and tables within the account. This ensures that no object can have its DATARETENTIONTIMEINDAYS set to a value lower than this account-wide minimum, which is critical for compliance and data governance. This parameter can only be set by a user with the ACCOUNTADMIN role.

B. Database: The DATARETENTIONTIMEINDAYS parameter can be set at the database level, but not the MINDATARETENTIONTIMEINDAYS parameter.
C. Schema: The DATARETENTIONTIMEINDAYS parameter can be set at the schema level, but not the MINDATARETENTIONTIMEINDAYS parameter.
D. Table: The DATARETENTIONTIMEINDAYS parameter can be set at the table level, but not the MINDATARETENTIONTIMEINDAYS parameter.

- Snowflake Documentation. (n.d.). MINDATARETENTIONTIMEINDAYS. In Object Parameters. Retrieved from https://docs.snowflake.com/en/sql-reference/parameters#min-data-retention-time-in-days

- Snowflake Documentation. (n.d.). Specifying the Data Retention Period for an Object. In Understanding & Using Time Travel. Retrieved from https://docs.snowflake.com/en/user-guide/data-time-travel#specifying-the-data-retention-period-for-an-object

In Snowflake, an owner's rights stored procedure executes with the privileges of the user who owns the procedure, not the user who calls it. To prevent potential misuse, such as privilege escalation or unauthorized information disclosure, Snowflake restricts certain commands from being executed within this type of procedure. The SHOW and DESCRIBE commands are explicitly restricted because they could be used to reveal information about objects or users that the calling role should not have access to.

B. MERGE is a standard DML command used to manipulate data and is permitted within an owner's rights stored procedure.
C. INSERT is a standard DML command used to add data to tables and is permitted within an owner's rights stored procedure.
D. DELETE is a standard DML command used to remove data from tables and is permitted within an owner's rights stored procedure.

1. Snowflake Documentation. (n.d.). Owner's Rights Stored Procedures. Retrieved from https://docs.snowflake.com/en/sql-reference/stored-procedures-owner-rights. "For security reasons, the following commands are not allowed in an owner’s rights stored procedure: ... DESCRIBE, ... SHOW."

2. Snowflake Documentation. (n.d.). Stored Procedure Security. Retrieved from https://docs.snowflake.com/en/developer-guide/stored-procedure/stored-procedures-security. "In an owner’s rights stored procedure, you cannot execute a SHOW or DESCRIBE command."

The DATASHARINGUSAGE schema, part of the shared SNOWFLAKE database, contains views specifically for providers who share data through listings, particularly on the Snowflake Marketplace. The MONETIZEDUSAGEDAILY view provides daily usage details for paid listings, helping providers track consumption against their pricing plans. The LISTINGTELEMETRYDAILY view offers telemetry data, such as query counts and execution times on a listing, giving providers insight into how consumers are interacting with their shared data.

A. The ACCESSHISTORY view is located in the ACCOUNTUSAGE schema and tracks object access across the entire account.
B. The DATATRANSFERHISTORY view is located in the ACCOUNTUSAGE schema and tracks data transfer costs.
C. The WAREHOUSEMETERINGHISTORY view is located in the ACCOUNTUSAGE schema and tracks warehouse credit consumption.

- Snowflake Documentation. (n.d.). DATASHARINGUSAGE Schema. In Snowflake Documentation. Retrieved from https://docs.snowflake.com/en/sql-reference/data-sharing-usage. Section: "Views in This Schema".

- Snowflake Documentation. (n.d.). Provider Usage Views. In Snowflake Documentation. Retrieved from https://docs.snowflake.com/en/native-apps/provider-usage-views. Section: "Provider Usage Views".

Snowflake's access control framework is a hybrid model that integrates two well-established security paradigms. The first is Discretionary Access Control (DAC), where each securable object has an owner who has the discretion to grant access to that object. The second is Role-based Access Control (RBAC), where access privileges are assigned to roles, which are then granted to users. This combination allows for a flexible and scalable security model where object owners control initial access, and roles simplify the management of privileges for large numbers of users.

A. Attribute-based Access Control (ABAC) is supported via features like policies, but it is not one of the two foundational models of the core framework.
C. Access Control List (ACL) is a different model where permissions are attached directly to objects for specific users, which is less scalable than Snowflake's RBAC approach.
E. Rule-based Access Control (RuBAC) is a distinct model where access is determined by a set of rules, which is not the primary basis of Snowflake's framework.

1. Snowflake Documentation. (n.d.). Overview of Access Control. Retrieved from https://docs.snowflake.com/en/user-guide/security-access-control-overview.html. In the section "Snowflake’s Access Control Model," it states, "Snowflake’s approach to access control combines aspects from both of the following models: Discretionary Access Control (DAC)... Role-based Access Control (RBAC)..."

The statement is False. Snowflake does not impose a requirement that source data files be no larger than 16MB. While there are performance best practices for file sizing to optimize parallel loading, these are recommendations, not hard limits. Snowflake recommends splitting larger data files into smaller chunks, typically between 10MB and 250MB compressed. This allows Snowflake to distribute the load across multiple servers in a warehouse. Files larger than this can still be loaded, but it may not be as efficient.

This is a True/False question. The statement is false because the 16MB figure is not a requirement; it's a misstatement of a general performance guideline for which the recommended range is much broader.

1. Snowflake Documentation. (n.d.). Data Loading Considerations. Retrieved from https://docs.snowflake.com/en/user-guide/data-load-considerations-prepare.html. In the section "File Sizing Best Practices and Performance," it states, "For the best performance... we recommend aiming for compressed file sizes between 100 MB and 250 MB." It also mentions that smaller files (e.g., 10MB) can be suitable. It never mentions a 16MB maximum requirement.

The statement is false. Fail-safe is a data recovery service provided by Snowflake that cannot be disabled or configured by account administrators or users. It is an integral part of the Snowflake data storage architecture, providing a non-configurable 7-day period for data recovery after the Time Travel retention period has ended. This feature is managed entirely by Snowflake to ensure a level of data protection against catastrophic data loss.

The option "True" is incorrect because user-configurable data retention is limited to the Time Travel feature (0-90 days depending on the edition). Fail-safe is a separate, subsequent, and non-configurable recovery mechanism.

1. Snowflake Documentation. "Understanding & Viewing Fail-safe". This page explicitly states: "The Fail-safe period is not configurable by the user." and "Fail-safe is not a feature that is intended for accessing historical data. Instead, it is for disaster recovery of data that has been lost or damaged due to extreme operational failures."

2. Snowflake Documentation. "Storage Costs for Time Travel and Fail-safe". In the overview table, the "Configurable by user?" row for Fail-safe is marked "No". This confirms that users have no control over enabling or disabling this feature.

The statement is false. Snowpipe, including when invoked via its REST API, can load data from both internal (Snowflake-managed) stages and external stages (e.g., Amazon S3, Google Cloud Storage, Microsoft Azure). The CREATE PIPE command allows the definition of a pipe that copies data from either an internal or an external stage. The REST API is simply a mechanism to notify Snowpipe to process specific files located in the stage defined in the pipe's definition, regardless of the stage type.

A. (True) This is incorrect because Snowpipe is designed to work with both internal and external stages, providing flexibility for various data ingestion architectures.

1. Snowflake Documentation. (n.d.). REST API for Snowpipe. Retrieved from https://docs.snowflake.com/en/user-guide/data-load-snowpipe-rest. The documentation describes the insertFiles endpoint, which triggers a pipe to load files from its defined stage, without restricting the stage type.

2. Snowflake Documentation. (n.d.). CREATE PIPE. Retrieved from https://docs.snowflake.com/en/sql-reference/sql/create-pipe. The syntax and examples clearly show pipes being created on both internal (@~, @%) and external (@myextstage) stages.

The statement is true. When a query is executed, Snowflake caches the result set for 24 hours. If an identical query is submitted by any user on the same account within this period, and the underlying data has not changed, Snowflake returns the cached result directly from the result cache. This operation does not require a running virtual warehouse and therefore consumes no compute credits.

The option "False" is incorrect because using the result cache is a key architectural feature of Snowflake designed to improve performance and reduce costs. It explicitly bypasses the need for compute resources (a virtual warehouse) when the exact same query result is available.

1. Snowflake Documentation. "Using the Result Cache". This page states: "When a query is executed, the result is cached for a period of time. If the same query is executed again and the data in the tables has not changed, the cached result is returned."

2. Snowflake Documentation. "Querying". Under the section "Retrieving results from the cache", it specifies: "This second query is not executed; instead, the results are returned from the cache. Note that retrieving results from the cache does not require a running warehouse and does not incur any credit charges."

3. Snowflake Documentation. "Understanding Snowflake virtual warehouse, query, and cloud services credit usage". This document clarifies that credit usage is tied to virtual warehouse uptime and cloud services, and explicitly notes that result cache usage does not consume virtual warehouse credits.

The statement is False. Reader accounts are designed to allow non-Snowflake customers to query data shared with them, but with significant restrictions. A key limitation is that they cannot execute the COPY INTO command to unload/extract data from the shared objects into an external stage. This restriction ensures the data provider maintains control over the data, preventing it from being moved outside the Snowflake ecosystem through the reader account. They can only query the data within Snowflake.

This is a True/False question. The statement is demonstrably false based on the documented limitations of reader accounts.

1. Snowflake Documentation. (n.d.). Managing Reader Accounts. Retrieved from https://docs.snowflake.com/en/user-guide/data-sharing-reader-config.html. In the "Reader Account Privileges and Limitations" section, it explicitly lists that reader accounts "Cannot unload data using the COPY INTO command."

2. Snowflake Documentation. (n.d.). Introduction to Secure Data Sharing. Retrieved from https://docs.snowflake.com/en/user-guide/data-sharing-intro.html. The documentation describes reader accounts as a mechanism for querying data, not for data extraction.