1. OCI Fundamentals

The physical and logical building blocks of Oracle Cloud Infrastructure, and the tenancy and compartment structure that every enterprise deployment stands or falls on.

What OCI is

Oracle Cloud Infrastructure is Oracle's public cloud: on-demand compute, storage, networking, database, and platform services delivered from Oracle-operated data centers, consumed over the network, and billed by usage. Compared to Oracle's first-generation cloud, OCI ("Gen 2") was rebuilt with an off-box network virtualization design - the virtualization and network isolation run on separate hardware from the customer's compute, which is the basis for its bare-metal offerings and its network isolation guarantees.

Practically, OCI gives you four things that matter to an enterprise Oracle shop:

• Real bare metal - you can rent an entire physical server with no hypervisor, which matters for licensing and for the highest-performance database workloads.
• Exadata as a cloud service - the same engineered system you may run on-premises, delivered as Base Database, Exadata Database Service, or Exadata Cloud@Customer.
• Autonomous Database - a self-managing database platform where Oracle runs patching, tuning, backup, and scaling.
• A flat, predictable network - a non-blocking, low-latency backbone with off-instance network virtualization.

OCI global architecture

Regions, Availability Domains, Fault Domains

Home region and subscriptions

When you sign up you pick a home region. IAM resources (users, groups, policies, dynamic groups, compartments, federation, and in the legacy model the tenancy's identity metadata) are mastered in the home region and replicated read-only to subscribed regions. You then subscribe the tenancy to additional regions to deploy workloads there.

• You cannot change the home region after it is set. Choose deliberately - it should be a region close to your identity administrators and one you intend to keep long-term.
• IAM writes (create a user, edit a policy) always go to the home region and propagate out. A home-region outage can therefore affect identity administration globally even while workloads keep running.
• Subscribing to a region is easy; unsubscribing is not - plan region subscriptions rather than turning them on casually.

Tenancy and compartments

Your tenancy is the root container for your entire OCI account - it is itself the root compartment. Everything lives under it.

Compartments are logical containers for resources (compute, VCNs, buckets, databases). They are the primary unit of access control, isolation, quota, and cost tracking. Key properties that trip people up coming from AWS/on-prem:

• Compartments are global, not regional. A compartment exists across all subscribed regions; the resources inside it are regional.
• Compartments are logical, not a network boundary. Two instances in different compartments can talk over the network if the VCN/subnet/security rules allow it. Isolation is by IAM policy, not by compartment walls.
• Compartments can be nested (up to six levels deep). Policies and quotas can be scoped at any level.
• Resources can be moved between compartments (most, not all), but some have caveats. Deleting a compartment requires it be empty and is asynchronous.

Limits, quotas, and service limits

Quota statements look like policy but control resource counts. Example that blocks expensive shapes in a Dev compartment:

# Applied in the Dev compartment (Governance > Quotas)
zero compute-core-count-standard-e5-quota in tenancy
set compute-core-count-standard-e4-quota to 64 in tenancy
# Deny all bare-metal database shapes in this compartment
zero database-dbcs-quota in tenancy

Resource OCIDs

Every OCI resource has a globally unique Oracle Cloud Identifier (OCID). You will use these constantly in CLI, Terraform, and support tickets. The format is readable:

ocid1.instance.oc1.us-ashburn-1.anuwcljr...abcd1234
   |        |      |       |            |
 version  type   realm   region     unique id (opaque)

• The type segment (instance, vcn, bucket, database, compartment, user, policy...) tells you what the resource is at a glance.
• Some resources are regionless (users, groups, compartments, policies) - their OCID has no region segment.
• OCIDs are stable for the life of the resource; scripts and Terraform state key off them.

Tags: freeform, defined, and namespaces

Ways to work with OCI

What to decide before production

• Home region - irreversible. Pick with identity-admin proximity and long-term intent in mind.
• Realm - commercial vs. government/dedicated - usually contractual, but confirm it matches your compliance needs.
• Tenancy strategy - single tenancy with compartments, or separate Prod/non-Prod tenancies.
• Compartment topology - environment vs. BU vs. hybrid; where shared services and security live.
• Identity domain strategy - default domain vs. multiple domains, and federation to your IdP (see section 2).
• Network CIDR plan - non-overlapping with on-premises and future regions (see section 3). This is very hard to change later.
• Tag model - defined tags + namespaces + tag defaults for cost and governance.
• Guardrails - compartment quotas, budgets, Security Zones, Cloud Guard baseline.
• DR region and RTO/RPO targets - which region, which DR pattern per tier.

2. Identity and Access Management

Who can do what, to which resources, in which compartment. IAM is where most OCI security incidents and access-denied tickets originate, so this section goes deep on the policy language, identity domains, and least-privilege design.

The IAM model

Modern OCI IAM runs inside Identity Domains - each domain is an isolated identity and access management container with its own users, groups, applications, and security settings (its lineage is Oracle Identity Cloud Service). A tenancy has a Default domain and can have additional domains. Within a domain you have users and groups; across the tenancy you have compartments and policies that reference those groups.

The evaluation is simple to state and important to internalize: a request is allowed only if at least one policy statement permits it; otherwise it is denied. There are no "deny" statements in classic IAM policy - you control access by what you grant and to which compartment. (Deny-style controls come from other layers: Security Zones, quotas, and network rules.)

Users, groups, and dynamic groups

ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaa...'}

Policy syntax

A policy is a named collection of statements living in a compartment (or the tenancy). Every statement follows this grammar:

Allow <subject> to <verb> <resource-type> in <location> [where <conditions>]

# subject:        group Admins | dynamic-group AppServers | any-user | group DomainName/Admins
# verb:           inspect | read | use | manage
# resource-type:  instances | virtual-network-family | object-family | database-family | all-resources
# location:       tenancy | compartment Prod | compartment Prod:AppTier
# conditions:     where request.region = 'us-ashburn-1'

Where the policy lives matters: a policy attached to a compartment can only grant access to that compartment and its children. Tenancy-level policies can grant anywhere, which is exactly why you should minimize them.

Verbs and resource types

The four verbs are cumulative - each includes everything in the ones before it, plus more permissions.

Resource types can be individual (instances, buckets, subnets) or aggregate family types that bundle related resources:

• virtual-network-family - VCNs, subnets, route tables, security lists, gateways, NSGs, DRGs.
• database-family - DB systems, databases, backups, Data Guard, etc.
• object-family - buckets and objects.
• instance-family - compute instances, images, boot/block volume attachments.
• all-resources - everything. Use with extreme care (see mistakes).

Conditions in policies

Conditions add a where clause that must be true for the statement to apply. They reference request/target variables.

# Restrict admin actions to a single region
Allow group NetAdmins to manage virtual-network-family in tenancy
  where request.region = 'us-ashburn-1'

# Only allow managing resources tagged for a given cost center
Allow group ProjectX to manage instances in compartment Workloads
  where target.resource.tag.Finance.CostCenter = 'CC-4412'

# Restrict to a specific resource type via request.operation (fine-grained)
Allow group Operators to use instances in compartment Prod
  where request.operation = 'InstanceAction'   # start/stop/reset, not delete

Instance principals and resource principals

These solve the "how does my code authenticate to OCI without storing keys" problem - the single most important security improvement most teams can make.

# Let all instances in AppCompartment read objects in a specific bucket's compartment
Allow dynamic-group AppServers to read objects in compartment Data
  where target.bucket.name = 'app-artifacts'

# CLI using instance principal - no ~/.oci/config keys needed
oci os object list --bucket-name app-artifacts --auth instance_principal

Identity domains, federation, SSO, MFA

Identity domains are self-contained IAM stacks in your tenancy. Each has its own users, groups, password policy, MFA settings, sign-on policies, and federation config.

• Default domain - created with the tenancy; where the initial administrator lives.
• Additional domains - useful to separate, for example, employees from external partners, or Prod-admin identities from Dev identities, each with their own MFA/sign-on rules. Domains also come in types/licensing tiers (Free, Oracle Apps, Premium, External User) that affect available features - verify current tiers.
• Federation / SSO - connect an external IdP (Microsoft Entra ID, Okta, ADFS, Ping) via SAML or OIDC so users sign in with corporate credentials. Map IdP groups to domain groups; policies reference the domain groups.
• MFA - enforced via sign-on policies in the domain. Require MFA for all human users, especially administrators. Exempt only automated service identities that use API keys/principals, not passwords.

Credential types

Real policy examples

Allow group Auditors to inspect all-resources in tenancy
Allow group Auditors to read audit-events in tenancy

Allow group AppOperators to read instance-family in compartment Prod
Allow group AppOperators to use instances in compartment Prod
  where request.operation = 'InstanceAction'

Allow dynamic-group AppServers to read objects in compartment Data
  where target.bucket.name = 'app-config'

Allow group BU_A_Admins to manage all-resources in compartment BU-A

Common OCI IAM mistakes

IAM troubleshooting

oci iam policy list --compartment-id <compartment-ocid> --all
oci iam group list-users --group-id <group-ocid>
oci iam dynamic-group get --dynamic-group-id <dg-ocid>

3. Networking Deep Dive

The VCN is the foundation every other OCI service plugs into. This section covers CIDR planning, subnets, gateways, security rules, hybrid connectivity, DNS, and the traffic-flow reasoning you need to design and debug real networks.

VCN and CIDR planning

A Virtual Cloud Network is a regional, private network. You assign it one or more CIDR blocks (RFC 1918 private ranges are standard; you can also use public ranges you own). Everything - instances, load balancers, databases, mount targets, private endpoints - gets an IP from a subnet inside the VCN.

• A VCN can have multiple CIDR blocks, added after creation, which helps when you outgrow the first block. But you cannot shrink or trivially renumber - plan generously.
• VCN CIDRs and subnet CIDRs must not overlap with each other, with peered VCNs, or with your on-premises networks. Overlap is the number-one cause of hybrid connectivity that "connects but cannot route."
• Reserve non-overlapping space for every region and every environment you might ever run, plus DR. Treat it like an enterprise IP address plan, because it is one.

Subnets

Gateways - the only ways out of a VCN

Security lists vs. Network Security Groups

Both are evaluated. A packet is allowed if either the applicable security lists or the NSGs permit it (they are additive for allows; there is no deny rule - you allow what you need and everything else is implicitly denied). Effective rules = union of all security lists on the subnet + all NSGs on the VNIC.

IPs, VNICs, and secondary addresses

DNS and DHCP

• VCN Resolver - each VCN has a built-in DNS resolver at 169.254.169.254. It resolves internal hostnames and forwards public queries.
• Private DNS zones/views - create private zones for custom internal names, and use the resolver's endpoints/forwarding rules to integrate with on-premises DNS (conditional forwarding both ways for hybrid name resolution).
• DHCP options - per-subnet; controls whether instances use the VCN resolver or a custom resolver, and the search domain. Point at custom resolvers when integrating enterprise DNS.

How traffic flows in OCI

For any packet leaving an instance, OCI decides the path in this order:

1. Is the destination inside the VCN? If yes, it routes locally (no gateway) - only security rules apply. Intra-VCN routing is automatic.
2. If outside the VCN, the subnet's route table is consulted for the most specific matching rule → picks a gateway (IGW, NAT, Service, DRG, LPG).
3. Security rules (security lists + NSGs on the VNIC) must allow the egress, and the return path must be allowed (stateful handles the return automatically).
4. At the destination side, the same security-rule check happens for ingress.

Debugging almost always comes down to three questions: Is there a route to the right gateway? Do the security rules allow it both ends? Is there a return path?

Reference diagrams

Three-tier architecture (public LB, private app, private DB)

Hub-and-spoke with DRG

Service Gateway to Object Storage (private backend/backups)

On-premises to OCI hybrid (VPN + FastConnect)

Hybrid connectivity: VPN vs FastConnect

Flow logs, path analysis, and packet capture

Network Firewall and Web Application Firewall

• Network Firewall - a managed, OCI-native firewall (Palo Alto-based) you place in a hub VCN to inspect north-south and east-west traffic: stateful filtering, IPS/IDS, URL filtering, TLS inspection. Route spoke traffic through it via the DRG hub.
• Web Application Firewall (WAF) - Layer-7 protection (OWASP rules, bot management, rate limiting) applied in front of public HTTP endpoints, either as an edge/policy attached to a load balancer or as an edge service. Covered further in section 8.

Networking troubleshooting

oci network route-table get --rt-id <ocid>
oci network security-list get --security-list-id <ocid>
# on the instance:
curl -s https://ifconfig.me ; sudo firewall-cmd --list-all

nslookup db.internal.example.com 169.254.169.254
cat /etc/resolv.conf   # confirm which resolver the OS uses

OCI Networking gotchas

4. Compute Deep Dive

Shapes, images, placement, scaling, and the operational patterns for running application and database compute in OCI - including how to pick shapes and how licensing interacts with instance choice.

Shapes: OCPU, memory, flexible

• OCPU vs vCPU: OCI historically measures CPU in OCPUs. One OCPU = one physical core = two hardware threads (vCPUs) on x86. Oracle Database licensing counts cores, so 1 OCPU generally corresponds to the licensing unit for a core (subject to the core factor). Newer shapes may also be expressed in vCPUs - confirm the unit for the exact shape.
• Flexible shapes (e.g. the E-series AMD, and Ampere Arm A-series) let you choose OCPU count and memory GB independently, within per-OCPU memory ranges. You pay for what you allocate.
• Fixed shapes come in preset sizes (older standard shapes, some bare metal, GPU shapes).
• Processor families: AMD EPYC (E-series), Intel Xeon (X/Standard), Ampere Arm (A-series, strong price/performance for scale-out and cloud-native), and NVIDIA GPU shapes for AI/ML.

Bare metal vs virtual machines

Dedicated hosts, capacity reservation, preemptible

Images, custom images, and cloud-init

• Platform images - Oracle Linux, and other OSes maintained by Oracle.
• Custom images - capture a configured instance as an image for repeatable launches (golden images).
• Bring Your Own Image (BYOI) - import a supported OS image; must meet OCI's paravirtualized/emulated driver requirements.
• cloud-init - pass a startup script (user data) that runs on first boot to configure the instance (install agents, mount volumes, join config management). The standard way to bootstrap without baking everything into an image.
• Instance metadata service - at 169.254.169.254, exposes instance metadata and is how instance principals fetch credentials. Restrict access to it inside the OS where appropriate.

# Example cloud-init passed as user_data (base64) to bootstrap an app host
#cloud-config
package_update: true
packages: [oracle-instantclient-basic, jq]
runcmd:
  - [ systemctl, enable, --now, myapp ]
  - [ /opt/app/register-with-lb.sh ]

Placement, fault domains, and HA

High availability for compute is about anti-affinity: never put both halves of an HA pair on the same failure unit.

• In a multi-AD region: spread across ADs for data-center-level resilience, and across FDs within each AD.
• In a single-AD region: spread across the three fault domains - that is your in-region HA. DR to another region covers AD/region loss.
• Instance pools distribute instances across FDs/ADs automatically per the placement configuration.
• Live migration: for supported VM shapes, OCI can live-migrate your VM off hardware needing maintenance, avoiding a reboot; some events still require a reboot-migration you schedule. Bare metal you always manage yourself.

Autoscaling, instance pools, and configurations

Choosing shapes by workload

Operational guidance

OS management, patching, and recovery

• OS Management (Hub) - manage OS updates/patch compliance across fleets of Oracle Linux (and other) instances from OCI.
• Serial console connection - out-of-band access for recovery.
• Instance recovery - stop/start moves the VM to healthy hardware; for corrupted OS, rescue via boot-volume detach/attach.

Compute troubleshooting quick runbook

oci compute instance get --instance-id <ocid> --query 'data."lifecycle-state"'
oci compute instance-console-connection create --instance-id <ocid> --public-key-file key.pub
oci compute instance action --instance-id <ocid> --action SOFTRESET

5. Storage Deep Dive

Block, Object, and File storage in OCI - their performance models, backup and replication behavior, and the decision of which to use for databases, shared file systems, backups, archives, and data lakes.

The three storage services

Block volumes and boot volumes

• Boot volume - the OS disk created with an instance. Can be backed up, cloned, and detached for rescue.
• Block volume - additional data disks. Attach via iSCSI or paravirtualized; multi-attach for shared-disk clusters (e.g. some RAC/HA configs).
• Performance tiers (VPU/GB): Lower Cost, Balanced, Higher Performance, and Ultra High Performance - set by Volumes Performance Units (VPU) per GB. Higher VPU = more IOPS and throughput per GB. Auto-tune can lower performance (and cost) when a volume is detached/idle and raise it when in use.
• Volume groups - group volumes (e.g. all of a DB's volumes) so backups/clones are crash-consistent across the set.
• Backups - full or incremental, policy-based (scheduled), and can be copied cross-region for DR. Clones are instant copy-on-write; replication keeps a volume asynchronously mirrored to another region.

Object Storage

• Namespace - a tenancy-wide unique container name; buckets live in it, scoped to a compartment and region.
• Storage tiers: Standard (hot, frequent access), Infrequent Access (cheaper storage, retrieval fee), Archive (cheapest, must be restored before reading, with a restore delay). Auto-Tiering can move objects between Standard/IA based on access.
• Multipart upload - upload large objects in parallel parts; required/recommended for big files (backups, images).
• Pre-Authenticated Requests (PARs) - time-boxed URLs granting access to a bucket/object without IAM credentials - handy but a sharing risk if leaked.
• Lifecycle rules - auto-transition objects to Archive or delete them after N days.
• Retention rules & versioning - retention locks objects against deletion for a period (WORM-style, supports compliance); versioning keeps prior versions.
• Replication - asynchronously replicate a bucket to another region/bucket for DR.

File Storage Service (FSS)

• File system - the NFS-exported filesystem; grows automatically, snapshots supported.
• Mount target - the NFS endpoint (with a private IP in your subnet) that instances mount. It carries the export set.
• Export paths & NFS export options - control which CIDRs/hosts can mount, and with what access (read/write, root squash).
• Snapshots - point-in-time, space-efficient; replication mirrors a file system to another region for DR.

When to use which

Practical examples

Data transfer options

• Data Transfer Service (disk/appliance) - ship physical media/appliances to Oracle to bulk-load very large datasets when network transfer is impractical.
• Online - CLI/SDK multipart upload, oci os object bulk-upload, or Storage Gateway-style/rclone tooling for ongoing sync.

Storage gotchas

6. Database Services Deep Dive

OCI's database portfolio, from self-managed IaaS through Base Database and Exadata to fully-managed Autonomous - what each one manages for you, how HA/DR/backup/patching differ, and how to choose.

The portfolio at a glance

Service deep dives

Database service decision table

How HA and DR work across services

Patching and backup differences

Data tooling and operations

Licensing: BYOL vs License Included

Enterprise examples

7. Load Balancing and Traffic Management

The Layer-7 Load Balancer and Layer-4 Network Load Balancer, their listeners/backend sets/health checks, SSL handling, routing, and a disciplined approach to the most common failure: unhealthy backends.

Load Balancer vs Network Load Balancer

Both come in public (internet-facing, in a public subnet) and private (internal, in a private subnet) variants.

Anatomy: listeners, backend sets, backends, health checks

• Listener - the front-end port/protocol (e.g. 443/HTTPS). Handles SSL, routing rules, and WAF.
• Backend set - a group of backends plus the balancing policy (round robin, least connections, IP hash) and the health check definition.
• Backend - an actual server (IP:port), weighted, drained gracefully during maintenance.
• Health check - protocol/port/path/interval defining "healthy." Unhealthy backends are pulled from rotation.
• Session persistence - cookie-based (LB-generated or app cookie) or IP-based, to pin a client to a backend.

SSL termination, end-to-end SSL, certificates

Hostname and path-based routing

• Hostname-based routing - one LB serves multiple virtual hosts (api.example.com vs app.example.com) to different backend sets.
• Path-based routing - route by URL path (/api/* → API backends, /static/* → static backends).
• Rule sets - header manipulation, redirects (HTTP→HTTPS), access control by source.
• Logging - enable access and error logs to the Logging service for traffic analysis and troubleshooting.

When to use which

Load balancer troubleshooting

8. Security Deep Dive

Defense in depth on OCI: identity, network, data, and detective controls - plus concrete guidance for securing a production tenancy, databases, Object Storage, and public endpoints, ending in a production security checklist.

Security design principles

• Least privilege - lowest verb, narrowest resource type, lowest compartment, conditions where useful. Separate admin/operator/read-only.
• Reduce blast radius - compartments, separate VCNs, separate keys per classification, break-glass isolation.
• Private by default - no public IPs unless required; front-facing only via LB/WAF; Bastion for admin access.
• Encrypt everywhere - at rest (TDE, block/object/file encryption) and in transit (TLS); customer-managed keys for sensitive data.
• Guardrails over guidelines - Security Zones and quotas that prevent misconfiguration beat policies that merely recommend it.
• Assume breach - detect and audit - Cloud Guard, Audit (immutable), Logging, alarms on anomalies. You cannot respond to what you cannot see.

The control layers

Vault: keys, secrets, certificates

• Vault - managed key management (KMS/HSM-backed). Create keys for TDE, block/object/file encryption, and app-level crypto.
• Oracle-managed vs customer-managed keys - Oracle-managed is default and simplest; customer-managed lets you control rotation and revoke access to encrypted data by disabling the key. Vaults can be software or HSM-protected (higher assurance).
• Secrets - store DB passwords, API tokens, wallets as versioned secrets; apps fetch them at runtime via principals - never bake secrets into images or code.
• Certificates - managed TLS certs and CAs for load balancers and services, with rotation.

Cloud Guard, Security Zones, Vulnerability Scanning

Data and database security

• Encryption at rest - on by default for block/boot/object/file storage and databases (TDE). Choose customer-managed keys for sensitive data.
• Encryption in transit - TLS for service endpoints; native network encryption / TLS for DB connections; ADB uses mTLS wallets.
• Data Safe - security assessment, user risk assessment, sensitive data discovery, dynamic/static masking (for non-prod copies), and DB activity auditing. The first tool to point at any production database.
• Database Vault (where licensed) - realms and separation of duties so even DBAs cannot read application data.
• Audit - the tenancy Audit service records all API calls (control-plane) immutably; combine with DB-level and OS logs.

How to secure specific things

Production OCI security checklist

• Human access federated to corporate IdP; MFA enforced for all users and especially admins.
• Break-glass local admins created, credentials sealed, every login alarmed.
• IAM least privilege: roles split (admin/operator/read-only), scoped to compartments, no broad manage all-resources in tenancy.
• Workloads use instance/resource principals - no long-lived API keys stored on hosts.
• Cloud Guard enabled tenancy-wide with notifications and responders configured.
• Production compartments enrolled in Security Zones with appropriate recipes.
• Vulnerability Scanning enabled for instances and container images.
• No unintended public IPs; databases and app tiers in private subnets; Bastion for admin access.
• WAF in front of public HTTP endpoints; Network Firewall inspecting hub traffic.
• All data encrypted at rest; customer-managed keys in Vault for sensitive data; keys rotated.
• Vault holds all secrets/wallets; nothing sensitive in images, code, or env files.
• Object Storage buckets private; versioning + retention on backup/compliance buckets.
• Data Safe assessments run; non-prod data masked; DB activity auditing on.
• Audit log retention configured; logs centralized via Service Connector Hub.
• Alarms on privilege/policy/network changes and anomalous access.
• Compartment quotas + budgets as guardrails; everything tagged with data-classification.
• DR and backups tested (restores verified), including key availability in the DR region.

Compliance basics

OCI maintains a broad set of certifications/attestations (SOC, ISO, PCI, HIPAA, FedRAMP/Gov in the relevant realms - verify current scope). Your responsibility is configuring services to meet your obligations: data residency (region/realm choice), encryption with controlled keys, access logging, and evidence. Cloud Guard and Security Zones help demonstrate continuous compliance; Audit provides the evidence trail.

9. Observability, Monitoring, and Operations

Metrics, alarms, logs, events, and the operational tooling to run OCI day-2 - including what to monitor per service, how to build useful alarms, and how to avoid drowning in noise.

The observability stack

What to monitor per area

Building useful alarms

• Alarm on symptoms users feel (LB 5xx, unhealthy backends, DB down, high latency), not only causes.
• Use appropriate statistics and windows (e.g. mean over 5 min, not a single spike) and a sensible trigger duration to avoid flapping.
• Set severity and route: critical → page; warning → ticket/Slack; info → dashboard only.
• Use absence alarms for "should always report" signals (heartbeat, backup completion).
• Tag alarms by service/team so ownership is clear.

# MQL: alarm when average CPU across an instance exceeds 85% for 5 min
CpuUtilization[5m]{resourceId = "ocid1.instance.oc1..xxxx"}.mean() > 85

# MQL: alarm when any backend set has unhealthy backends
UnHealthyBackendServers[1m].max() > 0

# Absence alarm: no metric reported for 10m (agent/host down)
CpuUtilization[10m].absent()

Example alarms to implement

Avoiding noisy alerts

Operational dashboards and reports

• Build Console dashboards (and Logging Analytics dashboards) per audience: an on-call "is anything on fire" view, a service-owner view, and an exec/cost view.
• Use Service Connector Hub to ship logs/metrics to Object Storage for retention or to your enterprise SIEM.
• Turn on Cost and usage reports and pair with Budgets (section 14) for a spend dashboard.
• Resource Manager + drift detection to monitor infrastructure conformance.

10. Containers, Kubernetes, and Cloud Native

OKE, Container Instances, Functions, and the event-driven building blocks - when to use each, how networking and IAM work for containers, and reference patterns for microservices and serverless.

The cloud-native services

OKE deep dive

• Control plane - managed by Oracle (you don't run etcd/API servers). Choose Basic or Enhanced clusters (enhanced adds features like more add-ons, workload identity, higher limits, SLA).
• Node pools - groups of worker nodes (managed VMs/BM) with a shape and image; scale and upgrade per pool.
• Virtual nodes - serverless worker capacity where Oracle manages the node lifecycle (you don't patch/scale VMs); pods run without you managing the underlying node.
• Networking - OKE uses VCN-native pod networking (pods get VCN IPs) or flannel overlay; plan subnet CIDRs to have enough IPs for pods and nodes.
• Load balancing - a K8s Service of type LoadBalancer makes OKE provision an OCI Load Balancer (or NLB via annotation); Ingress controllers front HTTP routing.
• Storage - CSI driver provisions Block Volumes as PVs; FSS for shared RWX volumes.
• IAM - workload identity - map K8s service accounts to OCI dynamic groups so pods call OCI APIs via resource principal, no keys in the pod.

# Expose a deployment via an OCI Network Load Balancer from Kubernetes
apiVersion: v1
kind: Service
metadata:
  name: web
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"   # or omit for L7 LB
    oci-network-load-balancer.oraclecloud.com/security-list-management-mode: "None"
spec:
  type: LoadBalancer
  selector: { app: web }
  ports: [ { port: 443, targetPort: 8443 } ]

OKE vs Functions vs Container Instances vs Compute

Networking, IAM, and security for containers

• Networking - clusters live in a VCN; control-plane/worker/pod/LB subnets with the right security rules. Private clusters keep the API endpoint off the internet.
• IAM - cluster admins via IAM policy; in-cluster RBAC for K8s objects; workload identity for pod → OCI API access.
• Image security - scan images in OCIR (Vulnerability Scanning); sign/verify; least-privilege pull secrets or instance principals.
• Runtime security - network policies, pod security standards, secrets from OCI Vault (via CSI/secret store), and Cloud Guard over the tenancy.
• Monitoring - cluster/node/pod metrics to Monitoring; container logs to Logging; APM for tracing.

Architecture patterns

• Microservices on OKE - deployments behind Ingress/LB, HPA autoscaling, service mesh for mTLS/traffic control, DevOps pipelines deploying images from OCIR, secrets from Vault, workload identity for OCI access.
• Serverless function triggered by Object Storage event - as diagrammed; ideal for image processing, ETL kick-off, validation.
• Event-driven architecture - Events + Streaming + Functions + Queue + Notifications for decoupled, resilient pipelines.
• Container deployment pipeline - DevOps build pipeline (from managed Git or GitHub) → image to OCIR (scanned) → deployment pipeline to OKE/Functions/Container Instances, gated by approvals.

Troubleshooting: OKE pod not starting

kubectl describe pod <pod>        # events explain Pending/ImagePull
kubectl logs <pod> --previous     # crash reason
kubectl get nodes -o wide          # capacity / readiness
oci ce cluster get --cluster-id <ocid>

11. Analytics, Data, and Integration

The services that move, catalog, transform, and analyze data on OCI, and the common data-lake, warehouse, streaming, and CDC patterns built from them.

The services

Common data patterns

Reference architecture: lakehouse + BI

12. AI, ML, and Generative AI on OCI

OCI's AI stack - Generative AI, Agents, AI Vector Search in the database, Data Science, and the pretrained AI services - plus the enterprise RAG patterns and the governance guardrails that separate a demo from something you can run on real business data.

The AI services

AI Vector Search in Oracle Database

Oracle Database 23ai/26ai adds a native VECTOR data type and vector indexes so you store embeddings in the same database as your relational data and run similarity search with SQL. For an Oracle shop this is significant: no separate vector database to operate, and you can combine semantic search with normal SQL filters, joins, and existing security.

-- Store document chunks with their embedding vectors
CREATE TABLE doc_chunks (
  id        NUMBER PRIMARY KEY,
  doc_id    NUMBER,
  chunk     CLOB,
  embedding VECTOR(1024, FLOAT32)
);

-- Retrieve the 5 most similar chunks to a query embedding (RAG retrieval)
SELECT id, doc_id, chunk
FROM   doc_chunks
ORDER  BY VECTOR_DISTANCE(embedding, :query_vec, COSINE)
FETCH FIRST 5 ROWS ONLY;

RAG architecture on OCI

Enterprise patterns

Governance and security for GenAI

• Serving layer, always - agents and LLMs call a governed API/service that enforces authentication, authorization, rate limits, input/output validation, and logging. They do not touch data stores directly.
• Entitlement-aware retrieval - filter retrieved context to what the requesting user is allowed to see (row/document-level), so RAG cannot leak data across users.
• Private connectivity - keep model and data traffic on private endpoints / the OCI backbone; dedicated AI clusters for isolation where required.
• Credential hygiene - secrets in Vault, access via principals; the model never sees raw credentials.
• Auditability - log prompts, retrieved context IDs, and responses (subject to privacy rules) so answers are explainable and reviewable.
• Human validation - outputs that drive business decisions or changes are reviewed before use; agents that act get approval gates.

Warnings (read before connecting AI to enterprise data)

Cost and endpoint considerations

• On-demand vs dedicated AI clusters - on-demand inference is pay-per-use and simple; dedicated clusters give isolation, predictable throughput, and fine-tuning, at a fixed cost. Match to volume and isolation needs.
• Embedding jobs are a real cost at scale - batch and cache embeddings; re-embed only changed content.
• Token/context size drives cost and latency - retrieve the smallest sufficient context, not everything.
• Region/model availability - models and dedicated-cluster availability vary by region; verify before designing.

13. Migration and Disaster Recovery

Getting workloads into OCI, and keeping them recoverable once there - the migration tooling, the DR patterns by tier, and how RTO/RPO drive the architecture and cost.

Migration tooling

Database migration paths

DR patterns

Building blocks: Data Guard / Active Data Guard and Autonomous Data Guard for databases; Object/Block/File replication for storage; cross-region image copy for compute; DNS failover and load balancers for traffic redirection; Full Stack Disaster Recovery to orchestrate the whole failover as a plan you can run and test.

RTO and RPO - the two numbers that drive everything

• RTO (Recovery Time Objective) - how long you can be down. Drives standby readiness (running vs. cold) and automation.
• RPO (Recovery Point Objective) - how much data you can lose. Drives replication mode: async (small lag), SYNC/Far Sync (zero data loss), or backup interval (large).
• Zero-data-loss (RPO 0) needs SYNC transport (Data Guard Maximum Protection/Availability, often via a Far Sync instance) - which requires low latency between sites and has performance implications. Confirm the network and the trade-off.

Architecture examples

• On-prem Oracle DB → OCI: ZDM/Data Guard over FastConnect, cut over in a window, keep on-prem as fallback briefly.
• EBS → OCI: migrate DB (Base/Exadata) + rebuild app tier + shared FSS; DNS cutover; validate certification.
• VM → OCI: custom image import/rebuild; block volume replication for large data disks.
• Cross-region DR (app): warm standby + DNS/LB failover + storage replication.
• Cross-region DR (database): Active Data Guard (or Autonomous Data Guard) with configurable failover.
• Backup-based DR: cross-region backup copies; rebuild in DR on demand (lowest cost, highest RTO).
• GoldenGate-based DR: when heterogeneous or active/active-ish read serving is required.

DR testing

• Standby database is applying and within RPO (monitor apply lag).
• Encryption keys/wallets present and usable in the DR region.
• App tier can start and connect in DR; config points to DR endpoints.
• DNS/LB failover mechanism tested and time-measured.
• Storage (buckets/volumes/FSS) replication within RPO.
• Runbook current; roles assigned; switchover rehearsed on a schedule.
• Capacity available in DR (reservations if RTO is tight).

14. Cost Management and Governance

How OCI charges, the tools to track and cap spend, the governance model (landing zones, quotas, budgets), and a concrete monthly cost-review checklist.

Pricing basics

• Universal Credits - a consumption model where credits apply across eligible OCI services; annual commitments earn better rates than pure pay-as-you-go.
• BYOL vs License Included - covered in section 6; BYOL typically the biggest database savings if you own licenses.

Cost tracking tools

Governance model and landing zones

A landing zone is a codified baseline for a well-governed tenancy: compartment topology, IAM groups/policies, network hub, logging/audit, Security Zones, Cloud Guard, budgets, quotas, and tag defaults - deployed as Terraform so it is repeatable and reviewable. Oracle publishes CIS-aligned landing zone reference architectures/Terraform to start from.

• Compartments for isolation and cost attribution (section 1).
• Quotas + budgets per compartment for control.
• Tags + tag defaults for attribution and automation.
• Security Zones + Cloud Guard for preventive/detective guardrails (section 8).
• Everything as code so environments are consistent and auditable.

Cost optimization examples

Monthly OCI cost review checklist

• Review Cost Analysis month-over-month by compartment and service; investigate any spike.
• Check each budget: which compartments/tags are over or trending over target.
• Act on Cloud Advisor rightsizing and idle-resource recommendations.
• Confirm non-prod stop/scale schedules ran (no Dev/Test running 24x7 by accident).
• Find and terminate orphaned block volumes, unattached boot volumes, and idle instances.
• Delete stale volume backups, DB backups beyond retention, and old snapshots.
• Review Object Storage: are lifecycle rules moving cold data to Archive / deleting expired data?
• Remove unused reserved public IPs and idle load balancers.
• Verify database licensing posture (BYOL applied where owned; OCPU counts right-sized).
• Check block-volume performance tiers vs. actual IOPS - downgrade over-provisioned volumes.
• Review egress charges - is OCI-service traffic correctly on the Service Gateway?
• Confirm every resource is tagged (CostCenter/Environment/Owner) for attribution.
• Validate quotas still reflect intent (no team quietly raised a cap).
• Reconcile Universal Credits burn-down vs. commitment; forecast to renewal.

15. Enterprise Architecture Patterns

Reference blueprints for real OCI deployments. Each card gives the business case, services, traffic flow, and the security / HA / DR / monitoring / cost / risk dimensions so you can adapt rather than start from a blank page.

Foundational three-tier (reference backbone)

Pattern library

Each pattern below follows the same dimension set. Expand the ones relevant to you.

16. Troubleshooting Guides

A runbook catalog for the failures you will actually hit. Each entry lists symptoms, likely causes, checks (with Console path and CLI where useful), fixes, and prevention. Deeper versions of some runbooks live in their service sections; this is the consolidated index.

Compute & access

oci compute instance get --instance-id <ocid> --query 'data."lifecycle-state"'
oci compute instance action --instance-id <ocid> --action SOFTRESET

Storage

oci os object list --bucket-name <name> --auth instance_principal

Network

Load balancer & certificates

Database

IAM

Containers & automation

Observability

17. OCI CLI and Terraform Examples

Practical, copy-friendly automation: CLI setup and common commands, the Terraform provider, Resource Manager, and clean examples for VCN, compute, buckets, IAM, alarms, and tags - plus state and structure practices.

OCI CLI setup, profiles, authentication

# Install (Linux/macOS)
bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

# Interactive setup: creates ~/.oci/config + API signing keypair
oci setup config

# ~/.oci/config with two profiles
[DEFAULT]
user=ocid1.user.oc1..aaaa...
fingerprint=aa:bb:cc:...
key_file=~/.oci/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..aaaa...
region=us-ashburn-1

[PROD]
user=ocid1.user.oc1..bbbb...
fingerprint=dd:ee:ff:...
key_file=~/.oci/prod_key.pem
tenancy=ocid1.tenancy.oc1..aaaa...
region=us-phoenix-1

# Use a profile; or use instance principal (no keys on disk)
oci os ns get --profile PROD
oci compute instance list -c <compartment> --auth instance_principal

Common CLI commands

# Identity / discovery
oci iam compartment list --all
oci iam region-subscription list
oci os ns get                                  # Object Storage namespace

# Compute
oci compute instance list -c <compartment-ocid> --output table
oci compute instance action --instance-id <ocid> --action STOP
oci compute image list -c <compartment-ocid> --operating-system "Oracle Linux"

# Networking
oci network vcn list -c <compartment-ocid>
oci network security-list get --security-list-id <ocid>

# Object Storage
oci os object bulk-upload -bn <bucket> --src-dir ./data --auth instance_principal
oci os object list -bn <bucket>

# Database
oci db system list -c <compartment-ocid>
oci db autonomous-database list -c <compartment-ocid>

# Query + filter with JMESPath
oci compute instance list -c <ocid> \
  --query "data[?\"lifecycle-state\"=='RUNNING'].{name:\"display-name\",ocid:id}" --output table

Terraform provider setup

# provider.tf
terraform {
  required_version = ">= 1.5"
  required_providers {
    oci = { source = "oracle/oci", version = "~> 6.0" }   # verify current major
  }
}

# Auth via config file profile (local runs)
provider "oci" {
  config_file_profile = "PROD"
  region              = var.region
}

# In Resource Manager / instance-principal runs, use:
# provider "oci" { auth = "InstancePrincipal"  region = var.region }

Create a VCN with subnets and a gateway

resource "oci_core_vcn" "main" {
  compartment_id = var.compartment_ocid
  cidr_blocks    = ["10.10.0.0/20"]
  display_name   = "app-vcn"
  dns_label      = "appvcn"
}

resource "oci_core_nat_gateway" "nat" {
  compartment_id = var.compartment_ocid
  vcn_id         = oci_core_vcn.main.id
  display_name   = "app-nat"
}

resource "oci_core_service_gateway" "sgw" {
  compartment_id = var.compartment_ocid
  vcn_id         = oci_core_vcn.main.id
  services { service_id = data.oci_core_services.all.services[0].id }
  display_name   = "app-sgw"
}

resource "oci_core_route_table" "private_rt" {
  compartment_id = var.compartment_ocid
  vcn_id         = oci_core_vcn.main.id
  display_name   = "private-rt"
  route_rules {
    destination       = "0.0.0.0/0"
    network_entity_id = oci_core_nat_gateway.nat.id
  }
  route_rules {
    destination_type  = "SERVICE_CIDR_BLOCK"
    destination       = data.oci_core_services.all.services[0].cidr_block
    network_entity_id = oci_core_service_gateway.sgw.id
  }
}

resource "oci_core_subnet" "app" {
  compartment_id             = var.compartment_ocid
  vcn_id                     = oci_core_vcn.main.id
  cidr_block                 = "10.10.2.0/24"
  display_name               = "app-private"
  route_table_id             = oci_core_route_table.private_rt.id
  prohibit_public_ip_on_vnic = true          # private subnet
  dns_label                  = "app"
}

data "oci_core_services" "all" {}

Create a compute instance

resource "oci_core_instance" "app" {
  compartment_id      = var.compartment_ocid
  availability_domain = var.ad
  display_name        = "app-01"
  shape               = "VM.Standard.E5.Flex"
  shape_config { ocpus = 2  memory_in_gbs = 32 }

  create_vnic_details {
    subnet_id        = oci_core_subnet.app.id
    assign_public_ip = false
    nsg_ids          = [oci_core_network_security_group.app.id]
  }
  source_details {
    source_type = "image"
    source_id   = var.image_ocid
  }
  metadata = {
    ssh_authorized_keys = file("~/.ssh/id_rsa.pub")
    user_data           = base64encode(file("cloud-init.yaml"))
  }
}

Create an Object Storage bucket

data "oci_objectstorage_namespace" "ns" { compartment_id = var.tenancy_ocid }

resource "oci_objectstorage_bucket" "backups" {
  compartment_id = var.compartment_ocid
  namespace      = data.oci_objectstorage_namespace.ns.namespace
  name           = "db-backups"
  access_type    = "NoPublicAccess"
  versioning     = "Enabled"
  # kms_key_id = oci_kms_key.data.id   # customer-managed key
}

Create IAM group, dynamic group, and policy

resource "oci_identity_dynamic_group" "app_servers" {
  compartment_id = var.tenancy_ocid
  name           = "app-servers"
  description    = "App instances in the app compartment"
  matching_rule  = "ALL {instance.compartment.id = '${var.compartment_ocid}'}"
}

resource "oci_identity_policy" "app_bucket_read" {
  compartment_id = var.compartment_ocid
  name           = "app-bucket-read"
  description    = "App servers read backups bucket"
  statements = [
    "Allow dynamic-group app-servers to read objects in compartment id ${var.compartment_ocid} where target.bucket.name = 'db-backups'"
  ]
}

Create a monitoring alarm

resource "oci_ons_notification_topic" "ops" {
  compartment_id = var.compartment_ocid
  name           = "ops-alerts"
}

resource "oci_monitoring_alarm" "cpu_high" {
  compartment_id        = var.compartment_ocid
  display_name          = "app-cpu-high"
  metric_compartment_id = var.compartment_ocid
  namespace             = "oci_computeagent"
  query                 = "CpuUtilization[5m].mean() > 85"
  severity              = "WARNING"
  destinations          = [oci_ons_notification_topic.ops.id]
  is_enabled            = true
  body                  = "App CPU above 85% for 5 minutes."
  pending_duration      = "PT5M"
}

Tag namespace, tag, and tag default

resource "oci_identity_tag_namespace" "finance" {
  compartment_id = var.tenancy_ocid
  name           = "Finance"
  description    = "Cost attribution tags"
}

resource "oci_identity_tag" "cost_center" {
  tag_namespace_id = oci_identity_tag_namespace.finance.id
  name             = "CostCenter"
  description      = "Charge-back cost center"
  validator {
    validator_type = "ENUM"
    values         = ["CC-4412", "CC-5501", "CC-7788"]
  }
}

# Auto-apply Environment tag to every new resource in a compartment
resource "oci_identity_tag_default" "env_default" {
  compartment_id    = var.compartment_ocid
  tag_definition_id = oci_identity_tag.environment.id
  value             = "prod"
}

State management and structure

• Remote, locked state: use Resource Manager (state managed for you) or an Object Storage/other backend with locking. Never keep prod state only on a laptop; never commit state (it holds secrets).
• Modular structure: reusable modules (network, compute, db, iam, monitoring) composed per environment - not copy-pasted stacks.
• Environment separation: separate state per env (workspaces or separate backends/stacks) driven by dev.tfvars / prod.tfvars; separate compartments and, ideally, separate credentials/pipelines.
• Drift detection: Resource Manager (or scheduled plan) to catch manual Console changes.
• No secrets in code: reference Vault secrets/keys by OCID; keep tfvars with secrets out of git.

oci-infra/
  modules/
    network/   compute/   database/   iam/   monitoring/
  envs/
    dev/    main.tf  dev.tfvars   backend.tf
    prod/   main.tf  prod.tfvars  backend.tf
  README.md

18. Learning Path

A structured route from OCI fundamentals to enterprise-grade architecture and operations, aimed at people coming from traditional Oracle/infrastructure backgrounds. Each level lists what to learn, why, hands-on labs, common mistakes, and the outcome you should reach.

Beginner

Intermediate

Advanced

Certification checkpoints (optional)