SnowPro Specialty: Gen AI Question 202
Single answerDocker imagesA data science team is deploying a custom LLM inference service to Snowpark Container Services so it can be called from a Snowflake-based generative AI application. The service must start quickly, remain reproducible across environments, and avoid unnecessary security risk. The current Dockerfile uses FROM python:latest, installs build tools and Python packages in a single stage, and copies the entire project directory including notebooks and test data into the image. Which change would BEST improve the Docker image for this Snowflake deployment scenario?
- A
Replace
python:latestwith a pinned base image version, use a multi-stage build to exclude build-time dependencies, and copy only the files required to run the inference service - B
Keep
python:latestso the image automatically receives the newest Python patches, and add more package installation commands to ensure compatibility at runtime - C
Bundle model training code, notebooks, sample datasets, and debugging utilities into the same runtime image so the service can support both development and inference workloads
- D
Use a larger general-purpose base image that includes common Linux utilities and compilers so troubleshooting can be performed directly inside the production container
Show answer and explanation
Correct answer: A
Explanation
For Docker images used in Snowpark Container Services, best practice is to build minimal, deterministic runtime images. In real deployments for generative AI inference, image size affects pull time and startup speed, and excess packages or files increase operational risk. Pinning base image versions instead of using latest supports reproducibility and controlled upgrades. Multi-stage builds are a well-established Docker best practice for separating build-time and runtime dependencies. Excluding notebooks, test artifacts, and training data from the runtime image aligns with the principle of least privilege and reduces the attack surface. These practices are consistent with Docker image hardening guidance and with Snowflake container deployment patterns that favor lean, production-focused images.
- A. Correct.
Correct. Pinning the base image version improves reproducibility and avoids unexpected behavior caused by upstream image changes. A multi-stage build is a standard Docker best practice for removing build tools and intermediate artifacts from the final runtime image, reducing image size and attack surface. Copying only runtime-required files avoids bloating the image with notebooks, tests, and sample data, which helps startup time and operational efficiency in Snowpark Container Services.
- B. Incorrect.
Incorrect. Using
python:latestreduces reproducibility because the underlying image can change over time, which may introduce package conflicts or runtime regressions. While security patching matters, production images should usually be rebuilt from explicitly pinned, tested versions rather than relying on an unpinnedlatesttag. Adding more installation commands also tends to increase image size and complexity rather than solving the core issue. - C. Incorrect.
Incorrect. Combining training assets and development materials with the inference runtime image is a common anti-pattern. It increases the image size, slows image transfer and startup, and expands the security surface unnecessarily. In a production Snowpark Container Services deployment for inference, the image should be as minimal and purpose-built as possible.
- D. Incorrect.
Incorrect. A larger base image with extra utilities and compilers can make ad hoc debugging easier, but it is not the best choice for a production inference service. It increases image size and attack surface and works against the goal of fast, reproducible, secure deployments. Production containers should generally include only what is needed to run the service.