Snowflake COF-C03: Data collaboration and protection Practice Questions

PUBLIC is the correct answer. Every user and role in Snowflake is automatically granted the PUBLIC role, but more precisely, for read-only access, a custom role with SELECT privileges is ideal. However, among these system-defined options, PUBLIC is the only role that does not carry object-creation or administrative privileges. SYSADMIN has full privileges to create and manage all database objects, violating least privilege. SECURITYADMIN manages users and roles and can grant any privilege, which is excessive. USERADMIN can create users and roles but is also far more powerful than needed for read-only access.

Snowflake's official best practices explicitly recommend: (1) having at least two users assigned ACCOUNTADMIN to avoid lockout scenarios, and (2) reserving ACCOUNTADMIN for tasks that truly require it while using SYSADMIN, SECURITYADMIN, or custom roles for routine work. Option D is wrong because setting ACCOUNTADMIN as the default role is discouraged — users should switch into it only when needed. Option B is wrong because Snowflake recommends that ACCOUNTADMIN NOT be granted to other roles, keeping it at the very top of the hierarchy and isolated. Option A is wrong because sharing credentials violates security principles and Snowflake best practices; each ACCOUNTADMIN user should have their own credentials, ideally protected by MFA.

Snowflake Marketplace uses secure data sharing, so consumers get a read-only, live database reference mounted in their account — no data is physically copied or moved. Option A is incorrect because Snowflake supports cross-cloud and cross-region sharing via replication; consumers do not need to be in the same region. Option C is incorrect for public listings — the consumer can request access directly through the Marketplace UI without the provider pre-adding their account; the provider approves the request. Option D is incorrect because free and standard listings can be accessed via self-service without a negotiated contract; direct listings (custom) may require a contract, but this is not universally true of all listings.

UNDROP SCHEMA RAW_DATA; restores the schema and all of its child objects, including all 20 tables, in a single command — making it the most efficient choice. Option D would work but requires issuing 20 separate commands AND the schema itself must first be restored (you cannot UNDROP tables in a dropped schema). Option C uses zero-copy cloning with time travel, which is a valid recovery technique but more complex and unnecessary when UNDROP is available within the retention period. Option B alters a setting on a dropped schema, which is invalid syntax and would fail.

Snowflake supports MFA token caching, which allows a token to be reused for a configurable period within a session, preventing repeated MFA prompts. If token caching is not enabled (via the ALLOW_CLIENT_MFA_CACHING account parameter or the client-side configuration), each authentication event triggers a new MFA challenge. Option B is incorrect; APPLY AUTHENTICATION POLICY is about applying policies, not about MFA prompt frequency. Option A is incorrect; MFA does not re-authenticate on every DDL statement by design. Option D is incorrect; mainstream Snowflake connectors support MFA, and 'per-query authentication' is not a fallback mode.