best-practices

What this skill does

# OCI Best Practices - Expert Knowledge

## 🏗️ Use OCI Landing Zone Terraform Modules

**Don't reinvent the wheel.** Use [oracle-terraform-modules/landing-zone](https://github.com/oracle-terraform-modules/terraform-oci-landing-zones) for OCI architecture.

**Landing Zone solves:**
- ❌ Bad Practice #1: Generic compartments (Landing Zone provides hierarchical Network/Security/Workloads structure)
- ❌ Bad Practice #2: Administrator for daily ops (Landing Zone enforces least-privilege IAM policies)
- ❌ Bad Practice #4: Poor network segmentation (Landing Zone implements hub-spoke topology with security zones)
- ❌ Bad Practice #8: Creating your own Terraform modules (Landing Zone provides battle-tested, Oracle-maintained, CIS-certified modules)

**This skill provides**: OCI-specific anti-patterns, architecture patterns, and operational knowledge for resources deployed WITHIN a Landing Zone.

---

## ⚠️ OCI CLI/API Knowledge Gap

**You don't know OCI CLI commands or OCI API structure.**

Your training data has limited and outdated knowledge of:
- OCI CLI syntax and parameters (updates monthly)
- OCI API endpoints and request/response formats
- OCI service-specific commands and flags
- Latest OCI features, limits, and regional availability
- CIS Benchmark requirements for OCI

**When OCI operations are needed:**
1. Use exact CLI commands from skill references
2. Do NOT guess OCI CLI syntax or parameters
3. Do NOT assume API endpoint structures
4. Reference landing-zones skill for Terraform modules

**What you DO know:**
- General cloud architecture concepts
- Security principles and compliance frameworks
- Multi-tier application design patterns

This skill bridges the gap by providing current OCI-specific patterns and anti-patterns.

---

You are an OCI architecture expert. This skill provides knowledge Claude lacks: OCI-specific anti-patterns, free tier specifics, terminology gotchas, multi-AD patterns, and differences from AWS/Azure/GCP.

## NEVER Do This

❌ **NEVER use /24 or smaller VCN CIDR (cannot expand)**
```
# WRONG - VCN too small, cannot expand later (OCI limitation)
oci network vcn create --cidr-block "10.0.0.0/24"
# Only 256 IPs total, exhausted quickly

# WRONG - copying AWS habit (/16 VPC default)
# OCI supports larger: /16 to /30

# RIGHT - start with /16, plan for growth
oci network vcn create --cidr-block "10.0.0.0/16"
# 65,536 IPs, room for 256 /24 subnets

# CRITICAL: OCI VCNs CANNOT be resized after creation
# Must create new VCN and migrate if too small
```

**Migration cost**: Recreating VCN = hours of downtime, IP changes, security rule updates

❌ **NEVER use AD-specific subnets (breaks multi-AD HA)**
```
# WRONG - subnet tied to single AD
oci network subnet create \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24" \
  --availability-domain "fMgC:US-ASHBURN-AD-1"  # AD-specific!

# Problem: Can't launch instances in other ADs, no HA

# RIGHT - regional subnet (works in all ADs)
oci network subnet create \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24"
  # No --availability-domain flag = regional
  # Instances can be in any AD in region
```

**Gotcha**: Some old OCI guides show AD-specific subnets (deprecated pattern)

❌ **NEVER confuse Security Lists vs NSGs (different use cases)**
```
OCI has TWO network security mechanisms:

Security Lists (stateful, subnet-level):
- Applied to ALL resources in subnet
- Use for: Broad rules (internet egress, DNS)
- Limit: 5 per subnet
- Changes: Affect all instances in subnet

Network Security Groups (NSG, resource-level):
- Applied to specific resources
- Use for: Granular rules (app tier → DB tier)
- Limit: 5 per resource, 120 rules per NSG
- Changes: Affect only tagged resources

# WRONG - using Security Lists for app-specific rules
Security List: Allow app-tier → database (applies to ENTIRE subnet)

# RIGHT - use NSG for app-tier resources
NSG "app-tier": Allow egress to NSG "db-tier" on port 1521
# Only instances in app-tier NSG can reach DB
```

**Best practice**: Security Lists for baseline (internet, DNS), NSGs for application-specific rules

❌ **NEVER assume single-AD deployment is acceptable (no SLA)**
```
OCI Availability Domains (ADs):
- 3 ADs per region (most regions)
- Isolated fault domains
- <1ms latency between ADs

# WRONG - all resources in single AD
All instances in AD-1 → AD failure = complete outage

# RIGHT - distribute across ADs
Production instances: AD-1, AD-2, AD-3
Load balancer: Automatically multi-AD
Database: Autonomous (auto 3-AD) or RAC (2+ nodes)

SLA impact:
Single-AD: NO SLA (OCI doesn't guarantee)
Multi-AD: 99.95% SLA
```

**Critical**: Oracle **refuses** SLA claims for single-AD deployments in regions with 3 ADs

❌ **NEVER hardcode AD names (tenant-specific)**
```
# WRONG - AD names are tenant-specific, not portable
availability_domain = "fMgC:US-ASHBURN-AD-1"  # Only works in YOUR tenancy!

# Another tenant's AD name for same physical AD:
availability_domain = "xYzA:US-ASHBURN-AD-1"  # Different prefix!

# RIGHT - query AD names dynamically
data "oci_identity_availability_domains" "ads" {
  compartment_id = var.tenancy_ocid
}

resource "oci_core_instance" "web" {
  availability_domain = data.oci_identity_availability_domains.ads.availability_domains[0].name
}
```

**Why**: OCI generates unique AD prefixes per tenant for security isolation

❌ **NEVER enable Cloud Guard auto-remediation without testing**
```
Cloud Guard = OCI threat detection + auto-response

# DANGER - auto-remediation can break production
Detector: "Public bucket detected"
Auto-remediation: Make bucket private → breaks public website!

Detector: "Security list allows 0.0.0.0/0"
Auto-remediation: Remove rule → breaks internet access!

# SAFER approach:
1. Enable detectors (read-only mode first)
2. Review findings for 1-2 weeks
3. Tune responders to avoid false positives
4. Enable auto-remediation for trusted patterns only
```

**Gotcha**: Cloud Guard enabled by default in some tenancies, can auto-break things

❌ **NEVER assume you need Oracle Linux (common misconception)**
```
OCI supports:
✓ Oracle Linux (free, optimized)
✓ Ubuntu, CentOS, Rocky Linux (free)
✓ Windows Server (BYOL or license-included)
✓ Custom images (import your own)

# WRONG assumption: "OCI = must use Oracle Linux"
Reality: Any Linux works, Ubuntu has larger community

# Cost: Oracle Linux is FREE (no license cost)
# But if team knows Ubuntu → use Ubuntu
```

**Marketing confusion**: Oracle pushes Oracle Linux, but it's not required

## OCI Always-Free Tier (Exact Limits)

**Generous permanent free tier** (no credit card trial, no expiration):

### Compute
- **2 AMD VMs**: VM.Standard.E2.1.Micro (1/8 OCPU, 1 GB RAM each)
- **4 Arm OCPUs**: VM.Standard.A1.Flex (allocate as 1×4 OCPU or 4×1 OCPU)
  - Up to 24 GB total RAM (6 GB per OCPU)
  - **Example**: Run 4× 1OCPU/6GB Arm instances free forever

### Database
- **2 Autonomous Databases**: 1 OCPU each, 20 GB storage per ADB
  - Can be ATP or ADW
  - **Limit**: 2 total per tenancy across all regions

### Storage
- **Block volumes**: 200 GB total (2× 100 GB boot volumes + custom)
- **Object storage**: 10 GB Standard tier
- **Archive storage**: 10 GB Archive tier
- **Block volume backups**: 10 GB

### Networking
- **Load balancer**: 1 flexible LB, 10 Mbps bandwidth
- **VCN**: 2 VCNs per region (free, no OCID cost)
- **Public IPv4**: 1 reserved public IP free per region

### Observability
- **Monitoring**: 1 billion data points ingested
- **Logging**: 10 GB ingested per month
- **Notifications**: 1 million emails per month

### Always-Free Gotchas

**CRITICAL limits often missed**:
```
# Gotcha 1: 2 ADB limit is TENANCY-wide, not per region
Can have: 1 ATP in Phoenix + 1 ADW in Ashburn = 2 (limit reached)
Cannot: Add 3rd ADB in any region

# Gotcha 2: Arm instances must be VM.Standard.A1.Flex only
Cannot: Use newer A2 shapes (paid only)

# Gotcha 3: Free tier != trial credits
Free tier: Permanent, no expiration
Trial: $300 credit for 30 days (separate)

# Gotcha 4: St