What you will be able to do
- Identify which controlled operations need an app specification and which Snowflake object backs each one
- Configure a network rule, external access integration and EXTERNAL_ACCESS app specification
- Walk through the consumer approval workflow, including sequence numbers and the privilege it requires
- Apply the security requirements for internet communication, secrets and authentication
1.App specifications: consumer-approved access beyond the account
Some app features need to reach outside the consumer's account: calling an external service, signing in to a third-party provider, sending data back to the provider or to other Snowflake accounts, talking to another installed app, or overriding a restricted setting. Each of these uses a specific Snowflake object. App specifications are how the consumer approves or declines each of these requests.
With automated granting of privileges, the setup script already has the privileges to create these objects. Because they open external connections or share data, the consumer still has to approve them. The result is that consumers do not have to create integrations, shares or listings by hand, and providers do not have to write code that checks for them at install time.
| Operation | Object | What it does |
|---|---|---|
| External endpoint access | External access integration | Uses network rules to restrict UDF or procedure access to specific external locations |
| Third-party authentication | Security integration | Secure access to providers such as OAuth |
| Cross-account data sharing | Shares and listings | Share data back to the provider or third-party Snowflake accounts |
| Inter-app communication | Connection (CONNECTION spec) | Connects to another installed app's server application roles |
| Restricted operations | SETTING spec | Permission to override settings such as account-level parameters |
Checkpoint 1 of 8· Check yourself
An app needs to send aggregated results back to the provider's Snowflake account. Which object, approved by the consumer through an app specification, makes this possible?
Sharing data with the provider or third-party Snowflake accounts goes through shares and listings. External access integrations are for network endpoints outside Snowflake.
“Allow apps to share data back to providers or third-party Snowflake accounts.”Source: docs.snowflake.com
Sources1
2.Building external network access
External access needs three objects, all created by the setup script. A network rule lists the endpoints. An external access integration (EAI) references the network rule. An EXTERNAL_ACCESS app specification asks the consumer to approve the endpoints. Before any of this works, the manifest must set manifest_version: 2, which turns on automated granting, and must request CREATE EXTERNAL ACCESS INTEGRATION. Snowflake then grants that privilege during install or upgrade.
The network rule uses TYPE = HOST_PORT and MODE = EGRESS. Its VALUE_LIST holds the allowed domains or ports. After the EAI exists, the setup script can create UDFs and procedures that name it in EXTERNAL_ACCESS_INTEGRATIONS and grant them to an application role. One app specification covers every EAI the app creates. The setup script's CREATE EXTERNAL ACCESS INTEGRATION command creates the EAI in the consumer account, which is why the consumer's approval decides whether it becomes usable.
ALTER APPLICATION SET SPECIFICATION eai_app_spec
TYPE = EXTERNAL_ACCESS
LABEL = 'Connection to an external API'
DESCRIPTION = 'Access an API that exists outside Snowflake'
HOST_PORTS = ('example.com')An EAI specification definition has two entries. HOST_PORTS lists the host ports from the network rule. PRIVATE_HOST_PORTS lists private host ports for private connectivity to resources outside Snowflake. The endpoints in the specification must match the network rule exactly. If the specification lists a port explicitly, such as example.com:443, the network rule must also include the port. If no port is given, it defaults to 443, but example.com and example.com:443 still do not count as the same value. A mismatch causes egress to fail. In the example above, both the specification and the network rule use plain example.com, so they match.
Checkpoint 2 of 8· Put it in order
Order the steps for setting up external access
- 1.Consumer reviews and approves the host ports
- 2.Setup script creates the external access integration
- 3.Set manifest_version: 2 and request CREATE EXTERNAL ACCESS INTEGRATION in the manifest
- 4.Setup script creates the network rule
- 5.Setup script creates the app specification
The privilege must be in place before the setup script runs. The EAI references the network rule, the specification asks for approval of the rule's endpoints, and the consumer approves last.
“create the following objects: Network rule External access integration App specification”Source: docs.snowflake.com
Sources2
3.The consumer approval workflow
Every app specification has a status. It starts as PENDING and becomes APPROVED or DECLINED. It also has a sequence number, which works like a version. Snowflake increments the number whenever the provider changes the definition, such as the hosts and ports. Editing fields outside the definition, such as the description, does not change it. A new sequence number tells the consumer there is something new to review.
Consumers list specifications with SHOW SPECIFICATIONS IN APPLICATION and read the details with DESC SPECIFICATION. They can then approve in two ways. In Snowsight, they open the app's Settings, then Connections, and approve or deny EXTERNAL_ACCESS endpoints. In SQL, they approve or decline a specific sequence number. SETTING specifications can only be approved through SQL.
Approval needs the MANAGE APPLICATION SPECIFICATIONS privilege on the account. SECURITYADMIN has it by default and can grant it to other roles. Owning the app is not enough.
App specifications are a separate request from the privileges an app lists in its manifest. Manifest privileges, such as CREATE EXTERNAL ACCESS INTEGRATION, let the app create objects. The specification is what approves the risky operation itself: approving it grants the app permission to perform a controlled operation. Each specification is an independent decision, so a consumer can approve some and decline others.
Checkpoint 3 of 8· Fill the gap
Complete the consumer's command
ALTER APPLICATION hello-snowflake-app ? SPECIFICATION
my-app-spec SEQUENCE_NUMBER = 2;ALTER APPLICATION … APPROVE SPECIFICATION approves one sequence number of the specification. DECLINE uses the same syntax.
Source: docs.snowflake.comCheckpoint 4 of 8· Check yourself
A data engineer installed an app with their own role, so that role owns it. When they try to approve its external access specification, they get an error. What is the most likely reason?
Approving a specification requires an account-level privilege, which SECURITYADMIN holds by default and can delegate. Owning the app does not include it.
“This privilege is granted by default to the SECURITYADMIN role.”Source: docs.snowflake.com
Checkpoint 5 of 8· Exam question
In the Native App Framework, when must a provider declare the privileges an app may request from a consumer?
Correct answer: A — All requestable privileges must be declared in the manifest file before the app can request them at runtime
- A. The manifest is the upfront declaration surface for requestable privileges, and consumers rely on it to review what the app can ask for before approving anything. This upfront declaration is what enables informed consumer review.
- B. Undeclared runtime privilege requests would bypass consumer visibility entirely, which contradicts the framework's transparency requirements. The manifest declaration must exist first.
- C. Privileges requested from consumers after installation, not just those used during setup, must also be declared in the manifest. Limiting declaration to setup-time needs would leave later requests undisclosed.
- D. A README is documentation, not an enforced declaration mechanism that Snowflake validates. The manifest file is the actual structured location Snowflake reads for privilege declarations.
4.Designing for declined or partial approval
Automated granting lets the app create these objects, but the consumer can still say no. A consumer might allow one of several requested ports, approve data sharing for some target accounts but not others, or reject an authentication integration altogether. The app must handle each of these cases cleanly and tell the consumer which features depend on which specifications.
Sometimes the app has to wait for a decision, for example to hold off API calls until external access is approved. For this, the manifest can name a callback procedure that runs whenever a specification is approved or declined. The procedure receives the name, the status and a payload. Streamlit apps can also use the Python Permission SDK: get_application_specifications() lists the specifications, and request_application_specification_review() opens an approval dialog.
lifecycle_callbacks:
specification_action: callbacks.on_spec_updateCheckpoint 6 of 8· Check yourself
An app requests two ports in its external access specification, and the consumer approves only one. What should the provider have designed for?
The documentation names partial port approval as a case the app must handle with error logic and clear feedback.
“When developing an app, you must account for situations where app specifications might not be approved.”Source: docs.snowflake.com
Sources1
5.Security requirements for APIs and internet traffic
Apps that go through automated security review must also meet the published security requirements. Several of them apply directly to external access:
- Disclosure. The listing must name every internet endpoint and URL the app connects to, every external function, and any consumer data the app logs, collects or stores. The manifest must list all API integrations. - Transport. All internet traffic should use HTTPS with a valid TLS certificate. - Secrets. Apps must not store or require plain-text customer secrets. For third-party authentication, the framework provides security integrations, such as OAuth, which the consumer approves through an app specification. - Authentication. Every connection to the app, including web UIs and APIs, must first authenticate through Snowflake. Any app-specific login comes after that, and the app should not create public endpoints that skip it. - Code provenance. The app must not load or run code from outside the application package, except Snowflake-provided libraries.
Data protection for shared content. Shared data is not exposed to consumers directly. The provider creates a view in the setup script and grants it to an application role. Snowflake recommends defining policies, such as row access or masking, on these proxy views. That way the policies cannot be changed after the app is installed, and running code keeps the policies applied when the version was created. Tables and views that already carry policies cannot themselves be shared, so the policy goes on the proxy view that exposes the data, not on the shared source. Policy functions such as CURRENT_USER can behave differently in the consumer account, so test policies there. Objects the app creates when installed belong to the app, and the framework redacts their implementation details from the consumer.
Checkpoint 7 of 8· Check yourself
An app must call a third-party API that needs a credential. Which design meets the security requirements?
Apps must not store or require plain-text customer secrets, and public endpoints must not bypass Snowflake authentication. Security integrations exist for third-party authentication.
“Apps must not store or require any plain text customer secrets.”Source: docs.snowflake.com
Checkpoint 8 of 8· Exam question
A provider wants to apply a data masking rule to a sensitive column that consumers should never see unmasked, regardless of which consumer account installs the app. Where should this boundary be enforced?
Correct answer: A — Inside the application package, using a secure view or masking policy owned by the provider
- A. Enforcing the masking inside objects the provider owns and ships as part of the package guarantees the rule applies consistently to every consumer, since the provider controls that boundary. This is the correct place to enforce a rule that must never depend on consumer configuration.
- B. Relying on each consumer to configure the same masking independently after install is fragile and inconsistent, and defeats the goal of a guaranteed, provider-controlled rule.
- C. The manifest declares requestable privileges, not the enforcement logic of a masking rule; a privilege grant alone does not implement or guarantee masking behavior.
- D. Delegating enforcement to the consumer's own administrative role means the provider loses control over whether the rule is actually applied, undermining the requirement that it always applies.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The role that owns the installed app can approve its app specifications.Why is that wrong?
Approval needs MANAGE APPLICATION SPECIFICATIONS on the account. SECURITYADMIN holds it by default and can delegate it.
Covered in The consumer approval workflow
2.example.com in the specification and example.com:443 in the network rule are the same endpoint, because 443 is the default.Why is that wrong?
The values must match exactly. A mismatch causes egress to fail.
Covered in Building external network access
3.An external function only has to be declared in the manifest. The listing does not need to mention it.Why is that wrong?
The listing must disclose every internet endpoint and every external function in the app.
Covered in Security requirements for APIs and internet traffic
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“However, because these objects enable external connections or data sharing, consumers must approve these operations when configuring the app.”
↩︎ App specifications: consumer-approved access beyond the account“A data sharing request might be declined or only partially approved for some target accounts but not others.”
↩︎ Designing for declined or partial approval“Allow secure access to third-party authentication providers such as OAuth.”
↩︎ Security requirements for APIs and internet traffic“Allow apps to share data back to providers or third-party Snowflake accounts.”
↩︎ Checkpoint“When developing an app, you must account for situations where app specifications might not be approved.”
↩︎ Checkpoint - 2.
“App specifications require that manifest_version: 2 be set in the manifest file.”
↩︎ Building external network access“PRIVATE_HOST_PORTS: A list of private host ports that allow private connectivity to resources outside Snowflake.”
↩︎ Building external network access“if the application specification lists a port explicitly (e.g. example.com:443), the network rule must also include the port.”
↩︎ Building external network access“This command creates an EAI in the consumer account.”
↩︎ Building external network access“When the port is omitted, it defaults to 443, so example.com and example.com:443 are not considered equivalent.”
↩︎ Exam trap 2“However, it is not usable until the consumer approves the app specifications that allow external access to the requested host ports.”
↩︎ Prediction“create the following objects: Network rule External access integration App specification”
↩︎ Checkpoint - 3.
“Sequence numbers are automatically incremented when a provider changes the definition of the app specification.”
↩︎ The consumer approval workflow“To approve a SETTING app specification, use SQL.”
↩︎ The consumer approval workflow“Approving an app specification grants an app permission to perform a controlled operation”
↩︎ The consumer approval workflow“To approve or decline an app specification, a role must have the MANAGE APPLICATION SPECIFICATIONS privilege on the account.”
↩︎ Exam trap 1“This privilege is granted by default to the SECURITYADMIN role.”
↩︎ Checkpoint - 4.
“You can approve none, some, or all of an app’s App Specs. Each is an independent decision.”
↩︎ The consumer approval workflow - 5.
“Any communication between the app and the Internet should be over an HTTPS connection with a valid TLS certificate.”
↩︎ Security requirements for APIs and internet traffic“All Internet endpoints and URLs that the app connects to. All external functions in the app.”
↩︎ Exam trap 3“Apps must not store or require any plain text customer secrets.”
↩︎ Checkpoint - 6.
“Defining policies on the proxy views ensures that the definition of the policies cannot be changed after an app is installed.”
↩︎ Security requirements for APIs and internet traffic - 7.
“Tables with defined policies (row access, masking, tag based, etc.) cannot be shared.”
↩︎ Security requirements for APIs and internet traffic