SnowPro Advanced: Security Engineer Question 385
Select 25.1 Secure and govern applications with Snowpark Container Services.A security engineering team is deploying an internal document-classification service on Snowpark Container Services (SPCS). The service must read sensitive files from an internal stage, process them inside containers, and write only classification results to a table. The team wants to minimize exposure of secrets, restrict the application so it can access only approved Snowflake objects, and ensure operators can govern what external capabilities the service is allowed to use in the future. Which TWO actions best meet these requirements?
- A
Create the service so it runs with a dedicated service role, and grant that role only the minimum privileges required on the stage and target table.
- B
Store cloud credentials and API keys as environment variables directly in the service specification so the container can read them at startup without additional Snowflake configuration.
- C
Use integrations such as external access integrations and/or security integrations to explicitly control what outbound connectivity or security capabilities the service can use.
- D
Grant the service owner's role broad privileges on the database and schema, because service runtime access is inherited from the user who created the service.
- E
Package the application into a Native App, because Native Apps automatically prevent the service from accessing any Snowflake object not owned by the application.
Show answer and explanation
Correct answers: A, C
Explanation
The best answers are to use a dedicated service role with minimal grants and to use integrations to govern sensitive external capabilities. For Snowpark Container Services, the main security design principles are: (1) grant the running service only the Snowflake object privileges it needs, and (2) centrally govern external connectivity and related capabilities through Snowflake integrations instead of embedding unmanaged credentials or allowing unrestricted outbound behavior. This aligns with Snowflake guidance around least-privilege access, managed secrets/integrations, and governance controls for services. In practice, security engineers should avoid broad ownership-based privilege assumptions and avoid placing long-lived secrets directly in service specs when Snowflake-managed mechanisms exist.
- A. Correct.
Correct. In Snowpark Container Services, services can run with a service role, and privileges to Snowflake objects should be granted to that role using least privilege. This is the core control for restricting what the running service can read from or write to inside Snowflake. For this scenario, granting only the needed access to the internal stage and the output table limits blast radius and aligns with security-engineering best practices.
- B. Incorrect.
Incorrect. Hardcoding cloud credentials or API keys into environment variables in the service specification increases exposure and complicates secret rotation. Snowflake provides managed secret handling and integrations for secure access patterns. A common misconception is that container startup variables are an acceptable place for long-lived credentials; for sensitive production workloads, they are not the recommended governance-oriented approach.
- C. Correct.
Correct. Snowflake uses integrations to govern sensitive capabilities. For Snowpark Container Services, external access integrations are used to control outbound network access, and security-related integrations can be used depending on the authentication pattern. This provides a centralized governance layer so operators explicitly allow only approved external capabilities rather than letting each container define unrestricted access.
- D. Incorrect.
Incorrect. Runtime access is not simply inherited from the user who created the service. Snowpark Container Services is designed so access can be controlled through service roles and grants. Granting broad owner privileges violates least privilege and does not provide the object-level restriction the scenario requires. This distractor reflects a frequent misunderstanding that creator privileges automatically define runtime data access.
- E. Incorrect.
Incorrect. Snowflake Native Apps are a packaging and distribution framework, not an automatic substitute for service-level privilege design in SPCS. While Native Apps have their own security model, they do not by themselves guarantee that an SPCS service can access only approved Snowflake objects. You still need explicit privilege grants, service roles, and governed integrations.