This domain is about 20% of the exam, roughly 20 of its 100 questions.

Every point below comes from Snowflake's official documentation; each section lists its sources.

Think first How do roles, ownership and policies combine to decide whether a Snowflake user can sign in and run a given statement?

Why it matters: Questions describe an access or login problem and ask which role, grant or policy explains it or fixes it.

Snowflake grants privileges to roles, and every object has one owning role that can share access. Roles inherit privileges upward through a hierarchy. Network policies are checked before authentication policies, and a blocked IP stops evaluation.

Access comes from roles (RBAC) and from object owners (DAC). Privileges go to roles, and roles go to users. Each object also has one owning role that can grant access to it. A privilege granted to a role flows up to every parent role in the hierarchy.

Role-based and discretionary access control compared

Exam trap Owning a role is not the same as being above it in the hierarchy. The owner role does not inherit the owned role's privileges; only a role hierarchy passes privileges on.

ACCOUNTADMIN sits on top and contains SYSADMIN and SECURITYADMIN. USERADMIN holds CREATE USER and CREATE ROLE. These built-in roles can never be dropped, and their built-in privileges cannot be revoked. Keep ACCOUNTADMIN to a few users, require MFA for them, and give them a lower default role such as SYSADMIN.

Exam trap MANAGE GRANTS is not held by every admin role. By default only ACCOUNTADMIN and SECURITYADMIN have it, and it lets the holder see every object.

Database roles work only after they are granted to an account role. A session can activate account roles but never a database role directly. Build custom roles as a hierarchy whose top role is granted to SYSADMIN. Creating any role needs USERADMIN or higher, or CREATE ROLE on the account.

Exam trap Seeing a database role is not the same as using it. Any privilege on the database lets a role list its database roles, but they still must be granted to an account role. They also do not appear in the roles graph.

Object privileges also need access to the database and schema around them. A role needs USAGE or another privilege on the container database and schema before it can work with an object inside. In a managed access schema, object owners lose grant rights. A holder of MANAGE GRANTS can even grant privileges straight to users.

Example: Gives a role SELECT on every table that already exists in one schema.

GRANT SELECT ON ALL TABLES IN SCHEMA my_db.my_schema
  TO ROLE my_role;

• ON ALL TABLES IN SCHEMA: covers existing tables only, not tables created later

Exam trap A grant on all tables in a schema does not cover tables created afterward. Those need a separate grant on future tables.

EXPLAIN_PRIVILEGES names exactly which privileges a failed statement lacks. To run it on your own query, you need at least one privilege on the objects involved. Set missing_only to true to list only what is still needed. With for_role, it checks that role together with its granted roles.

Exam trap Without at least one privilege on the objects, you cannot call this function on your query. Grant RESOLVE ALL ON ACCOUNT to someone who must diagnose access problems without them.

CREATE statements are always authorized by the primary role. At login, the user's default role and default secondary roles become active automatically. USE SECONDARY ROLES with ALL or NONE then changes how secondary roles are handled. Even with secondary roles active, creating an object relies on the primary role.

The two USE SECONDARY ROLES settings compared

Exam trap ALL does not lock in the roles you hold when you run it. Role grants are checked per statement, so a newly granted role becomes active without another command.

Network policies are checked first, and they do nothing until activated. If the network policy blocks a request's IP address, evaluation stops there. Authentication policies then set allowed methods, such as SAML, OIDC, OAuth, key pairs and passwords. MFA second factors include passkeys, authenticator apps and Duo.

Network and authentication policies compared

Exam trap Blocking client types in an authentication policy is not a firm security boundary. CLIENT_TYPES is best effort, so pair it with other controls.

Logged messages from handler code land in an event table. Telemetry collection must be turned on before any messages are collected. The log level controls which severities are kept. Snowflake Scripting logs with SYSTEM$LOG. Request and response translators in external functions cannot log at all.

Exam trap A log call inside a UDF's row handler is not written once per query. It runs for every row, so a large table can flood the event table.

• Privileges go to roles, roles go to users, and parent roles inherit from child roles.
• Database roles must be granted to an account role before a session can use them.
• CREATE statements are always authorized by the primary role, even with secondary roles active.
• A network policy blocking an IP stops evaluation before any authentication policy is checked.
• Use EXPLAIN_PRIVILEGES to find exactly which privileges a failed statement is missing.

Sources: Overview of Access Control | Snowflake Documentation · Configuring access control | Snowflake Documentation · Authentication policies | Snowflake Documentation · USE SECONDARY ROLES | Snowflake Documentation · Controlling network traffic with network policies | Snowflake Documentation · Access control best practices | Snowflake Documentation · SHOW DATABASE ROLES | Snowflake Documentation · Troubleshooting access control issues | Snowflake Documentation

Think first How do masking policies, tags, privacy policies and encryption work together to protect sensitive data in Snowflake?

Why it matters: Questions describe a governance need and ask which feature, privilege, limit or key setting meets it.

Snowflake protects data in layers. Masking and aggregation policies control what a query returns, while tags label objects so policies can follow them. Underneath, all customer data is encrypted by default with a managed key hierarchy.

Column-level security is Dynamic Data Masking plus External Tokenization. Both rely on masking policies applied at query time. Dynamic Data Masking never rewrites the table, so there is no static masking. External Tokenization stores tokens instead, and an external function restores the values at query runtime.

Dynamic Data Masking and External Tokenization compared

Exam trap Dynamic Data Masking never changes what is stored. The table keeps its plain-text values; only query results are masked.

A column takes only one masking policy at a time. The policy's input and output data types must match. Editing the policy body updates every column that uses it, with no reapplying. To drop a policy, first unset it from the column with an ALTER VIEW … MODIFY COLUMN or ALTER TABLE … MODIFY COLUMN statement.

Exam trap Dropping a masking policy that is still set on a column fails. Unset it on the column first, then run the drop again.

Object owners cannot unset a masking policy or see the data it hides. The APPLY privilege on a masking policy lets a role set and unset it. Dynamic Data Masking itself can keep even ACCOUNTADMIN and SECURITYADMIN from viewing protected data needlessly. Use IS_ROLE_IN_SESSION when conditions must respect role hierarchy. Inside a policy body, CURRENT_DATABASE returns the protected table's database, not the session's.

Exam trap Owning a table does not let a role read or remove its masking. The OWNERSHIP privilege alone cannot unset a masking policy.

A tag is a schema-level object whose value is always a string. One object can carry at most 50 tags. Tags flow down the hierarchy, so a table tag reaches every column. ALLOWED_VALUES caps a tag at 5,000 values of up to 256 characters. Removing an allowed value leaves existing assignments as they are. UNDROP TAG restores a dropped tag and its assignments within 24 hours.

Exam trap Automatic propagation of user-defined tags is not in every edition. It requires Enterprise Edition or higher.

A policy on a tag protects every tagged column of a matching data type. System tags cannot take masking policies. A table protected this way cannot back a materialized view. When a provider shares a database or schema, its tag-based policies still apply in the consumer account.

Direct and tag-based masking policies compared

Exam trap When a column has both a direct and a tag-based policy, the tag does not win. The directly assigned policy takes precedence.

Masking policies run before aggregation policies. An aggregation policy sets a minimum group size for query results. With an entity key, that minimum counts unique entities rather than rows. Each entity key maps to at most 1 policy, and only 1 policy may serve row-level privacy.

Exam trap Masking is not applied to results after they are aggregated. Masking policies run ahead of aggregation policies.

All customer data is AES-encrypted by default under a key hierarchy. The hierarchy has 4 levels: root, account master, table master and file keys. Snowflake rotates managed keys once they are over 30 days old. Tri-Secret Secure adds a customer-managed key, forming a composite master key. You register it with SYSTEM$REGISTER_CMK_INFO. Revoke it, and Snowflake can no longer decrypt the data.

Exam trap Files bound for an internal stage are not sent in plain text. The client encrypts them before upload, and they are encrypted again in the stage.

Trust Center's Security Essentials scanners run monthly by default. By default they email verified Admin users only about critical findings. To find every object a masking policy is set on, query the POLICY_REFERENCES view. After a failover, failover group objects become writable on the promoted account and read-only on the former primary.

Exam trap The QUERY_HISTORY view does not list masking policy names. Use POLICY_REFERENCES to find the objects a policy protects.

• A column takes one masking policy, and a direct policy beats a tag-based one.
• Object owners cannot unset masking or view masked data; the APPLY privilege controls set and unset.
• An object holds at most 50 tags, and a dropped tag can be undropped within 24 hours.
• Masking policies are enforced before aggregation policies, never after them.
• Revoking the Tri-Secret Secure customer key stops Snowflake from decrypting the data.

Sources: Understanding Column-level Security | Snowflake Documentation · Introduction to object tagging | Snowflake Documentation · Implementing entity-level privacy with aggregation policies | Snowflake Documentation · Understanding Encryption Key Management in Snowflake | Snowflake Documentation · Advanced Column-level Security topics | Snowflake Documentation · Understanding Dynamic Data Masking | Snowflake Documentation · Work with object tags | Snowflake Documentation · Tag-based masking policies | Snowflake Documentation

Think first How would you cap warehouse spending in an account and then work out where its credits actually went?

Why it matters: Questions describe a spending or monitoring need and ask which resource monitor setting, budget or usage view fits it.

Resource monitors set a credit quota on warehouses and act when thresholds are reached. Budgets cover the serverless and AI spending that monitors cannot track. ACCOUNT_USAGE views then keep 1 year of history to explain where credits went.

An account has one account monitor; each warehouse has at most one monitor. The account monitor watches credit use of every warehouse in the account. A warehouse monitor can watch several warehouses at once. Only ACCOUNTADMIN can create a monitor, but other roles can be granted rights to view and modify monitors.

Exam trap A warehouse cannot sit under two warehouse monitors for extra protection; it belongs to only one resource monitor at a time.

Suspend lets running queries finish; Suspend Immediate cancels them. A monitor holds one Suspend action, one Suspend Immediate action and up to five Notify actions. Choose Suspend Immediate only when cancelling running statements is acceptable.

The two suspend actions compared

Exam trap Reaching the Suspend threshold does not kill queries already running; only Suspend Immediate cancels them.

The quota counts warehouse credits plus the cloud services behind them. By default, monitoring starts at once and used credits go back to 0 each calendar month. Whatever start time you set, the reset happens at 12:00 AM UTC.

Exam trap A monitor set to start at 9:00 AM local time still resets at 12:00 AM UTC, not at its own start time.

Resource monitors track warehouses only; use a budget for serverless spend. Snowpipe, automatic reclustering and materialized views fall outside even an account monitor. A budget can track these features and AI services. On warehouses, a budget follows two service types: WAREHOUSE_METERING and QUERY_ACCELERATION.

Exam trap An account-level monitor watches every warehouse, yet it does not cap Snowpipe or reclustering credits.

A shared warehouse counts toward a budget only when selected users run queries. Idle time, very short queries, cloud services overhead and automated work such as tasks are not attributed to users. When a warehouse is both direct and shared, the direct measurement wins. Standard budgets can lag up to 11 hours here, and low-latency budgets up to 6.

CREDITS_USED adds compute and cloud services credits, before any adjustment. It can therefore exceed the billed amount, which METERING_DAILY_HISTORY shows. CREDITS_ATTRIBUTED_COMPUTE_QUERIES leaves out idle time, so subtract it from CREDITS_USED_COMPUTE to estimate idle cost. After a resume, metering starts once all compute resources are provisioned.

Exam trap CREDITS_USED is not the billed figure, because it ignores the cloud services adjustment. Use METERING_DAILY_HISTORY for billed credits.

Query load is query execution time divided by the interval's length. Low load with slow queries points to a larger warehouse size. High load or queuing points to a separate warehouse or more clusters. A warehouse running with load below 1 for long periods is wasting credits. Viewing the load chart needs the MONITOR privilege.

ACCOUNT_USAGE keeps 1 year of history but lags behind. Information Schema has no lag but keeps far less history. WAREHOUSE_METERING_HISTORY returns hourly credits for the last 365 days. WAREHOUSE_LOAD_HISTORY reports load in 5-minute intervals.

ACCOUNT_USAGE and Information Schema compared

Exam trap Information Schema cannot answer a question about last year's spending; it keeps at most 6 months of history.

• Suspend lets running queries finish, while Suspend Immediate cancels them.
• Monitors reset at 12:00 AM UTC, whatever start time you choose.
• Use a budget, not a resource monitor, to track serverless features and AI services.
• Check billed credits in METERING_DAILY_HISTORY, since CREDITS_USED ignores the cloud services adjustment.
• ACCOUNT_USAGE keeps 1 year of history, with up to 3 hours of latency.

Sources: Working with resource monitors | Snowflake Documentation · Account Usage | Snowflake Documentation · RESOURCE_MONITORS view | Snowflake Documentation · Using budgets for warehouses (shared resources) | Snowflake Documentation · Monitoring warehouse load | Snowflake Documentation · Account Overview | Snowflake Documentation · WAREHOUSE_METERING_HISTORY view | Snowflake Documentation · WAREHOUSE_EVENTS_HISTORY view | Snowflake Documentation