OCI Data Science Pro common mistakes
OCI Data Science Pro · Understand the traps and how to avoid them.
When a notebook session fails to start or a job fails on import, the candidate blames the conda environment and starts rebuilding it, instead of first checking whether the session or job principal can read the object storage bucket and whether the VCN/subnet has a service gateway or NAT route for the regional Object Storage endpoint.
In OCI Data Science, many 'environment' failures are actually networking or IAM failures surfaced as generic timeouts or connection errors. Candidates who only practice in the console with pre-built resources never see the private-endpoint and policy wiring, so they misattribute the symptom to the environment domain.
What to do instead
Before touching the environment, run a triage order: (1) confirm the object is reachable from the session with the CLI or SDK, (2) confirm the dynamic group and policy statement covering the bucket, (3) confirm the subnet route table has a service gateway for Object Storage or a NAT gateway for internet, (4) confirm the NSG/security list allows the needed egress. Only then inspect conda pack and environment variables.
Treating a notebook session as a persistent server: writing training artifacts and checkpoints to the local /home/datascience directory, then being surprised when a restart or idle-timeout loses them or when a job cannot see them.
Sessions feel like a VM, and the block volume does persist across stop/start of the same session, so candidates over-generalize to 'everything is durable'. They miss that a job runs in a separate ephemeral environment with no access to the session's local filesystem.
What to do instead
State the boundary explicitly: session-local storage is for interactive work only; anything a job, pipeline, or model deployment needs must be written to Object Storage (or a mounted file system) and referenced by URI. When reviewing a scenario, ask 'does the consumer run in the same session?' - if no, the artifact must be in Object Storage.
Answering questions about model deployment by describing the notebook-session compute shape (for example, choosing a GPU shape to serve a small scikit-learn model) rather than reasoning about the model deployment's instance shape, instance count, and bandwidth, and about whether the model artifact is a conda-scored artifact or a plain file.
The exam distinguishes the compute used to train from the compute used to serve. Candidates who only ever deployed models through the console default settings never had to reason about artifact type, score.py contract, and log access, so they conflate the two.
What to do instead
Memorize the deployment contract: the artifact must contain the model file plus a score.py exposing load_model and predict, with the artifact type declared when creating the model; the deployment then selects shape, instance count, and logging. Practice reading deployment logs to distinguish a load_model failure from a predict failure from a networking failure.
Assuming a model registered in the Model Catalog is automatically available to a deployment in another compartment or that registering a model also deploys it, and therefore not checking compartment scoping, IAM policies on the catalog, and the separate deployment step.
The console flow hides the compartment selector and the catalog/deployment split, and the terms 'model' and 'model deployment' sound interchangeable. Candidates who never built cross-compartment scenarios miss that catalog entries are compartment-scoped resources governed by policies.
What to do instead
Draw the chain explicitly: project → model artifact in Object Storage → model catalog entry (compartment-scoped, policy-controlled) → model deployment (separate resource, own shape and logging) → endpoint. For any access question, identify which link in the chain the policy must cover.
Confusing Data Science Jobs with OCI Data Flow or with a notebook run: describing a job as needing a running notebook session, or as always running on a cluster, instead of as a batch execution of a script or notebook on a job run with its own shape, environment, and output location.
Job runs reuse the same conda environments and can execute notebooks, so candidates assume the session must be alive. The mental model 'notebook = session' is strong, and job infrastructure is invisible unless you have submitted a job run and inspected its logs and outputs.
What to do instead
Anchor on three facts: a job run is independent of any session, it specifies its own compute shape and conda environment, and it writes outputs to Object Storage because its local filesystem is ephemeral. When a question mentions scheduling or reproducibility, the answer is a job or pipeline, not a session.
On data-access questions, answering 'create an Auth Token and put the credentials in the notebook' when the correct pattern is resource principals with dynamic groups and policies, or vice versa applying resource principals to a user-driven interactive scenario where they do not fit.
Both mechanisms appear in documentation, and candidates memorize one without learning the selection rule. They also miss that resource principals cover jobs, pipelines, and model deployments, not arbitrary user sessions.
What to do instead
Learn the decision rule: for automated resources (jobs, pipeline steps, deployments) use resource principals with a dynamic group matching the resource type and compartment, then grant that dynamic group access in a policy. For a human in a session, use the user's own identity or an Auth Token/config file. Match the principal to who is acting.
Building a pipeline that passes large datasets between steps as step artifacts or parameters instead of writing intermediate data to Object Storage and passing URIs, and then failing questions about pipeline scalability and step isolation.
In a notebook, variables flow freely between cells, so candidates carry that mental model into pipelines. They do not realize each pipeline step runs as an isolated job run with its own environment and no shared memory.
What to do instead
State the rule: steps communicate only through durable storage and through declared outputs/parameters. Any question about 'how does step B get step A's data' answers with an Object Storage URI (or a mounted file system), not an in-memory object. Design pipelines so each step is independently rerunnable from its inputs.
Describing MLOps monitoring as 'the model deployment shows metrics' without distinguishing invocation logging, access logging, and prediction drift monitoring, and without knowing where those logs land and what policy is needed to read them.
The console surfaces a logs link, and candidates assume logs are always on and always complete. In practice logging must be enabled, logs go to OCI Logging, and reading them requires the right policy; drift monitoring is a separate capability with its own setup.
What to do instead
Separate the three: access logs record requests, invocation logs record payloads and must be explicitly enabled, and drift monitoring compares incoming feature distributions against a baseline with its own configuration. For each, know the enabling step, the destination, and the policy needed to read it.
Treating the conda environment as immutable and rebuilding from scratch whenever a package is missing, instead of using the supported path of installing into the environment, publishing it, and referencing the published environment slug in jobs and deployments.
Candidates memorize 'environments are conda' but not the lifecycle. They do not know that a job or deployment must reference a published environment, so they edit a local environment and expect the job to pick it up.
What to do instead
Learn the lifecycle: create or activate an environment, install packages, publish it so it becomes referenceable by slug, then reference that slug in the job or deployment. Remember that a published environment is versioned; changing packages means publishing a new version, not mutating the old one.
Answering project and tenancy questions without the compartment and project boundary: assuming a project is a tenancy-wide namespace, or that resources created in one project are visible in another, rather than that a project is a compartment-scoped workspace holding notebooks, jobs, models, and pipelines.
The console shows one project at a time, so candidates never see the boundary. They also conflate the project with the compartment, missing that policies are written on compartments and that the project lives inside one.
What to do instead
Anchor on the hierarchy: tenancy → compartment → project → resources (sessions, jobs, models, pipelines, deployments). Policies are authored at compartment scope; the project is a container, not a security boundary of its own. For any access question, locate the compartment first, then the project, then the resource.