SnowPro Advanced: Security Engineer Question 398
Single answerManage sensitive configurations within service specifications (YAML)A security engineer is reviewing a Snowflake Native App with Snowpark Container Services. The development team plans to deploy a service using a YAML service specification and wants to provide a third-party API token and a database password to the containerized application. The team currently proposes hardcoding both values as environment variables directly in the YAML file stored in source control. The engineer must redesign this approach to reduce exposure of secrets while still allowing the service to access them at runtime. Which approach should the engineer recommend?
- A
Store the sensitive values in a Snowflake secret and reference the secret from the service specification so the container can retrieve them securely at runtime instead of embedding plaintext values in YAML.
- B
Base64-encode the API token and password in the YAML file and pass the decoded values to the container at startup.
- C
Move the API token and password into a separate YAML file in an internal stage and include that file during deployment so the main service specification does not contain the secrets.
- D
Store the secrets in a regular Snowflake table and have the container query the table at startup using a role with SELECT privileges.
Show answer and explanation
Correct answer: A
Explanation
For Snowpark Container Services and related service specifications, best practice is to avoid embedding sensitive values directly in YAML, environment variables, or source-controlled deployment files. Snowflake supports secrets for securely managing credentials and other sensitive configuration data. A service specification can reference a secret so the workload receives the sensitive value at runtime without exposing it in plaintext. This aligns with Snowflake security guidance to use purpose-built secret management rather than plaintext configuration, simple encoding, or ad hoc storage in tables or staged files.
- A. Correct.
Correct. Sensitive configuration values such as API tokens and passwords should not be hardcoded into the service specification. Snowflake provides secret management capabilities that are intended for storing and supplying sensitive values securely to services and other supported integrations. Referencing a Snowflake secret from the service specification is the appropriate way to make the secret available to the container at runtime while avoiding plaintext exposure in version control and deployment artifacts.
- B. Incorrect.
Incorrect. Base64 encoding is not encryption and provides no meaningful security. Anyone with access to the YAML can decode the values easily. This reflects a common misconception that obfuscation is sufficient for secret protection.
- C. Incorrect.
Incorrect. Moving secrets to a different YAML file or stage may reduce clutter, but it does not solve the core security issue if the values are still stored as plaintext configuration. The secret remains exposed to anyone who can read the staged file or deployment assets.
- D. Incorrect.
Incorrect. Although a table can store text values, regular tables are not the recommended mechanism for secret handling in service specifications. This approach increases the risk of broader exposure through SQL access patterns, query history considerations, and privilege misconfiguration. Snowflake secrets are designed specifically for managing sensitive values.