SnowPro Advanced: Security Engineer Question 393
Single answerImplement secure data access patterns for services running in Snowpark Container Services:A security engineering team is deploying an inference API in Snowpark Container Services (SPCS). The service must read sensitive customer features from Snowflake tables and write prediction results back to a separate schema. The team wants to avoid embedding long-lived credentials in the container image, ensure the service can access only the required objects, and make authorization auditable through standard Snowflake role-based controls. Which approach best meets these requirements?
- A
Run the service with a service role that is granted only the necessary privileges on the source and target objects, and have the containerized application use the Snowpark Container Services runtime identity to obtain scoped access to Snowflake.
- B
Store a Snowflake username and password in the container image, connect with the ACCOUNTADMIN role, and restrict access in application code so only approved SQL statements are issued.
- C
Generate a key pair for a powerful Snowflake user, bake the private key into the image, and rotate the image periodically to reduce credential exposure.
- D
Expose the required tables through a public endpoint and let the service retrieve data over HTTPS so Snowflake object privileges are not needed.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the Snowpark Container Services service identity model together with a least-privileged service role. This aligns with Snowflake security principles: avoid hard-coded secrets, use Snowflake RBAC for authorization, and grant only the privileges the workload needs on specific objects. In practice, the service should be configured so the application accesses Snowflake using the runtime's integrated identity rather than stored credentials. The role granted to the service should include only the minimum required privileges, such as USAGE on the database and schemas and SELECT/INSERT on the necessary tables, depending on the workload. This approach improves auditability because access is enforced and logged through standard Snowflake controls. These recommendations are consistent with Snowflake documentation and best practices for Snowpark Container Services, service roles, and least-privilege access design.
- A. Correct.
Correct. For services running in SPCS, the secure pattern is to use Snowflake-managed identity and RBAC rather than embedding credentials. Assigning an appropriate service role with least-privilege grants allows the service to access only the required schemas, tables, and write targets. This keeps authorization centralized and auditable in Snowflake, which is a core security best practice for containerized workloads in SPCS.
- B. Incorrect.
Incorrect. Embedding a username and password in the container image creates long-lived secret exposure risk and violates least-privilege if ACCOUNTADMIN is used. Relying on application logic to limit queries is not a substitute for Snowflake RBAC controls. The misconception is that app-layer restrictions can safely compensate for excessive database privileges.
- C. Incorrect.
Incorrect. Although key-pair authentication can be more secure than passwords in some contexts, baking a private key into the image still introduces a long-lived credential management problem. Using a highly privileged user also weakens separation of duties and auditability. The better pattern in SPCS is to avoid static credentials and use the service's Snowflake-integrated identity with narrowly scoped privileges.
- D. Incorrect.
Incorrect. Making sensitive data available through a public endpoint bypasses Snowflake's native access controls and increases exposure. Snowflake object privileges are still the correct mechanism for controlling table access. This option reflects a misunderstanding that network indirection can replace database authorization.