Environment Setup on OCI

Environment setup on OCI (Oracle Cloud Infrastructure) means preparing the cloud space so you can safely and effectively develop, train, and deploy generative AI models. Think of it as building the workshop before you start making furniture. This chapter covers four main pillars: policies, networking, authentication, and compartments.

Let's start with compartments. A compartment is a logical container that groups related cloud resources. For example, you might have one compartment called 'AI-Development' for all your test models and another called 'AI-Production' for models serving real customers. Compartments help you organise resources, apply cost tracking, and enforce security boundaries. Every single resource in OCI - every compute instance, every storage bucket, every AI model - must belong to exactly one compartment.

Next, policies. A policy in OCI is a document written in a simple language that declares who can do what to which resources. For example, a policy might say 'Allow group AIDevelopers to manage ai-service-family in compartment AI-Development'. The word 'manage' means full control - create, read, update, delete. Other verbs include 'use' (read and use but not delete) and 'read' (view only). Policies are written at the tenancy level or within a compartment and they cascade down. If you get the policy wrong, either developers cannot access the models they need, or unauthorised users can tamper with your AI workloads.

Networking is the third major piece. For generative AI, you typically need a Virtual Cloud Network (VCN) - your private slice of the OCI network. Inside the VCN, you define subnets (smaller network segments), security lists (firewall rules that control traffic in and out), and internet gateways (to allow your model to access public APIs or to be accessed by users). For example, a generative AI model that calls the external OpenAI API needs a route from its subnet to an internet gateway. Conversely, a model that only serves internal corporate users might sit in a private subnet with no internet access, connected only through a VPN or FastConnect.

Authentication is what proves you are who you say you are. OCI supports several methods: username and password, API keys (for programmatic access), instance principals (where a compute instance itself has an identity), and federation with external identity providers such as Microsoft Entra ID. For generative AI development, you often use API keys to let your code call OCI AI services like the Generative AI service. You must securely store these keys - never hard-code them in your source code.

Finally, there is Identity and Access Management (IAM). IAM is the umbrella service that manages users, groups, compartments, and policies together. You create users (people or services), put them into groups (like AIDevelopers or AIAdmins), then write policies that assign permissions to those groups. The policy engine evaluates every request - if no policy explicitly allows an action, it is denied by default.

Why does all of this matter for generative AI? Because AI models consume data, produce outputs, and often need to access other cloud services like Object Storage (for training data) or the OCI Data Science service. Without proper environment setup, your model might fail with 'permission denied' errors, your training data might be exposed to the public internet, or your costs might spiral because resources are shared across teams. OCI enforces a 'least privilege' security model by default - meaning resources start with no permissions, and you explicitly grant what is needed. This is opposite to older on-premise systems where everything was open by default.

Setting up an environment correctly also means planning for disaster recovery and compliance. For example, if you are building a healthcare AI chatbot, your compartment might have a policy that prevents any data from leaving the region. This is achieved through network security rules and IAM policies that block egress traffic. The exam expects you to know the exact policy syntax and network components needed for a generative AI workload.

An IT professional tasked with setting up an OCI environment for generative AI development follows a structured process. Let's walk through a realistic scenario: a company called 'HealthAssist AI' wants to build a generative AI model that drafts patient follow-up emails from doctor notes.

Step 1: The cloud architect creates a root compartment called 'HealthAssist-Tenancy'. Inside it, they create three child compartments: 'HealthAssist-Dev', 'HealthAssist-Test', and 'HealthAssist-Prod'. This isolates development work from production, so a bug in a development script cannot accidentally delete production patient data.

Step 2: The architect creates IAM groups. A group called 'AI-Engineers' for the development team, and another called 'AI-Admin' for the lead architect. They create users for each team member and add them to the correct group.

Step 3: They write policies. For the AI-Engineers group in the Dev compartment, the policy says: 'Allow group AI-Engineers to manage ai-service-family in compartment HealthAssist-Dev'. For the AI-Admin group, a tenancy-level policy says: 'Allow group AI-Admin to manage all-resources in tenancy'. This gives admins full control while restricting engineers.

Step 4: Networking is configured. They create a VCN with a CIDR block of 10.0.0.0/16. Inside, they create three subnets: a public subnet for the web front-end, a private subnet for the AI model compute instances, and a third private subnet for a database. An internet gateway is attached to the VCN, but only the public subnet has a route to it. The private subnets route traffic through a NAT gateway for outbound internet access (to download model libraries) but are not directly reachable from the internet.

Step 5: Security lists are defined. The public subnet allows incoming HTTPS traffic from the internet. The private AI subnet allows incoming traffic only from the public subnet on port 8080 (the model API port). The database subnet allows incoming traffic only from the AI subnet on port 1521 (Oracle DB). This is a classic three-tier architecture.

Step 6: Authentication for the AI model itself. The developer writing the model code wants it to access an Object Storage bucket containing training data. Instead of hard-coding API keys, they create an instance principal - a special identity assigned to the compute instance. They then write a policy allowing that instance principal to read objects from the bucket. This is more secure than keys.

Step 7: Testing the setup. The developer launches a small test model. If the model can access the data and respond to API requests, the environment is working. Common issues include a missing route rule (the model cannot reach the internet), a policy that is too restrictive (denying access to the AI service), or a security list blocking the API port.

Throughout this process, the IT professional uses the OCI Console (web interface) for initial setup, then switches to the CLI (command line interface) or Terraform (infrastructure as code) for repeatable deployments. They also enable Cloud Logging to audit who did what - crucial for compliance in healthcare.