Oracle Database@AWS Architect Professional common mistakes
Oracle Database@AWS Architect Professional · Understand the traps and how to avoid them.
Treating Oracle Database@AWS as a database running inside the customer's own AWS VPC that is managed only through the AWS console, and designing a solution where the DB subnet, route tables, and security groups are fully customer-controlled.
Candidates carry over assumptions from RDS or from self-managed Oracle on EC2, where the customer owns the entire network path and the AWS console is the primary control plane. Oracle Database@AWS is co-managed: OCI runs the Exadata infrastructure and database control plane, while AWS provides the network and identity integration. The split of responsibilities is the core architectural fact of the service, and candidates who skim the overview miss it.
What to do instead
Before any design question, write down the responsibility split explicitly: OCI owns Exadata infrastructure, Grid Infrastructure, and database lifecycle operations; AWS owns the VPC, subnets used for client connectivity, and IAM/identity federation touchpoints; the customer owns schema, data, and access policy. Practice stating which console or API performs each operation (provisioning, patching, backup, network changes) and check every design answer against that table.
Designing cross-region or multi-AZ high availability without accounting for the fact that the Exadata infrastructure is anchored to specific AWS availability zones and that the OCI region is paired with a specific AWS region.
Candidates assume the service behaves like a standard AWS regional service where any AZ is reachable. In reality the Oracle Database@AWS offering is available in defined AWS regions with a mapped OCI region, and the Exadata infrastructure is placed in specific AZs. Design answers that casually spread infrastructure across arbitrary AZs or pair an unsupported AWS region with an OCI region are wrong.
What to do instead
Memorize the region-pairing model: each supported AWS region maps to a specific OCI region, and infrastructure is created in a chosen AZ within that region. For HA questions, reason in terms of Data Guard across two Exadata infrastructures in different AZs (or regions where supported), and verify that both the AWS region and the OCI region pairing are valid before committing to a topology.
Assuming the database is provisioned directly into the application VPC with its own routable IPs, and skipping the design of the OCI VCN peering or private connectivity path between the OCI-side network and the AWS VPC.
Candidates think of the service as 'just another AWS resource' and forget that the database lives in an OCI-managed network that must be connected to the customer VPC. The connectivity layer (VCN, peering, route tables, security lists on the OCI side and security groups on the AWS side) is where most real deployments fail, so exam questions probe it heavily.
What to do instead
For every provisioning or connectivity question, draw both sides: the AWS VPC with its subnets and route tables, and the OCI VCN with its subnets, route tables, and security lists. Identify where traffic crosses (peering or private connection) and confirm that routes exist in both directions and that both the AWS security group and the OCI security list permit the port. Never answer a connectivity question by naming only one side's control.
Configuring security groups on the AWS side and assuming that is sufficient, without opening the corresponding ingress rule in the OCI network security group or security list for the database listener port.
This is the single most common real-world failure: the AWS security group allows 1521 from the application subnet, but the OCI-side network security group still blocks it, so connections time out. Candidates who have only worked in AWS do not expect a second firewall layer and answer the question as if one control governs all traffic.
What to do instead
Adopt a two-firewall checklist for every connectivity scenario: (1) AWS security group inbound on the client subnet CIDR for the listener port, and (2) OCI network security group or security list inbound for the same source and port. When a question describes a timeout, check both layers in order and state which one is misconfigured rather than guessing.
Designing identity and access so that database users are managed only in the database and AWS IAM is treated as irrelevant, or conversely assuming IAM policies alone grant access to the database.
The service spans two identity planes: AWS IAM governs who can call AWS APIs and the Oracle Database@AWS resource actions, while database authentication and authorization happen inside Oracle (with OCI IAM and identity federation also in play). Candidates collapse the two planes and either ignore IAM least privilege or assume an IAM role is a database credential.
What to do instead
Separate the question into 'control plane access' (IAM policies for provisioning, modifying, and deleting the Oracle Database@AWS resources, plus OCI IAM policies for the corresponding OCI-side actions) and 'data plane access' (database users, roles, and privileges). Write answers that name the correct plane and, for control-plane questions, specify least-privilege IAM actions rather than a broad administrator policy.
Planning backups as if they were standard AWS snapshots managed entirely from the AWS console, and not accounting for the OCI-side backup destination, retention, and restore workflow.
Candidates map the service onto RDS mental models where automated backups and point-in-time restore are AWS-native. In Oracle Database@AWS, backup and recovery are Oracle Database operations (for example, RMAN-based backups to OCI Object Storage or a specified destination) with retention governed on the Oracle side, so retention and restore answers built on AWS snapshot assumptions are wrong.
What to do instead
For operations questions, describe the backup mechanism as an Oracle Database capability with an OCI-side destination and policy, and describe restore as an Oracle operation that may require a new database or a point-in-time recovery within the same infrastructure. State where the backup is stored, who sets retention, and which console or API triggers the restore.
Answering a migration question by proposing a one-step cutover with no assessment of the source database version, character set, or the Data Guard or GoldenGate path used to keep the target in sync before switchover.
Candidates focus on 'how do I get the data across' and forget that migration to a co-managed Exadata platform requires a minimum supported database version, compatible character set and national character set, and a low-downtime strategy. Exam scenarios usually include a source that violates one of these constraints, and a naive cutover answer ignores it.
What to do instead
Structure every migration answer in four phases: assess (version, character set, size, dependencies), replicate (Data Guard for same-version Oracle sources, GoldenGate for cross-version or heterogeneous cases), validate (run the workload against the target before cutover), and switch over with a rollback plan. Explicitly call out any source constraint that must be remediated first.
Sizing Exadata infrastructure by CPU or memory alone and ignoring the fixed shape and storage-server granularity, then proposing a configuration that cannot actually be ordered.
Candidates treat Exadata sizing like EC2 instance sizing, where any combination of vCPU and memory is available. Exadata infrastructure comes in defined shapes with a fixed number of database servers and storage servers, and the database's CPU count is drawn from that fixed capacity. Answers that invent intermediate sizes are technically impossible.
What to do instead
Learn the shape model: quarter, half, and full rack configurations with defined database-server and storage-server counts and a maximum number of database CPUs per shape. Size by first estimating database CPU and storage requirements, then selecting the smallest valid shape that covers them with headroom, and state the shape name and its CPU and storage limits in the answer.
Assuming that once provisioned, patching and minor version upgrades are handled automatically by AWS on an AWS-defined maintenance window, and designing an operations runbook around that assumption.
Managed AWS database services patch automatically, so candidates transfer that expectation. In this service the Oracle Grid Infrastructure and database patching are Oracle-side operations with their own scheduling and approval model, and the customer still controls when database patching happens. Runbooks that omit this step leave a gap the exam tests directly.
What to do instead
In operations answers, distinguish infrastructure maintenance (performed by Oracle on the Exadata infrastructure) from database patching (scheduled and applied through the Oracle-side tooling, with the customer choosing the window and validating with a standby first). Include the pre-patch and post-patch validation steps and note that patching a Data Guard standby before the primary reduces risk.
Designing the network for a single flat subnet shared with application servers, without separate client and backup subnets or a plan for the private connectivity that the OCI side requires.
Candidates reuse simple VPC patterns from small RDS deployments. Oracle Database@AWS expects a deliberate VPC layout with dedicated subnets for client traffic and for backup or management traffic, and the OCI-side VCN must be planned in parallel. A flat design creates security-group sprawl and makes the cross-network rules hard to reason about under exam pressure.
What to do instead
Propose at least a client subnet and a separate backup or management subnet in the AWS VPC, each with its own route table and security group, and mirror that structure on the OCI VCN side. In answers, name the subnets, the CIDR ranges, and which traffic flows between them, so the connectivity and security-group questions become mechanical rather than guesswork.