OCI Developer Professional common mistakes
OCI Developer Professional · Understand the traps and how to avoid them.
Treating every OCI service as regional and assuming buckets, VCNs, or functions are scoped to the tenancy rather than a compartment inside a specific region.
Candidates who come from single-region cloud backgrounds memorize service names without memorizing the compartment-plus-region resource hierarchy, so they mis-answer questions about where a resource lives and how IAM policies scope to it.
What to do instead
Draw the hierarchy tenancy > compartment > region > resource once by hand and re-derive it for each service you study. For every resource type you review, write down whether it is regional, availability-domain scoped, or global, and test yourself by predicting where a policy statement must be attached before checking the docs.
Writing IAM policy statements with the wrong verb or resource-family syntax, for example using manage on a broad family when inspect or read is required, or placing the compartment target outside the statement grammar.
The policy language is terse and order-sensitive, and many candidates learn only the allow group X to manage all-resources in tenancy form, so they cannot evaluate least-privilege scenarios or spot a policy that silently grants nothing.
What to do instead
Memorize the verb ladder inspect, read, use, manage and which family each verb unlocks. Practice writing five-line policies from a stated requirement, then verify each against the official policy reference and the policy simulator reasoning. Pay attention to where the compartment clause sits relative to the verb and resource-type.
Assuming an instance principal or resource principal works for any target service without configuring the dynamic group matching rule and the matching policy for that specific target.
Instance principals are often demonstrated end to end in tutorials, so candidates remember that they exist but not that authorization still requires a dynamic group whose rule matches the instance and a policy granting that dynamic group access to the target compartment.
What to do instead
For each principal type, instance, resource, and user, write the three-part checklist: identity created, dynamic group or group rule that matches it, policy that grants it access to the target. Practice debugging a 404 versus a 401 by deciding which of the three parts is missing.
Confusing Object Storage pre-authenticated requests with public buckets and with security tokens, and assuming a PAR grants broader permissions than the specific object and operation it was created for.
All three mechanisms expose objects, and candidates collapse them into one mental model, then pick the wrong answer when a question asks how to share a single object for a limited time or how to revoke access.
What to do instead
Build a comparison table with columns for scope, expiry, revocability, and credential type, covering PAR, public bucket, and identity-based access. Note that a PAR is bound to the object and access type chosen at creation and can be deleted to revoke. Rehearse the scenario of sharing one object read-only for 24 hours versus sharing a prefix.
Treating the OCI CLI and SDK configuration as interchangeable with environment variables and forgetting that profile selection, region, and auth method all come from the config file unless explicitly overridden.
Candidates run commands in a preconfigured lab and never see how the CLI resolves credentials, so they cannot answer questions about switching profiles, using a security token versus API key, or why a script works locally but fails in a pipeline.
What to do instead
Create two CLI profiles by hand, one API-key based and one session-token based, and switch between them with the profile flag and the OCI_CLI_PROFILE environment variable. Document the precedence order of flags, environment variables, and config file, and reproduce a failure by pointing at the wrong profile.
Answering compute questions as though every shape is available in every availability domain and every region, and ignoring fault domains when designing for resilience.
Shape availability varies by region and AD, and candidates study a single-region lab where the shape they used happened to exist, so they overgeneralize and miss questions about capacity, flexible shapes, and placement.
What to do instead
For two regions you care about, list which shapes are offered and note flexible shapes where OCPU and memory are set independently. Learn the difference between availability domains and fault domains and which shapes expose fault domains. Practice choosing a placement strategy for a two-tier app with a stated RTO.
Designing VCN subnets as though all subnets are public, or forgetting that a route rule, a security rule, and a gateway must all agree before traffic flows.
The console makes gateways look like a single toggle, so candidates forget that connectivity requires the route table entry, the security list or network security group rule, and the correct gateway type together, and they misdiagnose reachability questions.
What to do instead
Trace one packet path end to end on paper: source subnet route table, gateway, destination security rules, and back. Then repeat for a private subnet reaching Object Storage through a service gateway and for an instance reaching the internet through a NAT gateway. Learn when each gateway type is the only correct choice.
Assuming a function or container can reach the internet or a private database by default, without configuring the VCN, subnet, and egress path for serverless resources.
Serverless abstracts away infrastructure, so candidates assume networking is handled, but Functions and Container Instances need explicit VCN attachment and egress configuration to reach private resources or the public internet.
What to do instead
Deploy one function with no VCN attachment and one attached to a private subnet, and observe the difference in what it can reach. Write down the egress options for each serverless service you study and which principal type it uses to call other OCI services.
Treating Autonomous Database connection options as equivalent and picking a wallet-based connection when the question calls for a TLS-only or mutual-TLS connection with specific credential handling.
There are several connection methods with different security properties, and candidates learn one from a tutorial and apply it everywhere, then miss questions about which method requires a wallet, which uses a username and password over TLS, and how to rotate credentials.
What to do instead
Create a table of connection methods with columns for transport security, whether a wallet is required, and typical use case. Practice choosing a method for a public internet client, an application in the same VCN, and a BI tool, and note how each is configured in the console and in a connection string.
Writing SQL that ignores how Autonomous Database handles parallelism, automatic indexing, or resource management, and assuming hints or manual tuning behave exactly as on a self-managed database.
Candidates carry over habits from conventional Oracle Database tuning, but Autonomous Database manages many decisions automatically, so hints and manual index strategies may be ignored or counterproductive, and questions probe that difference.
What to do instead
Read the documented list of features that Autonomous Database manages automatically and the notes on when hints are honored. For each tuning habit you rely on, record whether it still applies and what the managed alternative is. Practice rewriting a query that relied on a manual index into one that benefits from automatic indexing.