SnowPro Advanced: Security Engineer Question 261
Single answerTrace data access within AI/ML workloads running on Snowpark Container ServicesA security engineer must investigate which training dataset was accessed by a model-serving application running in Snowpark Container Services (SPCS). The application connects to Snowflake using a service identity and executes SQL statements to read feature tables during inference and retraining jobs. The engineer needs an approach that provides auditable tracing of what data objects were queried by the workload, without modifying every container image. Which solution best meets this requirement?
- A
Query ACCOUNT_USAGE.ACCESS_HISTORY and correlate the recorded object access to queries executed by the service identity used by the Snowpark Container Services workload
- B
Review only the service specification YAML and image repository tags because Snowpark Container Services stores all dataset access events in container metadata
- C
Enable masking policies on the feature tables and use policy references as the primary audit record for which tables the workload accessed
- D
Use NETWORK POLICIES on the service to determine which databases, schemas, and tables were read by the containerized application
Show answer and explanation
Correct answer: A
Explanation
To trace data access for AI/ML workloads running on Snowpark Container Services, focus on Snowflake's auditing views rather than container deployment metadata or network controls. When an application in SPCS connects to Snowflake and runs SQL, the access is captured through standard Snowflake query and object-access telemetry. ACCESS_HISTORY in ACCOUNT_USAGE is the key source for determining which objects were accessed by a given query or principal. In practice, security teams often combine ACCESS_HISTORY with QUERY_HISTORY and the service's Snowflake identity context to reconstruct what the workload read during inference or retraining. This aligns with Snowflake best practices for auditing data access: use account usage views for query/object lineage and access investigation, while treating masking policies and network policies as preventive controls rather than primary audit records.
- A. Correct.
Correct. For tracing data access, the most relevant Snowflake audit source is ACCESS_HISTORY in ACCOUNT_USAGE. It records object-level access associated with executed queries, including the base objects referenced. When an SPCS application connects to Snowflake and issues SQL using its service identity, those queries are auditable like other Snowflake queries. By correlating the identity and query activity, a security engineer can determine which training or feature tables were accessed by the workload without changing the container code.
- B. Incorrect.
Incorrect. Service specs and image tags help identify what was deployed, but they do not provide an authoritative record of which Snowflake data objects were actually queried at runtime. Snowpark Container Services does not use container metadata as the audit system for table-level data access.
- C. Incorrect.
Incorrect. Masking policies protect sensitive columns at query time, but they are not the primary mechanism for reconstructing a complete audit trail of what tables a workload accessed. A policy might apply to an object, but that does not by itself prove a specific query accessed it. Access auditing should rely on query and access history views.
- D. Incorrect.
Incorrect. Network policies restrict allowed client network locations and can help secure connectivity, but they do not capture database object usage. They cannot tell the engineer which tables or views were read by the application.