Security, Identity and Access Management
Security
Shared responsibility
Oracle secures the physical facilities, hardware, network fabric and the hypervisor layer. You secure what you put on top: identities, policies, data classification, guest OS patching, network rules and application configuration. Questions often test the boundary - Oracle does not patch your guest OS or design your security lists.
Encryption and keys
Data at rest is encrypted by default across OCI storage services and Oracle Database (Transparent Data Encryption), and data in transit is protected with TLS. You can move to customer-managed keys using OCI Vault, which provides hardware-security-module-backed key management and a secrets store. Encryption being on by default is a common exam point - you are not required to enable it, only to optionally control the keys.
Detection, prevention and access
Cloud Guard continuously monitors your tenancy for misconfigurations and risky activity using detectors and responders. Security Zones enforce a deny-list of insecure configurations so noncompliant resources cannot be created. Web Application Firewall protects internet-facing applications at the edge, Network Firewall provides centralized traffic inspection, and the Bastion service gives managed, time-bound SSH access without exposing public IPs. Audit records API activity and is available in the Console.
Traps
Cloud Guard detects and reports; it does not inherently block. Security Zones block. Vault stores keys and secrets; it is not a policy engine. And the default encryption answer is almost always "already encrypted."
Rule of thumb
For any "prevent an insecure configuration from ever being created" scenario, choose Security Zones; for "detect and alert on what already exists," choose Cloud Guard.
Identity and Access Management
Principals and containers
IAM has two jobs: authentication (who are you) and authorization (what may you do). Principals are users, groups, dynamic groups (which match compute instances or functions by rule), and instance or resource principals for workloads. The tenancy is the root compartment; policies attached to a compartment apply to that compartment and everything nested beneath it, but never to a parent or sibling.
Policy syntax
A policy statement reads: Allow group to in <compartment|tenancy> [where ]. Verbs escalate in this order: inspect (list resources, no contents), read (view contents), use (act on existing resources), manage (create, update, delete, and everything the lower verbs allow). Policies are granted to groups, never directly to individual users - a user receives permissions by belonging to one or more groups.
Federation and credentials
You can federate with an external identity provider using SAML 2.0 and provision users with SCIM. Users authenticate with a password plus optional multi-factor authentication, or with API signing keys for CLI/SDK, auth tokens for some APIs, and customer secret keys for S3-compatible access. Dynamic groups let you write policies for instance principals without storing credentials on the instance.
Exam traps
"Allow group Admins to manage all-resources in tenancy" is extremely broad because manage includes read, use and inspect, and tenant-level scope flows to every compartment. A policy that names a compartment does not reach the tenancy root.
Rule of thumb
Apply least privilege by starting at inspect, moving up to read, then use, and reaching for manage only when creation or deletion is genuinely required.