Domain 6: Migrate Infrastructure Workloads Between OCI Regions (15%)

Domain 6 of the 1Z0-1123-25 Oracle Cloud Infrastructure 2025 Migration Architect Professional exam covers cross-region workload migration, replication strategies, disaster recovery architecture, and the Full Stack DR service. At 15% of the exam this domain accounts for approximately 8 questions. The questions focus on which replication technology to use, how each one works mechanically, and how Full Stack DR orchestrates recovery across an entire application stack.

1. OCI Regions and Availability Domains

Before cross-region migration makes sense, you must understand the physical topology.

Exam trap: HA (High Availability) and DR (Disaster Recovery) are different. HA uses multiple ADs or fault domains within a region to survive data center failures. DR uses multiple regions to survive regional outages. Questions will test whether you pick the right scope.

2. Cross-Region Replication: Service-by-Service Comparison

This is the core of Domain 6. Three storage services offer native cross-region replication, each with different mechanics and trade-offs.

Quick Comparison Table

Source: Object Storage Replication, Block Volume Replication, File System Replication

3. Object Storage Replication

How It Works

You create a replication policy on the source bucket specifying a destination region and bucket. After creation, the destination bucket becomes read-only and receives asynchronous copies of objects written to the source. Replication is unidirectional only -- there is no bidirectional or chained replication. (Object Storage Replication)

Critical Constraints

IAM Policies Required

Two layers of authorization are required:

1. User policies -- the administrator must have manage object-family permissions in both source and destination compartments.
2. Service policies -- the Object Storage service must be authorized in each region:

Allow service objectstorage-<region-id> to manage object-family in compartment <compartment>

The region identifier format is objectstorage-us-phoenix-1, objectstorage-eu-frankfurt-1, etc. Without service authorization, replication silently fails. (Object Storage Replication)

Stopping Replication

• Delete policy on source -- permanent deletion. To replicate again, create a new policy.
• Stop from destination -- makes the destination writable again. The source replication status enters a "client error state." To resume, you must delete the source policy and create a new one.

Exam trap: Pre-existing objects are NOT replicated. If a question describes a bucket with 500 GB of existing data and asks what happens when you enable replication, the answer is that the 500 GB stays in the source only. You must use the OCI CLI oci os object bulk-upload or oci os object copy to manually copy existing objects.

Exam trap: Lifecycle policies that attempt to delete objects from a read-only destination bucket do not work. The read-only constraint overrides lifecycle rules.

4. Block Volume Replication

How It Works

Block Volume replication provides automatic asynchronous replication of block volumes, boot volumes, and volume groups to other regions or availability domains. The initial sync transfers all data, after which replication is continuous. There is no downtime or impact on source volumes during replication. (Block Volume Replication)

RPO and RTO

Cost Model

• Storage: Replica billed at Block Storage Lower Cost option price regardless of source volume performance tier.
• Network: Cross-region replication incurs outbound data transfer charges. Cross-AD replication within the same region has no network cost.
• Volumes with continual updates incur higher network costs. Total data transferred is visible in Console under Replica Details.

Limitations

Exam trap: Block Volume replication and Block Volume backups are complementary, not alternatives. Replication provides the current version of your data in another region (for DR). Backups provide point-in-time snapshots (for recovery from corruption or accidental deletion). A well-designed DR plan uses both.

Exam trap: If you need to resize a replicated volume, the entire replication relationship must be destroyed and rebuilt. The initial sync restarts. Factor this into maintenance windows.

5. File Storage (FSS) Replication

How It Works

FSS replication uses a snapshot-based mechanism with four components: source file system, target file system, replication resource (on source), and replication target resource (on destination). At each replication interval, the service captures an incremental (delta) snapshot on the source, transfers it to the target, and applies it. (File System Replication)

Replication Cycle States

Idle --> Capturing --> Transferring --> Applying --> Idle (repeat)

• Capturing: Taking a delta snapshot of changes since last replication.
• Transferring: Sending the snapshot data to the target.
• Applying: Committing the snapshot data to the target file system.

Configuration Parameters

What Gets Replicated vs What Does Not

Target File System Restrictions

The target file system is read-only after replication is configured. It must meet strict prerequisites:

• Never previously exported
• No existing user snapshots
• No snapshot policies attached

Workaround: If you need to use a previously exported file system as a target, create a clone of it first and use the clone as the target.

Failover Process

1. Export the target file system (makes it accessible to applications/users).
2. Applications connect to the target file system in the DR region.
3. The target takes over from the source.

For failback, Oracle recommends cloning the source from the last completely applied snapshot, which is faster and more cost-effective than creating a new file system.

Cost Model

• Source and target file systems are both metered at the same rate for capacity stored.
• Cross-region replication incurs network egress charges.
• Same-region, cross-AD replication has no bandwidth charge.

RPO Monitoring

The key metric is Replication Recovery Point Age, which tracks the age of the last successfully applied snapshot. Set alarms on this metric to detect replication lag before it becomes a problem.

Exam trap: Quota rules are copied to the target but arrive disabled. After failover, you must manually re-enable quota rules. This is easy to miss in a real DR scenario and is exactly the kind of detail the exam tests.

Exam trap: If you delete a replication resource, the replication snapshots on the target are converted to user snapshots. If you then delete those converted user snapshots, the target file system can never be used for future replications. This is irreversible.

6. Cross-Region Workload Architecture Patterns

DR Topology Comparison

Exam trap: Oracle's official CAF DR documentation defines four topologies (Backup/Restore, Pilot Light, Warm Standby, Active-Active). Some third-party resources add "Hot Standby" as a separate tier, but it does not appear in the official OCI framework.

Source: OCI Cloud Adoption Framework - Disaster Recovery

Database MAA Tiers (Exam-Critical)

Oracle's Maximum Availability Architecture (MAA) defines tiered DR for databases. These tiers map directly to exam questions:

Source: OCI Cloud Adoption Framework - Disaster Recovery

Exam trap: Gold tier (Data Guard) provides zero RPO and seconds RTO. Platinum tier (GoldenGate) provides zero RPO and zero RTO. Know the difference -- Data Guard is active-passive (standby is read-only or mounted), GoldenGate is active-active (both sides accept writes).

DNS-Based Failover with Traffic Management

OCI Traffic Management provides DNS-based traffic steering using steering policies. For cross-region DR, the Failover policy type is most relevant. (Traffic Management Failover Policy)

How failover steering works:

1. Create answer pools pointing to endpoints in each region (e.g., load balancer IPs).
2. Configure pool priority (primary region first, DR region second).
3. Attach health checks to monitor endpoint availability.
4. When health checks detect the primary endpoint is unhealthy, DNS responses automatically steer traffic to the DR endpoint.

The failover template processes rules in this order: FILTER --> HEALTH --> PRIORITY --> LIMIT.

Exam trap: Traffic Management failover depends on DNS TTL propagation. If the TTL is set to 300 seconds, clients may continue hitting the failed primary for up to 5 minutes after failover. For faster failover, use a lower TTL -- but this increases DNS query volume and cost.

7. Full Stack Disaster Recovery (Full Stack DR)

Full Stack DR is OCI's managed disaster recovery orchestration service. It does not perform replication itself -- it orchestrates the recovery of entire application stacks that use the underlying replication services (Block Volume replication, Data Guard, FSS replication, etc.). (Full Stack DR Overview)

Core Components

Member Types

Protection group members are classified as moving or non-moving:

Moving Compute Instance Details

When a compute instance is configured as a moving member:

• You specify VNIC-to-subnet mappings for the destination region (which subnet each VNIC attaches to in the DR region).
• If source and destination subnets have matching CIDR blocks and the IP is available, Full Stack DR assigns the same private IP. Otherwise, it assigns a new available IP.
• Boot volumes and block volumes must be in a replicated volume group (using Block Volume cross-region replication).
• Full Stack DR automatically creates the compute instance in the standby region during plan execution -- no need to pre-provision.

Source: Add a Moving Instance, Moving Instance Features

DR Plan Types

Plan Structure: Groups and Steps

DR plans are organized into plan groups (logical groupings) containing plan steps (individual actions).

Built-in steps (pre-configured by the service):

• Launch/terminate compute instances
• Update load balancer backends
• Promote database standby
• Restore volumes from replicas
• Update DNS/routing configuration

User-defined steps (custom):

• Run custom scripts (e.g., application startup, health checks, notifications)
• Execute application-specific recovery logic
• Perform external system updates

Steps can execute sequentially or in parallel within a plan group. Timeout handling is configurable per step.

Prechecks

Prechecks validate DR plan readiness without affecting production. They verify:

• Network connectivity between regions
• Storage replication status
• Compute resource availability in standby region
• IAM permission validity
• Database replication eligibility
• Custom script accessibility

Oracle recommends running prechecks weekly on all DR plans. Prechecks have zero impact on production workloads.

DR Drills

Drills test your DR readiness without affecting production:

1. Start Drill creates a replica of the production stack in the standby region.
2. The protection groups enter DrillInProgress state.
3. While in DrillInProgress: you cannot execute switchover, failover, or another start drill. You cannot add or remove members.
4. Stop Drill tears down the replica and reverts to Active state.

Exam trap: During a drill, protection group roles do NOT change. The primary remains primary and the standby remains standby. Only the lifecycle sub-state changes to DrillInProgress.

Execution Policies

Typical Recovery Timelines

8. Business Continuity Planning

Designing for Cross-Region DR

The exam expects you to select the right combination of services for a given RTO/RPO requirement:

Key Planning Decisions

1. Capacity Reservations: Reserve compute shapes in the DR region to guarantee availability during a regional outage. Without reservations, you may not be able to launch instances when everyone fails over simultaneously.

2. Network pre-configuration: VCNs, subnets, security lists, route tables, and DRGs must be pre-created in the DR region. These are non-moving members and must exist before failover.

3. Custom image replication: Compute custom images must be replicated to the DR region before they are needed. This is a prerequisite for moving compute members in Full Stack DR.

4. SSL certificates: Certificates used by load balancers must be available in the DR region. They are not automatically replicated.

9. Cost Considerations

Exam trap: Full Stack DR itself is free. The cost is in the infrastructure it orchestrates. If a question asks about the cost of implementing DR with Full Stack DR, focus on compute, storage, networking, and database licensing -- not the DR service fee.

10. Exam Focus Areas and Common Traps

High-Probability Question Topics

1. Which replication service for which scenario -- Object Storage for unstructured data, Block Volume for compute-attached storage, FSS for shared file systems, Data Guard for databases.
2. RPO differences -- Block Volume < 30 min, FSS depends on interval (min 15 min), Object Storage has no published RPO SLA.
3. Full Stack DR plan types -- Know the four types (switchover, failover, start drill, stop drill) and when each is used.
4. Moving vs non-moving members -- Compute instances are moving; databases are non-moving (they use replication).
5. Prechecks and drills -- Prechecks are non-disruptive validation. Drills create a replica stack. Neither affects production.
6. Encryption restrictions -- SSE-C blocks Object Storage replication. Customer-managed Vault keys block Block Volume replication.
7. Pre-existing object behavior -- Object Storage does NOT replicate pre-existing objects.
8. DR topology selection -- Given RTO/RPO requirements and budget, select the correct topology.

Summary of Key Gotchas

References

• Object Storage Replication
• Block Volume Replication
• File System Replication
• Full Stack Disaster Recovery
• Full Stack DR Plan Types
• Traffic Management Failover Policy
• OCI Cloud Adoption Framework - Disaster Recovery
• Add a Moving Instance to DR Protection Group
• Design a Pilot-Light DR Topology