Federated multi-BU governance after broad tenancy policies
Helios Manufacturing is moving 5 business units into OCI. It has 320 employees authenticating in Microsoft Entra ID and 12 compartments already created ad hoc. Developers currently receive broad manage all-resources in tenancy policies because project deadlines are tight. Production and development share the same compartment for two BUs. Finance cannot separate cloud spend by product line, and last month a developer created a 24-OCPU GPU shape in production that ran for 9 days unnoticed. Security requires MFA for all administrators, quarterly access reviews, and audit logs retained for one year. The cloud team wants self-service VCN creation in development but not in production, and wants budget alerts per business unit. The company has no tag policy and uses only free-form tags inconsistently.
1. Design the compartment hierarchy and IAM policy model. Show how self-service VCN creation in development is allowed without granting production access.
Read the worked answer
Create a hierarchy under the tenancy root: a Shared compartment for networking, logging, and security; a Production parent; a NonProduction parent; and a Sandbox. Under Production and NonProduction, create one subcompartment per business unit. Keep a separate compartment for each environment so policies and budgets inherit cleanly. Delete or quarantine the ad hoc compartments after migration.
Policies should attach at the business-unit subcompartment, not the tenancy. For development self-service, create a group such as dev-network-admins and allow it to manage virtual-network-family and instance-family in the NonProduction/BU compartment only. Do not grant manage all-resources in tenancy. Production network changes should be limited to a platform group or a dynamic group used by the CI/CD pipeline, with change approval outside OCI. Use distinct groups for compute operators, database operators, and security auditors.
Because OCI policies are allow-only and inherited downward, avoid broad statements at the root. If a group needs read-only visibility, grant inspect at the parent compartment. Use use rather than manage where possible. For the CI/CD pipeline, use instance principals or a dynamic group scoped to the production compartment, not a long-lived user API key. Test each policy with a real user in the console before rollout.
2. How should federation, MFA, break-glass access, and quarterly access reviews work with Entra ID and OCI IAM?
Read the worked answer
Use an OCI IAM identity domain as the primary domain and federate it with Microsoft Entra ID using SAML 2.0. Enforce MFA in Entra ID for all users, especially administrators, so OCI does not depend on a second MFA policy. Map Entra ID groups to OCI groups by function and business unit; do not map individuals. Use SCIM provisioning if available in the chosen identity domain to automate joiner/mover/leaver changes, and reconcile group membership quarterly.
Keep one or two break-glass local administrators in the Default identity domain, protected by MFA, with no API keys. Store credentials in a controlled vault, alert on sign-in, and test the account quarterly. Normal administrators should have federated accounts only. For production database and network changes, require a requestable group or a ticket-based approval; if the identity domain supports temporary group membership, use it, otherwise automate group add/remove through a workflow.
Quarterly access reviews should combine OCI IAM group membership exports with Entra ID sign-in logs and OCI Audit activity. Review who has manage at production scope, who used break-glass, and which API keys or customer secret keys exist. Remove unused keys and stale group members. Retain review evidence for the auditor; a policy is not a control until someone checks it.
3. Design the tagging, budget, quota, and audit-retention controls needed to prevent another unnoticed 24-OCPU production expense.
Read the worked answer
Define a tag namespace with required cost-tracking tags: business unit, product line, environment, owner, and cost center. Apply tag defaults on compartments so resources created through the console or API inherit values, and use defined tags rather than free-form tags. Enforce tag policy through Security Zones or Cloud Guard where possible; at minimum, report untagged resources weekly.
Create OCI Budgets at each business-unit compartment with alerts at 50, 80, and 100 percent of forecast. Budgets alone do not stop spend, so add compartment quotas for GPU shapes and OCPU counts in production. For example, cap production GPU OCPUs and require a separate approved compartment for large shapes. Use OCI Monitoring alarms on budget and quota events.
For audit retention, enable OCI Audit and export logs to Object Storage through a service connector or Logging. Set a one-year retention policy and restrict delete access to the security team. Also retain VCN flow logs for production. Cloud Guard should detect public buckets, open security lists, and untagged resources. The goal is defense in depth: policy prevents some actions, quotas cap the blast radius, budgets create visibility, and audit proves what happened.