OCI Object Storage, hands on: create a bucket, share a file safely, automate tiering and lock what must not change

Short answer: this is the Object Storage lab we run in the third week of the OCI program, written out so you can do it on your own tenancy. In about forty minutes you will create a bucket, upload a file two ways, share it with someone who has no OCI account, tell OCI to move old files to cheaper storage on its own, and lock a folder so nothing in it can be deleted for thirty days. Every step has the Console route and the CLI command, because interviews ask for both.

Before you start

• An OCI account. The Always Free tier includes 20 GB of Object Storage, which is far more than this lab needs.
• The OCI CLI installed and configured (oci setup config), or the Cloud Shell in the Console, which has the CLI ready.
• A compartment to work in. The lab uses one called training; replace it with yours.
• Two small files on your machine: a PDF or image (report.pdf below) and a text file (app.log).

Find your compartment's OCID once and keep it in a variable so the commands stay readable:

export COMP=ocid1.compartment.oc1..aaaa...   # Identity → Compartments → training → OCID
oci os ns get                                # your Object Storage namespace; note it, some tools need it

The concepts in one minute

• Namespace. One per tenancy, assigned by Oracle. All your buckets live under it.
• Bucket. A flat container for objects in one compartment and one region. Names must be unique within the namespace.
• Object. A file plus metadata, up to 10 TiB. There are no real folders; a slash in the name (reports/2026/q3.pdf) is just a prefix the Console displays as a folder.
• Tier. Standard for hot data, Infrequent Access for data read less than once a month, Archive for data you may never read again. The tier can be set per bucket and changed per object by a lifecycle rule.
• Visibility. Private by default. Public buckets serve objects to anyone with the URL; you almost never want that.

Step 1: create the bucket

Console. Menu → Storage → Buckets. Check the compartment on the left is training. Click Create Bucket, name it sha-lab-bucket, keep the default storage tier Standard, leave versioning off (we need retention rules later, and the two cannot coexist), and create.

CLI.

oci os bucket create --compartment-id $COMP --name sha-lab-bucket \
  --storage-tier Standard --public-access-type NoPublicAccess

Check it exists and note the time-created and etag fields; the etag changes whenever bucket settings change, which matters when you automate.

oci os bucket get --name sha-lab-bucket --query 'data.{name:name,tier:"storage-tier",public:"public-access-type"}'

Step 2: upload objects, two ways

Console. Open the bucket → Upload. Drag report.pdf in, set the object name prefix to reports/ and upload. Repeat for app.log with prefix logs/. The Console shows the two prefixes as folders.

CLI. Uploading with a name that includes a prefix creates the "folder" at the same time:

oci os object put --bucket-name sha-lab-bucket --file ./report.pdf --name reports/report.pdf
oci os object put --bucket-name sha-lab-bucket --file ./app.log   --name logs/app.log
oci os object list --bucket-name sha-lab-bucket --query 'data[].{name:name,size:size,tier:"storage-tier"}' --output table

Two things to notice. put on an existing name overwrites silently unless you pass --no-overwrite. And a file above 128 MiB is uploaded in parts automatically; if the upload is interrupted, oci os multipart list shows the leftover parts, which still cost money until you abort them.

Download one back to prove the round trip:

oci os object get --bucket-name sha-lab-bucket --name reports/report.pdf --file ./report-copy.pdf

Step 3: share a private file with a pre-authenticated request

The client wants the report. The bucket is private, and it should stay private. A pre-authenticated request (PAR) is a URL that grants one specific permission until a date you choose.

Console. Bucket → Pre-Authenticated Requests → Create Pre-Authenticated Request. Target: Object, name reports/report.pdf, access type Permit object reads, expiry a week from now. Copy the URL when it is shown; the Console will not show it again.

CLI.

oci os preauth-request create --bucket-name sha-lab-bucket --name share-report \
  --access-type ObjectRead --object-name reports/report.pdf \
  --time-expires 2026-09-30T00:00:00Z

The response contains access-uri. Prefix it with https://objectstorage.<region>.oraclecloud.com and open it in a private browser window: the PDF downloads with no login. That is the whole point. Now list and delete the PAR, because a shared link you have forgotten about is the most common storage security finding in an audit:

oci os preauth-request list --bucket-name sha-lab-bucket --query 'data[].{name:name,expires:"time-expires"}'
oci os preauth-request delete --bucket-name sha-lab-bucket --par-id <id-from-the-list>

Interview question that comes from this step: how do you let a mobile app upload photos to a bucket without embedding credentials in the app? A PAR with access type ObjectWrite on the bucket, created by your backend, handed to the app, expiring in minutes.

Step 4: a lifecycle policy that moves logs to cheaper storage

Logs are read for a day or two, then kept for compliance, then thrown away. Nobody should do that by hand. A lifecycle policy does it per prefix.

First, the permission that trips up every beginner. Lifecycle rules are executed by the Object Storage service itself, and it needs its own policy. Identity → Policies → create in the training compartment:

Allow service objectstorage-ap-mumbai-1 to manage object-family in compartment training

Use your region's identifier in place of ap-mumbai-1. Without this line the rule saves fine and never runs, and the Console gives no error.

Console. Bucket → Lifecycle Policy Rules → Create Rule. Name logs-to-ia-after-30, target Objects, action Move to Infrequent Access, 30 days, filter prefix logs/. Add a second rule logs-delete-after-365, action Delete, 365 days, same prefix.

CLI. Rules are supplied as a JSON array. Save this as lifecycle.json:

[
  { "name": "logs-to-ia-after-30", "action": "INFREQUENT_ACCESS", "timeAmount": 30, "timeUnit": "DAYS",
    "isEnabled": true, "objectNameFilter": { "inclusionPrefixes": ["logs/"] } },
  { "name": "logs-delete-after-365", "action": "DELETE", "timeAmount": 365, "timeUnit": "DAYS",
    "isEnabled": true, "objectNameFilter": { "inclusionPrefixes": ["logs/"] } }
]

oci os object-lifecycle-policy put --bucket-name sha-lab-bucket --items file://lifecycle.json
oci os object-lifecycle-policy get --bucket-name sha-lab-bucket

The put replaces the whole policy, so always send every rule, not just the new one. Rules are evaluated roughly once a day; you will not see the tier change during the lab, and that is expected. In production the same pattern moves database exports to Archive after 90 days and deletes them after seven years.

Step 5: a retention rule for what must not change

The finance team's reports must not be deleted or altered for thirty days after upload, whatever anyone does with their credentials. That is a retention rule, and it applies to the whole bucket.

Console. Bucket → Retention Rules → Create Rule. Name keep-30-days, duration 30 days. Leave the rule unlocked for the lab.

CLI.

oci os retention-rule create --bucket-name sha-lab-bucket --display-name keep-30-days \
  --time-amount 30 --time-unit DAYS
oci os retention-rule list --bucket-name sha-lab-bucket

Now try to delete the report:

oci os object delete --bucket-name sha-lab-bucket --name reports/report.pdf --force

The service refuses, which is the behaviour you were asked to guarantee. Two rules worth remembering for the exam and for real life: a retention rule with no duration keeps objects indefinitely, and a locked rule cannot be shortened or removed by anyone, including the tenancy administrator, after its 14-day grace period. Lock only when a regulator requires it.

Step 6: clean up

Because the retention rule blocks deletes, remove it first, then the objects, then the bucket. Buckets must be empty to be deleted.

oci os retention-rule delete --bucket-name sha-lab-bucket --retention-rule-id <id> --force
oci os object bulk-delete --bucket-name sha-lab-bucket --force
oci os bucket delete --name sha-lab-bucket --force

What you can now say in an interview

You created a private bucket, chose a tier, uploaded objects with prefixes, shared one securely with a time-limited link and revoked it, automated tiering and deletion with a lifecycle policy including the IAM policy that makes it work, and protected data with a retention rule. Those are the Object Storage objectives of the OCI Architect Associate exam, and they are also a normal Tuesday for an OCI administrator.

If you did this lab and want the rest of the platform taught the same way, with a mentor checking your work, the OCI program covers compute, networking, IAM, database and Object Storage over live sessions, and the Multi Cloud Administrator program does the same across OCI, AWS and Azure. Check your IT career eligibility and a counsellor will call you within one working day.

Frequently asked questions