SnowPro Advanced: Security Engineer Question 388
Select 3Understand the security model of compute pools (for example, isolation and network rules for inbound/outbound data)A security engineer is reviewing a Snowflake deployment that uses Snowpark Container Services. A development team wants to run a containerized inference service in a compute pool. The service must do two things: (1) accept HTTPS requests from approved corporate clients, and (2) call an external model registry on the internet to download signed model artifacts. The engineer must enforce least privilege and ensure traffic is explicitly controlled. Which TWO actions should the engineer take to meet these requirements?
- A
Create an ingress configuration that exposes the service endpoint only for the required inbound HTTPS access path, and separately configure outbound network rules/external access so the containers can reach only the approved external model registry.
- B
Rely on the compute pool definition alone, because compute pools automatically permit necessary inbound and outbound traffic for services running inside them once the pool is started.
- C
Configure a network rule for the approved external model registry and use the appropriate external access integration so egress from the service is limited to that destination instead of allowing unrestricted outbound internet access.
- D
Grant the service owner role broad ACCOUNTADMIN privileges so the service can bypass network restrictions when it needs to download model artifacts.
- E
Place the service in a dedicated compute pool to strengthen workload isolation, but still explicitly define the required ingress and egress controls because isolation by itself does not replace network policy configuration.
Show answer and explanation
Correct answers: A, C, E
Explanation
The best answer is to combine explicit inbound exposure for the service with explicit outbound restrictions for external access, while understanding that compute-pool isolation is helpful but not sufficient on its own. In Snowpark Container Services, a compute pool provides isolated compute resources for services and jobs, but network access must still be intentionally configured. Inbound traffic to a service is controlled through the service exposure/ingress configuration, while outbound access to external destinations is governed through Snowflake external access features, including network rules and external access integrations. Following Snowflake security best practices, engineers should avoid assuming that creating a compute pool or granting elevated roles implicitly opens network paths. They should also avoid unrestricted egress when a specific external destination, such as a model registry, can be allowlisted. This aligns with least privilege and defense-in-depth principles described in Snowflake documentation for Snowpark Container Services, service networking, and external network access.
- A. Correct.
Correct. In Snowpark Container Services, inbound access to a service is not something you should leave implicit. The service should be exposed through the intended ingress mechanism for HTTPS clients, and outbound access should be separately controlled using Snowflake's external access model. This reflects the fact that inbound and outbound paths are distinct security concerns: exposing a service endpoint does not automatically authorize arbitrary egress, and permitting egress does not by itself publish an inbound endpoint.
- B. Incorrect.
Incorrect. A compute pool provides the infrastructure on which services and jobs run, but it does not automatically open or broadly allow inbound and outbound connectivity just because the pool exists or is running. This option reflects a common misconception that compute pools behave like generic container platforms with default open networking. In practice, network access must be deliberately configured.
- C. Correct.
Correct. Outbound connectivity from code running in Snowflake should be explicitly constrained using network rules and an external access integration. This is the least-privilege approach for allowing the containerized service to reach only the approved model registry. It avoids the insecure assumption that services in a compute pool should have unrestricted internet egress.
- D. Incorrect.
Incorrect. Privileges such as ACCOUNTADMIN do not function as a workaround for network security controls. Administrative privileges govern object management and account-level administration, not bypassing service network restrictions. This distractor targets the misconception that broader RBAC permissions can override the compute pool and service networking model.
- E. Correct.
Correct. Dedicated compute pools can improve operational and security isolation between workloads, which can be an appropriate design choice for sensitive services. However, isolation at the compute-pool level does not itself define allowed inbound endpoints or outbound destinations. Explicit ingress and egress configuration is still required to satisfy least-privilege networking requirements.