# Landing Zones

> 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".

- Skill: `acedergren/landing-zones-2` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add acedergren/landing-zones-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/acedergren/landing-zones-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: acedergren (https://skillmd.com/u/acedergren)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/acedergren/landing-zones-2

---

# 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**
```bash
# 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**
```bash
# 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`](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`](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`](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`](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.