OCI AI Foundations common mistakes
OCI AI Foundations · Understand the traps and how to avoid them.
When a scenario says the target is a category (e.g., 'flag as fraudulent or not'), they select regression because the phrasing includes a number or a threshold, or they label a clustering task as supervised because labelled examples were mentioned earlier in the stem.
The exam stems are written as business scenarios, not textbook definitions, and candidates pattern-match on surface words ('score', 'amount') instead of the output type. Basic ML taxonomy is reviewed early and then under-practised.
What to do instead
Before reading the answer options, write one line: 'Output = continuous number (regression) / discrete class (classification) / no labels (unsupervised)'. Ignore numeric inputs entirely when deciding; only the prediction target matters.
They pick 'maximise accuracy' or 'use AUC' for a heavily imbalanced problem, or they choose precision when the business cost is missing a positive case.
Accuracy feels like the default 'best' metric and is the one most revisers can define fluently, so it becomes an automatic choice. Cost-of-error reasoning is a separate skill that candidates rarely rehearse.
What to do instead
For every metrics question, first ask 'which error is expensive?'. Missed positives -> recall; false alarms expensive -> precision; both -> F1. Never accept accuracy unless the stem states classes are balanced or errors cost the same.
They read a large gap between high training accuracy and low validation accuracy as underfitting, or conclude that adding layers and parameters will always improve validation performance.
'High training performance' is intuitively read as 'the model is working', and the words over/under are easy to swap under time pressure. Candidates also carry a general 'bigger model = better' intuition from product marketing.
What to do instead
Use the fixed diagnosis table: train poor + validation poor = underfitting (add capacity/features/train longer); train strong + validation weak = overfitting (regularisation, dropout, early stopping, more data, augmentation). Memorise the direction of the gap, not the absolute numbers.
They recommend raising temperature or top-p to make an LLM more accurate or more consistent at structured extraction, or treat temperature and top-p as two names for the same setting.
Sampling parameters look like generic 'quality dials' and the exam often asks for a configuration in a scenario where the trading-off dimension (creativity vs determinism) is not spelled out.
What to do instead
Anchor two rules: deterministic/extraction/classification-style tasks -> temperature near 0; creative brainstorming -> higher temperature. Temperature scales the distribution, top-p truncates the candidate set; changing one does not substitute for the other. If the stem says 'consistent' or 'repeatable', the answer is a low temperature.
They recommend fine-tuning when the requirement is to give the model access to frequently changing internal documents, or recommend RAG when the requirement is to change the model's output style and format on every response.
Both are described as 'making the model know your business', and the exam's phrasing ('use company data') does not always say whether the knowledge is static or dynamic.
What to do instead
Split on two questions: Is the gap knowledge (facts, documents, recency) or behaviour (tone, format, task pattern)? Knowledge and changing content -> retrieval/grounding. Behaviour and stable style -> fine-tuning. When both, prompt engineering plus retrieval is the first move; fine-tuning comes after.
They choose image analysis/vision capabilities for extracting fields and tables from scanned invoices or receipts, or choose document understanding for classifying photographs of products.
The services overlap in that both can read text, so the distinguishing factor is the output shape (document structure vs scene/image labels) rather than the input file. Candidates also skim the service name and stop at 'text in an image'.
What to do instead
Classify by output, not input: structured fields, key-value pairs, tables, form layout from business documents -> Document Understanding. Labels, objects, faces, defects in photos or video -> Vision. If the answer needs a field name and a field value, it is document understanding.
They select forecasting to identify unusual historical values in a time series, or select anomaly detection to predict next month's demand.
Both services consume time-series data and both are described with words like 'patterns' and 'outliers' in scenario stems, so candidates default to whichever service they studied last.
What to do instead
One-line discriminator: future values = forecasting; suspicious values already observed = anomaly detection. Look for tense in the stem: 'will be', 'next quarter' -> forecasting; 'unexpected', 'spike', 'fault' in existing data -> anomaly detection.
They design a production architecture in which a Data Science notebook session hosts the live inference endpoint, or they assume a notebook session and its installed environment persist indefinitely after creation.
Hands-on practice happens entirely inside notebooks, so notebooks feel like 'the product'. Session lifecycle and the separate model deployment resource are covered in documentation rather than in interactive work.
What to do instead
Memorise the separation of concerns: notebooks are for exploration and training; durable artefacts go to Object Storage and the model catalog; serving goes to a model deployment endpoint. If a scenario mentions production traffic, scaling, or availability, the answer must be a deployment endpoint, never a session.
They assume adding a content moderation or toxicity filter also defends against prompt injection and jailbreak attempts, or treat prompt injection as a model-training problem to be fixed by fine-tuning.
Both are described as 'unsafe prompts', and filters are the most visible guardrail, so the two threats collapse into one mental category.
What to do instead
Separate the threat by asset: content moderation protects against harmful output categories; prompt injection targets instruction hierarchy and data exfiltration. Mitigations for injection are structural - treat retrieved and user content as untrusted data, isolate instructions, restrict tool and data access, validate outputs - not just a classifier.
When asked how to make a model's output fairer or more responsible, they select 'add a disclaimer/user agreement' or 'review outputs manually' rather than addressing data and evaluation, and they treat responsible AI as a single check-box step at the end of the lifecycle.
Governance content reads as policy prose and gets skimmed, while the technical options in the same question look more 'AI-like'. Candidates also conflate transparency (disclosing that AI is used) with fairness (outcomes across groups).
What to do instead
Map each concern to its own control: bias -> representative data, subgroup evaluation metrics, testing; transparency -> documentation/model cards and user disclosure; accountability -> human oversight and logging. When a question says 'reduce bias', the answer must change data or evaluation, never just messaging.