Data Access, Pipelines, and MLOps Operations
Domain 4 - Data Access, Pipelines, and MLOps Operations
This domain tests connectivity, orchestration, and operating models after the first deployment: how notebooks and jobs reach data, how pipelines chain steps, and how teams retrain, monitor, and audit.
Core rules
- Object Storage is addressed by URI (
oci://bucket@namespace/path) and requires IAM plus a network path. Private subnets typically use a service gateway for Object Storage and a NAT gateway only if internet access is required. - Vault stores secrets; reference them at runtime instead of embedding credentials. Autonomous Database access needs a wallet and network rules; File Storage can be mounted where supported.
- Data Science pipelines orchestrate steps such as custom scripts, jobs, and model operations. Pipeline parameters and artifacts should be externalized to Object Storage so step runs are reproducible.
- MLOps is the operating loop: version data and models, gate deployment on evaluation, monitor predictions and drift, retrain on a schedule, and keep lineage from catalog to deployment.
- Automate with the OCI CLI, SDK, or DevOps rather than notebook clicks.
Worked example
A pipeline has three steps: prepare data, train and evaluate, and deploy only if the evaluation metric passes. The prepare step writes a feature table to Object Storage; the train step reads it and writes metrics and a model artifact; the deploy step registers the model and updates the deployment. Parameters for bucket, date, and threshold are pipeline parameters. A schedule triggers a pipeline run, and monitoring raises an alert if drift exceeds the threshold.
Traps
- Hardcoding credentials or Object Storage paths in pipeline steps.
- Assuming a pipeline step shares local state with the previous step; pass artifacts through Object Storage.
- Deploying every trained model without an evaluation gate.
- Treating MLOps as only deployment; monitoring, lineage, and retraining are tested.