Oracle Cloud Infrastructure Architect Associate common mistakes
OCI Architect Associate · Understand the traps and how to avoid them.
Reading a policy statement as an allow-by-default model and assuming that any user in the tenancy can perform an action unless a deny is written, then failing scenario questions about what an unprivileged user can do.
Candidates come from AWS or Azure backgrounds where account owners and administrators have implicit broad rights, and they skim the OCI policy syntax without registering that OCI IAM is default-deny and that every permission must be granted by a policy statement in a compartment hierarchy.
What to do instead
Before answering any access question, restate the rule to yourself: no policy means no access. Then trace the statement in the form 'Allow group X to verb resource-type in compartment Y' and check three things: is the group membership correct, does the verb cover the operation, and does the compartment path in the statement include the target resource's compartment through inheritance. Practise by writing the exact policy needed for a stated task rather than picking the most permissive-looking option.
Treating compartments as an access-control boundary by themselves, assuming that creating a compartment isolates resources or that moving a resource between compartments is impossible.
Compartments feel like projects or resource groups, so candidates assume they are security containers. In fact they are only a scope for policy and quota; access is granted by policies attached to the compartment tree, and resources can be moved between compartments if the caller has manage rights in both.
What to do instead
Separate the two concepts explicitly: compartments organise resources and provide a policy scope plus quota scope, while policies grant access. For any design question, identify the compartment hierarchy first, then write the policy at the highest compartment that gives exactly the intended reach, and remember that moving a resource changes which inherited policies apply to it.
Confusing security lists with network security groups and picking the wrong one for a scenario that asks how to apply rules to only a subset of instances in a subnet.
Both control traffic and both appear in the console, so candidates memorise the names without the structural difference. Security lists attach to a subnet and apply to every VNIC in it, while NSGs attach to individual VNICs and can be layered.
What to do instead
Anchor the distinction with a rule of thumb: subnet-wide equals security list, instance-level equals NSG. When a question mentions a specific set of compute instances or a three-tier application needing different rules per tier inside one subnet, the answer is an NSG. Also remember that NSGs are scoped to a VCN and that a VNIC can belong to several NSGs, with rules evaluated as a union.
Assuming that creating an internet gateway or a NAT gateway automatically gives instances outbound internet access, and forgetting the route table entry or the public IP requirement.
In other clouds the gateway attachment is often sufficient, so candidates skip the routing step. In OCI the gateway must be attached to the VCN and then referenced by a route rule in the subnet's route table, and a private subnet needs a NAT gateway for egress while a public subnet needs an internet gateway plus a public IP on the instance.
What to do instead
For every connectivity question, walk the full path in order: does the subnet have the right route table, does that table have a rule whose destination is 0.0.0.0/0 pointing at the correct gateway type, does the instance have a public IP if direct inbound is required, and do the security list or NSG rules allow the traffic. Rehearse the three common patterns: public subnet with internet gateway, private subnet with NAT gateway for outbound only, and private subnet with service gateway for Object Storage without traversing the internet.
Choosing a shape by vCPU count alone and ignoring the OCPU definition, the flex shape option, and the difference between AMD, Intel, and Ampere A1 architectures.
Candidates carry over vCPU intuition and misread OCPU as a one-to-one vCPU equivalent, and they overlook that many shapes are flexible so the OCPU and memory can be set within a range. They also forget that Ampere A1 is Arm-based, which affects image and application compatibility.
What to do instead
Memorise that one OCPU on x86 shapes corresponds to two vCPUs with hyperthreading, and that flex shapes let you specify OCPUs and memory independently within the shape's limits. When a question mentions cost optimisation with a steady workload, consider flex shapes sized to actual usage; when it mentions Arm compatibility or best price-performance for containerised workloads, consider Ampere A1. Check the image's supported architecture before committing.
Designing an instance configuration or autoscaling policy without stating that the configuration is a template and that the instance pool or autoscaling configuration must reference it, then expecting existing instances to change when the template is edited.
The naming suggests a live setting. In reality an instance configuration captures a snapshot of shape, image, metadata, and networking, and instances already launched from it do not inherit later edits. Autoscaling then adds or removes instances based on a policy and metrics.
What to do instead
Describe the chain explicitly: instance configuration is an immutable-style template, an instance pool or autoscaling configuration consumes it, and a scaling policy with a metric and threshold drives the count. To roll out a new image, create a new instance configuration and update the pool, which replaces instances rather than mutating them. Remember that autoscaling needs the monitoring metric to be available and that cooldown behaviour affects rapid scale events.
Assuming block volume data is protected automatically because the volume is attached to a compute instance, and not distinguishing volume backups from object storage durability or from file system snapshots.
Candidates blur the storage services together. Block volume backups are separate resources stored in Object Storage, they must be scheduled or taken explicitly, and deleting an instance does not delete or protect an attached volume. File system snapshots and object versioning are different mechanisms with different recovery semantics.
What to do instead
Map each service to its protection mechanism: block volumes use backup policies or manual backups; File Storage uses snapshots and replication; Object Storage uses versioning, lifecycle rules, and replication across regions. When a question asks for point-in-time recovery of a database, do not reach for a block volume backup; use the database's own backup capability. Always ask what the recovery point objective and recovery time objective imply before selecting a mechanism.
Treating Autonomous Database and DB systems as interchangeable and choosing Autonomous Database for a workload that requires operating-system access, custom patching, or a specific database version not offered by Autonomous Database.
Both are managed Oracle databases, so the decision gets reduced to 'newer is better'. The real differentiators are the level of operational control, the supported workload types, the scaling model, and whether the requirement includes full administrative access to the host.
What to do instead
Use a decision rule: if the requirement is minimal administration, automatic scaling, and built-in patching, choose Autonomous Database; if the requirement is custom configuration, specific patches, or full control of the database host, choose a DB system. For migration questions, match the tool to the source: Data Pump for logical exports, GoldenGate for minimal-downtime replication, and Zero Downtime Migration for orchestrated moves. State the constraint that drove the choice in your reasoning.
Confusing high availability with disaster recovery and answering a cross-region outage question with a within-region solution such as multiple availability domains or a backup policy.
The terms are used loosely in everyday speech, and availability domains feel like separate data centres, which they are, but they share a region. A regional failure is not covered by spreading instances across availability domains.
What to do instead
Define the terms before answering: high availability keeps a service running through component failure inside a region, typically using multiple availability domains, load balancing, and database Data Guard or Autonomous Database's built-in resilience; disaster recovery survives loss of a region, requiring cross-region replication of backups or data and a documented restore or failover runbook. Read the question for the words region, availability domain, RPO, and RTO, and let those words select the mechanism.
Ignoring cost and observability tooling in scenario questions, proposing over-provisioned always-on resources, and being unable to name the services that surface spend, alarms, and logs.
Candidates focus on making the design work and treat cost and operations as afterthoughts, so they miss budget, tagging, and monitoring signals embedded in the question and cannot distinguish Monitoring from Logging from Notifications.
What to do instead
Build a small checklist to apply to every design question: are resources tagged for cost allocation, is there a budget with an alert, is the shape flexible and right-sized, are idle resources scheduled off, and which metrics and logs feed alarms and notifications. Know the division of labour: Monitoring holds metrics and alarms, Logging holds audit and service logs, Notifications delivers messages, and the budget service tracks spend against a threshold. Mentioning the specific service by name is usually what the question is testing.