An Architect wants to integrate Snowflake with a Git repository that requires authentication.

This question tests Snowflake’s native Git integration setup pattern, which relies on Snowflake security objects to authenticate outbound access to an external Git provider. The correct sequence begins with creating an API integration because it defines and authorizes the external endpoint(s) Snowflake is allowed to communicate with. In Snowflake, integrations are the governance layer for external connectivity—administrators explicitly allow network destinations and control whether the integration is enabled, which is foundational before any credential object can be used.

Next, the Architect creates a secret to securely store the authentication material required by the Git provider (for example, a token or other supported credential). Secrets are designed for securely managing sensitive values and are referenced by other Snowflake objects without exposing the credential in plain text in SQL or configuration.

Finally, the Architect creates the Snowflake Git repository stage, which is the object that actually references the Git repo location and uses the configured integration and secret to authenticate and interact with the repository. Creating the stage last ensures all required prerequisites (allowed connectivity + stored credentials) exist and can be bound to the stage cleanly, aligning with Snowflake’s documented dependency model for external integrations.