OCI Architect Associate: Identity and Access Management

What to know

OCI IAM answers two questions: who (the principal) and what (the policy). Principals are users, groups, dynamic groups (instances and other resources matched by rules such as instance.compartment.id = 'ocid1.compartment...'), and service principals. Authorization lives in policy statements written at a compartment: Allow group AppDevs to manage instance-family in compartment AppDev. Policies attach to a compartment and are inherited by every child compartment - never upward and never sideways. Verbs escalate: inspect < read < use < manage. manage includes creating and deleting; use only works on resources that already exist. Resource families such as instance-family or object-family group related types, and conditions can narrow a statement by request attributes.

Federation, identity domains, MFA, and instance/resource principals are frequent topics. Be clear that authentication proves identity while authorization (policies) grants access, and that the tenancy itself is the root compartment.

Traps

• Assuming a policy in a child compartment affects the parent - it does not.
• Confusing use with manage; creating a resource requires manage or use on the parent container.
• Forgetting that dynamic group rules match resource attributes, not user names.
• Believing group membership or domain nesting automatically grants cross-domain access.

Rule of thumb

Grant at the highest compartment that contains everything the team should touch, and prefer manage on a narrow resource family in a narrow compartment over a broad manage all-resources in tenancy.