landing-zones

name	landing-zones
description	Use when the user asks to "design an OCI landing zone", "plan compartments", "enable Security Zones", "build hub-spoke OCI", or "meet CIS OCI Foundations".
version	2.0.0
keywords	["OCI","landing zone","compartment","Security Zone","Cloud Guard","CIS","hub-spoke","DRG","tenancy","tag defaults"]
aliases	["oci-landing-zone","oci-governance"]
domains	["oci","governance"]

OCI Landing Zones - Expert Architecture

Do NOT load this skill when

Do not load this skill for unrelated general programming, non-Oracle cloud work, or questions covered by a narrower sibling skill. When the request is only asking to find or install skills, use find-skills instead.

When to Use

Load this skill for: the user asks to "design an OCI landing zone", "plan compartments", "enable Security Zones", "build hub-spoke OCI", or "meet CIS OCI Foundations".

Prefer this skill only for its named domain. For broader OCI architecture triage, start with oci/best-practices as the router.

NEVER Do This

NEVER create a flat compartment structure

BAD:
tenancy/ app1-dev, app1-test, app1-prod, app2-dev ...

Problems:
- Cannot apply a single policy to all dev environments
- Cannot delegate administration per team
- Cost reports are unstructured
- Policy duplication grows O(n) with team count

GOOD - hierarchical:
tenancy/
  Network/ (Hub, Spokes)
  Security/ (Vault, Logging)
  Workloads/
    App1/ (Dev, Test, Prod)
    App2/ (Dev, Test, Prod)
  Shared-Services/ (Identity, Monitoring)

Policy inheritance flows DOWN the tree. One policy at Workloads/ applies to all workloads.

NEVER reuse 10.0.0.0/16 across VCNs

BAD - same CIDR everywhere:
Dev VCN:  10.0.0.0/16
Test VCN: 10.0.0.0/16   # Cannot peer with Dev
Prod VCN: 10.0.0.0/16   # Cannot peer with either

VCN CIDRs can be added or modified with restrictions, but overlapping address plans still block peering and can force disruptive migration. Plan non-overlapping ranges before provisioning.

GOOD - non-overlapping allocation:
Hub VCN:  10.0.0.0/16
Dev VCN:  10.10.0.0/16
Test VCN: 10.20.0.0/16
Prod VCN: 10.30.0.0/16

NEVER skip Security Zones for production compartments

# BAD: Compartment with no guardrails
oci iam compartment create --compartment-id $PARENT --name "Prod"
# Result: Anyone can create public IPs, unencrypted buckets, etc.

# GOOD: Security Zone enforces policies BEFORE resource creation
oci cloud-guard security-zone-recipe create \
  --compartment-id $TENANCY_ID \
  --display-name "CIS-Prod-Recipe" \
  --security-policies '["deny-public-ip","deny-public-bucket"]'

oci cloud-guard security-zone create \
  --compartment-id $PROD_COMPARTMENT_ID \
  --display-name "Prod-Security-Zone" \
  --security-zone-recipe-id $RECIPE_ID

Security Zones prevent violations BEFORE resource creation. Auditing finds them AFTER compromise.

NEVER put workload resources in the root compartment

Root compartment is for tenancy-wide IAM only (users, groups, policies).
Resources in root bypass governance, cannot be delegated, violate CIS OCI Foundations Benchmark.

Root should contain ONLY:
- Top-level child compartments
- Tenancy-wide IAM policies
Nothing else.

NEVER mix dev and prod resources in the same compartment

Developers with dev access can accidentally delete prod resources. Cannot set different backup policies, tagging strategies, or budget alerts per environment.

NEVER skip tagging strategy

# Without tags: "oci.compute.instance: $5,234/month" — which team? which project?
# Cannot chargeback, cannot identify waste.

# RIGHT: Create tag namespace with mandatory defaults
oci iam tag-namespace create --compartment-id $TENANCY_ID --name "Organization"
# Create: CostCenter, Environment, Owner tags
# Apply tag-defaults at compartment level (auto-applied to all resources)
oci iam tag-default create \
  --compartment-id $WORKLOAD_COMPARTMENT_ID \
  --tag-definition-id $COSTCENTER_TAG_ID \
  --value '${iam.principal.name}'

NEVER allow internet egress from spoke VCNs directly

BAD: Spoke subnet → Internet Gateway
- Data exfiltration undetectable
- Egress cost $3k-5k/month per spoke (unmetered)
- No DPI or egress filtering

GOOD - hub-spoke with centralized control:
Spoke → DRG → Hub VCN → Network Firewall → NAT Gateway → Internet
- Single egress point with firewall policies
- Complete visibility via VCN Flow Logs

NEVER use single-region for production workloads requiring SLA

Region outage = complete downtime. No automatic failover without DR.

Multi-region pattern:
Primary: us-ashburn-1 + DR: us-phoenix-1
- Autonomous Data Guard for database (near-zero RPO)
- Traffic Manager for DNS failover (RTO ~15 minutes)
- Object Storage cross-region replication
- Mirror compartment structure in DR region

---

Multi-Tenant IAM Decision Tree

Workloads single-tenant?
│
├─ YES → Environment-centric model
│        Compartments: Network, Shared-Services, Workloads/App/Dev-Test-Prod
│        IAM: Per-env groups (DevAdmins, ProdOps) scoped to env compartment
│
└─ NO (Multi-tenant SaaS)?
    │
    ├─ Strict tenant isolation required?
    │  ├─ YES → Tenant-per-compartment: Org/TenantA, Org/TenantB
    │  │        Dynamic Group per tenant VCN for instance principal auth
    │  │        Policy: `allow dynamic-group TenantA-VMs to manage all-resources
    │  │                  in compartment TenantA`
    │  └─ NO → Shared compartment + per-tenant tagging
    │           (faster setup, shared blast radius)
    │
    ├─ Multiple environments per tenant?
    │  └─ Nest: TenantA/Dev, TenantA/Test, TenantA/Prod
    │           Policies inherit down the tree automatically
    │
    └─ Centralized shared services?
         └─ Shared-Services compartment (Logging, Monitoring, Identity)
            Grant tenancy-level Ops group least-privileged read access

IAM policy template for multi-tenant:

Allow group TenantA-Admins to manage all-resources in compartment TenantA
Allow dynamic-group TenantA-VCN to manage virtual-network-family in compartment TenantA
Allow group Shared-Network to use virtual-network-family in compartment Shared-Services

Guardrails:

• Never grant tenant-specific policies at root; scope to tenant compartment hierarchy
• Require DRG route approval workflow before adding new tenants
• Refer to oci/iam-identity-management skill for fine-grained policy verb syntax

---

Security Zone Rollout Checklist

1. Inventory compartments — export JSON filtered by tag Environment=Prod
2. Create/update recipe — clone Oracle CIS recipe, append custom policies (no public LB, require CMEK). See references/security-zone-automation.md
3. Apply via CLI/Terraform — loop compartments or use Terraform module
4. Detect drift nightly — oci cloud-guard security-zone list-problems; alert on PROBLEM state
5. Rollback procedure — only remove zones with CISO approval; delete recipe only after all zones removed

Full scripts in references/security-zone-automation.md. Treat as MANDATORY for bulk Security Zone changes.

---

Reference Files

Load references/landing-zone-patterns.md when:

• Choosing compartment hierarchy pattern (workload-centric vs environment-centric vs tenant-centric)
• Designing hub-spoke network topology with DRG
• Setting up tagging strategy and cost allocation across compartments

Load references/landing-zone-cli.md when:

• Creating compartment hierarchies via CLI
• Configuring Security Zones and Cloud Guard in bulk
• Setting up tag defaults and tag namespaces
• Creating budgets with cost tracking

Load references/security-zone-automation.md when (MANDATORY for bulk changes):

• Rolling out or updating Security Zone recipes across multiple compartments
• Remediating drift (compartment lost Security Zone enforcement)
• Writing Terraform automation for Cloud Guard recipes

Load references/oci-well-architected-framework.md when:

• Starting a new landing zone design from scratch
• Preparing architectural review or compliance audit
• Comparing Core Landing Zone vs Operating Entities Landing Zone
• Need official Oracle guidance on all five pillars (Security, Reliability, Performance, Cost, Operations)

Arguments

$ARGUMENTS: Optional user-provided target, path, environment, symptom, or constraint. When empty, infer the narrowest safe scope from the current repository context and ask only if multiple high-impact choices remain.