# Navigating the Cloud: My Transition to Oracle's Autonomous Transaction Database - Part 3

Since I want to migrate many **APEX application**s to the same **Autonomus database**, it is obvious that each system needs its own **object storage** for the migration. Moreover, it may be useful later to store images or generated files in a separate **bucket** instead of in the **database**.

The question is how to separate the objects of each system within a tenancy in the **Oracle Cloud**. Or how can we give them individual, external access? In OCI we can assign **privilege**s to registered **users**. However, we do not want each (technical) **user** to have access to the resources of another.

# Architecture

In my architectural approach, a client has an **APEX application** (Application A). Each application has a separate **workspace** and a separate **schema**. It helps a lot to keep the architecture clean that each application, system, client, whatever you want to call it, is given an alias.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745319730125/796447c7-09fb-4ab3-9f1d-8226bade8c50.png align="center")

For example, Global Network Application has the alias GN. So the **schema** name is GN\_PROD, the **workspace** is GN\_PROD\_WKS, and the **application** alias is GN. And in the DEV environment, GN\_DEV, GN\_DEV\_WKS.

Following the logic above, each system also gets its own **compartment** (in our case, GN\_Compartment).

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745320184405/080ef42b-6034-4026-b5d3-5cd6186b9125.png align="center")

Here, the DEV and PROD environments share the **OCI resource**s. A **bucket** (GN\_Bucket) is created under each **compartment**. The **file**s created by the live and development environments can be separated within the **bucket**.

# What about privilege management?

In OCI, permission roles are managed by **policies**. I created this **policy** in the **root compartment**, in our case called GN\_ADMIN\_POLICY.

I also created a special **user group** to which I added the system administrators and the technical **user**. GN\_ADMIN\_POLICY has the following **policy statement:**

`Allow group GN_ADMIN_GROUP to manage all resources in compartment GN_compartment`

This gives all members of GN\_ADMIN\_GROUP read and write access to GN\_Bucket in GN\_compartment.

# Creating a technical user

In OCI, a **user** must have a unique **email** address. At least I did not find an alternative solution. For me, the problem was that as a Google Workspace subscriber, each new email address or user is a significant additional monthly cost.

Fortunately, Google allows up to 30 variations of an email address. So I didn't have to create the technical users as new Google users, that was enough in OCI.

Of course, there are many other combinations possible to separate permissions, but as a PROD and DEV **ATP** user, this seems to be the best solution.