OCI Operations Associate common mistakes
OCI Operations Associate · Understand the traps and how to avoid them.
Treating the OCI IAM policy verb set as if it were a generic read/write/admin ladder, so a candidate grants or expects `manage` to cover every operation and cannot explain when `use` is sufficient for launching instances in a compartment.
Candidates transfer mental models from other clouds where a single admin role covers everything. OCI splits verbs into inspect, read, use, manage, and the distinction between use (work with existing resources) and manage (create/update/delete) is tested constantly, and manage also implies the lower verbs.
What to do instead
Memorize the verb ladder and what each unlocks: inspect < read < use < manage, with manage inheriting all lower verbs. Practice writing policies for concrete tasks such as letting a group launch instances (use instances plus use vnics and read vnic-attachments) versus terminating them, and check every policy statement against the question's exact action.
Assuming a resource is reachable because the security list or NSG looks correct, without checking route table and gateway configuration, so the candidate picks a security-rule answer when the real fault is a missing route rule or an internet gateway attached to the wrong VCN.
Troubleshooting questions present several plausible layers. Candidates fixate on the layer they last studied (usually security lists) and stop diagnosing. OCI traffic flow requires subnet route table, gateway, security list, NSG, and (for public subnets) a public IP to all line up.
What to do instead
Adopt a fixed checklist order for connectivity questions: public IP present, internet gateway or NAT gateway attached, route rule for 0.0.0.0/0 pointing at that gateway, security list egress/ingress, NSG rules, then host firewall. For private-subnet egress, confirm NAT gateway plus a service gateway for OCI services. Answer only after the checklist eliminates layers.
Confusing the block volume's availability domain placement with the instance's, or assuming a volume can be detached and reattached across ADs, leading to wrong answers about migrating or resizing storage.
Block volumes in OCI are AD-scoped, and boot volumes follow the instance. Candidates who think of storage as regional (as object storage is) misjudge which operations are possible and pick cross-AD reattachment as a recovery step.
What to do instead
Anchor the rule: block and boot volumes are availability-domain scoped; Object Storage and File Storage are regional. For cross-AD recovery, the correct pattern is backup or clone to a new volume in the target AD, or use a regional block volume backup, not a direct reattach. Read the question's AD wording before choosing.
Choosing 'terminate the instance' or 'delete the compartment' as a remediation when the scenario calls for stopping or preserving data, ignoring that termination deletes attached boot volumes by default unless preservation is set.
Candidates focus on the immediate symptom (cost, error, stale resource) and forget lifecycle side effects. OCI's preserve-boot-volume option and compartment deletion safeguards are easy to overlook under time pressure.
What to do instead
Before selecting any destructive action, ask what data must survive. Recall that instance termination removes attached boot volumes unless you preserve them, and that compartment deletion requires the compartment to be empty. Prefer stop/start, backup, or detach-then-terminate sequences when the scenario mentions data retention.
Treating an Autonomous Database or DB system backup/restore question as a generic storage snapshot question, and answering that a manual backup is required before point-in-time recovery.
Candidates conflate block volume backups with database-native backup. Autonomous Database takes automatic backups with a retention window and supports point-in-time recovery without a manual pre-step, and DB systems use RMAN-based automatic backups configured at creation.
What to do instead
Separate the two backup systems explicitly: volume backups protect block storage; database backups are managed by the database service. For Autonomous Database, remember automatic backups plus restore to a timestamp. For DB systems, remember the automatic backup retention configured at launch and manual backups on demand. Match the answer to the service named in the stem.
Reading a Monitoring metric or alarm question as if alarms act directly on resources, so the candidate says the alarm will restart or resize the instance instead of publishing to a notification topic that triggers a function or stream.
Other platforms attach autoscaling or remediation directly to alarms. In OCI, the alarm fires a notification via ONS, and any automated action comes from a separate consumer such as a Functions function or an autoscaling policy.
What to do instead
Trace the chain: metric emits, alarm evaluates the query against the namespace, alarm transitions to FIRING and publishes to the notification topic, subscribers act. When a question asks how to auto-remediate, the answer must include the topic plus a consumer, or an autoscaling policy for horizontal scaling. Never claim the alarm itself changes the resource.
Assuming the Cloud Guard or Security Zones question is satisfied by enabling the service alone, missing that detector recipes, responder recipes, and target compartments must be configured for findings to appear and be remediated.
Candidates memorize service names but not the configuration objects. Cloud Guard needs a target (tenancy or compartment) and recipes; Security Zones need a recipe attached to a compartment at creation time and block non-compliant resources rather than reporting them.
What to do instead
Learn the object graph: Cloud Guard = target + detector recipe + responder recipe, producing problems. Security Zones = recipe + compartment, enforcing at resource creation. When the question asks why no findings exist, check the target and recipe attachment before assuming the service is broken.
Answering cost questions with generic 'turn things off' advice instead of naming OCI-specific mechanisms such as budgets with alert rules, cost-tracking tags, and the free-tier or committed-use shape of the tenancy.
Cost management is often studied last and superficially. Candidates do not distinguish budgets (threshold alerts on spend) from compartments and tags (allocation and reporting), so they pick an answer that does not actually produce the requested visibility.
What to do instead
Memorize the split: budgets and budget alert rules notify on actual or forecast spend; defined tags with cost-tracking enabled drive cost reports and chargeback; compartments provide the primary cost boundary. For 'how do we alert at 80% of monthly spend', the answer is a budget with an alert rule, not a tag or a compartment change.
Writing CLI or automation answers that assume a global default region or a single profile, so commands target the wrong region or tenancy and the candidate cannot explain why a script works locally but fails in another environment.
OCI CLI configuration is per-profile and region-scoped, and resources are regional. Candidates who test only in one region do not internalize that --region, --profile, and the config file determine the endpoint, and that some resources (IAM, Object Storage namespaces) behave differently from regional compute.
What to do instead
Practice commands with explicit --profile and --region, and know that IAM policies are tenancy-global while compute, VCNs, and volumes are regional. When a script must run across regions, loop regions explicitly. Read the question's region wording and reject answers that silently assume the default profile.
Assuming an instance can be launched into any subnet regardless of its type, or that a private subnet instance can reach the internet without a NAT gateway, producing answers that misplace public IPs and gateways.
Subnet type (public vs private) is set at creation and controls whether a public IP is allowed. Candidates treat it as a cosmetic label and then cannot explain why an instance in a private subnet has no internet access even with a route rule.
What to do instead
Lock in the pairing: public subnet permits public IPs and routes via internet gateway; private subnet disallows public IPs and needs a NAT gateway for outbound internet plus a service gateway for OCI services. When a scenario says 'no internet access', first check subnet type and gateway attachment, then route rules, then security rules.