Landing Zone for Shared Exadata Infrastructure Across Business Units
A conglomerate has 36 AWS accounts in AWS Organizations, three business units, and one OCI tenancy. It plans to run 22 Oracle databases on shared Oracle Database@AWS Exadata infrastructure: 8 production and 14 nonproduction. The DBA team is in India, security operations is in the US, and each business unit wants its own chargeback. Today engineers can see every OCI compartment, there is no consistent tagging, and a previous production-to-development clone exposed protected health information. The company wants onboarding in 60 days and must show environment isolation to auditors. The AWS Marketplace subscription is not yet linked to the OCI tenancy. Provisioning will include Exadata infrastructure, VM clusters, and databases. You are asked to define the landing zone before anyone creates resources.
1. Define the OCI compartment, IAM group, and tagging model for production, nonproduction, and business-unit chargeback.
Read the worked answer
Compartment model. Create compartments by environment first, then by business unit where chargeback requires it: Prod-BU1, Prod-BU2, Prod-BU3, NonProd-BU1, and so on. Avoid a single shared compartment. Federate AWS IAM Identity Center to OCI IAM; map groups such as ODB-Prod-DBA, ODB-NonProd-DBA, ODB-Security-Audit, and ODB-BU-Finance-Read. Grant least privilege at compartment scope, not tenancy scope. Use defined tags: Environment, BU, CostCenter, DataClass, and Owner; enforce with tag defaults and policies. Production DBAs get manage rights in Prod compartments but not tenancy admin; nonproduction DBAs get manage in NonProd only. Security gets read and audit across all. Chargeback uses tags plus the AWS Marketplace subscription linkage; without consistent tags, cost allocation fails. Break-glass tenancy admin is separate and monitored.
2. List the provisioning sequence and the guardrails to apply before the first production database.
Read the worked answer
Sequence. 1) Link the AWS Marketplace subscription to the OCI tenancy and confirm entitlements. 2) Create compartments, groups, policies, budgets, and tag defaults. 3) Create the Oracle Database@AWS network or VCN attachment with non-overlapping CIDRs. 4) Provision Exadata infrastructure in the chosen AZ or AZs with capacity for 22 databases plus headroom. 5) Create VM clusters per environment; do not put production and nonproduction on the same cluster if isolation is required. 6) Create databases with TDE, unified auditing, and a backup policy. 7) Register databases in monitoring and backup tooling. Guardrails: quota per compartment, no public endpoints, a clone approval workflow, and a deny policy for deleting backups. Test the full path in nonproduction first. This sequence prevents resources from landing in the wrong compartment before IAM exists.
3. How do you prevent production-to-development clones from exposing PHI while keeping test data realistic?
Read the worked answer
Treat cloning as controlled data release. Do not use a full physical clone of production into nonproduction for testers. Use Data Pump with subsetting and masking or redaction, or a masked clone workflow, and store mapping keys in a restricted vault. Require approval from the data owner and security; log every clone request. In OCI IAM, deny nonproduction DBAs the ability to read production backups or attach production storage. Apply Oracle Data Safe or equivalent masking before data leaves production. Validate with a post-clone scan for direct identifiers. Keep referential integrity by masking consistently, not by deleting rows. Auditors should see the approval, the masking report, and the access log. This is slower than a snapshot clone, but it is defensible and preserves realism for testing.