SnowPro Advanced: Security Engineer Question 387
Single answerDesign and deploy containerized services using Snowpark Container ServicesA security engineering team is deploying an internal tokenization API using Snowpark Container Services (SPCS). The service must read sensitive reference data from Snowflake tables, expose an HTTPS endpoint only to authenticated internal users, and follow least-privilege principles. The team wants to avoid embedding long-lived database credentials in the container image or application configuration. Which design choice best meets these requirements?
- A
Create the service to run with a dedicated service role, grant that role only the required privileges on the database objects, and expose the endpoint through an SPCS service that relies on Snowflake authentication and service access controls.
- B
Build the container image with a Snowflake user name and password stored as environment variables, then expose the service publicly over HTTPS because transport encryption is sufficient to protect access.
- C
Use a single ACCOUNTADMIN-owned service so the container can access any required table, and restrict access by allowing only the application team to pull the image from the repository.
- D
Store a key-pair for a powerful Snowflake service user inside the container filesystem at build time, then configure the application to connect with that user because key-pair authentication is more secure than passwords.
Show answer and explanation
Correct answer: A
Explanation
The best design is to use Snowpark Container Services with a dedicated service identity/role and grants scoped only to the objects the application must access. This aligns with Snowflake security best practices: avoid hard-coded secrets, use least privilege, and enforce authenticated access to service endpoints. For a Security Engineer, the key decision is separating three concerns correctly: runtime identity for the containerized workload, object privileges in Snowflake, and endpoint access controls for clients. Options that rely on embedded passwords or keys are weaker because they create long-lived secret exposure and operational burdens around rotation. Options that use highly privileged roles such as ACCOUNTADMIN violate least privilege and increase risk. Snowflake documentation on Snowpark Container Services, service roles, and service endpoint access patterns supports using Snowflake-native identity and access controls rather than static credentials inside containers.
- A. Correct.
Correct. In Snowpark Container Services, a service can run with a service role and use Snowflake-managed identity patterns rather than embedding static credentials in the container. Granting only the needed privileges to that role supports least privilege. For endpoint exposure, using Snowflake authentication and service access controls is the appropriate pattern for restricting access to authenticated internal users instead of making the endpoint broadly reachable.
- B. Incorrect.
Incorrect. Embedding credentials in environment variables inside the image or runtime configuration creates a secret-management and rotation problem and violates the requirement to avoid long-lived credentials. Exposing the service publicly just because HTTPS is enabled is also insufficient; TLS protects data in transit, not authorization. The misconception is treating encryption as a substitute for identity and access control.
- C. Incorrect.
Incorrect. Running the service under ACCOUNTADMIN ownership breaks least-privilege principles and greatly expands blast radius if the service is compromised. Restricting who can pull the image does not control who can invoke the running service or what data it can access in Snowflake. This distractor reflects a common confusion between image repository controls and runtime/data-access controls.
- D. Incorrect.
Incorrect. Although key-pair authentication can be stronger than passwords in some contexts, baking private keys into the container filesystem still introduces long-lived credential risk and makes rotation and incident response difficult. It also does not satisfy the requirement to avoid embedded credentials. The misconception is assuming a stronger credential type eliminates the security issue of storing credentials inside the container.