1.3 OCI Tenancy & Compartment Hierarchy

1.3 OCI Tenancy & Compartment Hierarchy

[!IMPORTANT] Foundational Exam Concept: Compartments are a LOGICAL boundary, NOT a physical or network boundary! Compute instances and databases located in different compartments can freely communicate across a Virtual Cloud Network (VCN) as long as network routing and security rules permit it. Compartments organize resources for access control, cost allocation, and quota enforcement.

In Oracle Cloud Infrastructure, organizing, securing, and tracking thousands of enterprise cloud assets requires a robust administrative structure. OCI delivers this management framework through two primary building blocks: Tenancies and Compartments.

---

What is an OCI Tenancy?

When an organization signs up for Oracle Cloud Infrastructure, Oracle automatically provisions a Tenancy.

• Root Administrative Boundary: The Tenancy is the overarching root container for all cloud resources, user credentials, identity groups, and commercial billing subscriptions associated with the organization.
• Root Compartment: Every tenancy contains a default top-level compartment called the Root Compartment. The Oracle Cloud Identifier (OCID) of the tenancy is identical to the OCID of the root compartment.
• Identity Anchor: IAM users, groups, dynamic groups, and federation providers are established at the tenancy root level, allowing identity governance to span all regions to which the tenancy is subscribed.

---

What is a Compartment?

A Compartment is a logical container used to organize, group, and isolate cloud resources within an OCI tenancy.

Why Use Compartments?

Without compartments, all cloud assets—virtual machine instances, autonomous databases, block volumes, and load balancers—would reside in a single flat list within the root compartment. Compartments provide three indispensable operational benefits:

1. Granular Access Control (IAM): IAM policies in OCI are scoped to compartments. An administrator can grant the database team full administrative rights over the Database-Compartment while restricting them to read-only visibility in the Networking-Compartment.
2. Cost Tracking, Budgets, and Chargeback: OCI cost analysis and budgets can be filtered directly by compartment. This enables financial teams to assign specific spending thresholds to departments (e.g., Marketing, R&D, Sales) and track consumption for internal chargeback and showback reporting.
3. Resource Quotas and Capacity Limits: Administrators can define compartment quotas to enforce governance policies. For example, a quota policy can restrict the Development-Compartment from consuming more than 16 OCPUs of high-cost GPU shapes, preventing accidental budget overruns.

Crucial Exam Distinction: Logical vs. Network Isolation

A common misconception on the exam is assuming that placing resources into different compartments isolates them on the network.

• Compartments enforce logical access boundaries, NOT network boundaries.
• Virtual Cloud Networks (VCNs), Subnets, Route Tables, Security Lists, and Network Security Groups (NSGs) dictate network isolation.
• A compute instance in Compartment-A can communicate with a database in Compartment-B across the same VCN subnet without restriction, provided standard firewall rules permit the port traffic.

---

Compartment Hierarchy and Nesting

To mirror corporate organizational hierarchies, OCI allows compartments to be nested into a hierarchical tree structure:

                          [ Root Compartment (Tenancy) ]
                                        │
             ┌──────────────────────────┴──────────────────────────┐
             ▼                                                     ▼
     [ Finance-Dept ]                                      [ Engineering-Dept ]  (Level 1)
             │                                                     │
     ┌───────┴───────┐                                     ┌───────┴───────┐
     ▼               ▼                                     ▼               ▼
  [ Payroll ]     [ Auditing ]                          [ Project-Alpha ] [ Project-Beta ]  (Level 2)
                                                           │
                                                   ┌───────┴───────┐
                                                   ▼               ▼
                                                [ Dev ]         [ Prod ]            (Level 3)

Rules Governing Nesting and Depth

• Maximum Nesting Depth: Compartments can be nested up to six (6) levels deep beneath the root compartment (the root compartment is considered Level 0; child subcompartments can extend from Level 1 down to Level 6).
• Policy Inheritance: OCI enforces downward policy inheritance. Any IAM policy defined on a parent compartment automatically applies to all child subcompartments within its tree. For example, a policy attached at Engineering-Dept that allows developers to manage compute instances will automatically grant them permission in Project-Alpha, Project-Beta, Dev, and Prod.
• Policy Placement: Policies can be attached directly to the root compartment (applying tenancy-wide) or scoped to any specific subcompartment to restrict administrative permissions to a sub-tree.

---

Scope of OCI Resources

Cloud resources in OCI operate within different architectural boundaries: Global (Tenancy-wide), Regional, or Availability Domain (AD)-specific. Mastering these scopes is critical for architecting resilient environments.

[!TIP] Regional Subnets Best Practice: In early OCI architectures, subnets were bound to individual Availability Domains. Oracle now strongly recommends Regional Subnets. A regional subnet spans all ADs within a region, allowing compute instances deployed in AD-1, AD-2, and AD-3 to share the same subnet CIDR block, route table, and security rules seamlessly.

---

Moving Resources Between Compartments

As enterprise organizations evolve, resources frequently need to be transferred between departments or projects:

• Zero Service Downtime: In OCI, resources such as Compute instances, Block Volumes, Object Storage buckets, and VCNs can be moved from one compartment to another without causing any downtime or service disruption.
• Preserved Identifiers: Moving a resource does not alter its Oracle Cloud Identifier (OCID), private IP address, public IP address, or underlying data.
• Immediate Policy Transition: As soon as a resource moves to its target compartment, the policies associated with the source compartment cease to govern it, and policies defined on the target compartment take effect immediately.
• Permission Requirements: An administrator initiating the move must possess MANAGE permissions on both the source compartment and the destination compartment.

---

Deleting Compartments and Cascading Cleanup

When a project finishes, administrators can delete unused compartments:

• Cascading Deletion: When you delete a compartment, OCI performs an asynchronous recursive check. If the compartment contains subcompartments or active resources, OCI initiates a cascading deletion process, systematically terminating child resources before removing the compartment.
• State Lifecycle: During deletion, the compartment moves from ACTIVE to DELETING. Once all resources are cleanly terminated, its status transitions permanently to DELETED.
• Root Compartment Protection: The Root Compartment cannot be deleted, disabled, or renamed under any circumstances.