Oracle Multicloud Foundations

Few organizations use only one cloud. You learn what multicloud means, why customers run services across providers, and what problem running Oracle Database beside a hyperscaler solves.

• Single cloud, multicloud and hybrid compared
• Why organizations spread across providers
• The problem of data far from where it is used
• Customer scenarios for multicloud
• Risks and costs of added complexity

You build A short case for or against multicloud for a sample company.

Oracle places its database services inside AWS, Azure and Google Cloud. You learn what each pairing is called, what stays the same between them, and where they differ.

• Oracle AI Database@AWS
• Oracle AI Database@Azure
• Oracle AI Database@Google Cloud
• What is common to all three
• Where the pairings differ

You build A side-by-side table of the three offers.

The service spans two providers, so a clear picture helps. You see where the database hardware sits, how the two clouds connect and which management tools reach which parts.

• Where the database infrastructure sits
• How the two clouds are connected
• Two consoles and one service
• What the customer controls and what Oracle controls
• Reading a simple architecture diagram

You build A labeled diagram of the architecture, explained in your own words.

Before a database can run, accounts and access must be in place. You follow the first steps of bringing the service into a customer’s cloud account, including access, permissions and the first provisioning.

• What must exist before onboarding
• Accounts and links between the clouds
• Access and permissions
• Provisioning for the first time
• Checking that it worked

You build An onboarding checklist for a customer new to the service.

The service offers several kinds of database. You learn what the services are for, and how they are looked after through their life: patching, scaling, backup, monitoring and retirement.

• The database services available through the pairings
• Choosing a service for a need
• Patching and updates
• Scaling and capacity
• Monitoring and backup
• Retiring and replacing environments

You build A table that matches four example workloads to a database service and its care routine.

Customers ask what happens when something fails. You learn the ideas behind keeping data safe and available: backups, redundancy, standby databases and disaster recovery, in plain terms.

• Backups and what they protect against
• High availability: surviving a local failure
• Disaster recovery: surviving a larger one
• Recovery time and recovery point
• How these apply across the three pairings

You build A plain-language resilience summary for a sample application.

Most customers already have databases. You learn why and how workloads move, the main approaches, and how a migration tool such as Zero Downtime Migration reduces the time a database is out of use.

• Reasons to migrate
• Assessing a database before moving it
• Online and offline approaches
• Zero Downtime Migration in outline
• Planning cutover and fallback

You build A migration outline for a sample database, with the approach chosen and why.

Security is shared between the customer and two providers. You learn who protects what, how identity, encryption and network isolation apply, and what a customer must still do for itself.

• Who protects what
• Identity and access
• Encryption of data
• Network isolation and private access
• Auditing and compliance basics

You build A responsibility chart that shows who handles each security task.

Use what you have learned on a realistic case. You read a customer scenario, pick a pairing, explain the architecture, resilience, migration and security in simple terms, and say why.

• Reading a customer scenario
• Choosing among the pairings
• Explaining architecture and onboarding
• Covering resilience, migration and security
• Presenting the recommendation

You build A recommendation for a sample customer, covering every area.