Define machine learning concepts for data science workloads.

The exam assumes you can identify, in one reading of a scenario, whether a problem is supervised or unsupervised, which Snowflake construct executes it most efficiently, and what the cost and governance trade-offs are. This section frames those decisions at practitioner depth, not as textbook definitions.

A workload qualifies as machine learning, rather than rules-based analytics, when the system improves a prediction or grouping by adjusting parameters in response to data rather than by hand-coded thresholds. Inside Snowflake, that distinction matters because the platform offers both deterministic SQL (CASE expressions, window functions, percentile thresholds) and learned models (Snowpark ML estimators, Cortex ML Functions). When a marketing team says "flag high-value customers above the 95th percentile of lifetime value," that is a percentile threshold, not a model. When the team says "flag customers likely to churn in the next 30 days based on behavior," that is a learned model with a binary target. Misclassifying the first as an ML problem leads to overengineering; misclassifying the second as a rule leads to brittle, unverifiable logic.

Supervised learning requires a labeled target column where each training row carries the known outcome. The model learns a mapping from feature columns to the target by minimizing a loss function. In Snowflake terms, supervised workloads include any CALL <model>!PREDICT(...) invocation against a Cortex ML Function such as CLASSIFICATION or FORECAST, every LogisticRegression, XGBClassifier, or LinearRegression estimator in snowflake.ml.modeling, and every custom PyTorch or TensorFlow model trained in the Container Runtime against a labeled DataFrame. The label is the contractual artifact: without it, the workload cannot be supervised regardless of how complex the features are.

Unsupervised learning works on unlabeled data and seeks structure, grouping, or anomaly without a ground-truth target. In Snowflake, the canonical unsupervised paths are clustering algorithms exposed through snowflake.ml.modeling.cluster (K-Means, DBSCAN through scikit-learn parity classes), the Cortex ANOMALY_DETECTION function which fits a univariate or multivariate model on historical patterns and flags departures, and association mining performed through SQL aggregations of co-occurrence on transaction baskets. The output of unsupervised models is not a prediction in the supervised sense but a cluster assignment, an anomaly score, or a rule with support and confidence values.

Semi-supervised and self-supervised paradigms appear in the exam only as distractors. Semi-supervised learning uses a small labeled set alongside a larger unlabeled set and is implementable in Snowflake but is not the focus of the DSA-C03 syllabus. Self-supervised learning, the dominant paradigm for foundation models, is consumed in Snowflake through Cortex LLM Functions (COMPLETE, EXTRACT_ANSWER, SUMMARIZE) rather than trained from scratch. The exam tests recognition that these exist and are distinct from the supervised and unsupervised core, not deep technical depth on them.

The Snowflake-specific selection criterion for ML workloads has three axes: where the data already lives, what skill level the producer has, and what governance the consumer requires. Data already in Snowflake tables should not be exported for training when Snowpark ML or Cortex ML Functions can train in place; doing so incurs egress, breaks lineage, and complicates row-level access policy enforcement. A SQL-only practitioner reaches for Cortex ML Functions because they are SQL-callable; a Python practitioner reaches for Snowpark ML for richer estimator coverage and pipelines; a research practitioner needing GPUs reaches for the Container Runtime for distributed training and custom frameworks.

The compute substrate matters for cost prediction. Snowpark ML training on a virtual warehouse scales with warehouse size and consumes credits at the warehouse rate; the same model in the Container Runtime consumes credits at the container instance rate, which is higher per second but parallelizes across nodes. Cortex ML Functions bill per call or per row processed, depending on the function, and abstract warehouse choice away. Choosing the wrong substrate inflates cost without improving accuracy; the exam frequently embeds a cost-sensitive scenario in a question about model choice.

# Naming convention used throughout this chapter
from snowflake.snowpark import Session

connection = {
 "account": "acme-retail",
 "user": "dsc_engineer",
 "role": "DATA_SCIENTIST",
 "warehouse": "DSC_TRAIN_WH",
 "database": "RETAIL_DSC_DB",
 "schema": "ML_DEV",
}
session = Session.builder.configs(connection).create()

# A supervised workload starts with a DataFrame that contains a label column
train_sdf = session.table("FEATURES.CUSTOMER_FEATURES_V3").join(
 session.table("FEATURES.CHURN_LABELS"),
 on="CUSTOMER_ID"
)

-- An unsupervised workload starts without a label column
-- Cortex ANOMALY_DETECTION fits on historical patterns alone
CREATE OR REPLACE SNOWFLAKE.ML.ANOMALY_DETECTION revenue_anomaly_model(
 INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'FEATURES.DAILY_REVENUE_V'),
 TIMESTAMP_COLNAME => 'ACTIVITY_DATE',
 TARGET_COLNAME => 'REVENUE_USD',
 LABEL_COLNAME => ''
);

💡 Exam Trap: A Cortex ANOMALY_DETECTION model accepts an optional LABEL_COLNAME argument. Passing a label column does not convert the workload into supervised learning; the label is used to mark known anomalies in training data so the model can exclude them from the baseline. The model is still unsupervised in the sense that it learns the normal pattern, not a mapping from features to label.

💡 Exam Trap: Cortex CLASSIFICATION requires a label column and is supervised. Cortex TOP_INSIGHTS does not train a model at all; it ranks SQL-level segment differences using statistical tests. Treating TOP_INSIGHTS as a clustering algorithm is a common error because the output looks like groupings.

Snowflake compute substrates for ML

The three substrates differ in startup time, parallelism, package support, and credit consumption rate. The table below summarizes the practical trade-offs.

Limits and quotas

The Cortex ML Function family enforces input shape and size constraints that the exam treats as testable. Cortex FORECAST requires the input to contain at minimum the timestamp column and the target column, and refuses to fit when the series is too short for the requested seasonality detection. Cortex CLASSIFICATION requires the label column to contain at least two distinct classes and refuses if any class falls below the minimum row count documented for the function. Snowpark ML estimators inherit Python memory limits of the warehouse node serving them; training a model on a dataset larger than node memory triggers an out-of-memory error unless the estimator supports distributed training through the Container Runtime's distributed APIs.

Model Registry imposes a model name uniqueness constraint within a schema and a version name uniqueness constraint within a model. Default behavior on a name collision is to raise an error, not to overwrite. Retention of model artifacts in the Registry follows the lifecycle of the containing schema and database; dropping the database drops the registered models. Time Travel on Registry objects follows the data retention period of the schema.

⚠️ Anti-Pattern: Exporting Snowflake tables to local CSV for training in a laptop Jupyter notebook, then re-uploading the trained pickle file to a stage for inference. This breaks lineage, exposes data to laptop disk, prevents row-level policy enforcement, and produces models that cannot be governed by Snowflake's access framework. Train in Snowpark ML or the Container Runtime and register the artifact in Model Registry.

💡 Exam Trap: Snowpark Python and Snowpark ML are not interchangeable terms. Snowpark Python is the DataFrame and Python UDF API for any workload; Snowpark ML is the modeling, feature engineering, and registry library built on top of it. A scenario that says "the team uses Snowpark" tells you nothing about whether they use the ML library.

Decision rule

Choose Cortex ML Functions when the problem fits a supported template (forecasting, classification, anomaly detection, segment ranking) and the practitioners are SQL-fluent. Choose Snowpark ML on a warehouse when the algorithm catalog of Cortex is too narrow but the model fits in node memory and runs on CPU. Choose the Container Runtime when the workload requires GPUs, distributed training, or a framework outside the Snowpark ML catalog.

🎯 Scenario: A retail analytics team must predict weekly demand for 8,000 SKUs across 300 stores using two years of daily history. The team is SQL-fluent, prefers minimal Python, and needs the forecasts to refresh weekly with row-level filtering by store region. The right substrate is Cortex FORECAST invoked from a scheduled task: the per-series modeling is built in, the SQL interface fits the team, and the row access policy on the underlying history table propagates through the function call. Pulling the data into a Container Runtime notebook for Prophet would be technically correct but more expensive and harder to govern.