OCI Architect Professional — Oracle’s Advanced Cloud Certification for 2026

Domain 1: Architecting Solutions — ~30%

The largest and most scenario-heavy domain tests the ability to select the right combination of OCI services to meet defined technical requirements: availability, performance, cost, compliance, and integration with existing systems. The most heavily tested architectural patterns are multi-AD (Availability Domain) deployments — distributing workloads across OCI’s independent fault isolation boundaries to eliminate single points of failure. Candidates must understand the hierarchy of OCI fault isolation: fault domains (physical groupings of hardware within an AD that protect against hardware failure), availability domains (independent data centers within a region with redundant networking between them), and regions (geographically separate deployments for disaster recovery and data residency). Designing for three-fault-domain coverage within a single AD provides protection against rack-level failures; spanning multiple ADs (available in regions with three ADs, like Ashburn, Frankfurt, and Tokyo) provides protection against data center-level failures.

Compute architecture decisions are a major topic: when to use VM instances vs. Bare Metal instances (BM instances provide dedicated host resources with no hypervisor overhead — optimal for database and high-performance computing workloads; VM instances provide the elasticity of shared infrastructure with smaller instance shapes), when to use instance pools with autoscaling policies vs. manually managed instance configurations, and how Oracle Container Engine for Kubernetes (OKE) and Oracle Functions (serverless) fit architectural decisions for containerized and event-driven workloads. Database architecture is equally prominent: candidates must understand when to use Autonomous Database (self-tuning, self-patching, shared or dedicated Exadata infrastructure) vs. Database Cloud Service (DCS, with manual DBA control) vs. MySQL HeatWave (MySQL-compatible with in-memory analytics acceleration) vs. NoSQL Database Cloud Service for document and key-value workloads, and how to size and shape each for the workload profile described in the scenario.

Domain 2: Network Architecture — ~23%

Network architecture is the most technically demanding domain for most candidates, because OCI networking has considerable depth and the Professional exam expects design-level fluency. Candidates must be able to design hub-and-spoke network topologies using Dynamic Routing Gateways (DRGs) — the OCI equivalent of a transit gateway, connecting multiple VCNs to a shared hub VCN that provides centralized egress, firewall inspection, and on-premises connectivity. DRG v2 (the current generation) supports up to 300 VCN attachments and can peer VCNs across regions through the OCI backbone, enabling global hub-and-spoke designs that span multiple OCI regions without routing traffic over the public internet.

Hybrid connectivity architecture is a core Professional topic: the differences between FastConnect (dedicated, private network connectivity from on-premises to OCI via a colocation provider or a FastConnect partner, with bandwidth options from 1 Gbps to 10 Gbps and predictable low latency) and Site-to-Site VPN (IPsec tunnels over the public internet, suitable for lower-bandwidth or backup connectivity), and when to use FastConnect with BGP routing for automated failover vs. static routes. The exam tests multi-cloud network design: Oracle Interconnect for Microsoft Azure (a dedicated low-latency link between OCI and Azure data centers in specific regions, used for organizations running Oracle databases on OCI alongside Azure application workloads) and the network architecture for Oracle Dedicated Region Cloud at Customer (an OCI region deployed inside a customer data center, which requires physical network integration with the customer’s existing campus and WAN infrastructure).

Load balancer architecture is tested in depth: OCI Load Balancer (Layer 7, HTTP/HTTPS-aware, with path-based routing, SSL termination, and health checks) vs. OCI Network Load Balancer (Layer 4, ultra-low latency for TCP/UDP traffic, preserves source IP, used for firewall appliances, gaming, and financial trading applications) vs. OCI DNS Traffic Management (global traffic steering at the DNS layer, supporting geolocation routing, load-based routing, and failover across regions). Candidates must select the right load balancing tier for the given scenario requirements and understand how to chain them (an NLB in front of a firewall appliance cluster, with an LB behind it for application-layer distribution) for defense-in-depth network architectures.

Domain 3: Security Architecture — ~20%

Security architecture tests the design of defense-in-depth OCI environments that satisfy enterprise and regulated industry requirements. The foundational OCI security model starts with compartments — the logical boundaries used to isolate resources, apply policies, and delegate administration. Designing a compartment hierarchy (root compartment for organization-wide policies, environment-level compartments for production, staging, and development, project-level compartments for workload isolation) is the first security architecture decision in any OCI environment. Candidates must understand how IAM policies are evaluated against compartment hierarchies (a policy at the tenancy level applies to all compartments; a policy at a compartment level applies to that compartment and all sub-compartments), how to use groups and dynamic groups (groups whose membership is defined by resource attributes rather than by manual user assignment — used to grant OCI instances permission to call OCI APIs without embedding credentials), and how instance principals allow OCI instances to authenticate to OCI services using their identity rather than API keys stored in configuration files.

OCI Vault (key management and secrets management) is a heavily tested Professional topic: the difference between software-protected keys (encrypted and stored in OCI Vault, protected by a master encryption key backed by a hardware-based FIPS 140-2 Level 3 HSM) and HSM-protected keys (private key material never leaves the HSM partition in clear text, required for PCI DSS, FedRAMP, and regulated healthcare workloads), and how to use Vault to manage encryption keys for Block Volume encryption, Object Storage server-side encryption, and application-level encryption. OCI Web Application Firewall (WAF) architecture — deploying WAF as a managed service in front of OCI Load Balancer to protect against OWASP Top 10 attacks, bot traffic, and DDoS at Layer 7 — is tested alongside OCI DDoS Protection (always-on volumetric DDoS protection for all OCI public endpoints) and Cloud Guard (a posture management service that continuously monitors the OCI tenancy for security configuration issues, detects risky activity via detector recipes, and responds via responder recipes that can automatically remediate common misconfigurations).

Domain 4: Observability and Management — ~15%

Observability architecture validates the ability to design monitoring, logging, and alerting solutions that provide actionable insight into OCI workloads at enterprise scale. The OCI observability stack is built around four integrated services: Monitoring (time-series metrics for all OCI services, with alarms that trigger notifications or auto-scaling actions when metrics cross defined thresholds), Logging (centralized log collection from OCI services, custom applications, and on-premises sources through the Unified Monitoring Agent), Logging Analytics (log parsing, enrichment, and correlation powered by Oracle’s machine learning-backed log intelligence engine, used for security investigations, performance analysis, and compliance reporting), and Application Performance Monitoring (APM) (distributed tracing and synthetic monitoring for application-level visibility into latency, error rates, and transaction flows across microservices).

The Professional exam tests architectural decisions within this stack: when to use Monitoring alarms vs. Events service triggers (Events reacts to OCI resource state changes — an instance being terminated, a bucket becoming public, a policy being modified — where Monitoring alarms react to metric threshold crossings); how to route logs from Logging to Object Storage (for long-term archival and compliance), to Streaming (OCI’s managed Kafka-compatible service, for real-time log processing pipelines), or to a third-party SIEM (Splunk, Datadog, Elastic) via the Logging service connector; and how to design Operations Insights configurations for database performance management that surface SQL performance regressions, resource utilization forecasts, and capacity planning recommendations for Autonomous Database and Database Cloud Service deployments at scale.

Domain 5: Migration and Disaster Recovery — ~12%

Migration and disaster recovery tests the design of strategies for moving workloads to OCI and for ensuring business continuity when failures occur. Migration patterns are evaluated against workload characteristics: lift-and-shift migration (moving existing VMs to OCI compute with minimal modification, using Oracle Cloud Migrations to discover, assess, and replicate on-premises VMware workloads to OCI VM instances), re-platform migration (moving a workload to a managed OCI service that eliminates operational overhead without rewriting the application, such as migrating a self-managed MySQL database to MySQL HeatWave or moving on-premises Oracle Database to Autonomous Database), and re-architect migration (redesigning a monolithic application as a cloud-native set of containerized microservices on OKE, with managed services replacing self-managed infrastructure components). Candidates must assess migration complexity, risk, and required downtime for each approach and recommend the appropriate pattern for the described workload.

Disaster recovery architecture is the second major topic: designing for defined Recovery Point Objective (RPO) and Recovery Time Objective (RTO) targets using OCI services. The four DR strategies on OCI map to different RPO/RTO targets and cost profiles: backup and restore (lowest cost, highest RPO/RTO — backups to Object Storage in a secondary region, restored manually on failure), pilot light (minimal secondary environment with replicated data but no running compute — compute is started on failover), warm standby (scaled-down secondary environment actively serving traffic or ready to serve within minutes), and active-active (both regions serving production traffic simultaneously, with global load balancing routing requests to the healthy region on failure — lowest RPO/RTO, highest cost). Full Stack Disaster Recovery (FSS), Oracle’s managed DR orchestration service, automates failover and failback across OCI regions by executing user-defined DR plans that sequence compute, database, networking, and DNS changes in the correct order — reducing manual failover execution time from hours to minutes.