OCI Multicloud Architect Associate common mistakes
OCI Multicloud Architect Associate · Understand the traps and how to avoid them.
Assuming that Oracle Interconnect for Azure or AWS provides automatic end-to-end routing between all VCNs and cloud VNets without configuring route tables and security rules.
Candidates treat the interconnect as a simple VPN that just works, forgetting that it only provides the physical/logical link; routing must be explicitly configured on both sides (VCN route tables, Azure UDRs, AWS route tables) and security lists/NSGs must allow traffic.
What to do instead
Always design and verify routing: on OCI, add route rules in the VCN route table pointing to the DRG or interconnect gateway; on Azure, configure user-defined routes to the ExpressRoute or VPN gateway; on AWS, add routes to the transit gateway or virtual private gateway. Also confirm security rules permit the required traffic. Test with ping/traceroute before assuming connectivity.
Confusing OCI Identity and Access Management (IAM) policies with Azure RBAC or AWS IAM policies, and assuming a single policy syntax or evaluation logic works across clouds.
Candidates map familiar concepts from one cloud to another without recognizing that OCI policies are written in a declarative language (allow group X to manage Y in compartment Z) while Azure uses role assignments and AWS uses JSON policy documents with different evaluation logic (e.g., OCI has no explicit deny).
What to do instead
Study the OCI policy syntax separately: policies are attached to compartments, use verbs like inspect, read, use, manage, and have conditions. For cross-cloud access, use federation (e.g., OCI Identity Federation with Azure AD or AWS IAM Identity Center) and map external identities to OCI groups. Always test policies with the Policy Simulator or by assuming the role.
Designing a multicloud architecture that replicates all data synchronously between clouds without considering latency and egress costs, leading to poor performance and unexpected bills.
Candidates focus on high availability and assume synchronous replication is always best, ignoring that inter-cloud latency (typically 20-100 ms) makes synchronous replication impractical for transactional workloads and that data egress between clouds incurs significant cost.
What to do instead
Choose asynchronous replication for cross-cloud data stores (e.g., Oracle Data Guard async, Azure Geo-Replication, AWS Cross-Region Replication). Use a data integration service or change data capture for near-real-time sync. Calculate egress costs early and consider using dedicated interconnects with committed data rates to reduce cost. Document the RPO/RTO trade-offs.
Overlooking that OCI's maximum security zone or compartment quotas can block resource creation in a multicloud deployment, and failing to request limit increases in advance.
Candidates test in a small environment and assume limits are infinite or easily raised. In production multicloud scenarios, services like OCI Interconnect, DRG attachments, or compute instances may hit service limits, causing deployment failures during critical phases.
What to do instead
Review OCI service limits for the target region and services (e.g., number of DRG attachments, interconnect ports, VCNs per tenancy). Submit limit increase requests early via the OCI Console or support. Include limit checks in the architecture review checklist and monitor usage with OCI Monitoring.
Assuming that OCI's identity federation with Azure AD or AWS IAM Identity Center automatically grants the same permissions across clouds without additional role mapping.
Candidates think federation is a one-time setup that synchronizes users and permissions. In reality, federation only authenticates users; authorization must be configured separately in each cloud (e.g., OCI groups and policies, Azure role assignments, AWS permission sets).
What to do instead
After federation, explicitly map external identity provider groups to OCI groups and assign OCI policies to those groups. On the other cloud, map the same groups to appropriate roles. Use SCIM for user/group provisioning if supported. Test with a federated user to ensure correct access.
Ignoring the need for a transit routing architecture (e.g., hub-and-spoke) when connecting multiple VCNs and cloud networks, resulting in a mesh of point-to-point connections that is hard to manage and scale.
Candidates start with simple two-point connections and then add more clouds or regions without redesigning, leading to complex peering and routing tables that become error-prone and difficult to troubleshoot.
What to do instead
Design a hub-and-spoke topology using OCI Dynamic Routing Gateway (DRG) as the hub for OCI VCNs and interconnects, and equivalent transit gateways in other clouds (AWS Transit Gateway, Azure Virtual WAN). Use separate route tables for each spoke and summarize routes where possible. Document the routing plan.
Failing to account for data residency and sovereignty requirements when replicating data across clouds or regions, leading to non-compliance.
Candidates focus on technical feasibility and cost, overlooking that some data (e.g., personal data, financial records) may be legally required to stay within specific geographic boundaries or may not be allowed to leave a certain cloud provider.
What to do instead
Identify data classification and regulatory constraints early. Use OCI regions that meet residency requirements, and configure replication to only compliant regions. For cross-cloud replication, ensure the destination cloud's region is also compliant. Implement encryption and access controls, and document compliance mapping.
Assuming that OCI's built-in security services (e.g., Cloud Guard, Security Zones) automatically extend to other clouds, and neglecting to configure equivalent native controls there.
Candidates rely on OCI's security posture management and assume it covers multicloud resources. In reality, each cloud has its own security tools (AWS Security Hub, Azure Security Center), and cross-cloud visibility requires integration.
What to do instead
Enable and configure native security services in each cloud (e.g., AWS GuardDuty, Azure Defender). Use a cloud security posture management (CSPM) tool that supports multicloud, or integrate OCI Cloud Guard with third-party SIEM. Regularly review security recommendations in all clouds.
Underestimating the complexity of identity propagation for applications spanning OCI and another cloud, and using long-lived credentials or shared service accounts instead of federated tokens.
Candidates take shortcuts by embedding static credentials in application code or configuration to simplify cross-cloud authentication, which creates security risks and operational overhead (credential rotation).
What to do instead
Use workload identity federation: OCI supports instance principals and resource principals; other clouds have similar features (AWS IAM roles for EC2, Azure managed identities). For cross-cloud, use OIDC federation between clouds or a secrets manager. Avoid long-lived credentials; automate rotation.
Designing a multicloud disaster recovery plan that assumes failover between clouds is instantaneous and requires no manual steps, without testing the runbook.
Candidates treat DR as a checkbox and assume that because data is replicated, applications will automatically fail over. In reality, DNS changes, IP address reconfiguration, and service dependencies often require orchestrated manual or automated steps that are not tested.
What to do instead
Define a detailed DR runbook with steps for each cloud, including DNS failover (e.g., using Global Traffic Management), reconfiguring connection strings, and starting compute instances. Test the plan regularly (at least annually) with a planned failover exercise, measure RTO/RPO, and update the runbook based on findings.