COF-C03 Question 250
Single answerGit integrationA data engineering team stores Snowflake SQL scripts and Streamlit app files in a Git repository. They want developers to work with repository contents directly from Snowflake so they can browse branches, fetch updates, and execute SQL files from a controlled copy inside Snowflake. A developer creates a Git repository clone object, but after new commits are pushed to the remote repository, the changes do not appear in Snowflake. What should the team do to make the latest remote commits available in the Snowflake clone object?
- A
Run ALTER GIT REPOSITORY ... FETCH to synchronize the Snowflake clone with the remote repository
- B
Run ALTER STAGE ... REFRESH because Git repository clones are refreshed the same way as external stages
- C
Recreate the Git repository clone each time new commits are pushed to the remote repository
- D
Run MERGE on the target schema so Snowflake can merge the remote branch into the local clone object
Show answer and explanation
Correct answer: A
Explanation
Snowflake Git integration allows users to work with repository contents from within Snowflake by creating a Git repository clone object that references a remote repository. However, that clone does not automatically reflect later remote commits. To bring in new branches, tags, and commits, users must explicitly fetch updates. In practice, this means using the Git repository management command supported by Snowflake, such as ALTER GIT REPOSITORY ... FETCH. This aligns with Snowflake documentation on repository clones and Git operations, where fetching is the required step to synchronize the Snowflake-side clone with the remote source. The other options misuse commands for unrelated object types or SQL operations.
- A. Correct.
Correct. A Git repository clone in Snowflake is not automatically updated whenever commits are pushed to the remote repository. To make newly pushed commits, branches, and tags available in Snowflake, the team must fetch from the remote repository by using the appropriate Git repository command, such as ALTER GIT REPOSITORY ... FETCH. This is the normal operational step for synchronizing the Snowflake clone object with the remote source.
- B. Incorrect.
Incorrect. ALTER STAGE ... REFRESH applies to stage metadata scenarios, such as refreshing file listings for certain staged data workflows. A Git repository clone is a different object type with its own commands and behavior. Confusing Git repository synchronization with stage refresh is a common misconception because both involve external content, but Git integration uses fetch operations rather than stage refresh.
- C. Incorrect.
Incorrect. Recreating the Git repository clone is unnecessary and operationally inefficient. Snowflake provides a fetch mechanism specifically so an existing clone object can be synchronized with the remote repository. Recreating the object each time would complicate permissions, automation, and references to the repository.
- D. Incorrect.
Incorrect. MERGE is a SQL DML command for combining rows in tables based on matching conditions. It has nothing to do with synchronizing a Snowflake Git repository clone with a remote Git provider. This distractor targets candidates who associate the word 'merge' with Git concepts, but Git repository synchronization in Snowflake is done through Git repository commands, not SQL table operations.