Nordwind Health: One Tenancy, Three Regulated Subsidiaries, Forty Projects a Year
Nordwind Health is a holding company with three subsidiaries: a hospital operator handling patient records under strict national residency rules, a diagnostics business running commercial workloads, and a shared services unit providing networking, identity and databases to both. There are 14,000 staff authenticating today against Microsoft Entra ID, and 60 external contractors who need time-boxed access. Roughly 40 new projects start each year, each wanting self-service ability to create compute, block volumes and buckets. The holding company already runs six AWS accounts and wants a single operating model across both clouds. Two previous cloud incidents involved orphaned resources nobody could attribute to a cost centre, and one involved a contractor retaining access 11 weeks after contract end. A shared network hub already exists on-premises with a 10.0.0.0/8 address plan, and the diagnostics business runs a 172.20.0.0/16 range that must remain reachable.
1. Design the tenancy and compartment topology. Justify the depth and the placement of shared services, and explain how you prevent one subsidiary's data from being visible to another.
Read the worked answer
Start from the failure you are preventing: a diagnostics engineer able to read patient data, or a project able to delete a shared database. Compartment structure must express both the organisational boundary and the environment boundary, because cost attribution needs the former and blast radius needs the latter.
- Root splits into three subsidiary compartments (hospital, diagnostics, shared-services) mirroring the legal entities. This is the boundary that maps to the compliance obligation - residency and access rules attach to the entity, not to a project.
- Under each subsidiary, environment compartments (prod / non-prod / sandbox), then project compartments beneath. Three to four levels is sufficient; deeper nesting adds policy verbosity without adding isolation, and policies written at the wrong level are the usual cause of over-broad access.
- Shared services get their own compartment plus a network compartment holding the hub VCN. Shared resources are never placed inside a project compartment, otherwise project-level policies grant delete rights over shared infrastructure.
Isolation is enforced by IAM policy at the subsidiary compartment, granting each subsidiary's group manage all-resources only within its own subtree, with no policy at tenancy root granting broad access. Because OCI policies are hierarchical and additive, the negative-space rule matters more than the grants: never write a tenancy-level policy for a human group. Cross-subsidiary reads (the shared database team) are granted explicitly at the resource compartment, not by widening the group.
Use separate VCNs per subsidiary even though a hub exists - a shared VCN makes the compartment boundary cosmetic, since security lists and route tables become a single surface. Connect via the hub instead.
2. How would you handle workforce federation, contractor time-boxing, and break-glass access? Be specific about where each mechanism lives.
Read the worked answer
Federation: the tenancy's identity domain federates to Entra ID over SAML, so Nordwind keeps one joiner/mover/leaver process and OCI never becomes an authoritative user store. Group-to-group mapping is declared once, and OCI policies reference the federated groups. Crucially, do not federate everything: at least one local identity-domain administrator must exist for the case where Entra ID or the federation metadata breaks, otherwise a federation outage becomes a total lockout.
Contractors: time-boxing cannot be enforced by federation alone - Entra ID governs authentication, not OCI authorisation. Two mechanisms do the real work:
- Put contractors in dedicated identity-domain groups with policies scoped to a single project compartment, so the maximum damage is one project.
- Automate deprovisioning from an HR/contract feed with a hard expiry attribute, and reconcile monthly against OCI Audit reports of who actually authenticated. The 11-week overrun happened because nobody could see usage; the fix is an access review driven by audit logs, not a better spreadsheet.
Break-glass: one or two named accounts in the Default identity domain (not federated), credentials in a physical safe or a sealed break-glass vault, MFA enforced, and every use generating an alert routed to security. The account holds tenancy-administrator rights but is never used for routine work - the test is that routine administrators should be unable to do certain things without it.
For the cross-cloud requirement, mirror the same model in AWS IAM Identity Center from the same Entra ID groups, so a leaver loses both clouds in one action. That is what makes the operating model single rather than duplicated.
3. Forty projects a year want self-service. Design the governance guardrails that let them have it without a central approval bottleneck.
Read the worked answer
Self-service fails in two directions: central approval creates a queue and projects route around it; no guardrails create orphaned resources. The design is to make the compliant path the fast path and the non-compliant path impossible rather than merely discouraged.
Tags as the enforcement spine. Define a small required set - cost-centre, subsidiary, project, environment, data-classification, owner - as defined tags in a tag namespace, with tag defaults set per compartment so every created resource inherits them without the project doing anything. Then write a policy that permits resource creation only when the classification tag is present. Orphan attribution becomes structurally impossible rather than a monthly cleanup exercise.
Templates over tickets. Publish a small number of validated Terraform stacks (web tier, database tier, analytics bucket) that create compartments, network, logging and budgets together. Projects self-serve from the catalogue; anything outside it goes to architecture review, which is now the exception rather than the rule.
Budgets and quotas per project compartment. Assign a budget with alerts at 50/80/100% on creation and cap shapes with quota policies, so a runaway instance stops at a defined boundary instead of surprising finance.
Audit as the feedback loop. Cloud Guard and Audit-based detections for public buckets, unused block volumes and users active past contract end. Publish the findings monthly to a cross-cloud hygiene dashboard.
Cost allocation is a policy outcome, not a finance-reporting afterthought. If tagging is enforced at creation, the 40 projects can be trusted with self-service; if it is not, no amount of reporting will reconcile the bill.