SnowPro Advanced: Security Engineer Question 399
Select 2Monitor and troubleshoot security issues within Snowpark Container Services deployments:A financial services company runs an internal API in Snowpark Container Services (SPCS). The service uses an external access integration to call a third-party fraud-check endpoint and is exposed internally through a Snowflake service. After a security hardening change, application owners report that requests to the external fraud-check API are failing, while the container itself still starts successfully and the internal service endpoint remains reachable. As the Security Engineer, you need to determine whether the issue is caused by SPCS security configuration and identify the most effective troubleshooting steps. Which TWO actions should you take first?
- A
Review the service specification and associated external access integration to confirm the service is allowed to reach the intended external host and secrets, then inspect service/container logs for outbound connection or authorization errors.
- B
Query Snowflake access history to identify whether SQL statements from the container are being blocked by masking policies, because external network failures in SPCS are primarily surfaced there.
- C
Validate that the role owning or operating the service still has the required privileges on the compute pool, image repository, service, and any referenced secret or integration objects that the service depends on.
- D
Rotate the key pair for all service users in the account, because failed outbound HTTPS calls from SPCS typically indicate stale Snowflake user credentials rather than service-level security controls.
- E
Increase the warehouse size used by the application, because outbound connectivity failures from SPCS usually result from insufficient virtual warehouse resources.
Show answer and explanation
Correct answers: A, C
Explanation
The strongest initial troubleshooting path is to focus on the security controls that govern Snowpark Container Services runtime behavior: the service specification, external access integration configuration, referenced secrets, and object privileges. In this scenario, the container starts and the internal endpoint works, which suggests the core deployment and service exposure are functioning. The failure is isolated to outbound calls to a third-party endpoint, making egress configuration and related authorization the most likely causes.
Best practice is to first inspect the service definition and logs to confirm whether the external host is permitted and whether any authentication material is still correctly referenced. In parallel, verify that hardening changes did not remove required privileges on the compute pool, image repository, service, secret, or integration objects. Snowflake documentation for Snowpark Container Services, external access, secrets, and access control emphasizes validating object dependencies, least-privilege grants, and runtime logs when diagnosing service behavior. By contrast, account-level user credential rotation and warehouse resizing do not address the security path used by an SPCS service making outbound HTTPS requests.
- A. Correct.
Correct. When an SPCS workload can start and serve internal traffic but fails only on outbound calls, a first-priority check is whether the service spec still references the correct external access integration, allowed network destinations, and secrets required for authentication. Reviewing container or service logs is also an appropriate first troubleshooting step because connection-denied, DNS, TLS, or authorization failures are typically visible there. This directly targets the most likely security control involved in external egress from Snowpark Container Services.
- B. Incorrect.
Incorrect. Access history is useful for auditing SQL activity and object access patterns, but it is not the primary place to diagnose outbound network access from an SPCS container to a third-party HTTPS endpoint. A candidate might choose this because security incidents often involve centralized audit views, but this scenario points to external connectivity controls, not SQL policy enforcement.
- C. Correct.
Correct. Security hardening changes often break services by removing or narrowing privileges. For SPCS, you should verify that the service owner/operator still has the required privileges on dependent objects such as the compute pool, image repository, service object, external access integration, and referenced secrets. If these privileges were altered, the service may start yet fail at runtime when attempting protected operations. This is a realistic and high-value troubleshooting step.
- D. Incorrect.
Incorrect. Rotating user key pairs is not the right first action here. SPCS outbound HTTPS calls to external services are generally governed by the service configuration, integrations, and referenced secrets, not by Snowflake user key-pair authentication for interactive users. This distractor reflects a common but misplaced assumption that all security failures are user credential problems.
- E. Incorrect.
Incorrect. Virtual warehouse sizing is unrelated to outbound network authorization from Snowpark Container Services. SPCS runs on compute pools, not warehouses, and increasing warehouse size would not resolve an egress restriction or missing secret/integration configuration. This option tests whether the candidate can distinguish core Snowflake compute concepts from SPCS architecture.