IAM policies are authorization documents that define who (user/group) can access what resources and how (level of access) within your tenancy. In simple terms, while a User is "Who you are," a Policy is "What you are allowed to do." Without a policy, a user can log in to OCI but will see an empty screen with no permissions to create or even view resources.

The OCI IAM model is governed by four hierarchical verbs, which determine the "depth" of access granted to a group.

The 4 Verbs (Access Levels)

1. Inspect

Provides the ability to list resources without access to metadata or confidential information.

Capability: The user can call List APIs. For example, they can see that a Virtual Machine exists but cannot see its Private IP address or OCID.

Use Case: Ideal for auditing or high-level monitoring where detailed configuration is not required.

2. Read

Includes Inspect capabilities plus the ability to retrieve the full configuration (metadata) of a resource.

Capability: The user can call Get APIs. They can view the shape, image, and networking details of an instance but cannot modify its state.

Use Case: Suitable for security analysts who need to verify configurations without making changes.

3. Use

Includes Read capabilities plus the ability to perform operational actions on existing resources.

Capability: The user can interact with the resource (e.g., Update or Action APIs). They can start/stop a VM or attach a block volume, but they cannot create or delete the resource itself.

Use Case: Designed for day-to-day operators and system administrators who manage environment uptime.

4. Manage

The highest level of permission, granting full CRUD (Create, Read, Update, Delete) capabilities over a resource type.

Capability: This encompasses all previous verbs and adds the ability to create new resources and terminate existing ones.

Use Case: Reserved for Cloud Architects or Lead Admins who are responsible for infrastructure deployment.

Verb	Access Level	Description
Inspect	Minimum	List resources only. No access to metadata or billing.
Read	Basic	Inspect + View detailed configuration/metadata.
Use	Operational	Read + Perform actions (Start/Stop/Reboot). No Create/Delete.
Manage	Administrative	Full Power. Create, Update, Delete, and Move resources.

Note:- Policy Hierarchy Limits: In OCI, the IAM framework restricts the maximum of 500 policy statements in a single compartment hierarchy path.

Root → Child → Sub-child →... This includes all policies residing in the Root compartment as well as those defined within child compartments like Swiggy (Application) or Network/Compute (Services).

Understanding this limit is crucial for designing a scalable and efficient identity management structure. Too many policies can slow down permission checks and impact performance. It also prevents overly complex access setups that are hard to maintain or audit. Overall, the limit ensures better security, stability, and simpler administration.

Best practices to avoid hitting the limit . Combine similar policies instead of duplicating . Use groups instead of assigning policies to individuals . Use tag-based access control (TBAC) . Place common policies at higher-level compartments

Steps to Create a Policy

Log in to your OCI Console.

Open the Navigation Menu (top-left) and go to Identity & Security.

Under the Identity section, click on Policies.

Select a Compartment: On the left side, under the List Scope, select the compartment where you want this policy to live.

Click the Create Policy button.

Enter Policy Details:

Name: Give it a clear name (e.g. compute, storage, network etc.).

Description: (Optional) you can give the description of the policy

Policy Builder: You can use the "Show manual editor" switch to type the rule directly.

Note:-We can leverage AI assistance Copilot in VS Code to generate and check the syntax of our policy statements.

Enter the Policy Statement: Type this standard rule (replace the bracketed words with your actual names):

Syntax:- for inspect- Allow group [Your_Group_Name] to inspect instance-family in compartment [Your_Compartment_Name]

              **for read**-     Allow group [Your_Group_Name] to read instance-family in compartment [Your_Compartment_Name]

               ****for use**-   Allow group [Your_Group_Name] to use instance-family in compartment [Your_Compartment_Name]

               **for manage**-  Allow group [Your_Group_Name] to manage instance-family in compartment [Your_Compartment_Name]

Click Create.

Policy has been created.