Domain 1: Getting Started with Autonomous Database (11%)
Domain 1 of the 1Z0-931-25 Oracle AI Autonomous Database 2025 Professional exam covers the foundational architecture, offerings, deployment models, and licensing for Oracle Autonomous Database. This domain represents approximately 6 questions on the 50-question exam (90 minutes, 68% passing score). Despite its moderate weight, every subsequent domain assumes you have internalized these concepts.
The exam syllabus defines three objectives for this domain:
- Describe Autonomous Database architecture and integration
- Explain Autonomous Database architectural components and key features
- Describe the different Autonomous Database offerings and license types
1. Autonomous Database Architecture and Integration
What Autonomous Database Is
Oracle Autonomous Database (ADB) is a fully managed cloud database service built on Oracle Exadata infrastructure. "Fully managed" means Oracle handles provisioning, patching, upgrading, backup, scaling, and tuning without human intervention or downtime. The database runs Oracle Database software (currently Oracle AI Database 26ai or Oracle Database 19c) on Exadata hardware with automated lifecycle management layered on top. (Oracle ADB Overview)
The Three Autonomous Pillars
ADB's marketing and exam content centers on three autonomous capabilities. Understand what each actually means technically:
| Pillar | What It Automates | Key Technical Details |
|---|---|---|
| Self-Driving | Provisioning, patching, upgrading, tuning, scaling | Automatic indexing, real-time statistics collection, automated SQL plan management, automatic compute and storage scaling up to 3x base capacity |
| Self-Securing | Encryption, security patching, threat detection | Always-on Transparent Data Encryption (TDE), automatic security patch application with zero downtime, network access controls (ACLs, private endpoints) |
| Self-Repairing | Failover, backup, recovery | Autonomous Data Guard for HA, automatic point-in-time backups (1-60 day retention), automatic failover to standby, self-recovering from infrastructure failures |
Source: ADB Key Features
Exam trap: "Self-driving" is not just about auto-scaling. It explicitly includes automatic indexing, automatic SQL tuning, and automatic statistics. If a question asks what self-driving covers, all of these are correct.
Integration with OCI
ADB is an OCI-native service. It integrates with the OCI control plane through standard constructs:
| OCI Component | ADB Integration |
|---|---|
| Compartments | Every ADB instance belongs to a compartment. IAM policies grant access at compartment level. |
| IAM | OCI IAM policies control who can create, manage, start, stop, and terminate ADB instances. The ADMIN database user is separate from OCI IAM users. |
| VCN / Subnets | ADB supports public endpoints (default), access control lists restricting to specific IPs/VCNs, or private endpoints inside a VCN subnet. |
| Object Storage | Native integration for data loading from OCI Object Storage, AWS S3, Azure Blob Storage, Azure Data Lake Storage, Google Cloud Storage, and GitHub. |
| Oracle Analytics Cloud | Direct connectivity for BI and analytics. |
| Oracle GoldenGate | Real-time data replication to and from ADB. |
| OCI Vault | Customer-managed encryption keys (same tenancy or cross-tenancy) as an alternative to Oracle-managed keys. |
| Resource Manager | ADB provisioning can be exported as a Terraform stack via "Save as Stack." |
Source: ADB Provisioning
Exam trap: The ADMIN user created during ADB provisioning is a database user, not an OCI IAM user. OCI IAM controls who can manage the ADB instance (start/stop/scale/terminate). The ADMIN user controls what happens inside the database (create tables, grant privileges). These are separate identity layers.
2. Architectural Components and Key Features
Compute: ECPUs
ADB uses ECPUs (Elastic CPUs) as the billing and compute metric. ECPU is the only billing metric for all new and existing deployments. The legacy OCPU model is deprecated. (ADB Provisioning)
- Minimum: 2 ECPUs (paid tier), 4 ECPUs fixed (Developer tier)
- Auto-scaling: Enabled by default. Allows the database to use up to 3x the base ECPU count automatically based on workload demand.
- Manual scaling: Increase or decrease ECPUs at any time with no downtime.
- Idle shutdown: Compute can be shut off when idle to save cost; storage persists.
Exam trap: Auto-scaling is enabled by default for compute but disabled by default for storage. The scaling factor is 3x for both, but the defaults are opposite. This is a common exam question.
Storage
- Storage is specified in TB for Lakehouse workloads and GB or TB for Transaction Processing and JSON workloads.
- Maximum pre-provisioned storage: 384 TB. Requests above 384 TB require an Oracle Support Service Request.
- Storage auto-scaling: Disabled by default. When enabled, automatically expands up to 3x reserved base storage.
- Flash cache: Automatically managed via Exadata Smart Flash Cache. Minimum 10% of provisioned (or allocated, if auto-scaling is enabled) storage.
Network Access Types
Three network access configurations are available at provisioning time:
| Access Type | Description | Security Level |
|---|---|---|
| Secure access from everywhere | Public endpoint, accessible over HTTPS from any IP. Default option. | Lowest (but still encrypted) |
| Allowed IPs and VCNs only | Public endpoint restricted by Access Control Lists (ACLs). Specify approved IP ranges and/or VCN OCIDs. | Medium |
| Private endpoint only | Private IP inside a VCN subnet. No public IP. Traffic restricted to the specified VCN. Network Security Groups control ingress/egress. | Highest |
Source: ADB Provisioning
Encryption
ADB always uses Transparent Data Encryption (TDE). There is no option to disable encryption. Two key management models:
- Oracle-managed keys (default): Oracle creates, stores, and rotates the TDE master encryption key.
- Customer-managed keys: Master key stored in OCI Vault. Can be in the same tenancy or a remote tenancy. Customer controls key lifecycle and rotation.
Backup and Disaster Recovery
- Automatic backups: Point-in-time recovery within a configurable retention window of 1 to 60 days.
- Immutable backup retention: Lock the retention period so it cannot be shortened without filing a Service Request. Designed for regulatory compliance.
- Autonomous Data Guard: Standby (peer) database with continuous replication. Available as local standby (same region) or cross-region standby.
- Backup-based DR: Lower-cost alternative to Data Guard. Higher RTO but lower ongoing cost. Local backups at no additional cost; cross-region backups incur additional charges.
Database Versions and Instance Tiers
| Tier | ECPUs | Storage | Use Case |
|---|---|---|---|
| Always Free | Limited | Limited | Learning, prototyping. Only in home region. |
| Developer | 4 ECPUs (fixed) | 20 GB (fixed) | Development and testing. Cost-effective, non-production. |
| Paid | 2+ ECPUs (configurable) | Configurable (up to 384 TB) | Production workloads. Full auto-scaling, DR, and tooling. |
Database version options: Oracle AI Database 26ai (current) and Oracle Database 19c (legacy). 26ai is available in all commercial public cloud regions except a few specific exclusions. (ADB Provisioning)
3. Autonomous Database Offerings (Workload Types)
ADB is a single service with four workload types. The workload type is selected at provisioning time and determines internal optimizations.
Workload Type Comparison
| Characteristic | Lakehouse (formerly ADW) | Transaction Processing (ATP) | JSON Database | APEX Service |
|---|---|---|---|---|
| Primary use | Analytics, data warehousing, multi-cloud data lakes | OLTP, mixed transactions and analytics, IoT | Document-centric NoSQL-style applications | Low-code application development |
| Optimized for | Complex analytical queries, columnar storage, Iceberg integration | High-concurrency transactions, mixed workloads | JSON document storage and retrieval via SODA APIs | Rapid application building with Oracle APEX |
| Data format | Apache Iceberg, Parquet, native Oracle | Native Oracle relational | OSON (Oracle binary JSON) | SQL tables |
| Non-JSON storage limit | None | None | 20 GB maximum for non-JSON data | None |
| API access | SQL | SQL | SODA (Simple Oracle Document Access) + SQL | SQL |
| Can be promoted | No | No | Yes, to ATP | Yes, to ATP |
| Multi-cloud | Yes (AWS, Azure, GCP, OCI, Databricks, Snowflake) | OCI | OCI | OCI |
Sources: ADB Workload Types
Lakehouse (Autonomous AI Lakehouse, formerly ADW)
The Lakehouse workload is the evolution of Autonomous Data Warehouse (ADW). It adds native Apache Iceberg support, a unified metadata catalog connecting to Databricks Unity, AWS Glue, and Snowflake Polaris, and a Data Lake Accelerator that auto-scales resources for Iceberg queries. Oracle GoldenGate streams real-time data into Iceberg tables. Table Hyperlinks enable controlled data sharing. Select AI Agent and Data Science Agent provide natural language data exploration. (ADB Workload Types)
Exam trap: The exam may still use the term "Autonomous Data Warehouse" or "ADW" interchangeably with "Lakehouse." They refer to the same workload type. Lakehouse is the current branding.
Transaction Processing (ATP)
ATP is optimized for mission-critical OLTP, mixed transaction and analytics workloads, and IoT applications. It includes all enterprise Oracle Database features: Real Application Clusters (RAC), Multitenant, Partitioning, In-Memory, Advanced Security, and Advanced Compression. ATP supports JSON document storage natively, but without the specialized SODA APIs and 20 GB non-JSON restriction of the JSON workload type. (ADB Workload Types)
JSON Database
The JSON Database workload is a specialized subset of ATP optimized for NoSQL-style, schema-less document applications. Key facts:
- Uses SODA (Simple Oracle Document Access) APIs for document operations
- JSON data stored in Oracle's native binary format (OSON)
- 20 GB limit on non-JSON data (no limit on JSON collection storage)
- SODA collections are backed by ordinary Oracle Database tables and views
- Full Oracle Database features remain available for all data types, including SQL queries on JSON data
- Can be promoted to ATP if requirements expand beyond document-centric workloads
Exam trap: The 20 GB limit applies to non-JSON data only. JSON collection storage is unlimited. If a question asks about storage limits on JSON Database, the constraint is on relational/non-JSON data.
APEX Service
The APEX Service workload provides low-cost access to the Oracle APEX low-code platform for rapid application development. It is the most resource-constrained workload type and is designed for building and deploying APEX applications rather than general-purpose database work. Like the JSON Database, APEX Service can be promoted to ATP if the workload outgrows the APEX-only use case. (ADB Workload Types)
4. Deployment Models: Serverless vs. Dedicated
ADB is available in two primary deployment models plus a data center variant:
| Characteristic | Serverless (Shared) | Dedicated Exadata Infrastructure | Cloud@Customer |
|---|---|---|---|
| Infrastructure | Shared Exadata hardware managed by Oracle | Dedicated Exadata hardware in OCI | Dedicated Exadata in your data center |
| Resource isolation | Logical isolation (multi-tenant on shared hardware) | Full physical isolation (compute, storage, network) | Full physical isolation on-premises |
| Who manages infra | Oracle entirely | Oracle manages, customer controls policies | Oracle manages, data stays in customer data center |
| Patching control | Oracle schedules patches | Fleet admin controls maintenance windows per VM cluster | Fleet admin controls maintenance windows |
| Architecture layers | ADB instance only | Exadata Infrastructure > AVMC > ACD > ADB (four-layer hierarchy) | Same as Dedicated |
| License options | License Included or BYOL | License Included or BYOL (can vary per VM cluster) | License Included or BYOL |
| Use case | Most workloads; simplest to manage | Regulatory compliance, strict isolation, enterprise governance | Data sovereignty, latency requirements, air-gapped environments |
| Pricing model | Pay-per-use (ECPU-based) | Committed infrastructure cost | Committed infrastructure cost |
Sources: ADB Dedicated, ADB Serverless
Dedicated Infrastructure Hierarchy
The Dedicated model has a four-layer resource hierarchy that the exam will test:
- Exadata Infrastructure: Physical Exadata Database Machine (compute nodes + storage cells)
- Autonomous Exadata VM Cluster (AVMC): Set of VMs across compute nodes. Multiple AVMCs per Exadata Infrastructure allow separate maintenance windows, different license models, and workload segregation.
- Autonomous Container Database (ACD): Container for autonomous databases. At least one ACD must exist before creating any ADB. Provisioned with either 19c or 26ai.
- Autonomous AI Database: The actual user database. Multiple databases per ACD.
Exam trap: On Dedicated infrastructure, you need the Fleet Administrator role (OCI IAM) to create and manage Exadata Infrastructure, AVMCs, and ACDs. The Database Administrator role manages the ADB instances themselves. Database users (developers) do not need OCI cloud accounts at all; they connect via SQL*Net through network access configured by the DBA.
5. License Types
Two licensing models are available for all ADB deployment types:
| License Model | Description | When to Choose |
|---|---|---|
| License Included | Oracle license cost is bundled into the service price. Default option. | New Oracle customers, no existing Oracle licenses, simplest billing model. |
| Bring Your Own License (BYOL) | Apply existing on-premises Oracle Database licenses to reduce ADB cost. Enabled in advanced options during provisioning. | Organizations with unused or underutilized Oracle Database Enterprise Edition licenses. |
Source: ADB Provisioning
Exam trap: BYOL requires existing Oracle Database Enterprise Edition licenses. Standard Edition licenses do not qualify. On Dedicated infrastructure, different AVMCs on the same Exadata Infrastructure can use different license models, allowing a mix of License Included and BYOL within one environment.
6. When to Choose Which Offering
The exam may present scenario-based questions where you select the correct workload type or deployment model.
| Scenario | Correct Choice | Why |
|---|---|---|
| Enterprise data warehouse with multi-cloud data sources | Lakehouse | Iceberg integration, multi-cloud metadata catalog, optimized for analytics |
| High-concurrency OLTP e-commerce application | ATP | Optimized for transaction processing, RAC, mixed workloads |
| Mobile app storing user profiles as JSON documents | JSON Database | SODA APIs, schema-less, optimized for document operations |
| Rapid internal tool built by citizen developers | APEX Service | Low-code, lowest cost, purpose-built for APEX development |
| Regulated financial services with strict data isolation | Dedicated | Physical resource isolation, fleet admin patching control |
| Small team, simple workload, minimal management overhead | Serverless | Fully managed, pay-per-use, no infrastructure to configure |
| Data must stay on-premises for sovereignty compliance | Cloud@Customer | Exadata in your data center, Oracle manages remotely |
Key Exam Traps Summary
- ECPU is the only billing metric. OCPU is deprecated. Do not select OCPU-based answers.
- Compute auto-scaling is ON by default; storage auto-scaling is OFF by default. Both scale up to 3x.
- JSON Database has a 20 GB non-JSON limit, not a 20 GB total limit. JSON storage is unlimited.
- JSON Database and APEX Service can be promoted to ATP. Lakehouse and ATP cannot be promoted (they are already full-featured).
- ADMIN user is a database user, not an OCI IAM user. They serve different purposes.
- Lakehouse is the current name for ADW. The exam may use either term.
- Dedicated infrastructure has a four-layer hierarchy (Exadata > AVMC > ACD > ADB). Serverless does not.
- BYOL requires Enterprise Edition licenses. Standard Edition does not qualify.
- Always Free tier is only available in the tenancy's home region. Not in every region.
- Encryption (TDE) is always on. There is no option to disable it.