Multicloud Fundamentals
Multicloud Fundamentals
This domain tests how you choose and justify a multicloud architecture on OCI: service placement, Oracle's multicloud products, billing and support boundaries, and shared responsibility. Oracle's model is not "move everything to OCI"; it is "run Oracle Database where your application and data already are" through Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS, plus OCI-native services connected by private interconnects.
Core rules and concepts
- Multicloud by design places a workload deliberately: app tier in one cloud, database or analytics in another, with a documented reason such as latency, data residency, existing skills, or M&A.
- Oracle Database@Azure runs Exadata Database Service, Autonomous Database, and Base Database Service on OCI-managed infrastructure inside Azure regions. It is ordered through Azure Marketplace, administered with Azure tooling and Microsoft Entra ID, and billed through Azure. Oracle Database@Google Cloud similarly places Exadata and Autonomous Database in Google Cloud regions with Google Cloud console and billing integration. Oracle Database@AWS is an emerging option; verify region and service availability before designing.
- OCI-native multicloud uses OCI regions plus private connectivity to another cloud. It is a different pattern from embedded database services: you operate two control planes.
- Shared responsibility changes by service. For embedded database services, the cloud provider manages infrastructure; the customer still owns data, database users, network rules, and patching choices that are not automated.
Worked example
A payments team has an Azure Kubernetes Service app and wants Oracle Exadata. Deploying Exadata in a distant OCI region and connecting over the internet adds latency and egress. Oracle Database@Azure in the same Azure region keeps database traffic on a private VNet path, lets the team use Entra ID and Azure billing, and avoids a second operational console for infrastructure. The reasoning is placement first, then connectivity, identity, and support.
Traps
Assuming every Oracle Database@... service is available in every region; assuming one console or one IAM policy set governs both clouds; ignoring the billing and support boundary; treating a VPN as equivalent to a private interconnect; and forgetting that embedded services still require customer-side database security.