Databases practice questions

Disable Automatic Workload Repository (AWR) collection on the source database

Why it fails: Data Pump export does not require disabling AWR; Autonomous Database simply ignores or rejects AWR-dependent export content, and AWR is a performance repository unrelated to dump compatibility. It is tempting because AWR is a source-side feature, and disabling it would be correct when reducing overhead during a resource-constrained export window.

Convert the source database into an Oracle Multitenant Container Database with a single pluggable database

Why it fails: Data Pump migrates schemas into Autonomous Database, which is itself multitenant; converting the source to a container with one PDB is unnecessary for export compatibility. It is tempting because Autonomous Database runs as a PDB, and this conversion would be correct when using remote cloning or PDB unplug/plug migration instead.

Manually drop all custom triggers and indexes to prevent import failures

Why it fails: Custom triggers and indexes import normally into Autonomous Database; dropping them is not mandatory and would lose schema objects. It is tempting because some invalid objects do fail import, and dropping and recreating them would be correct when a specific trigger references unsupported features or unavailable paths.

Direct database clone via SQL*Developer migration wizard

Why it fails: Incorrect. SQL*Developer migration is unsuitable for a 50 TB enterprise database workload.

Oracle GoldenGate initial load using SQL direct paths

Why it fails: Incorrect. GoldenGate is designed for replication, not bulk initial transport of entire storage formats with endian conversion.

Standard Oracle Data Pump export and import over direct database links

Why it fails: Incorrect. Data Pump handles endian conversion logically, but for a 50 TB database, Data Pump is extremely slow compared to binary transportable tablespaces.

Exactly three times the base OCPU count provisioned for the database instance

Why it fails: Incorrect. The 3x limit applies primarily to Autonomous Database on Shared Infrastructure, not Dedicated Infrastructure.

An unlimited amount limited only by OCI regional capacity limits

Why it fails: Incorrect. Auto-scaling is bounded by the specific Exadata rack or quarter-rack sizing provisioned.

Fixed at a maximum of 128 OCPUs regardless of hardware size

Why it fails: Incorrect. Limits depend on the shape of the Exadata infrastructure.

Setting the database character set to AL32UTF8 to handle multi-region strings

Why it fails: Incorrect. Character sets govern string encoding, not sequence generation or primary key collision avoidance.

Using Oracle Autonomous Health Framework to automatically resolve distributed deadlocks

Why it fails: Incorrect. Health framework diagnoses issues; it does not configure multi-region sequence intervals.

Enabling Autonomous Data Guard in Snapshot Standby mode in all regions simultaneously

Why it fails: Incorrect. Data Guard does not support multi-master active-active writes across regions concurrently.

The standby database automatically accepts write operations and replicates them back to the primary

Why it fails: Incorrect. Data Guard is unidirectional for writes (primary to standby).

The standby database accepts read-write transactions concurrently with the primary database

Why it fails: Incorrect. Active-active write configurations are not supported by Data Guard.

The standby database is completely inaccessible until a manual switchover or failover occurs

Why it fails: Incorrect. Unlike traditional physical standbys that might require manual role transitions, Autonomous Data Guard standby is accessible for reads.

Network File System (NFS) shared mounts from a third-party NAS filer

Why it fails: Incorrect. NFS is not the primary storage architecture for high-performance Oracle Base Database systems on OCI.

Raw Device Mapping (RDM) shared via Fibre Channel SAN

Why it fails: Incorrect. OCI does not expose traditional Fibre Channel SAN storage via RDM to database VMs.

Local NVMe drives directly attached to the hypervisor without redundancy

Why it fails: Incorrect. Base databases use network-attached OCI Block Storage with ASM, not raw local NVMe without protection.

Disable Transparent Data Encryption (TDE) on the source database before export

Why it fails: Incorrect. TDE status on the source has no impact on logical Data Pump exports.

Manually format all source datafiles into Oracle ASM disk groups prior to export

Why it fails: Incorrect. Data Pump is a logical export/import tool; physical disk formatting is unnecessary.

Configure a direct NFS mount between the source server and the Autonomous Database storage tier

Why it fails: Incorrect. Direct NFS mounting to Autonomous Database storage is not supported.

Autonomous Spark Analytics Engine (ASAE)

Why it fails: Incorrect. ASAE is not an official Autonomous Database workload type.

Autonomous Hadoop Distributed File System (AHDFS)

Why it fails: Incorrect. AHDFS does not exist as an Autonomous Database workload.

Exposing the database via an Internet Gateway and public IP address mapping

Why it fails: Incorrect. Private endpoints forbid public IP access.

Establishing an SSH tunnel through the OCI Vault key management service

Why it fails: Incorrect. OCI Vault does not provide SSH tunneling for databases.

Routing application traffic through OCI Object Storage public pre-authenticated requests

Why it fails: Incorrect. Object storage requests do not route database queries.

The number of local user SSH keys required for root password resets

Why it fails: Incorrect. SSH keys are for access control, not resource sizing.

OCI Identity and Access Management policy statement limits

Why it fails: Incorrect. IAM policy limits are unrelated to Exadata hardware sizing.

The public IP bandwidth quotas allocated to OCI API endpoints

Why it fails: Incorrect. API quotas do not dictate database compute/storage sizing.

Disabling all VCN route tables to block internal routing

Why it fails: Incorrect. Disabling route tables breaks necessary network connectivity.

OCI Web Application Firewall (WAF) applied directly to SQL port 1521

Why it fails: Incorrect. WAF protects HTTP/HTTPS traffic, not database TNS traffic.

Exposing database ports directly to the public Internet with default security lists

Why it fails: Incorrect. Exposing database ports publicly is a severe security anti-pattern.

Oracle Zero Downtime Migration (ZDM) with physical online migration workflow.

Why it fails: ZDM physical online migration relies on Data Guard, which does not support cross-endian platform migrations (AIX to Linux).

Oracle GoldenGate for real-time replication with initial load via datapump.

Why it fails: While GoldenGate supports heterogeneous platforms, setting up initial load and replication for a massive database with endian differences is significantly more complex than RMAN cross-platform transportables for a migration.

Standard RMAN backup and restore directly from an on-premises NFS mount to OCI Object Storage.

Why it fails: Standard restore does not perform cross-endian conversion and would result in extended downtime.

Local unformatted swap partitions on the database host

Why it fails: Incorrect. Swap partitions cannot store database backups.

Public GitHub code repositories

Why it fails: Incorrect. GitHub is for source code, not database backups.

Local USB flash drives plugged into the database VM guest node

Why it fails: Incorrect. USB drives are not supported cloud backup targets.

Maximum Availability mode with SYNC transport and NOAFFIRM.

Why it fails: Maximum Availability provides high availability with automatic failover capability, but Maximum Protection provides stricter zero data loss enforcement by halting the primary if all standbys fail.

Maximum Availability mode with ASYNC transport and ARCHivelog compression.

Why it fails: ASYNC transport in Maximum Availability does not guarantee zero data loss.

Maximum Performance mode with ASYNC transport.

Why it fails: Maximum Performance mode uses ASYNC and can experience minor data loss in the event of an unexpected primary failure.

Enable automatic backups with a retention period, then set the backup destination to an Object Storage bucket in a different commercial realm and assign an OCI Vault key to that bucket.

Why it fails: Object Storage buckets cannot be encrypted with OCI Vault customer-managed keys; bucket encryption is always AES-256 with Oracle-managed keys, so this approach cannot meet the customer-managed key requirement. Additionally, placing backups in a different commercial realm moves data outside the intended jurisdiction and adds cross-realm replication complexity that the compliance requirement does not permit.

Enable automatic backups, store them in a local Object Storage bucket, and configure a customer-managed key in OCI Vault located in a different region, since OCI Vault keys are global resources accessible from any region.

Why it fails: OCI Vault keys are regional resources, not global, so a vault in another region cannot be directly used as the backup encryption key for a DB system in Frankfurt. Even if cross-region access were possible, the customer-managed key would reside outside the required jurisdiction, which conflicts with the compliance mandate to keep all key material within the EU.

Enable automatic backups, store them in a local Object Storage bucket, and rely on the DB system's default TDE wallet key to encrypt the backup files, since TDE keys are always customer-managed.

Why it fails: The default TDE wallet in Base Database Service is Oracle-managed; customers do not control it unless they explicitly configure a customer-managed key in OCI Vault. Relying on the default wallet therefore fails the requirement to use a customer-managed key, even though the backups would remain in the Frankfurt region in a local bucket.

A single OCI Vault master encryption key can be shared across both regions because OCI Vault keys are globally replicated by default.

Why it fails: OCI Vault keys are not globally replicated by default; they are regional resources. A key created in one region cannot be used directly by resources in another region without explicit replication mechanisms that do not apply to TDE key references in this scenario. Assuming global key availability would leave the standby region without a usable key.

Deleting the OCI Vault key immediately renders the Exadata database unrecoverable, because TDE master keys cannot be restored from vault backups.

Why it fails: OCI Vault retains key versions and supports restoration within a scheduled deletion window, so accidental deletion does not instantly destroy the key. However, permanently deleting the key after the window would render encrypted data unrecoverable, which is why deletion should be scheduled carefully. The absolute claim that keys cannot be restored is incorrect.

The customer-managed key in OCI Vault replaces the need for a TDE wallet on the Exadata database, so no wallet files are created or managed.

Why it fails: Even with a customer-managed key in OCI Vault, the database still maintains a TDE wallet that stores the encrypted master encryption key and related metadata. The vault key wraps the TDE master key, but wallet files remain part of the configuration and must be backed up. Claiming the wallet is eliminated misstates how external key management integrates with TDE.

Manual RMAN backup replication via OCI Object Storage every 15 minutes

Why it fails: RMAN backup replication cannot meet a zero RPO: backups capture point-in-time copies, so any committed transaction after the last 15-minute run is lost, and restore plus recovery exceeds 30 seconds. It suits scheduled backup retention or cross-region archival, not continuous standby synchronisation.

Oracle Data Guard configured in Maximum Performance mode with asynchronous transport

Why it fails: Asynchronous transport commits locally before standby receipt, so a primary failure can lose the last transactions, breaking RPO zero. Maximum Performance suits latency-tolerant workloads; RPO zero demands Maximum Availability or Maximum Protection with SYNC transport.

Oracle GoldenGate real-time replication with asynchronous extract configurations

Why it fails: Oracle GoldenGate replicates at logical, transaction level, so it cannot deliver the zero-RPO guarantee that Data Guard's synchronous redo transport provides; asynchronous extract also introduces lag, breaching the sub-30-second RTO. GoldenGate suits heterogeneous migrations or active-active replication between dissimilar databases, not standby-based disaster recovery on Exadata Database Service.

OCI Compute Instance Scheduler

Why it fails: The Compute Instance Scheduler starts and stops compute instances on a timetable; it cannot patch, back up or manage Oracle Base Database lifecycles. It is tempting because it automates recurring operations, but it targets compute instances, not database fleet maintenance.

Oracle Cloud Infrastructure GoldenGate deployment console

Why it fails: GoldenGate deployment console replicates and migrates data between databases; it performs no patching, backup scheduling or lifecycle management. It is tempting because GoldenGate is database-focused, but its purpose is data replication, not fleet administration across compartments.

OCI Identity and Access Management (IAM) policies

Why it fails: IAM policies only authorise who may call OCI APIs; they do not schedule patching, backups or lifecycle operations across compartments. It is tempting because IAM governs access to every OCI resource, but fleet automation requires Database Management, not authorisation policy.

An Autonomous Database on Shared Infrastructure instance

Why it fails: Shared Infrastructure is a separate deployment model with its own provisioning path and cannot serve as the parent resource for a Dedicated Infrastructure Autonomous Container Database. It is tempting because it is the quickest way to run Autonomous Database, but it does not satisfy the isolation mandate or precede the ACDB.

A standard Oracle Base Database system

Why it fails: Autonomous Database on Dedicated Infrastructure requires an Exadata Infrastructure resource, not a Base Database system. A Base Database system is tempting because it also runs on dedicated Exadata hardware, and would be correct when deploying non-autonomous Oracle databases needing full administrative control.

A Virtual Cloud Network with a default database subnet only

Why it fails: A VCN is needed, but a default database subnet alone is insufficient; the Exadata Infrastructure must be provisioned first. Networking is tempting because connectivity is mandatory, and a VCN would be the right starting point for a Base Database deployment rather than Autonomous Container Database creation.

Generate a Kerberos ticket granting service token via the IAM security console

Why it fails: Kerberos tickets authenticate against directory services, not Autonomous Database mTLS; the wallet's client credentials are what the database validates. It is tempting because Kerberos is a real authentication mechanism, and would be correct where an application authenticates to a Kerberos realm rather than presenting a wallet-based certificate.

Retrieve the master encryption key directly from OCI Vault using an API key

Why it fails: The vault master encryption key protects data at rest and cannot authenticate a client; mTLS requires the wallet's client certificate and private key. It is tempting because Vault legitimately stores credentials, and retrieving keys from it is correct when the requirement is managing encryption keys rather than connecting to Autonomous Database.

Configure a public SSL certificate issued by Let's Encrypt in the database parameter settings

Why it fails: A public certificate authority issues server-side certificates for TLS endpoints; mTLS on Autonomous Database instead uses the instance wallet's client certificate and private key. It is tempting because Let's Encrypt certificates do secure connections, and would be correct for a public web server presenting a trusted certificate to browsers.