SnowPro Advanced: Security Engineer Question 392
Single answerUnderstand the lifecycle management of services and their security implicationsA security engineer is reviewing a Snowflake account that uses a Snowpark Container Services service to host an internal tokenization API. The service was created for a short-term project, but the project has ended. During the review, the engineer finds that the compute pool is still running, the service endpoint remains reachable from allowed network locations, and the service owner role still has privileges needed to operate the service. The organization wants to reduce attack surface and avoid leaving unused service components active while preserving the ability to redeploy later if needed. Which action is the MOST appropriate next step?
- A
Suspend the virtual warehouse that was used to deploy the service, because service reachability depends on warehouse state
- B
Drop the service immediately, because dropping the service automatically removes all related privileges, compute resources, and external access configuration
- C
Suspend or stop the service and decommission the compute pool if it is no longer required, then review and revoke unneeded privileges associated with service operation
- D
Rotate the password for the service owner role, because service lifecycle risk is primarily caused by stale role credentials rather than active service resources
Show answer and explanation
Correct answer: C
Explanation
This question tests applied understanding of service lifecycle management and its security implications in Snowflake. For Snowpark Container Services, a service runs on a compute pool, so lifecycle controls should focus on the service itself, its endpoint exposure, the compute pool that hosts it, and the privileges granted to roles that administer or operate it. When a service is no longer needed, best practice is to stop or suspend the active workload, decommission unnecessary compute capacity, and review role grants to ensure least privilege. This approach reduces attack surface, limits unintended access paths, and aligns with secure operational hygiene.
Candidates should recognize that service runtime is not tied to virtual warehouse state. They should also avoid assuming that dropping one object automatically resolves every related security concern. In real environments, engineers should inventory dependent objects, endpoint exposure, grants, and supporting resources as part of service retirement. Relevant Snowflake documentation areas include Snowpark Container Services concepts, compute pools, service administration, and access control / least-privilege guidance.
- A. Incorrect.
Incorrect. Snowpark Container Services services run on compute pools, not on virtual warehouses. Suspending a warehouse used during deployment does not stop a running service or remove its exposure. This distractor targets the common misconception that all Snowflake runtime components are warehouse-backed.
- B. Incorrect.
Incorrect. Dropping the service may remove the service object, but it is not the best next step in this scenario because the requirement is to reduce attack surface while preserving the ability to redeploy later if needed. In addition, security review should include associated resources and privileges separately rather than assuming all related access paths and compute implications are fully addressed by dropping only the service object.
- C. Correct.
Correct. From a lifecycle-management and security perspective, the right action is to stop or suspend unused service workloads and remove or scale down the compute pool when it is no longer needed, then review service-related privileges so inactive projects do not retain unnecessary operational access. This reduces attack surface, limits unnecessary running resources, and still allows controlled redeployment later through retained artifacts and infrastructure-as-code processes if the organization chooses.
- D. Incorrect.
Incorrect. Roles in Snowflake are not authenticated with passwords in the same way users are, so rotating a 'password for the service owner role' is not a meaningful control. The core risk described is an active, reachable service and retained privileges, not stale role credentials.