What you will be able to do
- Explain how services, service instances, containers and compute pool nodes relate, and what that means for isolation
- List the privileges a role needs to create a service, including the one needed for public endpoints
- Describe how a running container authenticates to Snowflake and why its OAuth token cannot leave Snowpark Container Services
- Reason about the security effects of service lifecycle events such as restarts, job completion and lost privileges
Key concept
Service owner role — A service runs with the privileges of the role that owns it. That role needs grants on the compute pool, the image repository, the specification stage and any secrets. Endpoints and public exposure depend on those grants continuing to exist, not only on what was granted when the service was created.
1.Compute pools, nodes and where containers land
Snowpark Container Services (SPCS) has three parts. An image repository in your account stores OCI images. A compute pool provides the machines. A service runs your images on those machines. A compute pool is a collection of virtual machine nodes. When you create a service, you name the pool it runs in, and Snowflake decides which nodes it uses. Note that a pool is not dedicated to one workload. In Snowflake's own architecture example, one node runs two instances of service A plus a job, and a second node runs the third instance of service A next to an instance of service B.
Placement matters for security. The containers in one instance are not isolated from each other at the network level: Snowflake runs them on a single node, and they share that node's network interface. A sidecar can therefore reach anything the main container listens on. Different services in the same pool can also share a node. The sources do not describe any isolation guarantee between services that share a node beyond that. The design lever they do give you is the pool itself: which pool a service runs in, and who has USAGE on that pool to place workloads there. The account usage data also separates out pools that Snowflake created for an application. Its IS_EXCLUSIVE column is TRUE for those pools.
Checkpoint 1 of 5· Check yourself
Why should two containers declared in the same service specification be treated as one trust zone?
Containers of one instance are co-located on one node and share its network interface, so network separation does not apply between them.
“When you create a service, Snowflake runs these containers on a single node in the specified compute pool, sharing the same network interface.”Source: docs.snowflake.com
2.Privileges needed to deploy a service
To create a service you need a name, a YAML specification and a compute pool. Each of these maps to a grant. CREATE SERVICE is a schema privilege, and running the service in a pool requires USAGE on that pool. The role also needs READ on the image repository the specification points to and, if the specification is on a stage, READ on that stage. Public endpoints add an account-level privilege on top.
| Privilege | Object | Why it is needed |
|---|---|---|
| CREATE SERVICE | Schema | The service is a schema-level object |
| USAGE | Compute pool | Lets the role run the service in that pool |
| READ | Stage | The stage where the specification is stored |
| READ | Image repository | Repository of images referenced by the specification |
| BIND SERVICE ENDPOINT | Account | Required only to create a service with public endpoints |
BIND SERVICE ENDPOINT is checked on an ongoing basis. If the owner role later loses it, the public endpoints stop being accessible. Revoking that grant is therefore a quick way to take a service off the internet while it keeps running. As with any schema object, the role also needs at least one privilege on the parent database and on the parent schema.
Checkpoint 2 of 5· Exam question
A service running in a compute pool must call https://api.partner.example.com:443 to enrich records, but outbound calls fail with connection errors. Security wants egress limited to that single host. What should the administrator do?
Correct answer: A — Create an EGRESS HOST_PORT network rule for api.partner.example.com:443, wrap it in an external access integration, and list it in the service's EXTERNAL_ACCESS_INTEGRATIONS.
- A. Correct: services have no outbound access by default, and egress is opened by an EGRESS HOST_PORT network rule packaged in an external access integration that CREATE SERVICE references. This limits calls to the single named host and port.
- B. Incorrect: account-level network policies govern inbound client connections to Snowflake, not outbound traffic from containers. Restarting the service does not change that.
- C. Incorrect: egress rules use MODE = EGRESS, not INGRESS, and network rules are not attached to compute pools. Egress is bound per service through the integration.
- D. Incorrect: the specification YAML has no allowedHosts field, and a network rule alone does nothing until it is placed inside an external access integration referenced by the service.
Checkpoint 3 of 5· Check yourself
A service was created with a public endpoint. Later, an administrator revokes BIND SERVICE ENDPOINT from the service's owner role. What happens?
Public endpoints depend on the owner role continuing to hold BIND SERVICE ENDPOINT. Without it, they can no longer be reached.
“If the service’s owner role loses this privilege, the public endpoints will not be accessible.”Source: docs.snowflake.com
Sources3
3.How a container reaches Snowflake data
Your container code does not need a stored password to query Snowflake. When a service or job service starts, Snowflake places an OAuth token in each application container and sets SNOWFLAKE_ACCOUNT and SNOWFLAKE_HOST. The code uses all three to authenticate as the service user. The token cannot be used outside SPCS, and it only works together with SNOWFLAKE_HOST. A token copied out of a container therefore does not work as a credential anywhere else.
What the service user can read is decided by roles. The connection runs as the service, so grant the owner role only the data the service needs. If the application should act with the end user's privileges instead, the specification's capabilities.securityContext.executeAsCaller flag declares that it intends to use caller's rights. Endpoint access is controlled separately: a service role lists endpoints, and you grant that service role to the users or roles that should call them.
Checkpoint 4 of 5· Check yourself
Container code reads /snowflake/session/token and an attacker copies the token to a laptop. What do the sources say about this token?
The OAuth token that Snowflake provides is limited to SPCS and must be used together with SNOWFLAKE_HOST.
“This OAuth token can’t be used outside Snowpark Container Services.”Source: docs.snowflake.com
4.Lifecycle: long-running services, jobs and change control
There are two kinds of service, and they behave differently. A long-running service does not end on its own. If a container stops for any reason, Snowflake restarts it. A crashing or compromised process therefore comes back. To actually stop the workload you have to act on the service, with ALTER SERVICE or DROP SERVICE. A job service, started with EXECUTE JOB SERVICE, ends when all its containers exit. With REPLICAS, any failed instance makes the whole job FAILED. A job stopped with SYSTEM$CANCEL_JOB moves through CANCELLING to CANCELLED.
CREATE SERVICE echo_service IN COMPUTE POOL tutorial_compute_pool FROM @tutorial_stage SPECIFICATION_FILE='echo_spec.yaml';Snowflake recommends keeping production specifications on a stage, applying separation of concerns. Only roles with READ on that stage can supply or change the specification. Specification templates let one reviewed file be deployed several times with different values through USING. Variables such as {{ tag_name }} pin the image tag for each service. Lifecycle state also affects cost: a pool is billed in IDLE, ACTIVE, STOPPING or RESIZING, and AUTO_SUSPEND is the recommended control.
Checkpoint 5 of 5· Check yourself
A container in a long-running service is killed during incident response. What happens next if nobody acts on the service?
Snowflake manages long-running services and restarts containers that stop. Containment needs an ALTER SERVICE or DROP SERVICE.
“if a service container stops, for whatever reason, Snowflake restarts that container so the service runs uninterrupted.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.BIND SERVICE ENDPOINT is needed for every service, including services with only private endpoints.Why is that wrong?
It is an account-level privilege needed only for public endpoints. A service with private endpoints needs CREATE SERVICE on the schema and USAGE on the compute pool, plus READ on the image repository and specification stage.
Covered in Privileges needed to deploy a service
2.Stopping a misbehaving container in a long-running service takes it offline.Why is that wrong?
Snowflake restarts stopped containers in long-running services. To contain the service you have to alter or drop it.
Covered in Lifecycle: long-running services, jobs and change control
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.snowflake.com/en/developer-guide/snowpark-container-services/working-with-servicesOfficial docs
“A service represents Snowflake running your containerized application on a compute pool, which is a collection of virtual machine (VM) nodes.”
↩︎ Compute pools, nodes and where containers land“A job service terminates when your code exits, similar to a stored procedure.”
↩︎ Lifecycle: long-running services, jobs and change control“apply the separation of concerns design principle and upload the specification to a stage”
↩︎ Lifecycle: long-running services, jobs and change control“if a service container stops, for whatever reason, Snowflake restarts that container so the service runs uninterrupted.”
↩︎ Exam trap 2“all containers within a single service instance always run on the same compute pool node.”
↩︎ Prediction“if a service container stops, for whatever reason, Snowflake restarts that container so the service runs uninterrupted.”
↩︎ Checkpoint - 2.https://docs.snowflake.com/en/sql-reference/account-usage/snowpark_container_services_historyOfficial docs
“TRUE, if the compute pool was created for an application.”
↩︎ Compute pools, nodes and where containers land - 3.
“A role used to execute this operation must have the following privileges at a minimum:”
↩︎ Privileges needed to deploy a service“If the service’s owner role loses this privilege, the public endpoints will not be accessible.”
↩︎ Key concept“A role must have this privilege to create a service with public endpoints.”
↩︎ Exam trap 1“If the service’s owner role loses this privilege, the public endpoints will not be accessible.”
↩︎ Checkpoint - 4.https://docs.snowflake.com/en/developer-guide/snowpark-container-services/spcs-execute-sqlOfficial docs
“Provides credentials (an OAuth token) in the container in a file that is named /snowflake/session/token.”
↩︎ How a container reaches Snowflake data“The OAuth token can’t be used without also using SNOWFLAKE_HOST.”
↩︎ How a container reaches Snowflake data“This OAuth token can’t be used outside Snowpark Container Services.”
↩︎ Checkpoint - 5.https://docs.snowflake.com/en/developer-guide/snowpark-container-services/specification-referenceOfficial docs
“indicates whether application intends to use caller's rights”
↩︎ How a container reaches Snowflake data“The service role is the mechanism you use to manage privileges to endpoints the service exposes.”
↩︎ How a container reaches Snowflake data“When you create a service, Snowflake runs these containers on a single node in the specified compute pool, sharing the same network interface.”
↩︎ Checkpoint - 6.https://docs.snowflake.com/en/developer-guide/snowpark-container-services/accounts-orgs-usage-viewsOfficial docs
“To optimize compute pool expenses, you should leverage the AUTO_SUSPEND feature”
↩︎ Lifecycle: long-running services, jobs and change control