Study guide
3.1 Full Stack Disaster Recovery: Protection Groups, Members & Permissions
OCI 2026 Architect Professional 1Z0-997-26
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Architecture Foundations
1.1 Exam Logistics, the 2026 Blueprint & How to Use This Guide 1.2 The OCI Well-Architected Framework & Architectural Tradeoffs
2 Chapter 2: High Availability & Resilient Design
2.1 Availability Domains, Fault Domains, Instance Pools & Load Balancers 2.2 OCI DNS Traffic Steering, Geolocation & Health Checks 2.3 Block Volume Replication, Volume Groups & Backup Policies 2.4 Object Storage Replication, Versioning & Retention Rules (WORM)
3 Chapter 3: Full Stack Disaster Recovery
3.1 Full Stack Disaster Recovery: Protection Groups, Members & Permissions 3.2 DR Plans: Switchover, Failover, Prechecks & Plan Execution 3.3 DR Drills, Plan Customization & Operational Readiness
4 Chapter 4: Container Instances, OCIR & OCI DevOps
4.1 Containerization, Microservices & OCI Container Instances 4.2 OCI Container Registry: Repositories, Push & Pull, and Image Management 4.3 OCI DevOps: Code Repositories, Build Pipelines & Deployment Strategies
5 Chapter 5: OCI Kubernetes Engine (OKE)
5.1 OKE Cluster Types, Node Options & Cluster Creation 5.2 OKE Networking: VCN-Native Pod Networking vs. Flannel, Subnet Sizing & Load Balancers 5.3 OKE Workload Identity, Secrets & Persistent Storage
6 Chapter 6: Serverless Functions & API Gateway
6.1 OCI Functions: Concepts, Invocation Modes, Integrations & Image Security 6.2 API Gateway: Authentication, JWT Validation, Rate Limiting & Usage Plans
7 Chapter 7: Messaging & Event-Driven Design
7.1 OCI Streaming, OCI Queue & Messaging Patterns for Microservices 7.2 OCI Events, Event Rules & OCI Notifications Fan-Out
8 Chapter 8: Infrastructure as Code with Terraform & Resource Manager
8.1 Infrastructure as Code with Terraform and the OCI Provider 8.2 OCI Resource Manager: Stacks, Jobs, Drift Detection & Private Endpoints
9 Chapter 9: Identity & Multi-Tenancy Governance
9.1 IAM Policy Design: Verbs, Conditions, Dynamic Groups & Principals 9.2 Organizations Management, Governance Rules & Compartment Quotas
10 Chapter 10: Security Posture with Cloud Guard & Security Zones
10.1 Cloud Guard: Detector Recipes, Problems, Scores & Responders 10.2 Security Zones & Vulnerability Scanning
11 Chapter 11: Secure Access & Network Protection
11.1 Layered Network Security: Security Lists, NSGs & Private Access to Services 11.2 OCI Bastion: Managed SSH, Port Forwarding & SOCKS5 Sessions 11.3 Zero Trust Packet Routing (ZPR): Security Attributes & Intent-Based Policy 11.4 OCI Network Firewall: Policies, Inspection Routing, Tunnel Inspection & Private NAT
12 Chapter 12: Application & Data Protection: WAF, Certificates & Vault
12.1 OCI Web Application Firewall: Policies, Modules, Actions & Enforcement Points 12.2 OCI Certificates: Private CAs, TLS Certificates, Renewal & Integrations 12.3 OCI Vault Key Management: Vault Types, Protection Modes, Dedicated KMS & External KMS 12.4 Vault Secrets: Versions, Rotation States, Automatic Generation & Rotation
13 Chapter 13: Base Database Service & Autonomous AI Database
13.1 Base Database Service: DB Systems, RAC, Data Guard, Cloning & Maintenance 13.2 Autonomous AI Database: Workload Types, Deployment Options, Services & Connectivity 13.3 Operating Autonomous AI Database: Scaling, Cloning, Backups, Patching & Self-Tuning 13.4 Autonomous Data Guard & Backup-Based Disaster Recovery for Autonomous AI Database
14 Chapter 14: Recovery Service, Global Distribution & OCI Cache
14.1 Autonomous Recovery Service: Protection Policies, Real-Time Protection & Retention Lock 14.2 Globally Distributed Autonomous AI Database: Sharding, Data Placement & Replication 14.3 OCI Cache: Valkey and Redis Clusters, Sharding, Security & Cross-Region Replication
15 Chapter 15: Monitoring, Alarms & Notifications
15.1 OCI Monitoring: Metrics, Namespaces, Custom Metrics & Monitoring Query Language 15.2 Alarms & Notifications: Trigger Rules, Absence Alarms, Split Messages, Suppression & Delivery
16 Chapter 16: Logging, Audit, Connector Hub & Search
16.1 OCI Logging: Log Groups, Service Logs, Custom Logs & the Unified Monitoring Agent 16.2 Logging Search, the Logging Query Language & OCI Audit 16.3 Connector Hub: Moving Logs, Metrics, Queue Messages & Streams Between Services 16.4 OCI Search with OpenSearch & Resource Search for Observability
3.1 Full Stack Disaster Recovery: Protection Groups, Members & Permissions
Key Takeaways Explain This Topic AI
A DR protection group (DRPG) is a consistency group of OCI resources, and each DRPG can be associated with exactly one peer DRPG in a primary/standby pair.
DR plans and DR plan executions can only be created in the standby DR protection group.
A moving compute instance and the volume group holding its boot and block volumes are added only to the primary DRPG; Full Stack DR launches the instance in the standby region during recovery.
Full Stack DR does not create load balancers; load balancers must already exist in both regions, and Full Stack DR updates their backend sets.
Oracle recommends resource principal authentication, using a dynamic group that matches resource.type='drprotectiongroup', so Full Stack DR can act on member resources.
Last updated: October 2026
What Full Stack DR Does
Disaster recovery projects rarely fail because replication breaks. They fail because the runbook that coordinates databases, storage, compute, and traffic is manual, out of date, or never tested. OCI Full Stack Disaster Recovery (Full Stack DR) is a managed orchestration service that turns that runbook into repeatable DR plans . It does not replace native replication. Instead, it drives services you have already configured, such as Data Guard, Autonomous Data Guard, block volume group replication, File Storage replication, and Object Storage replication, and it coordinates them with compute launches and load balancer updates.
Oracle defines disaster recovery as restoring a business system after an outage, either in the same geographic region or in another region. Most exam scenarios use two regions, such as Ashburn and Phoenix.
Key Terms
Term Meaning in Full Stack DR
Primary / Standby The role of an application and its region. Roles reverse after a switchover or failover.
Warm standby Some or all components are pre-deployed in the standby region. Higher running cost, lower RTO.
Cold standby Few or no components are pre-deployed; they are deployed during the transition. Lower cost, higher RTO.
DR protection group (DRPG) A consistency grouping: the collection of OCI resources that make up an application and must be recovered together.
Association The pairing of two DRPGs in a primary/standby relationship. It is exclusive: a DRPG can be associated with only one other DRPG.
DR plan A workflow made of plan groups and plan steps. Plans can only be created in the standby DRPG.
DR plan execution A running instance of a plan. Executions are also launched from the standby DRPG.
Member Types
When you create DR plans, Full Stack DR inspects the members of both DRPGs and generates built-in plan groups for them. Supported member types include:
- Category Member types
- Compute Moving instances; non-moving instances
Oracle Database Autonomous AI Database Serverless; Autonomous Container Database (dedicated); Base Database Service; Exadata Database Service on Dedicated Infrastructure, on Exascale Infrastructure, and on Cloud@Customer
- Other databases MySQL HeatWave DB systems
- Storage Volume groups; File Storage file systems; Object Storage buckets
- Networking Load balancers; network load balancers
- Developer services OKE clusters; Oracle Integration 3 instances
- Moving vs. Non-Moving Compute
A moving instance exists only in the primary region during normal operation. It is the classic pilot light or cold VM topology. You add the instance and the volume group that contains its boot and block volumes to the primary DRPG only. During a switchover or failover, Full Stack DR recovers the volume group in the standby region and launches the instance there, applying the VNIC mappings you defined (destination subnet, and optionally the same private IP and hostname if the destination subnet allows them).
A non-moving instance is pre-deployed in both regions (a warm standby). Each region's instance is added to its own DRPG. Full Stack DR starts and stops them, and it can also detach replicated block volumes from the primary instance and attach them to the standby instance.
Databases, Storage, and Load Balancers
For Oracle Database services , the primary database goes in the primary DRPG and the standby database in the standby DRPG. Data Guard (or Autonomous Data Guard) must already be configured, and the database password is supplied through a Vault secret.
For File Storage and Object Storage , you add the primary file system or bucket to the primary DRPG and configure replication beforehand.
For load balancers , Full Stack DR does not create or provision anything. Load balancers must already exist in both regions. Full Stack DR updates their backend sets so traffic reaches the instances that are active after the transition.
Role Reversal
After a successful switchover, the DRPG that was standby becomes primary, and the old primary becomes standby. Plans are then created or refreshed in the new standby group so you can switch back later. Oracle provides a DR plan refresh option to keep existing plans when members are added, removed, or changed, instead of deleting and recreating them.
Permissions: Users and the DRPG Resource Principal
Two kinds of permissions matter.
1. Permissions for people. Full Stack DR resources use the disaster-recovery-family , which contains disaster-recovery-protection-groups , disaster-recovery-plans , disaster-recovery-plan-prechecks , disaster-recovery-plan-executions , and disaster-recovery-workrequests . For example, Oracle's sample policies let one group fully administer DR, and another group create protection groups, plans, and prechecks without being able to execute plans: Allow group DRUberAdmins to manage disaster-recovery-family in tenancy
- Allow group DRConfig to manage disaster-recovery-protection-groups in compartment ApplicationERP
- Allow group DRConfig to manage disaster-recovery-plans in compartment ApplicationERP
2. Permissions for the service to act on members. Oracle recommends resource principal authentication. You create a dynamic group whose matching rule includes the DR protection groups, plus the compute instances (needed for running commands on them), and grant that dynamic group access to the member services: All {resource.type='drprotectiongroup', resource.compartment.id='<drpg_compartment_ocid>'}
- Allow dynamic-group fsdr-dg to manage instance-family in compartment AppCompute
- Allow dynamic-group fsdr-dg to manage volume-family in compartment AppStorage
- Allow dynamic-group fsdr-dg to manage database-family in compartment AppDB
- Allow dynamic-group fsdr-dg to read secret-family in compartment Vaults
If these permissions are missing, prechecks and plan executions fail when Full Stack DR tries to act on the member resources.
Getting Started Quickly: QuickDR
For a single compute instance, QuickDR sets up a DR configuration from the instance itself. It can create a new, dedicated Full Stack DR configuration for the instance (protection groups, volume group, and plans) or add the instance to an existing configuration. It is a fast path for pilot light protection of individual VMs.