OCI Multicloud Architect Associate cheat sheet

OCI Multicloud Architect Associate covers OCI-Azure Interconnect (Oracle Database@Azure), OCI-AWS Interconnect (Oracle Database@AWS), and OCI-Google Cloud Cross-Cloud Interconnect (Oracle Database@Google Cloud); each pairs OCI database services with a partner hyperscaler's compute, network, and marketplace.

Oracle Database@Azure runs Exadata and Base Database Service in Azure data centers, billed through Azure Marketplace and managed via the Azure portal; the OCI tenancy is federated behind the scenes and OCI IAM governs the database resources.

Oracle Database@AWS colocates Exadata in AWS Availability Zones and connects through OCI-AWS Interconnect; AWS billing covers the database while OCI controls the Exadata infrastructure and OCI IAM policies.

Oracle Database@Google Cloud uses Google Cloud Cross-Cloud Interconnect and Google Cloud regions; Google Cloud Marketplace billing and Google Cloud console provisioning sit on top of OCI-managed Exadata infrastructure.

OCI's multicloud value proposition rests on four pillars: lowest-latency database adjacency, consistent OCI IAM and governance, unified OCI Console visibility, and no data egress between OCI and the partner cloud on dedicated interconnect paths.

A multicloud tenancy is a single OCI tenancy that can host resources in multiple OCI regions and connect to multiple partner clouds; the tenancy is the root of IAM, compartment, and budget hierarchy.

Regional vs. multiregional: OCI regions are independent failure domains; multicloud designs should place the OCI database in the region nearest the partner cloud region to minimize interconnect latency (sub-2 ms typical on dedicated links).

Shared responsibility in multicloud: the partner cloud owns its physical and hypervisor layer for its services, OCI owns Exadata infrastructure and database patching for Oracle Database@ services, and the customer owns data, IAM policy, and network configuration.

OCI-Azure Interconnect uses a dedicated, private, low-latency link between an OCI region and an Azure region; it is provisioned through the OCI Console under Networking > Multicloud > Interconnect and appears as a virtual circuit in FastConnect terms.

OCI-AWS Interconnect is a private dedicated connection between OCI and AWS; it is not the public internet and not a VPN; it is ordered via OCI and AWS and requires a customer-owned or partner-provided cross-connect at the meet-me point.

OCI-Google Cloud Interconnect uses Google Cloud's Cross-Cloud Interconnect; OCI side is configured as a FastConnect virtual circuit and Google side as a VLAN attachment on a Partner Interconnect or Dedicated Interconnect.

A virtual circuit (VC) is the logical FastConnect construct; each multicloud interconnect maps to one or more VCs with a BGP session, a VLAN, and a bandwidth setting (1, 2, 5, 10 Gbps typical).

Routing rule: OCI VCN route tables must include a route for the partner cloud CIDR pointing to the Dynamic Routing Gateway (DRG); the DRG attaches to the interconnect and runs BGP with the partner.

BGP ASN planning: OCI DRG uses a private ASN (e.g., 64512) and the partner cloud uses another; never reuse ASNs across the two clouds, and avoid ASN 64512-65534 collisions with on-premises.

CIDR non-overlap is mandatory: OCI VCN CIDRs, partner cloud VPC/VNet CIDRs, and on-premises CIDRs must not overlap; overlapping ranges break BGP route installation and cause silent black holes.

Latency and bandwidth: dedicated multicloud interconnects typically deliver single-digit-millisecond RTT within a metro; bandwidth is provisioned per VC and can be upgraded without re-cabling, but the partner cloud's interconnect port capacity is the ceiling.

OCI IAM is the authoritative identity plane for Oracle Database@Azure, @AWS, and @Google Cloud resources; partner-cloud users are mapped to OCI IAM via federation (SAML 2.0 or OIDC) or via partner-cloud identity bridging.

OCI Identity Domains (the successor to the default identity provider) support SAML federation with Microsoft Entra ID, AWS IAM Identity Center, and Google Workspace; federation is configured per identity domain, not per tenancy.

Compartments are the OCI authorization boundary; policies are written as 'Allow group X to manage database-family in compartment Y'; cross-cloud access is granted by adding the federated group to an OCI group and attaching a policy.

Policy verbs: inspect < read < use < manage; 'manage' includes all lower verbs; use 'use' for consuming a resource and 'manage' for creating or deleting it.

Dynamic groups match OCI compute instances by matching rule (e.g., instance.compartment.id = 'ocid1.compartment...'); they are the OCI equivalent of AWS IAM roles for EC2 and are used for instance-principal access to Object Storage and Vault.

Federation trust direction: the partner cloud is the identity provider (IdP) and OCI is the service provider (SP); the SAML assertion carries group membership used for OCI policy matching.

Least privilege across clouds requires mapping partner-cloud roles (e.g., Azure Owner, AWS AdministratorAccess) to OCI groups; avoid granting partner-cloud Owner to identities that also hold OCI tenancy-admin.

OCI IAM policy conditions support request.principal.type, request.region, and target.compartment.id; use them to restrict federated partner-cloud principals to specific compartments or regions.

Oracle Database@Azure/@AWS/@Google Cloud exposes the database as a native resource in the partner cloud, so partner-cloud applications connect over the private interconnect using a standard Oracle Net (SQL*Net) connection string and TCPS on port 1521.

Transparent Data Encryption (TDE) is mandatory for Oracle Database@ services; keys are managed in OCI Vault (or the partner cloud KMS via OCI Vault external key management) and must be reachable during database startup.

Data Guard across clouds: a primary in Oracle Database@Azure and a standby in an OCI region (or another partner cloud) provides cross-cloud DR; redo transport uses the interconnect and requires matching DB and TDE wallet configuration.

Active Data Guard offloads read-only reporting to a standby, which is the standard pattern for keeping analytics traffic off the primary OLTP database in a multicloud deployment.

Autonomous Database is OCI-native and can be reached from partner clouds over the interconnect or a private endpoint; it is not deployed inside the partner cloud data center, unlike Oracle Database@ services.

Application tier pattern: keep latency-sensitive app servers in the same partner cloud region as the database; batch and reporting workloads can run in OCI and reach the database over the DRG path.

GoldenGate provides logical replication between Oracle Database@ services and other databases (including non-Oracle targets) and is the recommended tool for zero-downtime migration and active-active data distribution.

Object Storage cross-cloud access uses the S3-compatible API on OCI Object Storage or the partner cloud's object store reached over the interconnect; avoid public internet egress for bulk data movement.

OCI Audit records all API calls against OCI resources, including Oracle Database@ resources; logs are retained per tenancy and can be streamed to OCI Streaming or Object Storage for long-term retention.

OCI Logging and Monitoring: enable the Database service logs and the VCN flow logs on the DRG and interconnect VCs to observe multicloud traffic; flow logs are the primary tool for detecting unexpected cross-cloud paths.

OCI Cloud Guard detects misconfigurations such as public buckets and overly broad IAM policies; it uses detector recipes and responder recipes scoped to compartments.

OCI Security Zones enforce a maximum-security posture at compartment creation (e.g., no public buckets, no public IPs); they are the OCI equivalent of AWS SCPs combined with Config rules.

Budget and cost governance: OCI Budgets and Cost Analysis track OCI-side spend; partner-cloud marketplace billing for Oracle Database@ services appears on the partner cloud invoice, so multicloud cost reporting requires joining two billing datasets.

Compliance: OCI's compliance program covers SOC 2, ISO 27001, HIPAA, and PCI DSS; for multicloud, the customer must verify that the partner cloud's compliance attestations cover the colocated Oracle Database@ service.

Key management: OCI Vault holds TDE master keys and secrets; use OCI Vault external key management to bring your own key from a partner cloud HSM, and rotate keys on a defined schedule.

Incident response: the OCI Console and the partner cloud console each show only their own resources; runbooks must include both consoles, and OCI Audit plus partner-cloud CloudTrail/Activity Log are both required for a complete timeline.

Network change control: BGP session changes, CIDR additions, and VC bandwidth changes on multicloud interconnects should go through a change-management process because a misconfigured route table can black-hole database traffic.