OCI Architect Professional common mistakes
OCI Architect Professional · Understand the traps and how to avoid them.
Treating IAM policies as if a broad statement at the tenancy root or a compartment-level policy automatically covers every child resource, then being surprised when a user gets 'not authorized' on a specific bucket or instance.
Candidates carry over mental models from single-account cloud platforms where a root policy is implicitly inherited everywhere. OCI policies are scoped to the compartment they are attached to and apply to the resources in that compartment and its descendants, but the verb/resource-type combination must actually match, and cross-tenancy or identity-domain boundaries break inheritance. Candidates also forget that policy statements need both the correct resource-type and the correct verb (inspect/read/use/manage).
What to do instead
Before answering, write out the four policy components explicitly: subject (group or dynamic group), verb, resource-type, and compartment path. Check that the verb matches the action (read vs use vs manage), that the resource-type string is the exact OCI type, and that the compartment in the policy is the one containing the resource or an ancestor. For cross-tenancy, recall that both the source and target tenancy need matching policy statements.
Confusing instance principals (dynamic groups) with user principals, or writing a dynamic group matching rule that uses the wrong attribute, so a compute instance cannot call an OCI service even though the policy looks correct.
Candidates conflate 'who' the policy subject is. Dynamic groups match instances by rule (for example by compartment OCID or instance OCID), not by user membership. A common error is putting a user group in the policy when the caller is an instance, or writing a matching rule against an attribute the instance does not carry. Candidates also forget that the instance must be in a compartment referenced by the rule and that the instance principal must be enabled in the SDK/CLI.
What to do instead
Identify the caller first: human user, instance principal, resource principal, or service. For instances, verify the dynamic group matching rule references an attribute the instance actually has (compartment OCID is the most robust), confirm the instance sits in that compartment, and confirm the policy grants the dynamic group the needed verb on the target resource-type. For SDK calls, confirm the code is using the instance-principal auth provider, not a config-file user.
Assuming a VCN is reachable from the internet or from on-premises by default, and answering connectivity questions without checking route tables, security lists/NSGs, and gateways together.
Candidates reason about one control at a time. In OCI, reachability requires the route table to point traffic at the right gateway (Internet Gateway, NAT Gateway, Service Gateway, DRG), the security list or NSG to allow the traffic, and the subnet to be the correct type (public vs private). A public subnet with no route to an Internet Gateway is still unreachable. A correct route with a missing security rule still fails.
What to do instead
For any connectivity scenario, evaluate in order: (1) subnet type and whether the resource has a public or private IP, (2) route table entries for the relevant CIDR (0.0.0.0/0 to IGW for inbound internet, to NAT for outbound-only, to Service Gateway for OCI services, to DRG for on-prem), (3) security list and NSG rules in both directions (stateful, so return traffic is automatic), (4) whether the on-prem side has a matching route and the DRG attachment/IPSec or FastConnect is up.
Mixing up security lists and network security groups, or applying an NSG rule but forgetting the NSG must be attached to the VNIC, leading to wrong 'why is this blocked' conclusions.
Both controls filter traffic, but security lists apply at the subnet level and NSGs apply to individual VNICs. Candidates often assume an NSG rule alone opens traffic, or that a permissive security list overrides a restrictive NSG. In OCI both must allow the traffic for it to pass when both are in play.
What to do instead
State explicitly which control is subnet-scoped (security list) and which is VNIC-scoped (NSG). For a blocked-flow question, check that the NSG is attached to the relevant VNIC and that its rules allow the flow, and that the subnet's security list also allows it. Remember security lists and NSGs are stateful, so you only need the initiating direction.
Choosing a load balancer type or backend set configuration without matching the traffic profile, for example using a flexible shape with too few minimum bandwidth for sustained throughput, or putting a TCP health check on an HTTP-only application.
Candidates pick the 'default' or cheapest option and ignore that the load balancer shape, listener protocol, and health-check policy must align with the workload. A wrong health check marks healthy backends as unhealthy and causes 502s; an undersized flexible shape throttles under load. Candidates also forget session persistence and SSL termination placement.
What to do instead
Match listener protocol to the app (HTTP/HTTPS vs TCP), set the health check to a path and port the app actually serves, and for flexible shapes set minimum and maximum bandwidth based on expected peak. Decide where TLS terminates and whether backend SSL is needed. For session-dependent apps, enable cookie-based persistence and confirm backend set policy.
Under-sizing or misconfiguring an instance's boot volume and block volumes, such as assuming the boot volume can be shrunk, or expecting a volume resize to take effect without rescanning or extending the filesystem.
Candidates treat cloud disks like local disks. OCI block and boot volumes can be grown online but not shrunk; after a resize the OS must rescan the device and the filesystem must be extended, otherwise the guest still reports the old size. Candidates also forget performance is tied to VPUs/volume size and that attaching a volume is separate from mounting and formatting it.
What to do instead
For resize questions: grow only, then run the rescan and filesystem-grow steps in the guest, and confirm the partition table was updated. For performance, check the volume's VPU setting and whether it is balanced vs higher performance. For attach questions, confirm the volume is attached to the instance, then partitioned/formatted/mounted and added to fstab if persistence is required.
Assuming object storage buckets are private by default in every respect or that a pre-authenticated request (PAR) grants broader access than intended, and misjudging public bucket exposure.
Candidates blur bucket visibility, IAM policy, and PAR scope. A bucket can be private while an object is shared via a PAR with a specific expiry and permission (read or write). Conversely a public bucket exposes objects regardless of IAM. Candidates also forget PARs can be object-scoped or bucket-scoped and that they bypass normal IAM auth.
What to do instead
Separate the three layers: bucket visibility (private/public), IAM policies on the bucket/compartment, and PARs. For a sharing scenario, choose a PAR with the minimum permission (object read vs read/write), the narrowest target (single object vs bucket), and a defined expiry. For exposure questions, check bucket visibility first, then IAM, then any active PARs.
Ignoring fault domains and availability domains when placing instances or designing high availability, and assuming a regional subnet spans ADs automatically.
Candidates design for HA without mapping the physical topology. A regional subnet spans ADs, but an instance still lands in one AD and one fault domain. Placing all instances in one fault domain defeats HA even in a multi-AD region. Candidates also forget some regions are single-AD and that services like the load balancer need backends across ADs/fault domains.
What to do instead
For HA designs, explicitly distribute instances across availability domains where the region has multiple, and across fault domains within an AD. Confirm the subnet is regional if cross-AD placement is needed. Check that the load balancer, database, and storage tiers also tolerate an AD or fault-domain loss, and that the region actually offers the AD count assumed.
Answering identity questions without distinguishing identity domains (IAM with Identity Domains) from the legacy IAM model, and misstating where users, groups, and policies live.
OCI moved to Identity Domains, which changes how federation, MFA, and policy attachment work. Candidates apply legacy assumptions, such as policies being attached at the tenancy root in the old way, or forgetting that a user can belong to an identity domain and that federation is configured per domain. This produces wrong answers on federation and MFA scenarios.
What to do instead
Identify whether the scenario uses Identity Domains. Place users and groups inside the relevant identity domain, configure federation (SAML/OIDC) at the domain level, and attach policies to the compartment with the correct subject (group in the domain or dynamic group). For MFA, confirm it is enforced by the domain's sign-on policy, not assumed globally.
Treating the compute shape and image selection as interchangeable, for example assuming any shape supports any image or that a burstable/flexible shape gives guaranteed performance, and ignoring the implications for licensing or GPU workloads.
Candidates pick a shape by vCPU/memory alone. Not all shapes support all images (Windows vs Linux, GPU images, ARM vs x86), flexible shapes have configurable OCPUs/memory but not all combinations are allowed, and burstable shapes rely on CPU credits. Licensing (BYOL vs included) and GPU driver images also change the answer.
What to do instead
Match shape family to workload (standard, flexible, GPU, ARM), confirm the image is compatible with the shape's architecture and OS, and check that the OCPU/memory combination is valid for the flexible shape. For performance-sensitive workloads, avoid burstable shapes or size for sustained load. Confirm licensing model and that GPU shapes use the correct platform image with drivers.