Snowflake MLOps Engineer

Teams that share one account need a structure before the first model is trained. You set up compute, databases and roles for an ML project, separate development from production, and describe the whole setup as code.

• Compute pools and instance choices for ML
• Databases, schemas and roles for an ML project
• Separating development, test and production
• External access for packages and data
• Infrastructure as code for ML environments

You build A scripted ML environment with roles, compute and separate development and production stages.

Features are the part of a model most worth reusing. You build them as governed objects with defined entities and refresh schedules, compute them incrementally, and retrieve them so training data never uses the future.

• Features as governed, reusable objects
• Entities, feature views and refresh schedules
• Incremental computation with dynamic tables
• Point-in-time correct training data
• Retrieving features for training and for inference

You build A feature pipeline with a refreshed feature view and a point-in-time training set.

Training that works on a sample often fails on the full data set. You scale training across nodes, tune hyperparameters in parallel, and record every run so any result can be compared and reproduced.

• Distributed training on warehouses and containers
• Snowflake ML modeling APIs and open-source libraries
• Hyperparameter tuning across nodes
• Tracking experiments and comparing runs
• Reproducible training: pinning data and code

You build A training job that scales out, records every run and can be reproduced on demand.

A model nobody can find or trust is not operational. You log models to the registry with signatures and dependencies, attach metrics and metadata to each version, and control who may promote or call them.

• The Model Registry: models, versions and aliases
• Logging a model with its signature and dependencies
• Metrics and metadata on a version
• Promoting a version between stages
• Access control on registered models

You build A registered model with versions, recorded metrics and a defined promotion step.

A model has to run where its consumers are. You serve inference from a warehouse or from container services, compare batch scoring with real-time serving, and promote or roll back a version safely.

• Inference in a warehouse from SQL and Python
• Inference services on container compute
• Batch scoring against real-time serving
• Promoting a model from test to production
• Rolling back to an earlier version
• Sizing inference for latency and cost

You build A model deployed to test and production environments with a rehearsed rollback.

Models decay quietly. You decide what to watch across inputs, outputs and true outcomes, set up Snowflake-native monitoring with baselines, and route alerts to the owner so decline starts a response instead of a surprise.

• What to monitor: inputs, predictions and outcomes
• Model monitors and their metrics
• Drift against a baseline
• Alerts that reach the model owner
• Closing the loop to retraining

You build A monitor on a deployed model that alerts on drift and starts a retraining run.

A pipeline that depends on someone remembering to run it will fail. You chain steps into task graphs with dependencies, schedules and triggers, handle failures, and make the whole run repeatable from fresh data to registered model.

• Task graphs: dependencies, schedules and triggers
• Passing parameters between steps
• Serverless tasks against warehouse-backed tasks
• Retries, failure handling and notifications
• Running on a schedule and on new data
• Making a pipeline repeatable end to end

You build A scheduled task graph that refreshes features, retrains and registers a model.

ML code deserves the discipline software gets. You connect Git to Snowflake, test feature and model code in continuous integration, and promote through environments with approvals, using cloning to test against realistic data.

• Git integration and repository layout
• Snowflake CLI for deploying objects
• Testing feature code and models in CI
• Promotion through environments with approvals
• Zero-copy cloning for realistic test data
• Automating the lifecycle from a commit

You build A CI/CD workflow that tests, deploys and promotes an ML pipeline from a commit.

ML touches the most sensitive data a company holds. You design roles for scientists and engineers, apply masking and row policies to training data, trace lineage from model to source, and audit who trained, deployed and called what.

• Role design for scientists and engineers
• Masking and row policies on training data
• Lineage from a model back to its source data
• Tags and documentation for models and features
• Auditing training, deployment and use
• Secrets and network control for ML workloads

You build A governance design with roles, policies and lineage for one ML project.

GPU hours and idle warehouses add up quietly. You trace where ML spend comes from, size compute to the job, schedule to avoid idle time, and set limits and attribution so each project sees what it spends.

• Where ML spend comes from
• Warehouse and compute pool sizing
• Auto-suspend and scheduling to avoid idle cost
• Resource monitors and budgets
• Attributing cost to projects with tags
• Cheaper features and cheaper inference

You build A cost report for one pipeline with limits in place and the changes that cut its spend.

You build one lifecycle from raw data to a monitored model: features, training, registry, deployment, orchestration, CI/CD, governance and cost control. Then you defend each design choice to a review group.

• Scoping a use case and its operating needs
• Building features, training and registry steps
• Orchestrating and deploying the pipeline
• Adding monitoring, governance and cost limits
• Presenting the design and its trade-offs

You build A complete, scheduled and monitored ML pipeline with governance and cost controls.