Oracle Cloud AR common mistakes
Oracle Cloud AR · Understand the traps and how to avoid them.
Treating a single security list rule as sufficient for multi-tier traffic and forgetting that security lists are applied at the subnet (VNIC) level, so a rule opening port 1521 from 0.0.0.0/0 to a database subnet is accepted as 'fine because there is no public IP'.
Candidates memorize 'security lists are subnet-level, NSGs are VNIC-level' but never verify how that changes the effective rule set. The exam presents a private subnet and the candidate assumes private equals isolated, missing that a permissive ingress rule still allows lateral movement from any compromised host in the VCN.
What to do instead
For every scenario, enumerate the actual ingress/egress rules on both the security list and any attached NSG, then reason about the source CIDR or NSG reference. Prefer NSGs for tier-to-tier rules (web NSG -> app NSG -> DB NSG) and keep security lists to a minimal baseline. State explicitly that a private subnet with an open ingress rule is still reachable from inside the VCN.
Designing a hub-and-spoke topology with a DRG but omitting the route rules and the DRG attachment type, assuming that attaching two VCNs to the same DRG automatically makes them routable.
The DRG is introduced as the transit hub, so candidates stop at 'attach both VCNs'. They forget that the DRG attachment has a routing table and that each VCN needs a route rule pointing at the DRG, plus the DRG route table must import/export the right CIDRs. The default DRG route table behavior (auto-import of attached VCN CIDRs) is often misremembered.
What to do instead
Write out the full path: VCN A subnet route table -> DRG attachment -> DRG route table (with the destination CIDR and next-hop attachment) -> VCN B attachment -> VCN B subnet route table. Check that the DRG route table imports the peer CIDR and that no overlapping CIDRs exist. If transit between spokes is required, confirm the DRG route distribution allows it rather than assuming a full mesh.
Sizing a compute shape by picking the largest flexible shape 'to be safe' instead of calculating OCPU and memory from the workload, and ignoring that flexible shapes can be resized and that burstable shapes have CPU baseline limits.
Exam questions give a workload profile (e.g., steady 8 OCPU, 64 GB) and candidates default to a fixed shape or over-provision. They also conflate OCPU with vCPU (1 OCPU = 2 vCPU on x86) and miss that burstable shapes throttle above baseline, which changes latency-sensitive designs.
What to do instead
Convert the workload to OCPU and GB, choose a flexible shape, and state the resize path (stop/start or live resize where supported). For burstable shapes, compare the baseline against sustained load and reject them for steady high-CPU workloads. Show the OCPU-to-vCPU conversion explicitly so the arithmetic is auditable.
Choosing block volume performance by size alone, assuming a larger volume automatically delivers the IOPS and throughput the database needs, and ignoring volume performance tiers and the 32 volume attachments per instance limit.
The default 'Balanced' VPUs scale with size, so candidates assume bigger equals faster and never check the VPU setting or the per-instance attachment cap. Multi-volume designs (e.g., separate data, redo, and backup volumes) then exceed the attachment limit or under-deliver IOPS.
What to do instead
Compute required IOPS and MB/s, then select the volume performance level (Lower Cost, Balanced, High Performance, Ultra High Performance) and size that meets it, rather than inferring performance from capacity. Count attachments against the per-instance maximum and consider NVMe local storage or file storage for scratch data. State the VPU/IOPS relationship in the answer.
Placing all resources in a single availability domain and calling the design highly available because the region has three ADs.
Candidates confuse regional services (VCN, Object Storage, Autonomous Database) with AD-scoped services (compute instances, block volumes). They assume that because the VCN spans the region, instances are also spread across ADs, which they are not unless explicitly placed.
What to do instead
Classify each component as regional or AD-scoped, then place AD-scoped resources across at least two ADs (or use a fault-tolerant shape) behind a regional load balancer. For databases, distinguish AD-local from cross-AD Data Guard or Autonomous Database's built-in HA. Explicitly note which tier survives a single AD failure.
Building IAM policies with broad statements such as 'allow any-user to manage all-resources in tenancy' to make a demo work, and not scoping by compartment, resource family, or condition.
Policy syntax is easy to write loosely and hard to write precisely. Candidates under-test the verb/resource-type/compartment triple and forget that 'manage' includes 'inspect', 'read', 'use', and 'manage', and that 'any-user' bypasses identity domains. The exam rewards least privilege and explicit scoping.
What to do instead
Write policies as 'allow group to in compartment where '. Use the narrowest verb (inspect < read < use < manage), scope to a compartment, and add conditions (request.principal.type, target.compartment.id) where relevant. Avoid any-user except for genuinely anonymous access such as public Object Storage reads, and justify it.
Treating compartments as a security boundary and assuming that putting a resource in a separate compartment automatically prevents other compartments from reaching it.
Compartments organize and scope IAM policies and cost, but they do not isolate network traffic. Candidates conflate logical governance with network isolation and miss that a VCN or subnet in another compartment can still route to the resource unless network controls block it.
What to do instead
Separate the two concerns: compartments for IAM policy scope, quota, and cost tracking; VCNs, subnets, NSGs, and route tables for network isolation. In any 'isolate team A from team B' question, specify both the IAM policy (compartment-scoped) and the network control (separate VCN with no peering, or NSG rules denying the CIDR).
Assuming a single-node Autonomous Database or a Base Database System is highly available out of the box, and not distinguishing AD-local from cross-AD Data Guard or the Autonomous Database's automatic failover behavior.
The word 'managed' leads candidates to assume HA is automatic for every database offering. They miss that a Base Database System is AD-scoped, that Data Guard requires a standby in another AD or region, and that Autonomous Database Serverless provides HA within the region but not cross-region unless configured.
What to do instead
For each database option, state its HA model: Autonomous Database Serverless (regional, automatic), Autonomous Database Dedicated (Exadata infrastructure, AD placement matters), Base Database with Data Guard (primary and standby in different ADs), and note RTO/RPO implications. Match the choice to the stated RTO/RPO rather than defaulting to the most managed option.
Configuring monitoring and alarms only on CPU and then declaring observability complete, ignoring the metrics that actually indicate failure (availability, latency, error rate, storage utilization) and the logging/auditing services.
CPU is the most familiar metric, so candidates build alarms around it and skip service-specific metrics, log groups, and the Audit service. They also forget that alarms need a notification topic and that the Monitoring service is regional while Logging can aggregate across sources.
What to do instead
Design a layered observability plan: infrastructure metrics (CPU, memory, disk, network), service metrics (load balancer latency and 5xx, database connections and storage), alarms with notification topics, and Logging (service logs, custom logs, audit logs) with retention. Tie each alarm to an actionable runbook and state which signal detects which failure mode.
Ignoring cost levers beyond shape size: not using the cost estimator, not tagging for cost allocation, not using budget alerts, and not considering reserved capacity, autoscaling, or Object Storage tiering.
Cost questions look like arithmetic, so candidates answer only 'use a smaller shape'. They miss that budgets and budget alerts are separate from cost-tracking tags, that Object Storage has Standard/Infrequent/Archive tiers with retrieval costs, and that autoscaling and scheduled shutdown change the bill materially.
What to do instead
Build a cost plan with four levers: right-sizing (flexible shapes, autoscaling), commitment (reserved capacity where steady-state), storage tiering (lifecycle policies to move cold objects to lower tiers), and governance (defined tags for cost allocation, budget with alert rules). Mention the cost estimator for validating the design before deployment.