Oracle Cloud Infrastructure Architect Associate: Identity and Access Management, Compartments, and Tenancy Governance

What this domain tests

IAM questions check whether you can turn an access requirement into a policy statement that actually works at runtime, and whether you treat compartments as both permission boundaries and cost/quota boundaries. Expect policy inheritance, dynamic groups, federation, and least-privilege scoping.

Core rules

The tenancy is the root compartment. Compartments nest up to six levels deep, and a tenancy can hold many compartments.
Policies attach to a compartment or the tenancy and inherit downward to every child compartment. They never apply sideways to sibling compartments.
Policy verbs aggregate: inspect < read < use < manage. Granting manage on a resource type includes everything below it for that type.
manage instances alone does not let a user launch an instance. The launch also needs use subnets, use vnics, and read images in the target compartment.
Dynamic groups match principals through a matching rule - instance principals and resource principals - so workloads call APIs without stored keys.
Federation uses SAML 2.0 identity providers; IdP groups are mapped to OCI groups, and policies reference the OCI group.

Worked example

Developers must run instances in AppDev but must not change networking. Start with allow group Devs to manage instances in compartment AppDev. The first launch fails until you add use vnics and use subnets in AppDev, because creating a VNIC and choosing a subnet are separate authorizations. Keep manage on gateways and route tables out of their policies entirely - that is least privilege that still works.

Traps

Granting manage all-resources in tenancy to save time; forgetting that a root-compartment policy cascades everywhere; assuming a compartment is a network or fault-domain boundary (it is neither); assuming you can grant a group access to another tenancy's resources - cross-tenancy access needs an explicit policy in both tenancies.