Governance And Administration practice questions

IAM policies cannot be restricted by region; they always apply globally.

Why it fails: IAM policies can be conditioned using request variables like request.region and request.ip.

Use the condition 'where target.region.home = true'

Why it fails: Target region variables in OCI do not support a '.home' property suffix.

Use the condition 'where principal.region = home'

Why it fails: Principal region syntax is incorrect; context variables use the 'request.' prefix for request-time evaluations.

Allow user UserAdmins to inspect compartments in tenancy

Why it fails: Groups, not individual users, are the target of OCI IAM policies, and 'inspect compartments' does not grant user management permissions.

Allow group UserAdmins to manage all-resources in tenancy

Why it fails: This would grant full access to all infrastructure resources, violating the principle of least privilege.

Allow group UserAdmins to manage users in tenancy

Why it fails: User and group management in OCI identity falls under the identity-domains or general tenancy-level identity verbs depending on IAM configuration, but 'manage identity-domains' is the standard OCI IAM construct.

Descriptions are only mandatory when using the CLI, but optional in the Console.

Why it fails: The validation requirement applies across all OCI interaction interfaces (Console, CLI, SDK, API).

Only if the policy is created at the tenancy root level.

Why it fails: Descriptions are mandatory regardless of whether the policy is created at the root tenancy level or inside a compartment.

No, the description is entirely optional and can be left blank.

Why it fails: Leaving the description blank is not permitted by the OCI Console or API validation rules for policies.

Identity Domains

Why it fails: Identity domains manage user populations and authentication, not policy groupings.

Service Gateways

Why it fails: Service gateways provide private access to Oracle services from a VCN, entirely unrelated to IAM.

Dynamic Groups

Why it fails: Dynamic groups are used to group OCI compute instances or resources as principals, not policies.

Actual spend only

Why it fails: Actual spend only evaluates costs that have already been billed or metered up to the current timestamp.

Static historical spend

Why it fails: 'Static historical spend' is not a valid budget calculation type in OCI.

Compartment quota calculation

Why it fails: Compartment quotas are resource limits, not budget calculation rules.

Only when the instance is stopped and restarted.

Why it fails: Membership recalculates automatically as soon as the instance's compartment attribute changes, without any stop or restart. Requiring a restart is tempting because some agents and policies refresh only at boot, but OCI evaluates dynamic group rules against resource metadata continuously, independent of instance power state.

Dynamic group membership is static and never updates after initial creation.

Why it fails: Dynamic group membership is rule-based and recalculated automatically whenever an instance's attributes change, so it is not static. Treating it as fixed after creation is tempting because static groups do require manual membership edits, but dynamic groups exist precisely to track matching criteria such as compartment ID.

Exactly every 24 hours during the daily IAM sync cycle.

Why it fails: OCI evaluates dynamic group matching rules continuously, so membership changes within seconds of the instance's compartment move; a 24-hour IAM sync cycle does not govern this. Daily synchronisation is tempting because directory services often batch reconciliation, but here rule evaluation is event-driven, not scheduled.

where request.ip = 192.168.1.0/24

Why it fails: CIDR blocks must be enclosed in single quotes.

where request.ip = target.ip

Why it fails: Target IP is not a valid IAM condition variable.

where request.ip = '192.168.1.0/24'

Why it fails: Using '=' with a CIDR block is syntactically incorrect in OCI IAM conditions; the cidr function must be used.

where tag.Department.CostCenter = '1004'

Why it fails: Missing the 'target.' prefix required for evaluating resource tags in OCI IAM.

where resource.metadata.tag = '1004'

Why it fails: This is incorrect syntax; OCI condition variables use 'target.tag.<namespace>.<key>'.loc

where request.tag.value = '1004'

Why it fails: Requests do not carry arbitrary tag values in this format; resource tags are evaluated via target.tag variables.

OCI Resource Manager Terraform syntax checker.

Why it fails: Resource Manager checks Terraform files, not standalone OCI IAM policy syntax outside of TF.

OCI Audit log analysis.

Why it fails: Audit logs record past events; they do not validate prospective policy syntax.

OCI Cloud Guard policy rules.

Why it fails: Cloud Guard scans security posture, not IAM policy syntax.

Compartments are strictly bound to a single Availability Domain.

Why it fails: Compartments are logical constructs independent of availability domains and regions.

Once a compartment is created, its parent cannot be changed.

Why it fails: Compartments can be moved within the compartment hierarchy to a new parent compartment.

You cannot delete a compartment until all resources inside it have been deleted or moved.

Why it fails: While this is a common best practice, OCI allows deleting a compartment and its contents recursively in certain workflows, but the statement about global visibility and resource movement (A and B) are the textbook structural definitions.

modify

Why it fails: 'modify' is not an OCI IAM verb.

administer

Why it fails: 'administer' is not a standard OCI IAM verb; 'manage' is the most permissive verb.

Allow group Auditors to manage all-resources in compartment root

Why it fails: The 'manage' verb grants full create, update, and delete permissions, which directly violates the requirement that auditors must not change anything. Even though it is scoped to the root compartment, manage permissions cascade to child compartments and would let the group modify or delete production resources.

Allow group Auditors to read all-resources in compartment root

Why it fails: Scoping the statement to only the root compartment does not automatically include resources that live in nested child compartments for all resource types. Auditors would be unable to see resources in the other compartments, so the visibility goal fails and the administrator would need many additional statements.

Allow group Auditors to inspect all-resources in tenancy

Why it fails: The 'inspect' verb in OCI IAM returns only resource metadata such as names and OCIDs, not the contents or configuration details of the resources. Auditors who need to review actual resource settings and data would be blocked from viewing those details, so this verb is too narrow for the stated read-only visibility requirement.

Allow group ComputeAdmins to use virtual-network-family in compartment Production

Why it fails: This statement grants permissions over VCNs, subnets, and related networking resources, not compute instances. While launching an instance may need networking resources, this policy alone would not authorize the launch itself. The verb and resource type target the wrong service family entirely, so the group still could not create instances.

Allow group ComputeAdmins to read instances in compartment Production

Why it fails: The read verb only permits viewing instance metadata and does not allow launching, terminating, or modifying instances. The requirement is to launch compute instances, which needs the manage or use verb. Read access is useful for auditors and monitoring roles, but it cannot satisfy an operational requirement to create new compute resources.

Allow group ComputeAdmins to manage instances in tenancy

Why it fails: Granting manage instances in tenancy authorizes the group to act on compute instances in every compartment of the tenancy, not just Production. This directly violates the stated requirement. Tenancy-wide scope should only be used for genuinely global administrative roles, and here it would give the security team far broader reach than the scenario permits.

Assign the contractor a pre-authenticated request (PAR) scoped to the compartment

Why it fails: Pre-authenticated requests grant time-limited access to Object Storage buckets and objects, not to compartments or general OCI resources. A PAR cannot authorize the contractor to work with compute, networking, or other services in a compartment, so it does not satisfy the scenario.

Create an IAM policy with a condition that references the current date

Why it fails: OCI IAM policy conditions support variables such as request time, but there is no built-in date-expiration condition that disables a policy statement on a calendar date. Conditions evaluate request attributes at authorization time and cannot schedule a policy to stop applying after 30 days, so this approach cannot meet the automatic expiry requirement.

Add the contractor to a group and set an expiry date on the group membership

Why it fails: OCI IAM groups do not expose a native membership expiry setting in the Console or API. Access derives from group membership, and without a built-in expiration field the administrator would have to remember to remove the user manually, which fails the requirement for automatic revocation after 30 days.

Add the auditors to the Administrators group so they inherit its existing policies

Why it fails: The Administrators group in OCI typically holds manage-level policies over the entire tenancy, so membership would grant full control rather than read-only access. This is the opposite of least privilege and would allow the auditors to alter infrastructure. Group membership should never be used as a shortcut to obtain visibility permissions.

Create a policy with the statement Allow group Auditors to use all-resources in tenancy

Why it fails: The use verb grants the ability to work with existing resources in ways that can change their state, such as attaching or launching dependent resources, and it is intended for consuming resources rather than merely viewing them. It does not provide the neutral, non-modifying visibility an audit role requires, so it fails the read-only constraint.

Create a policy with the statement Allow group Auditors to manage all-resources in tenancy

Why it fails: The manage verb is the broadest permission set and includes create, update, and delete actions on every resource type in the tenancy. This would let auditors modify or destroy resources, directly violating the read-only constraint. Manage should be reserved for administrators who genuinely need lifecycle control, not for a visibility-only role.

Write a broad 'manage all-resources in compartment ProjectA' policy and no deny statement, relying on instance termination protection at the instance level

Why it fails: Instance termination protection is a per-instance setting that a user with manage permissions can disable before deleting, so it is not a reliable enforcement control. A broad manage policy with no restriction still permits deletion, and the requirement demands an explicit prevention that the platform enforces regardless of user action.

Write 'Allow group ProjectAdmins to manage all-resources in compartment ProjectA' plus a statement denying use of the instance terminate verb in that compartment

Why it fails: OCI IAM policies are additive and do not support explicit deny statements; there is no deny syntax in the policy language. Adding a deny-style statement is invalid and will not compile, so this approach cannot enforce the restriction and would leave the broad manage policy granting deletion rights unchecked.

Attach a tag-based access control policy that denies deletion to any instance tagged with ProjectA

Why it fails: Tag-based access control in OCI still uses allow-only statements scoped by tag conditions; it cannot express a deny. While TBAC can restrict which tagged resources a group may act on, it cannot subtract the delete verb from an otherwise granted manage permission, so this does not meet the explicit prevention goal.

Create three compartments and grant each business unit manage all-resources in tenancy so they can self-manage

Why it fails: Tenancy-wide manage all-resources gives every business unit control over all other units' resources, destroying isolation entirely. This is the opposite of the required design. Policies should be scoped to each unit's own compartment so that teams can operate their resources without touching neighbors, and cross-unit access should be granted explicitly and narrowly.

Create three compartments nested under a single business-unit compartment and give the platform team manage all-resources at the tenancy level

Why it fails: Nesting all three units under one parent blurs the intended separation and complicates policy inheritance, since parent-level statements cascade to children. Granting the platform team tenancy-wide manage all-resources goes far beyond networking and violates least privilege. This combination undermines both the isolation and the centralized-but-limited management goals.

Create one compartment for all business units and rely on tagging to separate their resources

Why it fails: Placing all units in a single compartment removes the hard isolation boundary that compartments provide, and tags alone are not an access-control boundary unless combined with tag-based policies. A single shared compartment makes quota management, cost tracking, and policy scoping far harder. This approach fails the isolation requirement even if tagging is used diligently.

IAM policies

Why it fails: IAM policies grant or deny access to resources; they carry no cost metadata. They are tempting because they are attached to compartments and groups, but cost allocation by business unit requires tags on resources, which policies cannot apply or report on.

Budgets

Why it fails: Budgets alert on spend against a defined threshold; they cannot attach metadata key-value pairs to resources or break costs down by business unit. They are tempting because they do track operational cost, but cost allocation by tag requires tagging itself, not budget alerts.

Compartment quotas

Why it fails: Compartment quotas cap how much a compartment may consume, enforcing governance limits rather than reporting spend. They are tempting because they operate on compartments, but they neither attach metadata key-value pairs to resources nor allocate costs back to business units.

OCI Notifications

Why it fails: OCI Notifications delivers published messages to subscribers and holds no record of API calls, so it cannot show who deleted the VCN. It is tempting because it is event-driven and audit-adjacent, and would be the correct choice for alerting a team when a monitored resource changes.

OCI Events

Why it fails: OCI Events routes event messages to targets for automation; it does not retain a queryable history of past API calls. It is tempting because it deals with the same API activity, and would be the correct choice when configuring a rule to trigger an action whenever a VCN is deleted.

OCI Monitoring

Why it fails: OCI Monitoring tracks metric streams and alarms, not API audit events, so it cannot name the principal who deleted the VCN. It is tempting because Monitoring does surface resource state changes, and would be right for alerting on CPU or availability thresholds rather than answering who-did-what forensic queries.

OCI Tag Defaults

Why it fails: Tag defaults automatically apply tags to newly created resources, completely unrelated to spending alerts.

OCI Cloud Guard

Why it fails: Cloud Guard is focused on security posture management, not budget tracking.

OCI Cost Analysis

Why it fails: Cost Analysis is a dashboard tool for viewing and filtering costs, not an automated alert engine.