SnowPro Advanced: Security Engineer Question 260
Single answerTrace data access within AI/ML workloads running on Snowpark Container ServicesA security engineering team at a healthcare company deploys an inference service on Snowpark Container Services (SPCS). The service reads patient feature data from Snowflake tables using a Snowflake service identity and writes model outputs back to another schema. During an audit, the team must determine which Snowflake objects the containerized workload accessed and which service principal performed the access, without relying on application logs from inside the container. Which approach best satisfies this requirement?
- A
Query Snowflake ACCESS_HISTORY and related account usage views to trace object-level access performed by the SPCS service identity, correlating reads and writes to the service or role used by the workload.
- B
Inspect the container image manifest and registry pull history, because Snowpark Container Services stores every SQL statement executed by the container in the image metadata.
- C
Review only NETWORK_POLICY and login history records, because all SPCS data access is captured as client IP events rather than object access events.
- D
Enable Tri-Secret Secure for the database, because encryption key events provide a full audit trail of which tables and views the SPCS workload queried.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake's native audit and governance telemetry to trace object access made by the Snowpark Container Services workload. In practice, if the containerized application accesses Snowflake using its configured Snowflake identity, those SQL operations are recorded in Snowflake account metadata and can be investigated through views such as ACCESS_HISTORY, often alongside QUERY_HISTORY and other ACCOUNT_USAGE views for correlation. This aligns with Snowflake best practices: use Snowflake's centralized auditing capabilities for data access tracing, rather than relying solely on application logs or infrastructure metadata. Network controls, image metadata, and encryption features are valuable for other security objectives, but they do not provide authoritative object-level lineage of reads and writes performed by an SPCS AI/ML workload.
- A. Correct.
Correct. For Snowflake-side auditing, object-level access should be traced using Snowflake governance and telemetry views such as ACCESS_HISTORY (and, where useful, QUERY_HISTORY or other ACCOUNT_USAGE views). When an SPCS workload uses a Snowflake identity to issue SQL statements, those accesses are auditable in Snowflake similarly to other Snowflake clients. This is the most appropriate way to determine which tables, views, or other objects were accessed and which principal or role was responsible, without depending on in-container logs.
- B. Incorrect.
Incorrect. Container image manifests and registry history track image packaging and pulls, not Snowflake SQL activity. They do not contain a reliable audit trail of object-level data access against Snowflake databases, schemas, tables, or views.
- C. Incorrect.
Incorrect. NETWORK_POLICY and login-related records can help with connection governance and authentication troubleshooting, but they do not replace object-access auditing. The misconception is that network-level controls provide sufficient evidence of data usage. In reality, auditors typically need object-level access details, which come from access/query telemetry rather than only IP or login events.
- D. Incorrect.
Incorrect. Tri-Secret Secure strengthens key management and encryption posture, but encryption key activity is not a substitute for query-level or object-level audit records. It helps protect data at rest, not enumerate which Snowflake objects a workload queried or modified.