SnowPro Advanced: Security Engineer Question 397
Single answerManage sensitive configurations within service specifications (YAML)A security engineer is reviewing a Snowflake service specification (YAML) for a containerized application deployed with Snowpark Container Services. The current spec includes a database password and API token as plain-text environment variable values in the YAML file stored in source control. The team wants to reduce exposure of secrets while still allowing the container to use them at runtime. Which approach should the engineer recommend?
- A
Store the secrets in a Snowflake SECRET object and reference that secret from the service specification so the container can access it securely at runtime.
- B
Keep the secrets in the YAML file, but base64-encode the values before committing them so they are not readable in source control.
- C
Move the secrets into a regular Snowflake table and have the container query the table during startup using its owner role.
- D
Replace the literal secret values with SQL session variables in the YAML so the values are resolved only when the service starts.
Show answer and explanation
Correct answer: A
Explanation
For Snowpark Container Services, sensitive configuration values such as passwords, API keys, and tokens should not be embedded directly in the service specification YAML. Snowflake provides SECRET objects specifically to manage sensitive data more securely and allow services to consume those values at runtime. This helps minimize credential exposure in source control, supports better separation of duties, and aligns with the principle of least exposure. Options such as base64-encoding values, storing secrets in ordinary tables, or attempting to use session variables do not provide appropriate protection or follow Snowflake best practices for service security. Candidates should recognize that secure secret handling in service specifications means externalizing sensitive values from YAML and using Snowflake-supported secret management capabilities.
- A. Correct.
Correct. Sensitive values used by Snowpark Container Services should not be hard-coded in the service specification. The recommended practice is to store credentials or tokens in Snowflake SECRET objects and configure the service to use those secrets at runtime. This reduces exposure in source control and aligns with Snowflake's security guidance for managing sensitive configuration in service specifications.
- B. Incorrect.
Incorrect. Base64 encoding is not a security control; it is easily reversible and does not protect secrets from disclosure. This option reflects a common misconception that obfuscation is equivalent to encryption or secure secret management.
- C. Incorrect.
Incorrect. A regular table is not an appropriate secret store for this use case. It increases the risk of broad data access, requires the application to retrieve secrets explicitly, and does not align with the intended Snowflake mechanism for handling sensitive credentials in services. Secret objects are designed specifically for this purpose.
- D. Incorrect.
Incorrect. SQL session variables are not a secure secret-management mechanism for service specifications and do not solve the source-control exposure problem described in the scenario. They are not the recommended way to inject sensitive runtime credentials into Snowpark Container Services.