SnowPro Advanced: Security Engineer Question 394
Single answerImplement secure data access patterns for services running in Snowpark Container Services:A financial services company is deploying an inference API in Snowpark Container Services (SPCS). The service must read customer features from a Snowflake table and write prediction results back to another table. Security requirements are strict: application developers must not embed user passwords, long-lived key pairs, or reusable tokens in container images or Kubernetes-style secrets, and the service should only have the minimum Snowflake privileges required for its job. Which approach best meets these requirements?
- A
Configure the SPCS service to use a Snowflake service identity, grant that service identity only the required privileges on the specific database objects, and have the application obtain Snowflake access through the service's injected credentials at runtime.
- B
Create a dedicated Snowflake user for the application, generate an RSA key pair, bake the private key into the container image, and assign the user a broad role so future schema changes do not break the service.
- C
Store a Snowflake username and password in the service specification as environment variables, then rely on network policies to prevent other services from accessing those credentials.
- D
Use a single shared personal access token generated by an administrator, mount it into every container that needs Snowflake access, and rotate it only when the administrator changes roles.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the Snowpark Container Services service identity and grant it only the necessary privileges. This is the recommended secure data access pattern for services running in SPCS because it avoids hard-coded or long-lived credentials and supports least-privilege access control. In practice, the service runs with a Snowflake-managed identity, and the application retrieves runtime credentials made available to the container to connect back to Snowflake. Security engineers should then grant only the minimal database privileges needed, such as SELECT on the source objects and INSERT (or other required DML privileges) on the target objects. This follows Snowflake best practices around minimizing secret sprawl, avoiding shared credentials, and using identity-based access for workloads. Relevant Snowflake documentation includes Snowpark Container Services security and service identity guidance, along with general Snowflake access control best practices for granting object privileges to roles or service principals only as needed.
- A. Correct.
Correct. For Snowpark Container Services, the secure pattern is to use the service's Snowflake identity rather than embedding static credentials in the workload. This allows the containerized application to authenticate to Snowflake using short-lived, runtime-provided credentials associated with the service. Granting only the required privileges to that service identity enforces least privilege and aligns with security best practices for machine workloads.
- B. Incorrect.
Incorrect. Although key-pair authentication exists in Snowflake, embedding a private key in a container image creates a static secret management problem and increases blast radius if the image is copied or compromised. Giving the user a broad role also violates least-privilege design. This option reflects a common legacy pattern for service accounts, but it is not the preferred secure access pattern for SPCS workloads.
- C. Incorrect.
Incorrect. Storing usernames and passwords as environment variables still relies on long-lived static credentials and does not meet the requirement to avoid embedded reusable secrets. Network controls help reduce exposure but do not solve the underlying credential security issue. In addition, using a password-based service account is less secure and less manageable than using the service identity model provided for SPCS.
- D. Incorrect.
Incorrect. A shared reusable token for multiple containers breaks workload isolation and makes attribution, revocation, and least-privilege access difficult. Rotating only when an administrator changes roles is not an acceptable rotation strategy for sensitive production access. This option may seem convenient operationally, but it conflicts with secure service-to-Snowflake authentication practices.