Domain 4: Managing and Maintaining Autonomous Database (20%)

Domain 4 of the 1Z0-931-25 Oracle AI Autonomous Database 2025 Professional exam covers the operational management of Autonomous Database: programmatic administration, networking, security, performance monitoring, disaster recovery, and cost governance. At 20% weight, this is one of the two heaviest domains on the exam (approximately 10 questions out of 50). These are practical, hands-on topics -- expect scenario-based questions that test whether you know which tool or configuration to use for a given operational requirement.

The exam syllabus defines six objectives for this domain:

1. Manage Autonomous Database instances: REST APIs, OCI CLI, patching and upgrading
2. Use Access Control Lists (ACLs) and Private Endpoints
3. Monitor ADB performance and set up service notifications
4. Use services in ADB: auto-indexing, Data Safe, compartment quotas
5. Use ADB connectivity: wallets, service handles
6. Configure Disaster Recovery (Data Guard)

1. Instance Management: REST APIs and OCI CLI

Programmatic Administration

Beyond the OCI Console, Autonomous Database instances can be managed programmatically through the OCI REST APIs, the OCI CLI, and SDKs (Python, Java, Go, .NET, Ruby, TypeScript). All three use the same underlying API endpoints and support identical operations.

Key OCI CLI Commands

The oci db autonomous-database command group provides full lifecycle management:

Exam trap: The update command handles both scaling and network configuration changes. There is no separate "scale" command -- you pass --cpu-core-count or --data-storage-size-in-tbs parameters to update.

REST API Authentication

OCI REST APIs use request signing with the user's API key (RSA key pair). The signature includes the date, request target, host, and content headers. All calls use HTTPS with TLS 1.2. The API operates at the control plane level (managing instances), not the data plane (running SQL).

Patching and Upgrading

Autonomous Database Serverless handles patching automatically. Key facts for the exam:

Exam trap: On Serverless, you do NOT schedule maintenance windows or choose specific patches. Oracle controls the schedule. The only user choice is Regular vs. Early patch level. On Dedicated infrastructure, administrators have more control over maintenance scheduling and versions.

Exam trap: Patching is online with zero downtime. If a question asks whether patching requires downtime, the answer is no for Serverless.

2. Network Security: ACLs and Private Endpoints

Network access is one of the most exam-tested management topics. Understand all three network access modes and how ACLs interact with TLS/mTLS. (ACL Documentation)

Three Network Access Modes

Access Control Lists (ACLs)

When you select "Secure access from allowed IPs and VCNs only," you define an ACL that blocks all IP addresses NOT in the list. ACL entries support four types:

Key ACL rules:

• Multiple IPs in same VCN: Use a single ACL entry with comma-separated values (e.g., 10.0.1.0/24, 10.0.2.0/24). Do NOT create multiple ACL entries for the same VCN.
• NAT Gateway: If clients are in a private subnet using a NAT Gateway, enter the NAT Gateway's public IP in the ACL -- private subnet clients have no public IP of their own.
• Tools affected: When an ACL is defined, access to Database Actions, APEX, Graph Studio, OML Notebooks, and ORDS is controlled by the same ACL. Unauthorized clients see: "login rejected based on access control list set by the administrator."
• Restore behavior: Existing ACLs are NOT overwritten during a database restore.
• No downtime: Adding or modifying ACLs causes the lifecycle state to change to "Updating" then back to "Available" with no downtime.

Private Endpoints

A private endpoint places the ADB instance inside a specific VCN subnet, removing any public IP:

• All traffic stays within the VCN (or connected networks: peered VCNs, on-premises via FastConnect/VPN)
• Network Security Groups (NSGs) control ingress/egress rules at the instance level
• When configured with a private endpoint, TLS connections are automatically available without requiring ACLs
• Switching from private to public endpoint requires disabling TLS first and all users must download new wallets afterward

Exam trap: With a public endpoint and no ACLs, the database is reachable from any IP on the internet. ACLs are the mechanism to restrict public endpoint access. With private endpoints, the network topology itself restricts access.

mTLS vs. TLS

To enable TLS (wallet-less) connections on a public endpoint, you must first define at least one ACL entry. On a private endpoint, TLS is automatically available.

Exam trap: You cannot enable TLS connections on a public endpoint without ACLs. This is a security prerequisite. The exam may present a scenario where someone wants TLS without a wallet but has no ACLs configured -- the answer is they must add ACLs first.

Exam trap: Removing all ACLs when TLS is enabled requires disabling TLS first. You cannot have a public endpoint with TLS and no ACLs.

3. Performance Monitoring and Service Notifications

Performance Hub

Performance Hub is the primary performance monitoring interface, accessed from the ADB instance details page in the OCI Console.

Tabs and capabilities:

Time controls: Quick select (Last Hour, 8 Hours, 24 Hours, Week) or custom range. Time zones: UTC, browser local, or database time zone.

AWR (Automatic Workload Repository)

AWR collects, processes, and maintains performance statistics automatically. Data is stored both in-memory and on disk. AWR provides:

• Object statistics (access and usage of database segments)
• Time model statistics (time-based activity breakdown)
• System and session statistics
• Top SQL by elapsed time, CPU time, and other criteria
• Active Session History (ASH) data

AWR reports can be generated and downloaded from Performance Hub. They are the primary tool for after-the-fact performance analysis.

OCI Events and Notifications

Autonomous Database emits events for state changes that can trigger automated actions through OCI Events service:

Event categories:

• Critical events: Disruptions to the database (failures, capacity issues)
• Information events: Lifecycle events (start, stop, scale, backup, Data Guard transitions)

Notification delivery channels:

Event rule structure: Each rule contains a condition (which event types to match) and one or more actions (notifications, Functions invocations).

OCI Monitoring and Alarms

OCI Monitoring continuously collects metrics from ADB instances. Alarms are configured with thresholds and fire when conditions are met for a specified period (minimum 5 minutes). Key ADB metrics include CPU utilization, storage utilization, sessions, and the oci_autonomous_database peer lag metric for Data Guard.

4. Auto-Indexing, Data Safe, and Compartment Quotas

Auto-Indexing

Automatic indexing automates index management by monitoring application workload and creating/maintaining indexes without DBA intervention.

Limitations:

• Auto-indexing is NOT supported for SQL/PL/SQL using the json_exists SQL/JSON function
• Auto-indexing is NOT supported for SODA query-by-example (QBE) operations

Exam trap: Auto-indexing is disabled by default. You must explicitly enable it. This is a common exam question that tests whether you know the default state.

Oracle Data Safe

Oracle Data Safe is included with every Autonomous Database instance at no additional cost. It provides a unified security control center with eight core features:

Getting started workflow: Register target database -> Assess security -> Assess users -> Discover sensitive data -> Mask data -> Enable audit collection -> Create policies -> Configure alerts.

Exam trap: Data Safe is included free with Autonomous Database. Activity Auditing includes 1 million audit records per month per database at no cost. Exceeding this threshold incurs additional charges.

Compartment Quotas

Compartment quotas give administrators control over resource consumption across compartments. They are distinct from service limits:

Quota policy statements use declarative language:

• set: Set maximum resources for a compartment (e.g., set database quota atp-ecpu-count to 100 in compartment Dev)
• unset: Remove a quota restriction
• zero: Set quota to zero, preventing any resource creation

Exam trap: Compartment quotas do NOT increase service limits. They can only restrict within what the service limits already allow. If your tenancy service limit is 200 ECPUs, setting a compartment quota of 300 has no effect beyond 200.

5. Connectivity: Wallets and Service Handles

Wallet-Based Connections (mTLS)

Wallets contain encrypted keys and certificates needed for mutual TLS authentication. They are downloaded as a ZIP file from the OCI Console or via oci db autonomous-database generate-wallet. The wallet ZIP includes:

• tnsnames.ora -- connection string definitions for all predefined service names
• sqlnet.ora -- network configuration including wallet location
• cwallet.sso -- auto-login wallet file
• ewallet.p12 -- PKCS#12 wallet file
• truststore.jks / keystore.jks -- Java keystores for JDBC

Wallet rotation: Wallets must be periodically rotated as a maintenance procedure. After rotation, all clients must download and deploy the new wallet.

TLS Connections (Without Wallet)

Qualifying clients can connect via TLS without a wallet. The client verifies the server's CA root certificate (one-way authentication):

Predefined Database Service Names

Every ADB instance provides predefined service names that map to consumer groups with different resource allocations. The service name format is databasename_servicetype (e.g., mydb_high).

For Transaction Processing / JSON / APEX workloads (all five services):

For Autonomous AI Lakehouse (formerly ADW) workloads: All five services (TPURGENT, TP, HIGH, MEDIUM, LOW) are available. However, TP and TPURGENT may not appear in the wallet's tnsnames.ora by default -- re-download the wallet after provisioning to see them (Predefined Service Names).

Sessions parameter: Determines concurrent session limits.

• ECPU model: sessions = 75 x number of base ECPUs
• OCPU model (legacy): sessions = 300 x number of base OCPUs

Switching services within a session: Use DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP or the ADB-specific service switching mechanism. Do NOT assume manual consumer group changes produce the same effect as service-level switching -- ADB performs additional configuration beyond just the consumer group setting.

Viewing current resource rules: SELECT * FROM CS_RESOURCE_MANAGER.LIST_CURRENT_RULES();

Key parallelism facts:

• Minimum 4 ECPUs (2 OCPUs) required for parallelism
• Simple queries may get double the degree of parallelism
• Lakehouse workload: parallelism hints ignored by default (enable with ALTER SESSION SET optimizer_ignore_parallel_hints=false)
• Transaction Processing / JSON / APEX: parallelism hints honored
• HIGH and MEDIUM services enable Parallel Query, DDL, and DML automatically

Exam trap: Resource shares determine CPU/IO allocation only when the database reaches 100% utilization. When the database is underutilized, any service can use available resources. Shares are about guaranteed minimums during contention, not absolute caps.

Exam trap: All five predefined services (TPURGENT, TP, HIGH, MEDIUM, LOW) are available on ALL workload types, including Lakehouse. However, TP and TPURGENT may not appear in the default wallet download for Lakehouse workloads -- candidates should know that re-downloading the wallet will reveal them. If a question asks whether TP/TPURGENT are available for Lakehouse, the answer is yes.

Connection String Format

Connection strings use TCPS protocol on port 1522:

dbname_high = (description=
  (address=(protocol=tcps)(port=1522)(host=adb.region.oraclecloud.com))
  (connect_data=(service_name=example_high.adb.oraclecloud.com))
  (security=(ssl_server_dn_match=yes)))

Port assignments (fixed, cannot be changed):

• Port 1522: mTLS connections
• Port 1521 or 1522: TLS connections

Firewall requirement: Clients must allow outbound traffic on port 1522 to *.oraclecloud.com.

6. Disaster Recovery: Autonomous Data Guard

Autonomous Data Guard creates and maintains a standby database that continuously receives updates from the primary. It is the primary DR mechanism for Autonomous Database.

Deployment Options

RTO and RPO Values (Memorize These)

Exam trap: Cross-region automatic failover is NOT available. Only local standby supports automatic failover. Cross-region only supports switchover and manual failover. This is a frequently tested distinction.

Automatic Failover Behavior

The system monitors the primary continuously. Automatic failover occurs only when:

1. The primary database is down, AND
2. Potential data loss is less than or equal to the configured data loss limit

Data loss limit: Default is 0 (zero data loss required). Configurable range: 0-3600 seconds. If potential data loss exceeds the limit, automatic failover does NOT occur and manual failover becomes the option.

Switchover vs. Failover

Connection Behavior During DR Events

This is critical exam knowledge:

• Connection strings: No changes required after failover or switchover
• Wallets: Continue working without regeneration
• APIs and scripts: Continue working without modification
• Applications experience a brief interruption during the role transition but reconnect automatically to the new primary

Standby Lifecycle States

Feature Preservation After Role Transition

All of the following transfer identically to the new primary: ECPU count, storage, display name, database name, auto-scaling settings, tags, licensing, OML notebooks and users, APEX data and metadata, ACLs, private endpoint configuration, compute auto-scaling.

Billing for Standby

• Base ECPUs of the primary: billed on the standby (additional cost)
• Storage of the primary: billed on the standby (including auto-scaled storage)
• Auto-scaled ECPUs of the primary: NOT billed on the standby

Data Guard Operations Reference

Data Guard Events for Automation

OCI Events supports these Data Guard-specific event types: begin/end automatic failover, begin/end manual failover, begin/end switchover, begin/end enable Data Guard, begin/end disable Data Guard. Each end event includes a success/failure result.

Monitoring metric: oci_autonomous_database peer lag metric measures total time (seconds) by which the standby lags behind the primary.

Exam trap: You cannot manually failover to a cross-region standby if a local standby exists and is available. Local failover takes priority. To failover cross-region, you must first terminate the local standby.

Exam trap: A disconnected cross-region standby becomes a standalone database and CANNOT be reconnected to the primary. Disconnect is irreversible.

Backup-Based Disaster Recovery vs. Autonomous Data Guard

Each ADB instance includes a local Backup-Based Disaster Recovery peer at no additional cost. Understanding the trade-offs is exam-relevant:

7. Terraform and Resource Manager

Oracle Cloud Infrastructure Resource Manager provides managed Terraform for provisioning ADB instances as infrastructure-as-code:

• Terraform provider: oci_database_autonomous_database resource type
• State management: Resource Manager stores state files centrally with state locking (only one job runs per stack at a time)
• Execution model: Create stack -> Generate execution plan -> Apply
• Integration: Can be triggered from OCI Console, REST API, OCI CLI, or CI/CD pipelines (OCI DevOps, Jenkins, GitHub)
• Save as Stack: Any existing ADB instance can be exported as a Terraform stack from the Console

Key Terraform parameters for ADB: compartment_id, db_name, display_name, db_workload (ADW, ATP, AJD, APEX), cpu_core_count, data_storage_size_in_tbs, is_auto_scaling_enabled, is_free_tier, license_model (LICENSE_INCLUDED or BRING_YOUR_OWN_LICENSE), whitelisted_ips (ACL), subnet_id (private endpoint), nsg_ids.

8. Tagging and Cost Tracking

OCI Tagging

Tags are key-value metadata attached to resources. Two types exist:

Cost-tracking tags: A special property of defined tags that enables filtering and summing costs by tag value in Cost Analysis reports. Enable cost-tracking on a defined tag to allow chargeback by project, department, or environment.

Budgets

OCI Budgets monitor spending at compartment level or cost-tracking tag level. Budgets support:

• Monthly or annual periods
• Alert thresholds (percentage of budget or absolute amount)
• Email notifications when thresholds are exceeded
• Forecasting based on historical trends

Combined with compartment quotas, budgets create a governance framework: quotas prevent over-provisioning, budgets prevent over-spending.

Exam Strategy for Domain 4

1. Network security is heavily tested: Know the three access modes, how ACLs interact with mTLS/TLS prerequisites, and when private endpoints are required.
2. Memorize the RTO/RPO table: Cross-region vs. local, automatic vs. manual failover values appear frequently.
3. Know what is automatic vs. manual: Patching is automatic (no user scheduling on Serverless). Auto-indexing is OFF by default. Data Safe is included but must be configured.
4. Service names map to resource allocation: Understand which services are available for which workload types and what parallelism each provides.
5. Data Guard limitations: Cross-region has no automatic failover. Local failover takes priority over cross-region. Disconnect is irreversible.
6. TLS prerequisites: TLS without a wallet requires ACLs on public endpoints or a private endpoint. You cannot remove all ACLs while TLS is enabled.

References

• Configuring Network Access with Access Control Rules (ACLs)
• About Autonomous Data Guard
• Predefined Database Service Names
• Performance Hub for Autonomous Database
• Manage Automatic Indexing
• Oracle Data Safe
• Data Safe Features
• Compartment Quotas
• About Connecting to Autonomous Database
• Maintenance Windows and Patching
• Use Autonomous Database Events
• OCI Resource Manager
• 1Z0-931-25 Exam Syllabus