Identity And Access Management practice questions

MATCH {instance.id == 'ocid1.instance...' OR tag.Project == 'Alpha'}

Why it fails: Dynamic group rules use the keywords ANY and ALL, not OR, and the correct operator for equality is ==, not a bare OR expression. It is tempting because the logic reads naturally and mirrors SQL or Boolean syntax, and would be correct if OCI accepted Boolean operators inside matching rules.

DYNAMIC {instance.id IN ('ocid1.instance...'))}

Why it fails: The DYNAMIC keyword is not valid in a matching rule, and the rule covers only the instance OCID, omitting the freeform tag condition the scenario requires. It is tempting because DYNAMIC appears in the dynamic group name itself, and would be correct if the requirement involved only a single OCID match.

ALL {instance.id = 'ocid1.instance...', tag.Project.name = 'Alpha'}

Why it fails: ALL requires every condition to be true, so an instance must match both the OCID and the tag, whereas the scenario needs either condition to grant membership. It is tempting because ALL is a genuine rule keyword, and would be correct if membership depended on satisfying both criteria simultaneously.

Policies can only be created in the root tenancy, never in child compartments.

Why it fails: Policies are written in compartments, so the root-tenancy restriction is false; placing it in ProjectA itself scopes the statement to that compartment and its descendants only. The root is where you would write tenancy-wide or cross-compartment policy, which would grant visibility into sibling compartments under DepartmentX.

The policy must be created in the Identity service global container.

Why it fails: The Identity service global container holds IAM policy statements, but policies are attached to compartments, not to that container, so no scoping to ProjectA occurs. Writing policy at the tenancy root is the actual mechanism for broad grants; the global container is not a policy attachment point.

The policy must be created in the root compartment (tenancy).

Why it fails: Root-compartment policy statements inherit downward to every child compartment, so Auditors would also see sibling compartments under DepartmentX. Writing the policy inside ProjectA confines it to that compartment and its descendants. The root is correct when the grant must span the whole tenancy.

Allow group Developers to terminate instances in tenancy where client.subnet = '192.168.100.0/24'

Why it fails: client.subnet is not a valid OCI policy condition variable, so the statement cannot evaluate the caller's source network. It is tempting because subnet-based conditions exist in other cloud IAM systems, and the CIDR notation matches the requirement, but OCI uses request.ip for this check.

Allow group Developers to inspect instances in tenancy where request.ip = '192.168.100.0/24'

Why it fails: The verb inspect grants only list-level visibility of resources, not the terminate permission the requirement demands. It is tempting because the request.ip condition is correctly formed, and inspect is the least-privilege verb, but termination requires manage or use on the instance resource.

Allow group Developers to manage instance-family in tenancy where request.ip = '192.168.100.0/24'

Why it fails: manage instance-family grants full lifecycle control over every instance operation, not solely termination, so it violates least privilege. It is tempting because request.ip is the correct condition variable and the statement does enforce the CIDR restriction, but the verb is broader than the requirement specifies.

Allow dynamic-group AppInstances to read objects in compartment Production where target.tag.Operations.Environment = 'true'

Why it fails: The condition compares the tag value against 'true', but the stem requires 'Production'; the value literal must match exactly. Tag-based conditions are the correct mechanism here, so the syntax is close — only the compared value is wrong.

Allow dynamic-group AppInstances to read objects in tenancy where request.tag.Operations.Environment = 'Production'

Why it fails: Request tags describe the caller's own tags, not the bucket's, so this never evaluates the target bucket's Environment tag. Request.tag conditions suit limiting access by tags attached to the requesting principal or its session, not by resource tags.

Allow dynamic-group AppInstances to read buckets in tenancy where bucket.tag.Operations.Environment = 'Production'

Why it fails: Scoping to the entire tenancy rather than the compartment holding the bucket grants read access to every matching bucket across all compartments, not just the intended one. The condition syntax itself is valid, making this tempting when the bucket's compartment is unknown or tenancy-wide access is genuinely required.

Unlimited

Why it fails: Nesting is not unlimited; it is hard-capped at 6 levels.

2 levels

Why it fails: Compartment nesting depth is significantly higher than 2 levels.

10 levels

Why it fails: Oracle Cloud Infrastructure permits a maximum nesting depth of six compartments within a single parent hierarchy, rendering a ten-level structure technically invalid. This option appears logical because ten is a common default limit for organisational units or nested groups within Microsoft Entra ID. Candidates often conflate these identity management constraints with OCI resource organisation policies, mistakenly assuming that the deeper nesting depth allowed in directory services applies to the compartment framework used for resource isolation and access control.

Compute instances must be manually added to dynamic groups via the IAM console.

Why it fails: Dynamic groups rely on automated membership rules based on resource attributes, rendering manual intervention unnecessary and contrary to their design. This option incorrectly suggests a static management approach, which is actually the function of standard IAM user groups. You would only manually assign members to a group when managing human identities or service principals that lack the specific resource metadata required for dynamic matching. Consequently, this manual process fails to address the automated lifecycle requirements of compute instances within the specified compartment.

The compute instances must be restarted for IAM policies to take effect.

Why it fails: Policies and group memberships apply to API calls made by the instance metadata service without requiring a reboot.

Dynamic groups only support tagging rules, not compartment OCID rules.

Why it fails: Dynamic groups natively support compartment OCID matching, meaning this rule type is entirely valid for grouping compute instances within a specific compartment. This option appears logical because tagging rules are frequently utilised to manage resources across disparate compartments or projects where identity-based attributes are preferred over structural hierarchy. Administrators often rely on tag-based membership when resources must be grouped by lifecycle status or cost centre rather than their physical location within the tenancy tree.

Configure a security list rule allowing instance deletion from the specified subnet.

Why it fails: Security lists filter network packets to and from subnets; they cannot evaluate the source subnet of an OCI API call or authorise instance deletion. It is tempting because subnet OCIDs appear in both contexts, and would be correct for controlling inbound and outbound traffic to resources in that subnet.

Allow group Developers to delete instances in subnet 'ocid1.subnet...'

Why it fails: Policies cannot be attached directly to subnets; they are attached to compartments or the tenancy root.

Allow group Developers to manage instances in tenancy where client.subnet.id = 'ocid1.subnet...'

Why it fails: OCI policies cannot filter on client.subnet.id; the condition variables available for instance access are request.principal or target resource attributes, not source subnet. It tempts because subnet-scoped conditions exist for other services, but here the correct approach uses instance principals or a dynamic group tied to the subnet.

Define group Partners in Tenancy B: accept group Partners to read objects in tenancy TenancyA

Why it fails: The commitment policy must use the verb "endorse", not "accept", to reciprocate Tenancy A's endorsement; "accept" is not valid policy syntax here. It is tempting because "accept" reads naturally as agreeing to the partnership, but the cross-tenancy handshake specifically requires endorse in the commitment statement.

Define group Partners in Tenancy B: permit group Partners to read objects in compartment Root

Why it fails: The commitment policy must name the remote tenancy (tenancy TenancyA) and use "endorse"; scoping to compartment Root in the local tenancy grants nothing across the boundary. It is tempting because Root compartments appear to cover everything, but cross-tenancy access requires the remote tenancy as the resource target.

Define group Partners in Tenancy B: allow group Partners to access tenancy TenancyA

Why it fails: The verb must be "endorse", and the resource must be specified as objects, not the broad "access tenancy" verb-and-resource pairing, which is not valid for this grant. It is tempting because "allow" and tenancy-level scope feel comprehensive, but the commitment policy requires the endorse verb with a concrete resource type.

Policies can never reference child compartments; they must always apply to the entire tenancy.

Why it fails: Policies can be scoped to specific child compartments.

The verb 'manage' cannot be used with instances; it must be 'use'.

Why it fails: Manage is a valid verb for instances and all other OCI resource types.

The group name must be prefixed with the tenancy name.

Why it fails: Group names in OCI policies are written unqualified, exactly as they appear in the identity domain; no tenancy prefix is required or accepted. Prefixing applies to resource types and compartments, not groups, so this is not the syntax error preventing the DevGroup policy from working.

Allow group NetworkAdmins to manage all-resources in tenancy where target.type != 'gateway'

Why it fails: The condition filters only gateway resources, so peering connections remain manageable and subnets, route tables and VCNs are still granted via all-resources. It is tempting because broad `manage all-resources` with a target-type exclusion is a recognised pattern for carving out one resource class, and would suit a scenario excluding gateways alone.

Allow group NetworkAdmins to use networking in tenancy

Why it fails: 'use networking' grants only the ability to associate existing networking resources with other services; it cannot create or modify VCNs, subnets or route tables. The use verb fits referencing a network in a compute or load balancer deployment.

Allow group NetworkAdmins to manage virtual-network-family in tenancy

Why it fails: virtual-network-family includes all networking resources, including gateways and peering connections, which violates the requirement.

10 groups

Why it fails: Oracle Cloud Infrastructure imposes a higher ceiling on group membership, allowing an individual user to belong to up to 300 distinct groups. Ten groups is tempting because administrators frequently encounter this exact numerical limit as a default quota for secondary user memberships in alternative identity management platforms, such as Microsoft Entra ID, where users are often restricted to a maximum of 10 security groups for token size management. In that specific foreign identity scenario, ten would be the correct operational constraint, but it severely underestimates the scalability designed into Oracle Cloud Infrastructure.

Unlimited

Why it fails: Oracle Cloud Infrastructure enforces a strict service limit of 250 groups per user to optimise policy evaluation performance, making an unlimited membership technically impossible. This choice tempts administrators accustomed to directory services like Microsoft Entra ID, where group memberships are virtually unlimited, or those designing federated identity architectures where external users belong to thousands of security groups before mapping.

50 groups

Why it fails: A limit of 50 groups is incorrect because Oracle Cloud Infrastructure permits a single user to belong to up to 300 distinct groups. This figure represents the maximum number of dynamic groups a single instance can be a member of for cross-tenancy resource principal policies, making it tempting due to confusion between IAM user group limits and dynamic group membership thresholds.

Allow group CostAnalysts to inspect compartments in tenancy

Why it fails: Inspecting compartments merely grants metadata visibility and read permissions on basic resource configurations, completely failing to cover the required usage-report and cost-tracking permissions needed for financial data. This option initially appears tempting because the term "inspect" suggests a non-destructive, read-only viewing capability; consequently, it would be the correct choice if the administrator's goal were solely to audit standard resource metadata and structure across compartments without permitting destructive changes, but it lacks the specific IAM verbs required to view billing and cost data.

Allow group CostAnalysts to manage billing in tenancy

Why it fails: Granting the `manage` verb provides full administrative control over billing resources, which violates the strict read-only constraint specified in the requirement. This statement appears tempting because it directly targets the billing domain within the tenancy, making it seem suitable for a cost-analysis team. It would be the correct choice in a scenario where the group required full permissions to create, update, and manage billing-related configurations and subscriptions, rather than simply needing visibility into cost data.

Allow group CostAnalysts to use tenancy-budget in tenancy

Why it fails: While budgets have a specific resource type, 'usage-reports' or 'tenancy' read access is required for comprehensive cost analysis.

ANY {defined.tag.Department.CostCenter == '400'}

Why it fails: Using the `ANY` conditional operator evaluates to true if a resource matches at least one condition within the braces, which fails here because the rule contains only a single tag criterion rather than multiple alternatives requiring logical disjunction. This syntax is tempting because `ANY` is frequently used to match resources meeting any of several specified criteria, and it would be the correct choice if you needed to dynamically group compute instances belonging to multiple distinct cost centres, such as matching instances tagged with either CostCentre '400' or '500'.

ALL {instance.tag.Department.CostCenter = '400'}

Why it fails: This option fails because it attempts to evaluate a tag value directly rather than targeting the tag's existence or namespace structure using the required `tag.namespace.value` syntax for defined tags, which results in a syntax evaluation error in Oracle Cloud Infrastructure. It is tempting because `ALL` combined with curly braces is the standard logical grouping syntax for dynamic group matching rules, and it would be the correct choice if you needed to evaluate multiple criteria simultaneously where every condition must be met for a resource to join the group.

MATCH {tag:Department:CostCenter = '400'}

Why it fails: This syntax attempts to filter using standard tag matching brackets, which would be valid if you wanted to evaluate free-form tag values or specific metadata attributes outside of defined tag namespaces. It is tempting because the curly brace structure mirrors general tagging syntax found elsewhere in the console, appearing to target key-value pairs directly. However, dynamic group matching rules for defined tags require the `instance.tag.namespace.key` syntax with the `value` operator, meaning this shortcut fails to evaluate the strict namespace hierarchy mandated by Oracle Cloud Infrastructure for defined tags.

Allow user Developers to create load-balancers in compartment AppCompartment

Why it fails: Policies grant access to groups, not individual users, so 'user Developers' is invalid syntax; the subject must be 'group Developers'. It tempts administrators who think per-user grants work, but OCI IAM only supports group-based policy statements.

Allow group Developers to manage lb-family in tenancy

Why it fails: Granting 'manage lb-family' at tenancy scope gives Developers control over load balancers in every compartment, not just AppCompartment. Scoping to a single compartment is the requirement; tenancy-wide grants suit administrators managing resources across the whole tenancy.

Allow group Developers to use network-load-balancers in compartment AppCompartment

Why it fails: 'network-load-balancers' is a distinct resource type covering only network load balancers, so this omits the load balancer family the developers must create and manage. The lb-family verb set is needed; network-load-balancers suits policies targeting only layer-4 load balancers.

10 compartments

Why it fails: Ten compartments is far too restrictive, given that Oracle Cloud Infrastructure supports up to six levels of nested compartments with thousands of entries permitted per tenancy to effectively isolate resources across different business units. Administrators often confuse resource quotas or default service limits with hard architectural caps on compartment depth or quantity. This lower limit would only apply if you were configuring a highly constrained, custom IAM policy threshold rather than managing enterprise-wide resource organisation within the root compartment.

Unlimited with no restrictions

Why it fails: OCI tenancies enforce a hard technical limit on the maximum hierarchy depth and total count of compartments, meaning they cannot scale infinitely without governance boundaries. This misconception arises because resources such as object storage buckets or cloud networks often scale without practical limits, making administrators assume that all structural elements share this unbounded flexibility. In scenarios where an organisation requires a vast logical grouping for resource tagging or flat tenancy designs, ignoring the hierarchical limits would normally apply, but OCI strictly caps the compartment tree depth at six levels beneath the root to ensure predictable policy evaluation and IAM performance.

100 compartments

Why it fails: Oracle Cloud Infrastructure permits up to six levels of nested compartments within a single tenancy, leading to a much higher structural ceiling than one hundred. This lower figure likely confuses tenancy limits with quotas for other distinct resource types, such as the maximum number of custom IAM policies or virtual cloud networks permitted within a standard tenancy region. Such a threshold would severely restrict enterprise resource organization, given that tenancies routinely require hundreds or thousands of compartments to accurately mirror complex departmental hierarchies and security boundaries.

Allow group AppSupport to use metrics in tenancy

Why it fails: The use verb on metrics permits creating and modifying metric-related resources such as alarms, exceeding the read-only requirement. It is tempting because metrics is the correct resource family, and would be correct for a team that must configure alarms, not merely view them.

Allow group AppSupport to inspect telemetry in tenancy

Why it fails: 'telemetry' is not a valid OCI resource type.

Allow group AppSupport to manage alarms in compartment root

Why it fails: The verb "manage" grants full create, read, update and delete control over alarms, exceeding the read-only requirement. It is tempting because manage is the standard verb for administering a resource, and would be correct if the group genuinely needed to create or modify alarms rather than merely view them.

DYNAMIC {compartment.id IN ('ocid1.compartment..oc1..aaaa...')}

Why it fails: Using the `DYNAMIC` keyword with a compartment filter is invalid syntax for OCI dynamic group matching rules, which must use `resource.compartment.id` instead. This option is tempting because the `compartment.id` syntax is legitimately used in IAM policies to define permissions tied to a specific compartment scope. Therefore, administrators often confuse policy syntax with identity domain rule syntax when attempting to group resources by compartment.

ANY {resource.compartment = 'ocid1.compartment..oc1..aaaa...'}

Why it fails: Using `resource.compartment` will fail because this variable evaluates against the compartment where the dynamic group itself resides rather than the compartment housing the target compute instances. This option appears tempting because administrators frequently need to scope dynamic groups by resource location, and `resource.compartment` would indeed be the correct syntax if you intended to match all resources contained within the specific compartment where the dynamic group object has been created.

MATCH {compartment.ocid == 'ocid1.compartment..oc1..aaaa...'}

Why it fails: Omitting the resource type prefix from the matching rule syntax means the evaluation engine cannot parse the condition, rendering the rule invalid. This syntax is tempting because filtering by compartment OCID is a standard requirement for scoped access control, and developers often intuitively assume that passing an identifier directly will scope the evaluation. It would be partially correct if combined with a resource type qualifier, such as `instance.compartment.id`, but standalone attribute matching without specifying the target resource category violates the grammar rules for IAM dynamic group definitions.

You must create a local dynamic group in Tenancy A with the exact same matching rules as Tenancy B.

Why it fails: Replicating dynamic groups locally is unnecessary because cross-tenancy policies handle the principal reference across tenancies.

You must configure an API signing key for the dynamic group in Tenancy B.

Why it fails: Dynamic groups do not use API signing keys; authentication is handled natively by instance principals.

You must establish a Remote VCN Peering connection between the two tenancies.

Why it fails: Remote VCN Peering connects virtual cloud networks across different tenancies for private network traffic, but it is entirely irrelevant here because Object Storage access is handled globally via Identity and Access Management (IAM) service APIs rather than private subnet routing. This option is tempting because administrators often confuse network-level connectivity with identity federation when bridging distinct tenancies. However, VCN peering is the correct choice only when compute instances in Tenancy B require private IP communication, such as database replication or internal microservice traffic, with resources deployed inside a VCN in Tenancy A.

Allow dynamic-group BatchProcessors to manage objects in tenancy CONDITION tag.Project.Name = 'Analytics'

Why it fails: This syntax fails because Oracle Cloud Infrastructure Identity and Access Management policies evaluate conditions against the request context using target variables like `request.instance.tag`, rather than appending a resource-level tag directly to a tenancy-wide statement. This structure appears tempting because it mimics high-level administrative grants designed to scope broad resource management across entire compartments, which would be the correct choice if you needed to authorise a group to administer all objects within a designated compartment based purely on resource labelling without restricting the origin of the API call to specific compute instances.

Allow dynamic-group BatchProcessors to manage objects in tenancy IF target.tag.Project.Name == 'Analytics'

Why it fails: This statement fails because it applies the `target.tag` variable to the tenancy resource level rather than restricting access to requests originating from instances bearing specific compute tags, thereby failing to enforce the required instance-level provenance for the Object Storage bucket. This syntax is tempting because it mirrors the structure used for compartment-wide or tenancy-wide resource governance, and it would be the correct choice if you needed to permit the dynamic group to manage objects across all buckets based purely on administrative resource tagging applied directly to the tenancy compartment.

Allow dynamic-group BatchProcessors to manage objects in tenancy WITH tag Project.Name = 'Analytics'

Why it fails: This syntax fails because the `WITH tag` clause evaluates resource-level free-form tags rather than restricting access based on the instance metadata tags originating the request, thus ignoring the strict requirement to validate the caller's specific instance tags. This rule structure is tempting because it resembles syntax used to scope permissions or audit resources across a compartment based on attached free-form tags, which would be the correct choice if you needed to grant a dynamic group permissions over buckets that themselves bear a specific metadata tag rather than filtering by the compute instance's operational tags.

Allow group SecurityOps to manage log-files in tenancy

Why it fails: The manage verb grants full control over log-files, exceeding the read-only requirement, and log-files is not the audit resource. It tempts because manage appears to cover reading, but least privilege demands inspect, which reads without modifying metadata or content. The correct statement targets audit-events, not log-files.

Allow group SecurityOps to use audit in tenancy

Why it fails: The use verb permits creating and managing audit configurations, not reading audit records, so it fails the read-only requirement. It looks plausible because use is a recognised OCI verb, yet audit reading requires inspect on audit-events. The verb-resource pairing, not the group or scope, is what breaks the statement.

Allow group SecurityOps to inspect audit-trails in compartment root

Why it fails: Audit records live in the tenancy, not a compartment, so scoping to compartment root misses the target resource; audit-trails is also the wrong resource name. Compartment scoping tempts because most OCI resources are compartment-bound, but audit-events must be granted at tenancy scope with inspect.