SnowPro Advanced: Security Engineer Question 400
Select 2Monitor and troubleshoot security issues within Snowpark Container Services deployments:A security engineer is investigating a Snowpark Container Services service that suddenly cannot read from an internal stage containing model files. The service previously worked, but after a deployment change it now returns authorization errors when the container starts. The engineer must determine whether the issue is caused by a privilege problem on the service, a change to the service's execution identity, or a broader security event. Which TWO actions are the most appropriate to monitor and troubleshoot this issue?
- A
Review the service specification and recent deployment changes to confirm which role or execution context the service uses, then validate that identity still has the required privileges on the stage and related objects.
- B
Query account usage views such as ACCESS_HISTORY and login/audit-related history where applicable to correlate the failed access with object-level authorization activity and recent security changes.
- C
Grant OWNERSHIP on the stage to the service so the container can bypass future authorization failures without further investigation.
- D
Restart the compute pool repeatedly and check whether the authorization problem clears, because stage access failures in Snowpark Container Services are typically caused by pool-level networking state.
- E
Modify the container image to embed the model files directly so Snowflake no longer evaluates access control for stage reads at runtime.
Show answer and explanation
Correct answers: A, B
Explanation
The best answer focuses on security-oriented troubleshooting rather than infrastructure guesswork or overprivileging. For Snowpark Container Services, a realistic investigation of denied access to an internal stage should validate the service's effective execution context, review recent service/deployment changes, and confirm the necessary grants on the stage and dependent objects. In parallel, Snowflake monitoring and audit capabilities, including Account Usage views such as ACCESS_HISTORY and other relevant history views, help correlate failed object access with recent grant changes or security events. This approach follows least-privilege and audit-driven troubleshooting best practices documented across Snowflake guidance for access control, monitoring, and Snowpark Container Services operations.
- A. Correct.
Correct. In Snowpark Container Services, troubleshooting access failures starts with verifying the execution context used by the service and confirming that the appropriate privileges still exist on the referenced stage and other dependent objects. A deployment change can alter how the service runs or which objects it references, so checking the service definition and current grants is a practical first step.
- B. Correct.
Correct. Monitoring and troubleshooting security issues should include reviewing Snowflake's auditing and usage data to determine whether the failure aligns with revoked privileges, changed grants, or other security-related events. ACCESS_HISTORY is useful for understanding object access attempts and correlating them with recent changes, while other account usage and audit-related views can help identify when security posture changed.
- C. Incorrect.
Incorrect. Granting OWNERSHIP is excessive and violates least-privilege practices. It is not an appropriate troubleshooting step for a service that only needs read access to staged files. This option reflects a common misconception that broad privileges are a safe shortcut during incident response.
- D. Incorrect.
Incorrect. Repeatedly restarting the compute pool does not address an authorization error on an internal stage. While compute pool issues can affect service availability, object authorization failures are typically resolved by checking privileges, identity, and audit data rather than by recycling infrastructure.
- E. Incorrect.
Incorrect. Embedding the files in the image may avoid the immediate stage read, but it does not troubleshoot the actual security issue and creates operational and governance drawbacks. It bypasses the root-cause analysis instead of determining whether a grant, role, or deployment change caused the authorization failure.