Identity and Access Management practice questions

Worked examples for Identity and Access Management

1. Question 1

   An architect wants an application on a Compute instance to call OCI APIs using instance principal authentication. Which TWO items must be configured in IAM for those calls to be authorized?

   1. A. An API signing key pair generated for the instance and placed in the OCI CLI/SDK configuration file on that instance.

      Claims an instance principal still needs a stored key. The whole point of instance principals is that credentials are issued to the instance and rotated by the service, so no signing key is created or stored by the administrator.

   2. B. A dynamic group whose matching rule matches the instance (for example by its OCID, its compartment, or a defined tag on it).Correct answer

      The dynamic group is what turns the instance into a recognizable principal; matching rules can select an instance by instance.id, instance.compartment.id, or a tag value.

   3. C. An IAM user account created for the application and added to the dynamic group as a member.

      Mixes up the two constructs. Dynamic groups do not take user members, and creating a user reintroduces the credential the instance principal design removes.

   4. D. An IAM policy that grants the dynamic group the required permissions on the target resources.Correct answer

      Identity alone authorizes nothing in OCI; a policy statement naming the dynamic group is required before any API call by the instance succeeds.

   5. E. A policy attached directly to the Compute instance resource that lists the permissions it may exercise.

      Imagines a resource-attached permission document. OCI policies are attached to a compartment or the tenancy and name a group or dynamic group as the subject — never attached to an individual instance.

   Explanation

   Instance principal access is built from exactly two IAM pieces: a dynamic group that matches the instance, giving the workload an identity, and a policy that grants that dynamic group permissions on the resources it must touch. No administrator-managed signing key exists in this model, because credentials are provided to the instance and rotated automatically; no IAM user is involved, since dynamic groups accept resources rather than users; and OCI has no mechanism for attaching a permission document directly to an instance — policies live on a compartment or the tenancy.

2. Question 2

   An on-premises CI/CD server, which is not an OCI resource, must call OCI APIs to deploy artifacts into a tenancy. Which identity approach is appropriate?

   1. A. Create a dynamic group with a matching rule on the server's hostname so it is recognized as a principal.

      Matching rules operate on attributes of OCI resources (compartment, resource id/type, defined tags). A non-OCI host has no such attributes and can never match a rule.

   2. B. Use instance principals — the OCI SDK issues an instance principal to any host that can reach the identity endpoint over the internet.

      Misconception that instance principals are available to arbitrary hosts. They are issued only to OCI compute instances, which obtain their identity locally from the instance itself.

   3. C. Create an IAM user for the automation, upload its API public key, place that user in a group granted the needed permissions by policy, and configure the server with the corresponding private signing key.Correct answer

      Correct: a user plus an API signing key is the supported pattern for callers outside OCI, since instance and resource principals require the caller to be an OCI resource.

   4. D. Have the OCI CLI on the server generate a resource principal session token and refresh it on a schedule.

      Resource principals are issued to OCI resources such as functions or Data Science sessions by the platform; a client tool cannot mint one for an external machine.

   Explanation

   Instance principals and resource principals remove stored credentials precisely because the caller *is* an OCI resource whose identity the platform can vouch for; a machine outside OCI has no such identity, so it must authenticate as an IAM user with an uploaded API signing key and receive permissions through an ordinary group and policy. A matching rule cannot select a non-OCI host, instance principals are not obtainable by external hosts, and resource principal tokens are issued by OCI services rather than generated on a client.

3. Question 3

   A group named `OpsOnCall` must be able to stop, start, and reboot compute instances that already exist in the `Prod` compartment. They must not be able to launch new instances or terminate existing ones. Which single policy statement grants exactly the access required and nothing more?

   1. A. Allow group OpsOnCall to use instances in compartment ProdCorrect answer

      `use` covers read plus the ability to work with an existing resource — including instance power actions — while stopping short of the create and delete permissions that only `manage` adds. This is the least-privilege verb for operating (not provisioning) an existing resource.

   2. B. Allow group OpsOnCall to manage instances in compartment Prod

      Over-privilege: `manage` is the top of the cumulative ladder and includes the create and delete permissions, so it would let the group launch and terminate instances — exactly what the requirement forbids.

   3. C. Allow group OpsOnCall to read instances in compartment Prod

      Under-privilege: `read` adds retrieval of the resource and its metadata to `inspect`, but it does not include acting on the resource, so power actions such as stop/start would be denied.

   4. D. Allow group OpsOnCall to inspect instance-family in compartment Prod

      Assumes `inspect` can change resource state; it only permits listing. It also widens scope to the whole instance-family aggregate rather than the single resource-type needed.

   Explanation

   OCI policy verbs are cumulative — inspect ⊂ read ⊂ use ⊂ manage — and least privilege means picking the lowest verb that still covers the required operations. Operating an existing instance (power actions) sits in `use`; `manage` is what adds create and delete, so it grants more than the requirement allows. Listing-only and get-only verbs cannot change resource state at all, and swapping the individual resource-type for the family aggregate broadens the grant without being needed.

4. Question 4

   Which TWO statements about nested compartments in OCI are correct? (Choose two.)

   1. A. A compartment can contain child compartments, allowing a hierarchy several levels deep beneath the root.Correct answer

      Correct. Compartments can be nested, which is what enables environment or workload sub-structures beneath a top-level compartment.

   2. B. A policy attached to a parent compartment can grant access that also applies to resources in its child compartments.Correct answer

      Correct. Access granted on a compartment is inherited by the compartments nested inside it, which is why placement in the hierarchy matters for governance.

   3. C. Nesting is limited to a single level, so a child compartment can never itself have children.

      Misconception that the hierarchy is flat below the root. Multi-level nesting is supported, which is the basis of environment/workload isolation designs.

   4. D. A child compartment automatically inherits its parent's compartment quota values as its own hard caps.

      Quotas are set by explicit policy statements, not auto-copied to a child as its own caps. Quotas do cascade in one sense - a subcompartment's usage counts toward its parent's quota, and a parent's quota can override a child's - but a child compartment does not automatically receive the parent's quota VALUES as its own hard caps, so this statement is incorrect as worded.

   5. E. A child compartment is always tied to the same region as its parent compartment.

      Applies regional scoping to compartments. Compartments at every level are global constructs, so a child has no region binding to inherit.

   Explanation

   Compartments support multi-level nesting, and access granted by a policy on a compartment flows down to the compartments nested within it, which together are what make a compartment tree a usable governance structure for separating environments and workloads. A one-level-only restriction contradicts the documented hierarchy, quotas are declared explicitly against a named compartment rather than copied from parent to child, and compartments at every level are global constructs with no region binding to inherit.

5. Question 5

   A team has been running a set of block volumes and compute instances in a shared "Sandbox" compartment. Governance now requires those resources to live in a dedicated "ProjectX" compartment so that policies and cost reporting can target the project directly. What is the correct characterisation of moving an existing resource between compartments in OCI?

   1. A. Most OCI resources support being moved to a different compartment, and after the move the policies that govern the resource are those of the new compartment.Correct answer

      Correct. OCI supports moving resources between compartments; once moved, the resource inherits the policies attached to the new compartment (and its ancestors), so access can change immediately after the move.

   2. B. Resources can never be moved once created; the only option is to delete each resource and recreate it in the target compartment.

      The 'compartments are permanent' misconception. Most OCI resources support a move operation, so wholesale delete-and-recreate is unnecessary.

   3. C. A resource may be moved only to a compartment in the same region and availability domain as the one it currently occupies.

      Treats compartments as region- or AD-scoped. Compartments are global constructs that span regions, so no such same-AD restriction applies to a move.

   4. D. A resource may be moved between compartments, but the policies from its original compartment continue to apply to it indefinitely.

      Assumes policy 'follows' the resource. Policy grants are attached to compartments, not to individual resources, so the destination compartment's policies govern after a move.

   Explanation

   OCI lets administrators move most resources from one compartment to another, which is the supported way to reorganise a tenancy without rebuilding workloads. The key governance consequence is that policies are attached to compartments, so once a resource lands in a new compartment it is governed by that compartment's policies and access can change right away. Claims that resources are immovable ignore the documented move operation, the same-availability-domain restriction wrongly treats compartments as physically scoped when they are global, and the idea that old policies persist misunderstands that grants attach to compartments rather than to individual resources.

6. Question 6

   A team is describing the difference between an identity domain and a compartment to new OCI administrators. Which statement correctly distinguishes the two constructs?

   1. A. An identity domain and a compartment are two names for the same container; the console simply shows the identity view of a compartment

      The classic 'domains are just compartments' misconception. They are distinct constructs solving different problems — one containing principals, the other containing resources.

   2. B. An identity domain is a container for identities (users, groups, sign-on and federation settings), whereas a compartment is a container for resources used to organize and control access to themCorrect answer

      Correct. IAM separates who the principals are (identity domain) from what they act on (compartment); policies then bind a group in a domain to permissions on a compartment.

   3. C. An identity domain contains resources such as compute instances and buckets, while a compartment contains the users allowed to access them

      Inverts the two roles. Resources live in compartments; users and groups live in identity domains.

   4. D. A compartment can be nested inside another compartment, and an identity domain is simply the top-level compartment of the tenancy

      Conflates the root compartment with the default identity domain. Nesting is a compartment property; a domain is a separate identity container and is not a level in the compartment hierarchy.

   Explanation

   OCI IAM draws a clean line between principals and resources: identity domains contain users, groups, sign-on policies and federation configuration, while compartments contain resources and provide the scope over which access is granted. Policies join the two by granting a group in a domain permissions on a compartment. Treating the two as the same construct, swapping their contents, or equating a domain with the root compartment all break that separation and lead to unworkable designs.

7. Question 7

   Members of the `Devs` group are covered by two policies: one attached at the tenancy stating `Allow group Devs to read all-resources in tenancy`, and one attached to the `Dev` compartment stating `Allow group Devs to manage all-resources in compartment Dev`. A member issues a request to delete a bucket that lives in the `Dev` compartment. What is the result, and why?

   1. A. The request is allowed, because a principal's effective permissions are the union of every policy that applies to the request.Correct answer

      Correct: OCI policies are additive and allow-only, so the compartment-level manage grant supplies the bucket-delete permission regardless of what other statements grant.

   2. B. The request is denied, because the more restrictive of the two applicable grants takes precedence.

      'Most restrictive wins' misconception imported from deny-capable policy systems. OCI has no deny statement and no precedence rule — grants only add.

   3. C. The request is denied, because a compartment-attached policy cannot grant more than the tenancy-attached policy already grants.

      Invents a hierarchical ceiling. A tenancy-level grant does not cap what compartment-level policies may grant; each statement is evaluated on its own and adds permissions.

   4. D. The request is allowed only after the tenancy-level policy is deleted, since the two statements conflict on the same resource-type.

      Assumes overlapping statements conflict. Statements covering the same resource-type at different verbs coexist without conflict; the broader permission simply prevails as part of the union.

   Explanation

   OCI IAM evaluates a request against every policy that applies to the principal, and a request succeeds if any of them grants the required permission — access is the union of all grants, with everything else implicitly denied. Because there is no deny construct, there is nothing that can subtract from or cap a grant, so neither a broader tenancy-level statement nor the relative position of the attachment points establishes precedence. Overlapping statements at different verbs are normal and do not conflict; the higher verb's permissions simply apply where its location clause reaches.

8. Question 8

   When a user signs in to the OCI Console and views a list of compute instances, what determines which instances are displayed?

   1. A. All instances in the tenancy are listed, and access is enforced only when the user attempts an action on one.

      Assumes authorization is checked only on write operations. Listing itself is a permission-checked, compartment-scoped operation.

   2. B. The instances in the compartment the user selects, provided policy grants that user access to that compartment.Correct answer

      Correct. Console resource lists are scoped to a chosen compartment, and the user sees them only where policy grants access to that compartment.

   3. C. The instances in the availability domain the user selects, since compartments do not affect resource listings.

      Substitutes a physical placement construct for the organizational one. Availability domain may filter results but is not the access-scoping container.

   4. D. All instances the user created personally, regardless of which compartment they live in.

      Assumes ownership-based visibility. OCI authorization is granted to groups over compartments, not tied to which principal created a resource.

   Explanation

   Working with resources in the Console is compartment-scoped: a user picks a compartment and sees the resources within it, and only for compartments where an IAM policy grants that user's group access. Access is evaluated on the read operation itself rather than deferred to the first write, availability domains are a placement construct rather than the access-scoping container, and OCI grants permissions to groups over compartments rather than by which principal originally created a resource.