Snowflake COF-C02 Practice Test - Questions Answers, Page 58

To monitor updates, such as SCIM API requests sent to Snowflake by the identity provider, an administrator can use the REST EVENT HISTORY feature. This feature allows administrators to query historical data about REST API calls made to Snowflake, including those related to user and role management through SCIM (System for Cross-domain Identity Management).

The REST EVENT HISTORY table function returns information about REST API calls made over a specified period. It is particularly useful for auditing and monitoring purposes, especially when integrating Snowflake with third-party identity providers that use SCIM for automated user provisioning and deprovisioning.

An example query to check for SCIM API requests might look like this:

SELECT * FROM TABLE(information_schema.rest_event_history(date_range_start=>dateadd('hours',-1,current_timestamp()))) WHERE request_type = 'SCIM';

This query returns details on SCIM API requests made in the last hour, including the request type, the identity provider's details, and the outcome of each request.

When a Snowflake user wants to share a newly created object in a database with consumers, the correct action to take is to use the GRANT privilege ... TO SHARE command to grant the necessary privileges for the object to be shared. This approach allows the object owner or a user with the appropriate privileges to share database objects such as tables, secure views, and streams with other Snowflake accounts by granting access to a named share.

The GRANT statement specifies which privileges are granted on the object to the share. The object remains in its original location; sharing does not duplicate or move the object. Instead, it allows the specified share to access the object according to the granted privileges.

For example, to share a table, the command would be:

GRANT SELECT ON TABLE new_table TO SHARE consumer_share;

This command grants the SELECT privilege on a table named new_table to a share named consumer_share, enabling the consumers of the share to query the table.

Automatic sharing, dropping and re-adding the object, or recreating the object with a different name are not required or recommended practices for sharing objects in Snowflake. The use of the GRANT statement to a share is the direct and intended method for this purpose.

OPERATE. In Snowflake, to pause or resume a pipe, the OPERATE privilege is required on the pipe object. The OPERATE privilege allows users to perform operational tasks on specific objects such as pipes, tasks, and streams. Specifically, for a pipe, the OPERATE privilege enables the user to execute the ALTER PIPE ... SET PIPE_EXECUTION_PAUSED=TRUE or ALTER PIPE ... SET PIPE_EXECUTION_PAUSED=FALSE commands, which are used to pause or resume the pipe, respectively.

Here's a step-by-step explanation and reference:

Understanding Pipe Operations: Pipes in Snowflake are used for continuous data loading from staging areas into Snowflake tables. Managing pipes involves operations such as creating, monitoring, pausing, and resuming.

Privileges for Pipe Operations: The OPERATE privilege is essential for pausing and resuming pipes. This privilege is more specific than general object access privileges like SELECT or USAGE and is tailored for operational control.

Granting the OPERATE Privilege: To grant the OPERATE privilege on a pipe, an administrator or a user with the necessary grants can execute the SQL command:

GRANT OPERATE ON PIPE TO ROLE <role_name>;

Pausing and Resuming Pipes: Once the OPERATE privilege is granted, the user or role can pause the pipe using:

ALTER PIPE SET PIPE_EXECUTION_PAUSED=TRUE;

To resume the pipe, they use:

ALTER PIPE SET PIPE_EXECUTION_PAUSED=FALSE;

Details around the privileges that have been granted for all objects in an account. The ACCESS_HISTORY view in Snowflake provides a comprehensive log of access control changes, including grants and revocations of privileges on all securable objects within the account. This information is crucial for auditing and monitoring the security posture of your Snowflake environment.

Here's how to understand and use the ACCESS_HISTORY view:

Purpose of ACCESS_HISTORY View: It is designed to track changes in access controls, such as when a user or role is granted or revoked privileges on various Snowflake objects. This includes tables, schemas, databases, and more.

Querying ACCESS_HISTORY: To access this view, you can use the following SQL query pattern:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY WHERE EVENT_TYPE = 'GRANT' OR EVENT_TYPE = 'REVOKE';

Interpreting the Results: The results from the ACCESS_HISTORY view include the object type, the specific privilege granted or revoked, the grantee (who received or lost the privilege), and the timestamp of the event. This data is invaluable for audits and compliance checks.

In the Snowflake Data Exchange, the ability to get or request data from listings is generally controlled by specific roles and privileges:

A . Users with ACCOUNTADMIN role: This role typically has the highest level of access within a Snowflake account, including the ability to manage and access all features and functions. Users with this role can access data listings within the Data Exchange.

D . Users with import share privilege: This specific privilege is necessary for users who need to import shared data from the Data Exchange. This privilege allows them to request and access data listings explicitly shared with them.

In Snowflake, the authorization to execute CREATE <object> statements, such as creating tables, views, databases, etc., is determined by the role currently set as the user's primary role. The primary role of a user or session specifies the set of privileges (including creation privileges) that the user has. While users can have multiple roles, only the primary role is used to determine what objects the user can create unless explicitly specified in the session.

To upload data files from a local directory or folder on a client machine to an internal stage in Snowflake, the PUT command is used. The PUT command takes files from the local file system and uploads them to an internal Snowflake stage (or a specified stage) for the purpose of preparing the data to be loaded into Snowflake tables.

Syntax Example:

PUT file://<local_file_path> @<stage_name>;

This command is crucial for data ingestion workflows in Snowflake, especially when preparing to load data using the COPY INTO command.

The GET_PRESIGNED_URL file function in Snowflake provides a URL with access to a file on a stage without requiring authentication and authorization. This is particularly useful for sharing data files stored in Snowflake stages with external parties securely and conveniently. The presigned URL generated by this function gives temporary access to the file, which expires after a specified duration.

Example usage of GET_PRESIGNED_URL:

SELECT GET_PRESIGNED_URL('<stage_name>', '<file_path>');

This function generates a URL that can be used to directly access a file in the stage, making it easier to share data without compromising security.

Top of Form

Snowflake's governance features vary across different editions, but the OBJECT_DEPENDENCIES view is supported by all Snowflake editions. This feature is part of Snowflake's Information Schema and is designed to help users understand the dependencies between various objects in their Snowflake environment.

The OBJECT_DEPENDENCIES view provides a way to query and analyze the relationships and dependencies among different database objects, such as tables, views, and stored procedures. This is crucial for governance, as it allows administrators and data engineers to assess the impact of changes, understand object relationships, and ensure proper management of data assets.

Object tags, masking policies, and row access policies are more advanced features that offer fine-grained data governance capabilities such as tagging objects for classification, dynamically masking sensitive data based on user roles, and controlling row-level access to data. These features may have varying levels of support across different Snowflake editions, with some features being exclusive to higher-tier editions.