SnowPro Specialty: Gen AI Question 203
Single answerSpecification filesA data engineering team is deploying a custom GenAI workload in Snowflake Container Services. They want the service definition to be version-controlled, portable across environments, and easy to review during change management. The team decides to use a specification file rather than defining the service inline in SQL. Which approach best meets these goals while aligning with how Snowflake uses specification files?
- A
Store the service specification as a YAML file in a Snowflake stage, then reference that staged file when creating or updating the service.
- B
Store the service specification only in a local developer workstation file system and rely on Snowflake to automatically sync it during service creation.
- C
Convert the service specification into a Python worksheet and execute it so Snowflake can infer the service definition.
- D
Embed the full service specification directly into every CREATE SERVICE statement because Snowflake does not support external specification files.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake Container Services, specification files are used to define services in a structured, portable format, typically YAML. A best practice is to keep the specification file under source control and upload it to a Snowflake stage so it can be referenced consistently in deployment workflows. This improves auditability, promotes infrastructure-as-code style operations, and reduces errors from manually embedding large definitions inline. Options suggesting local-only files or Python inference reflect common misconceptions about how Snowflake consumes service definitions. Snowflake documentation for Snowpark Container Services describes using specification files and staged artifacts for service deployment.
- A. Correct.
Correct. Snowflake Container Services supports service specification files, commonly written in YAML, and these can be stored in a Snowflake stage and referenced during service creation or update. This supports versioning, review, and portability across environments because the spec is managed as a file artifact rather than repeatedly hand-authored inline.
- B. Incorrect.
Incorrect. A file on a developer's local machine is not automatically available to Snowflake. To use a specification file with Snowflake, it must be made accessible to Snowflake, typically by uploading it to a stage. Relying on local files breaks portability and deployment repeatability.
- C. Incorrect.
Incorrect. A Python worksheet is not a substitute for a Snowflake Container Services specification file. Snowflake does not infer a service definition from arbitrary Python code. The service definition must follow the expected specification format rather than being reverse-engineered from worksheet logic.
- D. Incorrect.
Incorrect. Inline service definitions may be possible in some workflows, but this option is wrong because Snowflake does support external specification files. Saying external specification files are unsupported is factually incorrect and contradicts the team's goal of using a reviewable, reusable artifact.