Back to SnowPro Core Certification (COF-C02)

Account Access and Security

Implement role-based access control, authentication, encryption, and compliance features in Snowflake (18% of exam).

This domain covers implementing role-based access control (RBAC), configuring authentication methods including MFA and SSO, managing network policies, understanding data encryption at rest and in transit, monitoring and auditing user activities, and ensuring compliance with security standards. These skills are essential for securing Snowflake deployments.
5 minutes 5 Questions

Account Access and Security in Snowflake encompasses the comprehensive framework for managing user authentication, authorization, and protecting sensitive data within the platform. This is a critical domain for the SnowPro Core Certification exam. **Authentication Methods:** Snowflake supports mul…

Concepts covered: Role-based access control (RBAC), System-defined roles (ACCOUNTADMIN, SYSADMIN, SECURITYADMIN, etc.), Custom roles and role hierarchy, Privileges and privilege management, Object ownership and access, User authentication methods, Multi-factor authentication (MFA), Single sign-on (SSO) with SAML, Key pair authentication, OAuth integration, Network policies, Private connectivity (AWS PrivateLink, Azure Private Link), Data encryption at rest and in transit, Tri-Secret Secure encryption, Account usage views and monitoring, Access history and auditing, Session policies

Test mode:
Start practice test
COF-C02 - Account Access and Security Example Questions

Test your knowledge of Account Access and Security

Question 1

A cybersecurity firm has deployed Snowflake for their threat intelligence platform. Their security architect is designing the authentication strategy and notices that the organization has two distinct user populations: internal security analysts who use workstations joined to the corporate domain with Ping Identity SSO, and automated threat detection scripts that run on isolated network segments. The scripts need to authenticate every 15 minutes to pull fresh data, and storing any form of password in the script environment is prohibited by policy. The architect must recommend appropriate authentication methods for both user populations. Which combination of authentication methods best addresses both use cases?

Correct Answer: Federated authentication via SAML 2.0 for internal analysts and key pair authentication using RSA private keys for the automated scripts

The correct answer recommends Federated authentication via SAML 2.0 for internal analysts and key pair authentication using RSA private keys for the automated scripts. This combination perfectly addresses both use cases:

For Internal Security Analysts:
SAML 2.0 federated authentication is the ideal choice because:
- It integrates seamlessly with the existing Ping Identity SSO infrastructure
- Analysts on domain-joined workstations get single sign-on experience
- Authentication is managed centrally through the corporate identity provider
- No additional credentials need to be managed within Snowflake

For Automated Scripts:
Key pair authentication is the best solution because:
- It uses public/private key cryptography where only the public key is stored in Snowflake
- The private key can be stored securely (in hardware security modules or secure key management systems) without violating the 'no password storage' policy
- It supports frequent authentication (every 15 minutes) without credential exposure
- It's specifically designed for programmatic/service account access in Snowflake

Why other options are incorrect:

OAuth with refresh tokens for scripts is problematic because refresh tokens would still need to be stored somewhere, and OAuth is typically designed for user-delegated access rather than machine-to-machine authentication in isolated environments.

Key pair authentication for internal analysts combined with SAML for automated scripts reverses the ideal pairing - human users benefit from SSO integration, while key pairs are designed for programmatic access, not daily interactive use.

Using SAML 2.0 for both populations with cached assertions is impractical for automated scripts because SAML is designed for interactive user authentication flows, requires browser-based redirects, and cached assertions would violate the spirit of the no-password-storage policy while being architecturally inappropriate for scheduled scripts.

Question 2

What type of key does Snowflake use to encrypt the master key in its hierarchical key model for data at rest protection?

Correct Answer: A customer-managed key stored in a cloud provider's key management service when using Tri-Secret Secure

Snowflake uses a hierarchical key model for encrypting data at rest. In this model, the master key sits at the top of the hierarchy and encrypts the keys below it. When using Tri-Secret Secure (also known as Customer-Managed Keys), the master key is encrypted using a customer-managed key that is stored in the cloud provider's key management service (such as AWS KMS, Azure Key Vault, or Google Cloud KMS).

This approach provides an additional layer of security because it combines Snowflake's encryption with a key that the customer controls. The customer maintains control over their key in the cloud provider's KMS, and both keys (Snowflake's and the customer's) are required to access the data - hence the name 'Tri-Secret Secure.'

The other options are incorrect:

  • Symmetric session keys are used for data in transit (TLS connections), not for protecting the master key in the hierarchical key model for data at rest.

  • Public-private key pairs maintained by an internal certificate authority are typically used for authentication and TLS certificate management, not for encrypting the master key in Snowflake's data-at-rest encryption hierarchy.

  • Ephemeral keys derived from user authentication credentials are not used in Snowflake's encryption key hierarchy. User credentials are for authentication purposes, not for the encryption of data at rest.

Question 3

Scenario: Kevin, a platform engineer at a SaaS company, is troubleshooting intermittent performance issues reported by customers using their Snowflake-powered analytics platform. The issues seem to occur during specific hours when multiple tenants run heavy workloads simultaneously. Kevin wants to analyze query execution patterns and identify which queries are competing for resources. He decides to use the QUERY_HISTORY view in ACCOUNT_USAGE to correlate slow query times with warehouse queue events. While building his analysis, Kevin joins QUERY_HISTORY with WAREHOUSE_EVENTS_HISTORY to understand queuing behavior. He notices that for some recent queries executed 30 minutes ago, the QUERY_HISTORY view returns results, but there are no corresponding records in WAREHOUSE_EVENTS_HISTORY for the same time period. What is the most likely reason for this data discrepancy between these two ACCOUNT_USAGE views?

Correct Answer: ACCOUNT_USAGE views have latency periods ranging from 45 minutes to 3 hours before data becomes available, and different views may have varying latency characteristics

The correct answer explains the key characteristic of ACCOUNT_USAGE views in Snowflake: they have inherent latency periods before data becomes available. This latency typically ranges from 45 minutes to 3 hours depending on the specific view.

In Kevin's scenario, he's looking at queries executed just 30 minutes ago. Since ACCOUNT_USAGE views have this built-in latency, it's entirely possible that QUERY_HISTORY (which may have a shorter latency) has already populated the recent query data, while WAREHOUSE_EVENTS_HISTORY (which may have a longer latency) hasn't yet received the corresponding warehouse event records. Different ACCOUNT_USAGE views can indeed have varying latency characteristics, which explains why Kevin sees data in one view but not the other for the same time period.

The other answers are incorrect for the following reasons:

  • The suggestion that ACCOUNT_USAGE views synchronize in 6-hour batches is incorrect. Snowflake uses a latency-based approach, not fixed 6-hour batch cycles, and the latency is measured in minutes to hours, not in rigid batch windows.

  • The claim that WAREHOUSE_EVENTS_HISTORY has a consistent 24-hour delay compared to QUERY_HISTORY is false. While latencies differ between views, there is no documented 24-hour priority-based delay system between these specific views.

  • The suggestion that users need to execute a REFRESH_ACCOUNT_USAGE() command is completely incorrect. There is no such command in Snowflake. ACCOUNT_USAGE views are automatically populated by Snowflake's internal processes, and users cannot manually refresh them.

More Account Access and Security questions
507 questions (total)
Start 100 question test