OCI Multicloud Architect Professional common mistakes
OCI Multicloud Architect Professional · Understand the traps and how to avoid them.
Treating the Oracle Interconnect for Microsoft Azure as a single all-purpose link and assuming it carries traffic for every VCN and VNet in both tenancies once it is provisioned.
Candidates memorize the FastConnect-plus-ExpressRoute pairing but never learn that reachability is scoped by which VCNs and VNets are attached to the interconnect's virtual circuit and by the routing that is configured on each side, so they answer topology questions as if the connection were global and automatic.
What to do instead
For every interconnect scenario, redraw the topology explicitly: list the attached VCNs on the Oracle side, the attached VNets on the Azure side, the region pairing, and the route tables and security rules on both ends. Practice stating which subnets can reach which, and confirm that unattached networks need their own path (for example a second interconnect or a transit hub).
Assuming the interconnect provides redundancy by itself and answering high-availability questions with a single interconnect and no secondary path.
The service name suggests a resilient managed link, so candidates skip the design step of pairing it with a redundant option such as a second interconnect in another region or a backup IPsec VPN over the internet, and they miss questions about failover behaviour.
What to do instead
Memorize the standard resilient pattern: a primary interconnect plus a secondary path (second interconnect or site-to-site VPN), with routing configured to fail over. Be able to explain what happens to in-flight sessions during failover and why the backup path must be pre-provisioned and tested rather than built on demand.
Mixing up CIDR overlap handling and answering that overlapping VCN and VNet address ranges can be solved purely with routing rules.
Candidates focus on route tables and forget that overlapping private ranges break the interconnect design at the address level, forcing NAT, re-addressing, or a transit architecture; the exam tests whether the architect spots the overlap before proposing routes.
What to do instead
Make CIDR review the first step of every multcloud networking question. If ranges overlap, name the concrete remedies (re-IP one side, use a private NAT or load balancer as an intermediary, or isolate via a hub VCN) and state the trade-off. Practice quickly comparing two address plans and flagging collisions.
Confusing Oracle Cloud Infrastructure security lists with network security groups and applying the wrong one when asked to control traffic between specific instances across the interconnect.
Both filter traffic, but security lists apply at the subnet level while NSGs apply to VNICs; candidates who only remember 'both are firewalls' choose the wrong construct and forget that Azure uses NSGs at the subnet and NIC level, so the mental models do not line up.
What to do instead
Build a comparison table: scope (subnet vs VNIC), statefulness, default rules, and how each maps to the Azure NSG model. Then practice a scenario where one host must be reachable and its subnet peers must not be, and justify why an NSG is the correct tool there.
Designing cross-cloud identity by creating separate local users in each cloud and calling it federation.
Candidates know federation exists but default to local users because it is simpler to describe, missing that the exam expects an identity provider as the source of truth with SAML or OIDC federation into both clouds and group-to-policy mapping.
What to do instead
Practice drawing the identity flow: user authenticates to the IdP, receives a token or assertion, and is mapped to a group in each cloud that carries the policies. Be ready to explain how group membership drives authorization in OCI IAM and in Azure, and why local break-glass users are an exception rather than the design.
Granting broad permissions such as tenancy administrator or subscription owner to a service principal or dynamic group because the candidate cannot recall the least-privilege pattern.
Cross-cloud automation needs a non-human identity, and candidates who are unsure of the exact policy syntax fall back to wide grants, which the exam treats as a design defect in security questions.
What to do instead
Learn the dynamic-group pattern on the OCI side and the service-principal or managed-identity pattern on the Azure side, then write the narrowest policy that permits only the required actions on only the required compartments or resource groups. Practice writing one policy statement per task (read objects, manage buckets) rather than one catch-all statement.
Assuming an Autonomous Database can be reached from the Azure side over the private interconnect without configuring the network access controls and private endpoint path.
Candidates treat Autonomous Database as automatically reachable once the interconnect exists, forgetting that access control lists, private endpoint settings, and the database's own network access configuration all gate connections.
What to do instead
Walk through the full connection path for a private Autonomous Database: client in Azure, route over the interconnect, private endpoint or reserved private IP, network access control list, and database credentials or wallet. Be able to say which layer rejects a connection when one piece is missing.
Choosing between Autonomous Database and Database Service (VM DB systems) by cost or habit rather than by workload characteristics, and misapplying Data Guard or sharding concepts across the interconnect.
The exam frames database questions as architecture decisions, but candidates answer from familiarity with one product and cannot articulate when a self-managed DB system is required, or how standby and replication traffic behaves across clouds.
What to do instead
Prepare a decision matrix: management overhead, scaling model, feature needs (custom OS access, specific patches, third-party agents), and licensing. Then practice describing where the standby sits, which network path carries redo, and what the recovery time objective looks like when the primary cloud is unavailable.
Placing WebLogic domains across clouds without addressing session affinity, shared persistence, and the latency of cross-cloud database calls.
Candidates know WebLogic clustering at a single-site level and assume the cluster extends cleanly over the interconnect, overlooking that multicast-style discovery, session replication, and chatty database access behave differently over a long-haul link.
What to do instead
Design the WebLogic tier as a per-cloud cluster with a load balancer in front and a shared external session store, or keep the cluster in one cloud and use the other for disaster recovery. Be ready to explain how you avoid cross-cloud session replication and how you size the interconnect for database round trips.
Answering observability and operations questions by naming each cloud's native monitoring tool separately and never describing a unified view across the interconnect.
Candidates learn products in isolation and do not connect logging, metrics, and alerting into one operational picture, so they miss questions about detecting a degraded interconnect or correlating an incident that spans both clouds.
What to do instead
Practice a single incident narrative: an application in Azure calls a database in OCI, latency rises, and you must show which metrics and logs on each side you would inspect and how you would correlate timestamps and trace identifiers. Name the specific services you would use for centralized logs and dashboards on each side.