OCI Certified Generative AI Professional (1Z0-1127) — Complete Study Guide

Learn → Practice → Apply · Build Smart. Scale Fast.

The Oracle Cloud Infrastructure Certified Generative AI Professional credential covers pretrained chat and embedding models, dedicated AI clusters, fine-tuning, endpoints, inference parameters, Retrieval-Augmented Generation (RAG) pipelines, and the OCI Generative AI Agents service. Expect scenario questions about picking the right fine-tuning method, sizing a dedicated AI cluster, tuning decoding parameters, choosing between HNSW and IVF vector indexes, and configuring an agent knowledge base. The current edition (as of July 2026) is 1Z0-1127-26, which carries an identical blueprint to the retired -25 edition — everything in this guide applies to the current exam.

The exam is organized into four domains weighted 20/40/20/20. The heavyweight is Using OCI Generative AI Service at 40% — roughly 20 of your 50 questions — so Part 2 of this guide is proportionally the deepest.

How to Use This Guide

Work through the four parts in order — Part 1 gives you the vocabulary that Parts 2–4 build on. Budget the most study time for Part 2, exactly as the exam does. After each part, quiz yourself with the section headings: if you can explain every heading from memory, move on.

Part 1 · Fundamentals of Large Language Models (20%)

About 10 of 50 questions. This domain is pure concepts — no OCI product names — covering what LLMs are, how transformer architectures differ, how prompting and fine-tuning adapt a model, how decoding turns probabilities into text, and where models fail (hallucination, bias). Every later domain reuses this vocabulary.

1.1 What a large language model is

A large language model (LLM) is a probabilistic model of text: given a sequence of tokens (sub-word units), it computes a probability distribution over the vocabulary for the next token. Generation is simply repeated next-token prediction — the model appends a chosen token to the sequence and predicts again until it emits a stop condition. "Large" refers to the parameter count (billions of weights) and the scale of the training corpus.

Because the model outputs a distribution, not a single answer, two levers control behavior: what you feed in (prompting, and more permanently training/fine-tuning, which alters the distribution itself) and how you pick from the distribution (decoding, Section 1.5).

1.2 Transformer architectures: encoder, decoder, encoder-decoder

All modern LLMs are built from the transformer architecture, whose core mechanism — self-attention — lets every token weigh its relationship to every other token in the sequence, capturing long-range context that older recurrent networks lost. Transformers come in three configurations, and the exam expects you to match architecture to task:

1.3 Prompt design and prompting techniques

A prompt is the input text that conditions the model's output; prompt engineering is the iterative craft of refining that text — instructions, examples, output-format requests — to steer the model without changing any weights. Key techniques:

• In-context learningthe model "learns" a task purely from demonstrations placed in the prompt. No weights change; the learning lives only in the context window and vanishes when the conversation ends.
• Zero-shot promptingtask instruction only, no examples ("Classify this review as positive or negative").
• Few-shot (k-shot) promptinginclude k worked examples before the real input. k-shot means exactly k examples; few-shot typically means a handful. Usually improves accuracy and format compliance over zero-shot.
• Chain-of-Thought (CoT)ask the model to reason step by step ("Let's think step by step") or show examples containing intermediate reasoning. Dramatically improves multi-step arithmetic and logic problems by making the model emit its reasoning before the answer.
• Least-to-most promptingdecompose a hard problem into simpler subproblems and solve them in order, feeding earlier answers into later steps.
• Step-back promptingfirst ask the model for the general principle or abstraction behind the question, then apply it to the specific case.

Prompting has a dark side the exam tests: prompt injection (jailbreaking) — adversarial input crafted to override the system's instructions and make the model ignore its guardrails, leak its system prompt, or produce prohibited content. Treat any user-supplied text that reaches the prompt as untrusted input.

1.4 Fine-tuning concepts: full fine-tuning, PEFT, T-Few, soft prompting

When prompting cannot get the behavior you need — the model must adopt a domain vocabulary, a strict output format, or a task it consistently fails at — you adapt the weights:

• Full (vanilla) fine-tuningcontinue training and update all of the model's parameters on your labeled dataset. Most expressive, but the most expensive in GPU time and storage (a full copy of the weights per task), and it risks catastrophic forgetting — degrading general capabilities while specializing.
• Parameter-Efficient Fine-Tuning (PEFT)update only a small fraction of parameters (or small added modules) while freezing the base weights. Far cheaper, faster, and less prone to forgetting. LoRA and T-Few are PEFT methods.
• T-Fewthe PEFT method used by OCI Generative AI. It inserts small additional T-Few transformer layers and updates only that fraction (on the order of ~0.01% of total weights) during training. You get near-full-fine-tuning quality at a fraction of the cost, plus an operational bonus covered in Part 2: many T-Few-tuned variants of the same base model can share one hosting cluster.
• Soft prompting (prompt tuning)freeze the entire model and learn a small set of continuous prompt vectors ("soft prompt") prepended to the input. No human writes these tokens — they are trained parameters. It is the lightest adaptation method, sitting between prompt engineering (no training at all) and PEFT.

When do you choose which adaptation path? The standard decision framework: start with prompt engineering (cheapest, instant); add RAG when the model needs your current, factual data it was never trained on; use fine-tuning when the model needs a style, format, or skill that prompting cannot reliably produce; combine RAG + fine-tuning for both.

1.5 Decoding strategies: greedy, temperature, top-k, top-p

Decoding is how a single output token is chosen from the model's probability distribution at each step:

• Greedy decodingalways pick the single highest-probability token. Deterministic, safe, and repetitive; equivalent to temperature 0.
• Random sampling with temperaturesample from the distribution after scaling it by temperature. Higher temperature flattens the distribution (low-probability tokens become more likely → more creative, more random); lower temperature sharpens it toward the most likely tokens (more focused, more deterministic). Temperature changes the shape of the distribution; it does not cut candidates out.
• Top-k samplingrestrict sampling to the k highest-probability tokens, renormalize, sample among them. A fixed-size shortlist.
• Top-p (nucleus) samplingrestrict sampling to the smallest set of tokens whose cumulative probability ≥ p. The shortlist size adapts to the distribution: confident predictions give a tiny nucleus, uncertain ones a large one.

1.6 Hallucinations, bias, and model limitations

A hallucination is model output that is fluent and confident but factually wrong or unsupported by any source — invented citations, wrong dates, fabricated APIs. Hallucinations happen because the model optimizes for plausible next tokens, not true ones. Key exam framing:

• •
  There is no method that eliminates hallucination entirely. Mitigations reduce it: RAG grounding, lower temperature, instructing the model to say "I don't know," and human review for high-stakes output.
• •
  Groundedness/attributability — an answer is grounded if it can be traced to a supporting source document. RAG systems improve groundedness by retrieving evidence and (in OCI Agents) attaching citations.
• •
  Bias — models reproduce and can amplify biases present in training data; mitigation includes data curation, evaluation, and moderation layers.
• •
  Other limits: a fixed knowledge cutoff, bounded context window, sensitivity to prompt wording, and non-determinism under sampling.

1.7 Code models, multimodal models, and language agents

Three LLM extensions round out the domain:

• Code modelsLLMs trained or specialized on source code (e.g., Codex-class models, Code Llama). They power completion, generation from natural-language specs, explanation, and translation between languages. Same next-token machinery, code-heavy corpus.
• Multimodal modelsmodels that accept and/or produce multiple modalities (text + image, audio, video). "Multimodal" refers to data types, not the number of languages or tasks. Diffusion models — which generate images by iteratively denoising random noise — belong in this space; note that diffusion works poorly for text generation because text is discrete and sequential rather than continuous.
• Language agentssystems in which an LLM does more than answer: it plans, uses tools, and acts in an environment iteratively. The canonical pattern is ReAct — interleaving reasoning traces ("Thought") with actions (tool calls, searches) and observations — letting the model gather information and adjust its plan mid-task. OCI's Generative AI Agents service (Part 4) is a managed productization of this idea.

Part 2 · Using OCI Generative AI Service (40%)

The core of the exam — around 20 of 50 questions — and where scenario detail matters most. OCI Generative AI is a fully managed, serverless service in which you consume pretrained foundation models through a single API, customize them with your own data, and (optionally) run them on dedicated GPU capacity. Know its models, parameters, cluster mechanics, fine-tuning workflow, endpoints, security posture, and moderation features cold.

2.1 Service fundamentals

OCI Generative AI provides:

• Pretrained foundation modelschat models (Cohere Command family, Meta Llama family) and embedding models (Cohere Embed family), accessible via console playground, CLI, SDK, and REST API.
• Two serving modeson-demand (pay per character/token against shared multi-tenant capacity, no infrastructure to manage) and dedicated (your own GPU cluster with predictable throughput, required for hosting fine-tuned models).
• Customizationfine-tuning pretrained base models with your labeled dataset on a dedicated fine-tuning cluster.
• Playgrounda console UI for testing models and parameters without writing code; it can also generate the equivalent code (Python SDK) for what you configured.

The exam's mental model of the service has four moving parts: pretrained models → fine-tuning (optional) → dedicated AI clusters (capacity) → endpoints (access points).

2.2 Pretrained chat models: Cohere Command and Meta Llama

The chat model lineup evolves, but the exam tests families and characteristics, not release-by-release specifics:

• Cohere Command family (e.g., Command R, Command R+ and successors) — enterprise-oriented chat models. Larger "+"-class variants offer stronger quality and larger context windows at higher cost; smaller R-class variants trade some capability for speed and price. Cohere chat models support a preamble override — replacing the model's default system context to change its persona, tone, or style guidelines.
• Meta Llama family (e.g., Llama 3.x and later) — open-weights models hosted as a managed offering; strong general chat and generation capability, large context windows in recent versions.

Chat models are conversation-aware: the API accepts a message history (roles for system/user/assistant style turns) so the model can use prior turns as context. Model choice questions hinge on the same factors as any FM selection: quality needs, context window, latency and cost, and whether you need fine-tuning support for that base.

2.3 Inference parameters and the chat API

You must know each request-time parameter and its effect:

• Maximum output tokenscap on tokens the model may emit in the response.
• Temperaturesampling randomness dial (Section 1.5). 0 ≈ greedy/deterministic; higher values flatten the distribution for more varied output.
• Top-ksample only among the k most likely next tokens.
• Top-psample only from the nucleus of tokens whose cumulative probability ≥ p.
• Frequency penaltypenalizes a token proportionally to how many times it has already appeared, discouraging verbatim repetition; the more often a token occurred, the stronger the penalty.
• Presence penaltyapplies a flat, one-time penalty to any token that has appeared at all, encouraging the model to move to new topics.
• Stop sequencesstrings that immediately terminate generation when produced.
• Seedmakes sampling best-effort repeatable: same seed + same parameters + same prompt tends to reproduce the same output. Useful for testing, not an absolute guarantee.

2.4 Embedding models and semantic search

Embeddings are dense numeric vectors that represent the meaning of text; texts with similar meaning land close together in vector space, which is what makes semantic search possible — matching by meaning rather than keywords. OCI's embedding models are the Cohere Embed family:

• English and multilingual variantsmultilingual models place semantically equivalent text from different languages near each other, enabling cross-lingual search.
• Standard vs. light variantsstandard models output 1024-dimensional vectors; "light" variants output smaller vectors (e.g., 384 dimensions) for lower storage and faster search at some quality cost.
• Input limitseach input is truncated/limited around 512 tokens, and a single API call can embed up to 96 inputs.
• Input typeCohere v3-era embed models distinguish the purpose of the text (e.g., embedding a document for storage vs. a query for search) to optimize retrieval quality — so embed your corpus as documents and your user questions as queries.

Typical uses: semantic search (the RAG retrieval step in Parts 3–4), clustering, and classification. Remember from Part 1: embedding models are encoder architectures.

2.5 Dedicated AI clusters: units, sizing, and cost

Dedicated AI clusters are single-tenant GPU allocations that host your model workloads with no sharing across customers. There are two cluster types, and their mechanics are heavily tested:

Additional cluster facts to memorize:

• •
  Clusters are sized in units, and each base model requires a specific unit type/size (e.g., a large Cohere-class unit for large Command models, an embed-class unit for embedding models, a Llama-class unit for Llama models). You cannot host a model on a mismatched unit type.
• •
  Cost formula — total cost = units × unit-hours × unit price. A fine-tuning job that runs 5 hours on a 2-unit cluster consumes 10 unit-hours.
• •
  Increasing hosting units raises throughput (more concurrent requests / replicas of the model).
• •
  A hosting cluster is billed while it exists even at zero traffic — the 744 unit-hour monthly minimum is the fact the exam loves.

2.6 Fine-tuning on OCI: T-Few vs. vanilla

OCI fine-tuning takes a pretrained base model + your labeled training dataset (prompt/completion pairs, uploaded to Object Storage, typically JSONL) and produces a custom model on a fine-tuning cluster. Two training methods:

• T-Few (recommended, PEFT) — inserts additional T-Few transformer layers and updates only that small fraction (~0.01%) of weights. Faster and cheaper training, resistant to catastrophic forgetting, and — critically for economics — multiple T-Few models tuned from the same base can be hosted on one hosting cluster, sharing the frozen base weights and swapping only the small tuned layers (stacked serving, up to about 50 models per cluster).
• Vanillaclassic fine-tuning that updates the model's layers broadly (configurable as the last N layers). More expressive for large behavioral shifts and complex/large datasets, but slower, costlier, and each vanilla model needs its own hosted capacity.

Choose T-Few for most tasks, smaller datasets, and when you plan to serve many task-specific variants; choose vanilla when you have a large dataset and need deeper adaptation.

Key training hyperparameters you can set: total training epochs, learning rate, training batch size, and early stopping (patience/threshold) — defaults are model-specific and usually sensible.

2.7 Fine-tuning metrics: accuracy and loss

Every fine-tuning job reports two evaluation numbers, and the exam asks what they mean:

• Accuracythe fraction of output tokens the tuned model predicted correctly against the reference completions. Higher is better; near 1.0 means the model reproduces the target outputs almost exactly.
• Losshow wrong the model's predictions are (penalizing bad predictions, with partial credit for near-misses). Lower is better; loss should decrease as training proceeds. A model that has learned the task shows falling loss and rising accuracy.

2.8 Model endpoints

An endpoint is the network access point through which applications send inference requests to a model on a hosting cluster:

• •
  Endpoints are created on a hosting cluster and reference either a pretrained base model or your fine-tuned custom model.
• •
  One hosting cluster can expose up to ~50 endpoints, and with T-Few stacked serving those endpoints can front many different fine-tuned variants of the same base.
• •
  Endpoints can be updated, deactivated, and deleted independently of the cluster; moving to a new model version means pointing an endpoint at the new custom model.
• •
  Content moderation (Section 2.10) is enabled per endpoint.

Applications call endpoints through the OCI SDKs/REST API with standard OCI IAM authentication; access is governed by IAM policies on the Generative AI resources in the compartment.

2.9 Security architecture: dedicated GPUs, RDMA, isolation

OCI's Generative AI security story is a named exam topic. The pillars:

• Dedicated GPU isolationfor dedicated clusters, the GPUs that serve your models are allocated to your workload alone; your model weights and inference traffic never share GPU hardware with other tenants.
• RDMA cluster networkthe GPUs in a cluster are connected by an ultra-low-latency RDMA (Remote Direct Memory Access) network, providing the bandwidth to serve large models across GPUs while remaining an isolated network island for that customer's workload.
• Customer data isolationprompts and generated responses are not shared across tenants and are not used to train base models; your fine-tuned model weights are stored encrypted in Object Storage and are accessible only to your dedicated cluster.
• Platform integrationthe service leans on core OCI security: IAM for authentication/authorization (policies scoped to compartments), key management/encryption for data at rest, and audit/logging services for traceability.

2.10 Content moderation

OCI Generative AI includes content moderation to detect and handle harmful content — categories along the lines of hate/harassment, self-harm, sexual content, and violence. Exam-relevant mechanics:

• •
  Moderation can apply to inputs (prompts), outputs (responses), or both.
• •
  On dedicated hosting, moderation is configured when you create or update an endpoint — it is an endpoint-level toggle, not a cluster-level one.
• •
  Moderation complements, not replaces, prompt-injection defenses and human oversight; it is one guardrail layer in a responsible-AI stack.

Part 3 · Implement RAG Using OCI Generative AI Service (20%)

About 10 of 50 questions. This domain is the build-it-yourself RAG path: LangChain as orchestration framework, OCI Generative AI models for embedding and chat, and Oracle Database 23ai as the vector store. (Part 4 covers the managed alternative.) Understand the pipeline end to end and every named component in it.

3.1 RAG concepts and the three-phase workflow

Retrieval-Augmented Generation grounds an LLM's answers in your own documents: instead of relying on parametric memory, the system retrieves relevant passages at question time and hands them to the model as context. Benefits: current and private knowledge without retraining, fewer hallucinations, and answers that can cite sources.

The canonical workflow has three phases:

1. 1Ingestion (offline) — load documents → split them into chunks → embed each chunk into a vector → store/index vectors in a vector database.
2. 2Retrieval (query time) — embed the user's question with the same embedding model → run a similarity search against the index → return the top-k most relevant chunks.
3. 3Generationassemble a prompt containing the question + retrieved chunks → the chat model generates an answer grounded in that context.

3.2 LangChain integration: models, prompts, chains, memory

LangChain is the orchestration framework that wires the pipeline together. Know its building blocks and the OCI-specific classes:

• ModelsLangChain wraps LLM/chat providers behind a uniform interface; the OCI integration (e.g., a ChatOCIGenAI-style class) points at an OCI Generative AI model or endpoint, and an OCI embeddings class wraps the Cohere Embed models.
• Prompts / prompt templatesPromptTemplate and ChatPromptTemplate build parameterized prompts with placeholders ({context}, {question}) filled at runtime — the standard way to inject retrieved chunks into the generation prompt.
• Chainscomposable sequences of components (prompt → model → output parser), including retrieval chains that combine a retriever with a chat model to implement RAG in a few lines. Modern LangChain composes these with the pipe-style expression language.
• Document loaders and text splittersloaders read source formats (PDF, HTML, etc.); splitters chunk them (Section 3.3).
• Vector stores and retrieversa vector store (here, Oracle 23ai via the OracleVS integration) stores embeddings; calling as_retriever() turns it into a retriever component that returns top-k documents for a query.
• Memorycomponents that persist conversation history so follow-up questions have context (Section 3.7).

3.3 Document loading, splitting, and chunking

Splitting matters because embedding models have input limits and because retrieval granularity drives answer quality:

• Chunk sizesmall chunks give precise retrieval but can lose surrounding context; large chunks preserve context but dilute the embedding's focus and eat prompt budget. There is no universal best size — it is a tuning tradeoff.
• Chunk overlaprepeating some text between adjacent chunks so sentences straddling a boundary are not orphaned; preserves continuity at the cost of some redundancy.
• Recursive character splittingthe workhorse strategy: try to split on natural boundaries (paragraphs, then sentences, then words) to keep chunks semantically coherent rather than cutting mid-thought.

Oracle 23ai also ships in-database utilities (the DBMS_VECTOR_CHAIN family) that can chunk and embed text inside the database, an alternative to doing it in Python.

3.4 Oracle Database 23ai as the vector store

Oracle Database 23ai adds AI Vector Search — native vector capability inside the converged relational database:

• •
  A VECTOR data type stores embeddings in a table column right next to the business data they describe — no separate specialized vector database required.
• •
  A VECTOR_DISTANCE function computes similarity between vectors with a chosen metric (cosine, dot product, Euclidean), enabling similarity search in plain SQL (ORDER BY VECTOR_DISTANCE(...) FETCH FIRST k ROWS ONLY).
• •
  Because vectors live in the same database as relational data, one query can combine semantic similarity with ordinary SQL filters (dates, categories, joins, row-level security) — the headline advantage the exam wants you to know.
• •
  LangChain's Oracle vector store integration (OracleVS) handles inserting chunk embeddings and running similarity searches against 23ai from Python.

3.5 Vector indexes: HNSW vs. IVF

At scale, exact search over every vector is too slow, so approximate-nearest-neighbor indexes trade a sliver of accuracy for large speedups. Oracle 23ai offers two, and their contrast is a guaranteed exam topic:

3.6 Similarity search and retrieval metrics

How "closeness" between a query vector and chunk vectors is measured:

• Cosine similarity/distancethe angle between vectors, ignoring magnitude; the default intuition for text similarity and the most common choice for normalized text embeddings.
• Dot productcombines direction and magnitude; equivalent in ranking to cosine when vectors are normalized to unit length.
• Euclidean (L2) distancestraight-line distance between vector endpoints; smaller = more similar.

Retrieval quality knobs: top-k (how many chunks to return — too few misses evidence, too many adds noise and cost) and the metric must match the one the embedding model was trained for. Use the same embedding model for documents and queries, or the vectors live in incompatible spaces and similarity is meaningless.

3.7 Response generation and conversational memory

The final chain fills a prompt template with the retrieved chunks and the user question, instructs the model to answer only from the provided context, and invokes the OCI chat model. For multi-turn assistants, add memory:

• •
  Chat message history — a record of prior human/AI turns stored per conversation (in-memory objects, database-backed stores, or UI-framework stores such as a Streamlit chat history).
• •
  The history is injected into subsequent prompts so the model can resolve follow-ups ("what about the second one?") — often paired with a step that rephrases the follow-up into a standalone question before retrieval, so the vector search sees a self-contained query.
• •
  Memory is what upgrades a one-shot RAG QA chain into a conversational RAG chatbot.

Part 4 · Using OCI Generative AI RAG Agents Service (20%)

About 10 of 50 questions. OCI Generative AI Agents is the managed counterpart to Part 3: instead of assembling LangChain pipelines yourself, you configure a knowledge base, create an agent, and OCI runs ingestion, retrieval, grounding, citations, and sessions as a service.

4.1 What the Agents service is

The service pairs LLMs with an agent runtime that retrieves from your enterprise knowledge and answers with grounded, cited responses through a chat interface or API. The core RAG agent flow: user asks → agent retrieves relevant chunks from a knowledge base → LLM composes an answer with citations → the conversation continues within a session that preserves context. You manage four resource types: knowledge bases, agents, data sources, and endpoints.

4.2 Knowledge base options: Object Storage, 23ai, OpenSearch

A knowledge base is the agent's data backbone, and choosing among the three supported store types is the domain's signature question:

4.3 Ingestion and hybrid search

For service-managed (Object Storage) knowledge bases, an ingestion job processes the bucket's files: parsing, chunking, embedding, and indexing happen automatically, and you re-run ingestion when source files change — the job picks up new/updated files (and can resume, skipping files that already ingested successfully rather than reprocessing everything).

Hybrid search combines lexical (keyword) search with semantic (vector) search so that a query benefits both from exact term matching (product codes, names, acronyms) and meaning-based matching (paraphrases). This matters most with the OpenSearch knowledge-base path and in tuning retrieval quality: pure semantic search can miss exact identifiers; pure lexical search misses synonyms; hybrid captures both.

4.4 Creating and deploying an agent

The deployment workflow to memorize:

1. 1Create a knowledge base (choose one of the three store types) and attach a data source; run ingestion if service-managed.
2. 2Create the agent, connecting it to the knowledge base and optionally supplying a welcome message and routing/instruction preamble that shapes its behavior.
3. 3Create an endpoint for the agent — the callable access point — choosing options such as whether sessions, tracing, citations, and content moderation are enabled.
4. 4Test in the console chat, then integrate via SDK/API.

IAM policies must grant the service and users access to the relevant resources (buckets, database connections, agent resources) in the compartment — permission-flavored answer options are usually about missing policies.

4.5 Endpoints, sessions, and tracing

• Endpointsexpose the agent to callers; an agent can have one or more endpoints, and endpoint-level switches control the features below.
• Sessionskeep multi-turn context: within a session, the agent remembers earlier turns, enabling follow-up questions. Session behavior is set at endpoint creation (you enable or disable it up front — it is not toggled per request), and idle sessions expire after a configurable timeout (defaults to about an hour of inactivity, extendable up to days).
• Tracingrecords the agent's intermediate steps for each exchange — notably the retrieved chunks and the search/generation steps behind an answer — indispensable for debugging why an agent answered the way it did and for verifying retrieval quality.

4.6 Citations and content moderation

• Citationseach grounded answer carries references to its source material: the source location (for example, the Object Storage file path/URL), title, and where available the page or section of the document the supporting passage came from. Citations let users verify answers — the operational cure for "how do I trust this?" — and can be inspected to confirm the agent used the right documents.
• Content moderationan endpoint-level guardrail that screens harmful content categories on the user input, the generated output, or both, mirroring the base service's moderation (Section 2.10).

4.7 Invoking the RAG agent from a chatbot

Beyond the console chat, applications call the agent programmatically through the Agent Runtime API/SDK:

1. 1.
   Instantiate the runtime client against the agent endpoint's region/ID.
2. 2.
   Create a session (if the endpoint has sessions enabled) — the response includes a session ID and the agent's welcome message.
3. 3.
   Send each user message with a chat request carrying the session ID; receive the answer plus citations (and trace data if enabled).
4. 4.
   Reuse the session ID across turns for context; build the UI with any framework (CLI, web app, Streamlit-style chat) around this loop.

This is the integration pattern for embedding the agent in Slack bots, web chat widgets, and internal tools — the exam checks that you know the order: endpoint → session → chat calls with session ID.

4.8 Service limits and vector retrieval guidelines

Limits questions are shallow but real — know the flavor of constraints rather than chasing every number:

• •
  Regional availability — the Agents service runs in a subset of OCI regions; agent, knowledge base, and endpoint resources live in a region/compartment.
• •
  Resource limits — tenancy-level caps on the number of agents, knowledge bases, data sources, endpoints, and sessions (soft limits that can be raised via service-limit requests).
• •
  Data constraints — service-managed ingestion accepts PDF/TXT up to 100 MB per file; keep individual documents within the size cap and prefer text-extractable PDFs.
• •
  Vector retrieval guidelines (23ai path) — your retrieval function must return results in the expected shape, use a consistent embedding model for documents and queries, and keep chunk sizes sensible so retrieved passages fit the model's context effectively.
• •
  When answers degrade: check ingestion job status, chunking/embedding consistency, retrieval top-k, and tracing output — in that order.

Exam-Day Checklist

Run through this list the night before; every line is a recurring exam answer.

• Architectures: encoder = embeddings/search; decoder = generation/chat; encoder-decoder = translation/seq2seq.
• Prompting: zero-shot = no examples; few-shot/k-shot = examples in prompt; CoT = step-by-step reasoning; in-context learning changes no weights; prompt injection = adversarial override of instructions.
• Adaptation ladder: prompt engineering → soft prompting (learned prompt vectors) → PEFT/T-Few (~0.01% of weights via added layers) → vanilla/full fine-tuning (broad weight updates, catastrophic-forgetting risk). RAG adds knowledge; fine-tuning adds behavior/style.
• Decoding: greedy = argmax; temperature reshapes the distribution (higher = flatter = more random); top-k = fixed shortlist; top-p = nucleus by cumulative probability.
• Hallucination: fluent but ungrounded; mitigated (never eliminated) by RAG, grounding, citations, lower temperature.
• OCI models: chat = Cohere Command + Meta Llama (Cohere supports preamble override); embeddings = Cohere Embed, 1024-dim standard / smaller light, ~512-token inputs, up to 96 inputs per call, multilingual variants for cross-lingual search.
• Parameters: frequency penalty scales with occurrence count; presence penalty is one-time flat; stop sequences end generation; seed gives best-effort reproducibility.
• Clusters: fine-tuning cluster ≈ 2 units, minimum 1 unit-hour; hosting cluster ≥ 1 unit, minimum 744 unit-hours/month; cost = units × hours × unit price; unit type must match the base model.
• Fine-tuning: T-Few = cheap, PEFT, up to ~50 stacked models per hosting cluster; vanilla = deeper adaptation, dedicated capacity per model. Metrics: accuracy up, loss down.
• Security: dedicated GPUs + isolated RDMA network + in-tenancy encrypted weights + IAM policies; no cross-customer sharing; moderation is an endpoint-level setting.
• RAG pipeline: Load → Split → Embed → Store; query-time Embed → Search → Top-k; then grounded generation. Same embedding model for documents and queries.
• 23ai:VECTOR type + VECTOR_DISTANCE (cosine/dot/Euclidean) + SQL filters in the same query. HNSW = in-memory graph; IVF = storage-backed partitions.
• Agents: knowledge bases = Object Storage (service-managed, PDF/TXT ≤ 100 MB), 23ai (custom retrieval function), OpenSearch (bring your own index, hybrid/lexical search). Endpoint → session → chat with session ID. Sessions = user memory; tracing = developer visibility; citations = source-grounded answers.

Finally, treat the weight distribution as your time budget: if you are short on prep time, drill Part 2 (clusters, fine-tuning, parameters, security) first — it alone is worth as much as any two other domains combined.

Official Resources

• Exam page and blueprint: Oracle University — search "1Z0-1127" on education.oracle.com for objectives, registration, and edition notes.
• Free official training: the OCI Generative AI Professional learning path on Oracle MyLearn (mylearn.oracle.com) — includes the full course, demos, skill checks, and a free practice exam; this is the single highest-yield resource because exam questions track its modules closely.
• OCI Generative AI documentation: docs.oracle.com — service concepts, pretrained model cards, dedicated AI cluster sizing/pricing mechanics, fine-tuning parameters.
• OCI Generative AI Agents documentation: docs.oracle.com — knowledge base types, ingestion, endpoints/sessions/tracing, service limits.
• Oracle Database 23ai AI Vector Search documentation: vector data type, VECTOR_DISTANCE, HNSW/IVF index creation.
• LangChain documentation: the OCI Generative AI and Oracle vector store integrations (python.langchain.com).
• OCI Free Tier / LiveLabs: hands-on labs for the Generative AI playground, fine-tuning, 23ai vector search, and Agents — an hour in the console is worth several hours of reading.

Good luck — pass 1Z0-1127 and you hold the credential that proves you can take generative AI from prompt to production on Oracle Cloud.