What you will be able to do
- Enable and verify private connectivity to the Snowflake service on AWS, Azure and Google Cloud
- Configure private endpoints for internal stages on AWS and Azure, including the Snowflake parameter, authorization calls and DNS changes
- Choose the network rules that can and cannot restrict internal stage access on each cloud
- Identify the authentication methods and network policy requirements that apply to Snowflake SQL API requests
1.Private connectivity to the Snowflake service
Traffic to Snowflake can go over the public internet or through a private IP address on the cloud platform that hosts your account. Private connectivity routes traffic from your VPC or VNet to Snowflake's VPC or VNet. The service you use depends on the host cloud: AWS PrivateLink, Azure Private Link or Google Cloud Private Service Connect. The same approach covers more than the core service, including Snowsight, Streamlit in Snowflake, internal stages, Snowflake-managed storage volumes and Snowpark Container Services. It applies only to inbound traffic, from your network into Snowflake.
On AWS, enabling private connectivity takes three steps:
1. Generate a federated token with aws sts get-federation-token. The token expires after 12 hours, so if a later call fails, generate a new one.
2. As ACCOUNTADMIN, call SYSTEM$AUTHORIZE_PRIVATELINK with your 12-digit AWS account ID and the token. Verify with SYSTEM$GET_PRIVATELINK using the same arguments, and disable with SYSTEM$REVOKE_PRIVATELINK.
3. Call SYSTEM$GET_PRIVATELINK_CONFIG, record its privatelink-vpce-id value, and create your VPC endpoint against it. Then allow your security group to reach ports 443 and 80 of the VPCE CIDR.
The service endpoint can be in a different AWS region from your VPC if you choose Enable Cross Region endpoint. Cross-region connectivity is not supported for PaaS services such as Amazon S3, which matters for stages, covered in the next section. Snowflake also recommends pinning private endpoints. You remain responsible for your own VPC endpoints, security group rules and DNS records.
| Cloud | Private connectivity service | Arguments | Credential source |
|---|---|---|---|
| AWS | AWS PrivateLink | '<aws_id>' , '<federated_token>' | aws sts get-federation-token --name sam |
| Azure | Azure Private Link | '<private-endpoint-resource-id>' , '<federated_token>' | az account get-access-token --subscription <SubscriptionID> |
| GCP | Google Cloud Private Service Connect | '<gcp_project_id>' , '<access_token>' | Access token for a Google Cloud user |
Once private connectivity works, you can restrict who uses it with ingress rules of type AWSVPCEID, AZURELINKID or GCPPSCID in a network policy. Those rules restrict the service only, not the stage.
Checkpoint 1 of 8· Check yourself
A SYSADMIN user calls SYSTEM$AUTHORIZE_PRIVATELINK with a federated token generated the previous day, and the call fails. Which TWO problems does the documentation point to? Choose the option that names both.
Only ACCOUNTADMIN can run the authorize, verify and revoke functions. The federated token is valid for 12 hours, so a day-old token has to be regenerated.
“Only account administrators (i.e. users with the ACCOUNTADMIN role) can execute this function.”Source: docs.snowflake.com
Checkpoint 2 of 8· Exam question
An account has a network policy that allows only `203.0.113.0/24`, set with `ALTER ACCOUNT SET NETWORK_POLICY`. The service user `SVC_ETL` has its own user-level policy that allows only `198.51.100.0/24`. A job connects as `SVC_ETL` from `203.0.113.15`. What happens?
Correct answer: A — The login is rejected, because only the user-level policy is evaluated for SVC_ETL and `203.0.113.15` is outside its allowed range.
- A. Correct. A user-level network policy replaces the account-level policy for that user; the two are never merged, so the source IP is judged only against the user's allowed range.
- B. Incorrect. Snowflake does not take the union of the policies. When a user policy exists, the account policy is not consulted for that user at all.
- C. Incorrect. Precedence runs the other way: the user-level policy is the most specific and takes priority over the security integration and account levels.
- D. Incorrect. Intersection logic is not how Snowflake evaluates policies. Only one policy applies to a given user, so a connection never has to satisfy both.
2.Private endpoints for internal stages on AWS and Azure
An internal stage lives in cloud storage, so it needs its own endpoint, separate from the service endpoint. With a stage endpoint, loading and unloading data stay on the cloud provider's internal network, and you no longer need the proxy farm that was used before. On both AWS and Azure, the account administrator first turns on the feature and reads the stage details from the privatelink_internal_stage key:
USE ROLE ACCOUNTADMIN; ALTER ACCOUNT SET ENABLE_INTERNAL_STAGES_PRIVATELINK = true; select key, value from table(flatten(input=>parse_json(system$get_privatelink_config())));AWS. A deployment has a single S3 bucket for internal stages, and each account's data sits under its own prefix. You combine a VPC interface endpoint with AWS PrivateLink for S3, which is an AWS service you must enable yourself. Because S3 doesn't support cross-region interface endpoints, the endpoint must be in the same region as your Snowflake account. In SnowGov regions, PrivateLink for S3 doesn't support FIPS endpoints. The setup involves three people: the Snowflake ACCOUNTADMIN, the AWS administrator and the network administrator.
1. The AWS administrator creates the S3 endpoint and records its VPCE DNS name, replacing the leading * with the bucket name.
2. The network administrator maps <bucket_name>.s3.<region>.amazonaws.com to that name, without using wildcards.
3. You run dig from a client to confirm that the bucket resolves to a private IP.
If you need the stages of several accounts, use dedicated interface endpoints, one per stage.
Azure. Each Snowflake account has its own storage account as its internal stage. The private address adds a privatelink segment: <storage_account_name>.privatelink.blob.core.windows.net. A single private endpoint talks to a single Snowflake service endpoint, and the number of endpoints per storage account has a fixed maximum. To check which endpoints are authorized and their approval status, call SYSTEM$GET_STAGE_PRIVATELINK_AUTHORIZED_ENDPOINTS. When the first endpoint is authorized, Azure adds a public CNAME record. If you already have private DNS zones for .privatelink.blob.core.windows.net, Microsoft recommends enabling Fallback to Internet before that first authorization.
Checkpoint 3 of 8· Put it in order
Put the Azure internal-stage private endpoint setup in order
- 1.Update the private DNS zone so the privatelink blob URL resolves to the endpoint's private IP
- 2.As ACCOUNTADMIN, set ENABLE_INTERNAL_STAGES_PRIVATELINK and record the privatelink_internal_stage ResourceID
- 3.Verify the Azure subscription is registered with the Azure Storage resource manager
- 4.Call SYSTEM$AUTHORIZE_STAGE_PRIVATELINK_ACCESS with the private endpoint resource ID
- 5.Create the private endpoint with Target sub-resource blob and record its resource ID
The authorization call needs the endpoint's resource ID, so the endpoint must exist first. DNS changes come last, once the endpoint has been authorized.
“You will provide this value as the privateEndpointResourceID function argument in the next step.”Source: docs.snowflake.com
Checkpoint 4 of 8· Fill the gap
Which function authorizes an Azure private endpoint to reach the internal stage?
USE ROLE ACCOUNTADMIN; SELECT ? ('<privateEndpointResourceID>');SYSTEM$AUTHORIZE_PRIVATELINK enables private connectivity to the service. SYSTEM$GET_STAGE_PRIVATELINK_AUTHORIZED_ENDPOINTS only lists endpoints that are already authorized.
Source: docs.snowflake.comCheckpoint 5 of 8· Exam question
A security engineer must maintain a network rule `corp_ips` that is referenced by several network policies. The office added a new CIDR block and dropped an old one. Select TWO statements that correctly describe how to update the rule.(Select 2)
Correct answers: A, C — Run `ALTER NETWORK RULE corp_ips SET VALUE_LIST = (...)` with the full new list, because the statement replaces every existing value.; Policies that reference the rule pick up the new values automatically, so no policy needs to be recreated or reattached.
- A. Correct. `SET VALUE_LIST` overwrites the whole list, so the engineer must supply every CIDR that should remain, not only the new one.
- B. Incorrect. ALTER NETWORK RULE has no ADD VALUE_LIST clause; values are changed by resetting the full list with SET.
- C. Correct. A network policy stores a reference to the rule, not a copy, so a change to the rule takes effect for every policy that uses it.
- D. Incorrect. The TYPE and MODE of a network rule are fixed at creation, and a rule of one type cannot be switched to another to accept different value formats.
- E. Incorrect. Reattaching is not needed; the account policy reads the current rule definition, so the new CIDR list applies without repeating the ALTER ACCOUNT statement.
3.Locking down internal stage access with network rules
A private stage endpoint gives you a private path, but it doesn't close the public one. How you restrict the stage depends on the cloud.
On AWS, the account administrator first enables ENFORCE_NETWORK_RULES_FOR_INTERNAL_STAGES. After that:
- An INGRESS rule of type IPV4 protects both the service and the stage. - To restrict the stage by VPCE ID, you need a separate rule with MODE = INTERNAL_STAGE and TYPE = AWSVPCEID. This rule restricts the stage without restricting the service. - INGRESS rules of type IPV6, AWSVPCEID, AZURELINKID or GCPPSCID never protect the stage.
Snowflake-managed storage volumes work the same way, using the SNOWFLAKE_MANAGED_STORAGE_VOLUME mode and its own enforcement parameter.
On Azure, no network rule can restrict the internal stage. What you can do, if you use Azure Private Link, is block all public access to it. On every cloud, a network policy activated for a security integration does not restrict the internal stage.
Checkpoint 6 of 8· Match them up
Match each configuration to its effect on internal stage access
Tap a term, then the definition that fits it.
Only IPV4 INGRESS rules with the enforcement parameter, or INTERNAL_STAGE rules, reach an AWS stage. Endpoint-ID ingress rules and security-integration policies stop at the service.
“Controls access to an AWS internal stage without restricting access to the Snowflake service.”Source: docs.snowflake.com
Sources5
4.Securing Snowflake SQL API calls
Every request to the Snowflake SQL API must carry authentication information. The documented methods are OAuth, key-pair authentication and workload identity federation.
With OAuth, each request sends Authorization: Bearer <oauth_token>. You can also set the optional X-Snowflake-Authorization-Token-Type header to KEYPAIR_JWT, OAUTH or PROGRAMMATIC_ACCESS_TOKEN. If you leave it out, Snowflake works out the token type from the token itself.
Programmatic access tokens (PATs) can also authenticate to the SQL API. This is where network controls apply directly. By default, a user can only generate or use a PAT if a network policy with one or more network rules applies to them. For service users (TYPE=SERVICE or TYPE=LEGACY_SERVICE) this is a hard requirement, which limits the token to known addresses or endpoints. The policy that counts is decided by the same account, user and security integration precedence as for any other connection.
The sources for this lesson cover only SQL API authentication and the PAT network policy requirement. They describe no other SQL API-specific controls, so don't assume any beyond these.
Checkpoint 7 of 8· Check yourself
An application authenticates to the SQL API as a TYPE=SERVICE user with a programmatic access token. Neither the user nor the account has a network policy. What happens?
A service user can only generate or use a PAT when a network policy applies to them. The token type header is optional and doesn't affect this.
“you can only generate or use a token if the user is subject to a network policy.”Source: docs.snowflake.com
Checkpoint 8 of 8· Exam question
A contractor works from `10.20.30.40`, inside the `10.0.0.0/8` range that the company's account-level network policy allows through `ALLOWED_NETWORK_RULE_LIST`. The company needs to deny that single address without shrinking the allowed range. What is the most appropriate change?
Correct answer: C — Add a rule for `10.20.30.40` to `BLOCKED_NETWORK_RULE_LIST` of the same policy, since a blocked match wins over an allowed match.
- A. Incorrect. Splitting a range around one address is brittle and hard to maintain, and Snowflake already offers a blocked list that makes this unnecessary.
- B. Incorrect. User-level policies do not provide the only means of denying an address, and creating one per user duplicates work the account policy can do directly.
- C. Correct. When an address matches both lists in one policy, the blocked list takes precedence, so the allowed range stays intact and the single address is denied.
- D. Incorrect. The COMMENT property is documentation only and has no effect on which connections the policy admits or denies.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.On Azure, you can restrict internal stage access with an AZURELINKID network rule.Why is that wrong?
No network rule can restrict an internal stage on Azure. With Azure Private Link you can block all public access to the stage instead.
Covered in Locking down internal stage access with network rules
2.A network policy on a security integration also protects the account's internal stage.Why is that wrong?
Security-integration policies stop at the service. To protect an AWS stage, use account- or user-level rules together with the stage enforcement parameter.
Covered in Locking down internal stage access with network rules
3.Because PrivateLink to the service can be cross-region, the S3 endpoint for the internal stage can be in another region too.Why is that wrong?
S3 interface endpoints can't be cross-region, so the stage endpoint must be in the same region as the Snowflake account.
Covered in Private endpoints for internal stages on AWS and Azure
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“These connections use AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect.”
↩︎ Private connectivity to the Snowflake service - 2.
“The federated token expires after 12 hours.”
↩︎ Private connectivity to the Snowflake service“Cross-region connectivity isn’t currently supported for any platform as a service (PaaS) services, such as Amazon Simple Storage Service (Amazon S3)”
↩︎ Private connectivity to the Snowflake service“Snowflake isn’t responsible for the actual configuration of the required AWS VPC endpoints, security group rules, and Domain Name System (DNS) records.”
↩︎ Private connectivity to the Snowflake service - 3.
“There is a single Amazon S3 bucket per internal stage deployment.”
↩︎ Private endpoints for internal stages on AWS and Azure“Do not use wildcard characters (i.e. *) with DNS mapping because of the possible impact of accessing other Amazon S3 buckets outside of Snowflake.”
↩︎ Private endpoints for internal stages on AWS and Azure“your VPC interface endpoint must be located in the same region as your Snowflake account”
↩︎ Exam trap 3 - 4.
“In Azure, each Snowflake account has a dedicated storage account to use as an internal stage.”
↩︎ Private endpoints for internal stages on AWS and Azure“Microsoft recommends enabling the Fallback to Internet option in the private DNS zone configuration before authorizing the first private endpoint.”
↩︎ Private endpoints for internal stages on AWS and Azure“You will provide this value as the privateEndpointResourceID function argument in the next step.”
↩︎ Checkpoint - 5.
“The TYPE property of the network rule must be AWSVPCEID.”
↩︎ Locking down internal stage access with network rules“If TYPE=AWSVPCEID, TYPE=AZURELINKID, or TYPE=GCPPSCID, then the network rule controls access to the Snowflake service only.”
↩︎ Locking down internal stage access with network rules“Controls access to an AWS internal stage without restricting access to the Snowflake service.”
↩︎ Checkpoint - 6.
“When you send a request, the request must include authentication information.”
↩︎ Securing Snowflake SQL API calls“If you omit the X-Snowflake-Authorization-Token-Type header, Snowflake determines the token type by examining the token.”
↩︎ Securing Snowflake SQL API calls - 7.
“By default, the user must be subject to a network policy with one or more network rules to generate or use programmatic access tokens”
↩︎ Securing Snowflake SQL API calls“you can only generate or use a token if the user is subject to a network policy.”
↩︎ Checkpoint
Also cited
“You cannot use a network rule to restrict access to an internal stage on Microsoft Azure.”
↩︎ Exam trap 1“A network policy that is activated for a security integration does not restrict access to an internal stage.”
↩︎ Exam trap 2“Only account administrators (i.e. users with the ACCOUNTADMIN role) can execute this function.”
↩︎ Checkpoint