Oracle Autonomous Database Professional common mistakes
Oracle Autonomous Database Professional · Understand the traps and how to avoid them.
Treating the shared (Serverless) and dedicated (Exadata Database Service on Dedicated Infrastructure) deployment models as interchangeable and assuming every feature or scaling behaviour is available on both.
Marketing material and older study notes often describe 'Autonomous Database' as a single product, so candidates memorise one feature list and apply it to both models; questions that hinge on which model supports a given capability then fail.
What to do instead
Build a two-column table for each model covering scaling unit (ECPU vs OCPU), supported workload types, network options, and administrative access, and for every practice fact ask 'which model?' before answering.
Confusing the roles of OCI IAM, database-local users, and the ADMIN account, and answering access-control questions as if a single credential controls all layers.
The console, the API, and SQL clients each authenticate differently, and candidates who learned only the console workflow assume IAM policies also grant database-level privileges.
What to do instead
Separate the layers explicitly: OCI IAM identity and policies govern control-plane actions; database users and roles govern SQL access; ADMIN is a database user created at provisioning. Practise stating which layer a scenario touches before choosing an answer.
Assuming a database is reachable from a client as soon as provisioning finishes, without accounting for network access configuration such as access control lists, private endpoints, or the requirement to download and use a wallet for mutual TLS connections.
The provisioning wizard creates the database successfully while network access remains restricted by default, so candidates who only watched the create flow assume connectivity is automatic.
What to do instead
Rehearse the full connection checklist in order: network access type, allowed IPs or private endpoint, wallet download and placement, TNS alias or connection string, then client test. Memorise which steps differ between public and private endpoint setups.
Mixing up the connection strings and ports offered in the wallet, using a high-concurrency or medium service where a transaction-processing or low-latency service was intended, or assuming the same string works for every workload type.
The wallet exposes several service names with similar-looking aliases, and candidates skim them rather than learning what each service level is optimised for.
What to do instead
Learn the service-name families and what each is tuned for (for example parallelism and concurrency versus short transactions), and note that available services depend on the workload type. Practise reading a wallet's tnsnames file and matching each alias to its intended use.
Treating auto-scaling and manual scaling as the same lever, or expecting storage and compute to scale together, and answering capacity questions as if a single setting controls both.
The console presents compute and storage settings near each other, and auto-scaling applies only to compute, so candidates generalise incorrectly.
What to do instead
Memorise the scaling dimensions separately: base compute, auto-scaling of compute within a range, and storage, which is provisioned independently. For each scenario, state which dimension changes and whether the change is automatic or manual.
Misreading the performance and monitoring views, for example confusing average CPU utilisation with peak, or expecting a workload to show activity in a view that only captures a specific category such as long-running or blocked statements.
Several monitoring surfaces overlap in appearance, and candidates memorise view names without learning what each one records or its time granularity.
What to do instead
For each monitoring surface, write one sentence on what it captures, its time window, and a scenario where it is the right tool. Then answer practice questions by first identifying the question's time horizon and statement category.
Assuming automatic maintenance, backups, or patching can be paused or scheduled freely, or that a manual backup is required before every change, and answering availability questions with generic database habits.
Experience with self-managed databases leads candidates to expect to control maintenance windows and backup schedules, which does not match the managed model's defaults.
What to do instead
Learn which lifecycle operations are automatic, which are configurable, and which are fixed. Note the retention and restore behaviour of automatic backups and the role of any manual backup, and check each assumption against the managed-service model.
Choosing a data loading method without matching it to data shape and source, for example planning row-by-row inserts for a large file load or assuming every load method supports the same file formats and transformations.
Multiple loading tools exist and candidates learn one workflow, then force every scenario into it instead of comparing tools by volume, format, and whether transformation is needed.
What to do instead
Create a decision table with columns for source type, data volume, file format, need for transformation, and whether the load is one-off or recurring. Practise selecting a method from the table rather than from familiarity.
Overlooking credential and object-storage prerequisites for loading from cloud storage, such as the credential object, bucket permissions, or the correct URI form, and expecting a load to work with only a file path.
Tutorials often start after the credential is already configured, so candidates never see the prerequisite step and cannot diagnose why a load fails.
What to do instead
Memorise the prerequisite chain for each external source: credential creation, policy or bucket-level permission, correct URI syntax, and the load specification. Rehearse writing the credential step from memory before the load step.
Planning a migration as a single copy step and ignoring schema conversion, data-type or unsupported-feature handling, and post-load validation such as row counts and constraint re-enablement.
Migration is often studied as a transfer mechanism rather than an end-to-end project, so candidates skip assessment and validation phases that exam scenarios test directly.
What to do instead
Structure every migration answer into assess, convert, move, validate. For each phase, name one artefact or check produced, and always include a validation step comparing source and target before declaring the migration complete.