High Availability And Disaster Recovery practice questions

Ensure the standby database has a larger shape than the primary database.

Why it fails: Standby shapes need not exceed the primary; equal or smaller shapes are acceptable, and sizing is chosen independently per region. A larger standby suits workloads where the DR site must absorb additional reporting load, not the baseline prerequisite for creating a Data Guard association.

Manually install the Oracle Data Guard binaries on the standby database compute instance prior to association.

Why it fails: Oracle Base Database Service provisions and patches Data Guard software automatically; manual installation on the standby compute instance is neither required nor supported. Manual binary installation applies to self-managed Oracle Database on Compute, where the customer controls the software stack end to end.

Convert the primary database to an Autonomous Database instance.

Why it fails: Data Guard association links two Base Database Service instances; Autonomous Database is a separate managed offering and cannot serve as the standby target. Converting to Autonomous Database suits migrations away from self-managed administration, not establishing cross-region Data Guard protection.

Manual database cloning from Object Storage snapshots.

Why it fails: Cloning from backups does not utilize Data Guard's real-time testing capabilities.

Logical Standby mode with SQL Apply disabled permanently.

Why it fails: Disabling SQL apply permanently stops synchronization, breaking the DR posture.

Primary database switchover executed during peak business hours.

Why it fails: Switchover impacts primary availability and is not a non-disruptive testing method.

Automatic provisioning of VCN remote peering connections across regions

Why it fails: Network peering must be configured manually by administrators; Data Guard does not configure VCN connections.

Copying database datafiles via Secure Copy (scp) while the database is in read-write mode without RMAN

Why it fails: Copying active database files via scp without quiescing or RMAN results in inconsistent, corrupt backups.

Exporting database files directly to an OCI Block Volume attached as a swap file

Why it fails: Swap files are for virtual memory, not database backups.

Round-robin routing through a single static IP address without health checks

Why it fails: Round-robin steering distributes answers equally and, without health checks, cannot detect a failed primary region, so it cannot drive disaster-recovery failover. It is tempting because round-robin suits even load distribution, but DR requires health-checked failover or failover steering.

Manual BGP hijacking between VCN subnets

Why it fails: BGP hijacking is a routing attack, not an OCI DNS steering method, and Traffic Management operates at the DNS resolution layer. It is tempting because BGP influences path selection, but steering policies such as failover, geolocation and ASN steering control DNS answers instead.

Configure Data Guard in maximum performance mode with asynchronous redo transport and use a backup and restore strategy to the Phoenix region instead of a standby database.

Why it fails: A backup and restore strategy cannot meet a 5-minute RPO because backups are typically taken less frequently and restoring takes much longer than 15 minutes. Data Guard is required for near-real-time replication and fast failover. Using backups instead of a standby database would fail both the RPO and RTO objectives.

Configure Data Guard in maximum protection mode with synchronous redo transport and no observer, relying on manual failover by the DBA team.

Why it fails: Maximum protection mode requires that redo be written to at least one standby before the primary commits, which can halt the primary if the standby becomes unavailable. Manual failover would likely exceed the 15-minute RTO because it requires DBA intervention. This configuration prioritizes zero data loss over availability and is not suitable for the stated RPO/RTO.

Configure Data Guard in maximum availability mode with synchronous redo transport and place the observer in the primary region.

Why it fails: Maximum availability mode with synchronous transport can increase commit latency because the primary waits for the standby to acknowledge redo. More critically, placing the observer in the primary region means that if the primary region fails, the observer is also lost, preventing automatic fast-start failover. This does not meet the RTO requirement for a full region failure.

Use OCI File Storage with a mount target in each region and configure a cross-region replication policy between the file systems.

Why it fails: OCI File Storage is a shared file system service, not an object storage service. It does not natively support cross-region replication for object data, and it would require additional configuration and management. The scenario specifically involves large video files stored as objects, so File Storage is not the appropriate service.

Create a bucket in Ashburn and use OCI Data Transfer Service to schedule daily copies of all objects from Frankfurt to Ashburn.

Why it fails: OCI Data Transfer Service is designed for bulk data migration using physical appliances or secure file transfer, not for continuous replication. Daily copies would introduce significant RPO and would not provide automatic failover or latency reduction. It is also not a real-time replication mechanism.

Enable Object Storage replication on the bucket, specifying Frankfurt as the source and Ashburn as the destination, and configure a pre-authenticated request (PAR) for users in each region.

Why it fails: Object Storage replication does copy objects asynchronously to a destination bucket, but a PAR is a time-limited URL that grants access to a specific object or bucket; it does not automatically route users to the nearest region. Users would still need to know which regional endpoint to use. This does not provide automatic latency reduction.

An autoscaling configuration that automatically adds instances to the backend set when CPU utilization exceeds a threshold.

Why it fails: Autoscaling helps with performance and cost optimization, but it does not directly ensure availability during an AD failure. While it can replace failed instances, it does not provide the health-check-based traffic distribution that a load balancer does. It is a complementary feature, not a core HA component for this scenario.

A site-to-site VPN connection to the on-premises data center for management access.

Why it fails: A site-to-site VPN is used for secure connectivity between on-premises and OCI, not for high availability of a web application. It does not help distribute traffic or survive an AD failure. Management access can be provided via other means, such as a bastion host.

A NAT gateway in each availability domain to provide outbound internet access for software updates.

Why it fails: A NAT gateway provides outbound internet access for instances in a private subnet, but it is not required for high availability of the web application itself. It does not contribute to distributing traffic or surviving an AD failure. While useful for updates, it is not a core HA component for this scenario.

Create a block volume clone in the DR region every 15 minutes using a script and attach it to a standby compute instance.

Why it fails: Cloning a block volume is a point-in-time operation that can take several minutes and does not provide continuous replication. Running a clone every 15 minutes would be complex, error-prone, and may not meet the RPO due to the time taken to complete the clone. It is not a native replication feature.

Schedule hourly backups of the block volume to Object Storage and restore the backup in the DR region during failover.

Why it fails: Hourly backups would result in an RPO of up to 60 minutes, which exceeds the 15-minute requirement. Restoring from Object Storage also takes time and may exceed the 1-hour RTO. While backups are cost-effective, they do not meet the specified objectives.

Use OCI File Storage with a mount target in both regions and configure a replication policy between the file systems.

Why it fails: OCI File Storage is a shared file system service, not block volume. While File Storage supports cross-region replication, it requires applications to use NFS mounts instead of block volumes. The scenario specifies a block volume, so switching to File Storage would require application changes and may not be compatible.

Backup Policy Group

Why it fails: Backup policies schedule and retain volume backups; they group nothing for DR orchestration and cannot contain compute or load balancers. FSDR groups assets in a protection group. A backup policy is the right choice when defining automated backup frequency and retention for block or boot volumes.

OCI IAM Dynamic Group

Why it fails: Dynamic groups are IAM constructs that grant policies to principals matching rules; they hold no application assets and FSDR does not orchestrate them. The protection group is FSDR's grouping mechanism. Dynamic groups are correct when authorising instances to call OCI services without static credentials.

Load Balancer Backend Set Group

Why it fails: A load balancer backend set groups only compute targets behind one listener; it cannot contain databases or represent the full stack. FSDR's grouping mechanism is the disaster recovery protection group. Backend sets are the correct construct when defining health-checked traffic distribution for a single load balancer.

The standby database automatically initiates a flashback database operation to sync with object storage backups before opening.

Why it fails: Flashback does not synchronise a standby with object storage backups; it rewinds a database to an earlier SCN using flashback logs. During MAA failover, Active Data Guard applies remaining redo and opens the standby read-write. Flashback is tempting because it reverses logical corruption, but it is not part of standby activation.

Active Data Guard remains in read-only mode until a manual database restore command is issued.

Why it fails: A Data Guard standby opens read-write after failover without any manual restore; the broker transitions it using existing datafiles and applied redo. Restoring from backup is the separate, slower reinstate or rebuild path. Read-only mode describes normal standby operation before failover, not the post-failover state.

The database becomes inaccessible until Full Stack Disaster Recovery automatically reprovisions the storage cells.

Why it fails: Active Data Guard failover promotes the standby using its own broker and Data Guard role transition; storage cells are not reprovisioned by Full Stack Disaster Recovery. FSDR is used for orchestrating full-stack failover of compute and infrastructure, not the Data Guard switchover itself.

Custom Oracle Autonomous Linux scripts cron-scheduled to push to Object Storage.

Why it fails: Cron scripts on Autonomous Linux are not a native backup feature and lack crash-consistent, incremental block-level snapshots. It is tempting because scheduled scripts pushing data to Object Storage do provide automation, which suits custom file-level exports rather than block volume protection.

OCI File Storage service snapshot schedules.

Why it fails: File Storage snapshot schedules protect file systems mounted via NFS, not block volumes attached to compute instances. It is tempting because OCI snapshot schedules do automate recurring backups, which is correct for file systems rather than block volume data.

OCI Block Volume Vaults with automated cross-region replication policies.

Why it fails: Block Volume Vaults with cross-region replication policies copy backups to another region for disaster recovery, not the daily local backup schedule required. It is tempting because vaults do automate backup retention, which is correct when the requirement is regional resilience rather than daily snapshots.

It requires manual setup of keepalived and IP failover scripts on backend compute instances.

Why it fails: OCI's NLB is a managed Layer 4 service providing built-in failover across availability domains; keepalived and IP failover scripts are unnecessary. It is tempting because self-managed HA clusters on compute instances do use keepalived, but that approach applies to custom load balancing, not the managed NLB.

It terminates SSL/TLS connections before forwarding traffic to backend servers.

Why it fails: OCI's NLB operates at Layer 4, forwarding TCP/UDP flows without inspecting or terminating TLS; SSL termination belongs to the Layer 7 Flexible Load Balancer. It is tempting because TLS offloading is a common load-balancer feature, but that capability sits with the Layer 7 service, not the NLB.

It can only route HTTP and HTTPS traffic.

Why it fails: OCI's NLB is protocol-agnostic at Layer 4, handling any TCP or UDP traffic, not just HTTP/HTTPS. It is tempting because HTTP/HTTPS routing is the familiar load-balancer use case, but that restriction describes the Layer 7 Flexible Load Balancer, whereas the NLB forwards arbitrary TCP/UDP flows.

OCI Block Volume cross-region replication

Why it fails: Block Volume replication copies raw storage blocks, not the Autonomous Database's managed data files, so it cannot serve as a failover target for the serverless service. It is intended for replicating block volumes attached to compute instances, where a standby VM mounts the replica.

Manual RMAN incremental backups copied to Object Storage in the remote region

Why it fails: Manual RMAN incremental backups are not supported against Autonomous Database Serverless, which restricts direct RMAN access; recovery would also require manual restore, giving a large RPO. RMAN is the right tool for Base Database Systems or Exadata where you control the host.

Database Express Export/Import scheduled via cron

Why it fails: Data Pump export/import produces logical dumps at scheduled intervals, so RPO equals the cron period and failover is manual, far from minimal. Data Pump suits migrations and schema-level copies, not continuous cross-region disaster recovery for Autonomous Database.

Active Data Guard with snapshot standby mode and automated cron-based switchovers.

Why it fails: Snapshot standby applies redo only after conversion to a physical standby, and cron-based switchovers cannot meet a sub-two-minute RTO. It is tempting because Active Data Guard is a real Data Guard configuration, but it would be correct for read-only offload or reporting against a standby.

Maximum Performance mode with asynchronous redo transport and a Data Guard Observer.

Why it fails: Asynchronous redo transport ships redo only after local commit acknowledgement, so a failover can lose the last transactions, breaking the zero-RPO requirement. It is tempting because Maximum Performance mode is the default Data Guard protection level, and it would be correct when throughput matters more than zero data loss.

Maximum Protection mode with asynchronous redo transport and manual failover scripts.

Why it fails: Maximum Protection mode requires synchronous redo transport; pairing it with asynchronous transport is contradictory, and manual failover scripts cannot achieve a sub-two-minute RTO. It is tempting because Maximum Protection guarantees zero data loss, and it would be correct when zero RPO outweighs availability impact.

An OCI Dynamic Routing Gateway (DRG) configured with equal-cost multi-path routing.

Why it fails: A DRG routes traffic between VCNs, on-premises networks and remote regions; ECMP there balances paths, not client requests across web instances. It is tempting because ECMP sounds like even distribution, and a DRG is the right choice for hybrid connectivity or inter-VCN routing, not for load balancing a web tier.

A Network Load Balancer restricted to a single Availability Domain subnet.

Why it fails: A Network Load Balancer is bound to a single subnet, so it cannot span the multiple Availability Domain subnets the web tier requires. It is tempting because NLBs distribute TCP/UDP traffic at layer 4 for extreme throughput and low latency, which suits single-AD or regional internal workloads rather than cross-AD HTTP balancing.

A primary Local Peering Gateway (LPG) connected to multiple VCNs.

Why it fails: An LPG connects a VCN to another VCN in the same region for private peering; it forwards packets between networks and performs no request distribution across instances. It is tempting because peering sounds like spreading load, and an LPG is correct when two VCNs must exchange traffic privately without a DRG.

In an OCI File Storage Service (FSS) mount target.

Why it fails: File Storage Service provides shared NFS file systems, not the default destination for Base Database Service automated backups, which land in OCI Object Storage. FSS is correct when applications need a shared POSIX-compliant mount across compute instances.

In a customer-managed Block Volume attached to the database compute instance.

Why it fails: Automated backups are written to OCI Object Storage, not to a Block Volume attached to the compute instance; that volume holds database files, and its loss would destroy the backups with the instance. Block Volumes suit manual, instance-attached storage needs.

In local temporary NVMe drives on the database node.

Why it fails: Local NVMe drives are ephemeral node storage, erased on instance termination or maintenance, so they cannot hold 12-month retention. Automated backups reside in OCI Object Storage; local NVMe suits temporary scratch data such as database temp files.

DNS steering policies cannot route traffic across different geographic regions.

Why it fails: OCI DNS traffic management steering policies explicitly support geographic and global steering across regions, so this claim is false. It is tempting because DNS itself is region-agnostic and latency-based steering is commonly used for cross-region distribution, making the restriction sound plausible to anyone unfamiliar with OCI steering policy capabilities.

DNS records are permanently immutable once created in OCI.

Why it fails: OCI DNS records are editable, so immutability is false. The genuine limitation is DNS caching and TTL delays: resolvers hold stale answers, so failover is not instantaneous. Immutability would matter only if records genuinely could not be changed, which is not the case.

DNS routing requires public IP addresses to be configured on the database backends.

Why it fails: DNS steering resolves names to endpoints; it cannot detect a database failure or redirect connections already established to the primary database, so failover depends on health-checked application endpoints, not database backends. It is tempting because DNS traffic management genuinely distributes client requests across public web endpoints, where public IPs are expected.

Exceeded OCI Block Volume IOPS limits on the standby database's local NVMe scratchpad.

Why it fails: Redo transport lag reflects network bandwidth or log-write throughput, not local NVMe scratchpad IOPS on the standby, which affects apply, not shipping. IOPS limits matter when the standby's apply process falls behind, producing apply lag rather than transport lag.

Misconfigured OCI IAM policy allowing read-only access to database backups.

Why it fails: IAM policies govern authorisation, not redo transport throughput, so read-only backup access cannot delay redo shipping. It would matter when auditing permissions or troubleshooting denied access, not when diagnosing Data Guard transport lag against a five-minute RPO.

Incorrect OCI Load Balancer SSL certificate configuration on the web tier.

Why it fails: Load balancer SSL certificates terminate web-tier TLS and have no bearing on Data Guard redo shipping between primary and standby. Certificate misconfiguration matters when clients report handshake failures or expired certificates on the application endpoint, not database replication lag.

Restrict all subnets to a single Availability Domain to prevent cross-AD latency.

Why it fails: Confining subnets to one availability domain removes the fault-tolerance the design requires; regional subnets spanning all ADs are needed. Single-AD subnets tempt architects worried about cross-AD latency, but that configuration is intended for latency-sensitive workloads accepting AD-level failure risk.

Disable security lists on subnets to allow uninterrupted cross-AD replication traffic.

Why it fails: Security lists filter traffic at the subnet level; disabling them removes network access control without enabling replication, which flows through gateways and routes. It tempts candidates who misattribute connectivity failures to security lists, but security lists are intended to enforce subnet ingress and egress rules.

Attach all VNICs directly to the Dynamic Routing Gateway without using subnets.

Why it fails: VNICs must reside in subnets; attaching them directly to a Dynamic Routing Gateway is not a supported configuration. It tempts candidates seeking simplified routing, but a DRG is intended to connect VCNs to on-premises or remote networks, not to host VNICs.