Use this for last-mile review. Keep it open during mixed OCI security questions and pair it with the Resources when you want Oracle’s exact terminology.
1Z0-1104-25 usually gets easier when you classify the stem in this order:
- Identity lane: users, groups, dynamic groups, policy scope, or least privilege?
- Network lane: path design, exposure reduction, NSG, security list, or gateway choice?
- Data-protection lane: Vault, keys, secrets, encryption, or sensitive-data access?
- Detection and response lane: Cloud Guard, logs, audit, notifications, responders, and runbooks?
OCI answer sequence
Use this when the stem mixes ingress, async delivery, reliability, security, or operations.
flowchart TD
S["Scenario"] --> I["Classify the interaction mode"]
I --> E["Pick API Gateway, Events, Notifications, Streaming, or Functions"]
E --> R["Check retry, idempotency, ordering, and dead-letter behavior"]
R --> S2["Check Vault, IAM, private exposure, logs, and auditability"]
Fast lane picker
| If the question is mostly about… |
Start with… |
Usual winning idea |
| who should be allowed to do something |
IAM policy scope and least privilege |
identity first |
| where the control should sit |
identity vs network vs data vs detection |
put the control at the right layer |
| key, secret, or encryption handling |
Vault and key-management patterns |
separate key management from policy scope |
| suspicious posture or drift |
Cloud Guard plus logs and audit |
posture needs evidence and response |
| reducing blast radius |
compartments, network segmentation, and narrow permissions |
combine controls instead of relying on one big control |
Control-layer table
| Layer |
What it should answer |
Do not confuse it with |
| IAM and policy |
who can act |
packet filtering |
| compartments |
governance and permission scope |
network isolation |
| NSGs or security lists |
what traffic is allowed |
identity permission model |
| Vault and keys |
how secrets and encryption are managed |
broad authorization policy |
| Cloud Guard, logs, and audit |
what changed or drifted and how you know |
prevention control by itself |
Security control map
flowchart TD
Identity["Identity: Users, Groups, Policies"] --> Network["Network: NSGs, Security Lists, Gateways"]
Identity --> Data["Data: Vault, Keys, Secrets, Encryption"]
Network --> Detect["Detection: Cloud Guard, Logging, Audit"]
Data --> Detect
Detect --> Respond["Response: Notifications, Responders, Runbooks"]
Exam cue: the best answer usually uses the smallest control that solves the real layer problem instead of throwing one broad security product at everything.
IAM and policy patterns
Policy structure
1Allow group <group-name> to <verb> <resource-family> in compartment <compartment-name>
IAM chooser
| You need… |
Prefer |
Why |
| human access administration |
users, groups, policies |
classic principal path |
| resource-based OCI access |
dynamic groups and policies |
avoids user-style credentials for workloads |
| narrow permission design |
inspect, read, use, manage |
least privilege matters |
| clear governance separation |
compartments |
scope permissions and operations logically |
IAM boundary table
| If the issue is really about… |
Strongest first lane |
| workload identity |
dynamic group and policy |
| human role access |
users, groups, and least-privilege verb |
| overbroad authority |
narrower policy verb or smaller compartment scope |
| unclear administrative ownership |
compartment and policy boundary |
IAM traps
| Trap |
Better reading |
using manage everywhere |
choose the narrowest verb that satisfies the task |
| solving a network problem with IAM only |
IAM does not replace segmentation |
| solving a policy-scope problem with more subnets |
compartments and policies govern access scope |
| treating compartments as network isolation |
they are governance and permission boundaries |
Vault and data-protection chooser
| Requirement |
Prefer |
Why |
| manage encryption keys and rotation |
Vault |
key-management lane |
| keep secrets out of code and configs |
Vault secrets |
secret storage and retrieval lane |
| customer-managed key expectation |
Vault-backed key-management pattern |
explicit ownership and governance |
| protect sensitive values in runtime workflows |
least-privilege secret access path |
reduce exposure |
Data-protection traps
| Trap |
Better reading |
| thinking encryption alone solves the whole security design |
key management, identity, network, and audit all matter |
| storing secrets in application config for convenience |
move them into Vault and narrow retrieval rights |
| using one key or secret path for everything |
separate duties and reduce blast radius |
Network protection chooser
| Requirement |
Strongest first fit |
Why |
| granular workload-level filtering |
NSGs |
narrower workload scope |
| broader subnet-level filtering |
Security Lists |
simpler subnet boundary |
| path design and exposure reduction |
route tables and gateway choice |
path first, filter second |
| private access to service dependencies |
private path design |
reduce public exposure before convenience |
Network boundary table
| Boundary |
What it really answers |
| route and gateway path |
where traffic can go |
| NSG or security list |
what traffic is allowed |
| private path design |
how exposure is reduced |
| public edge decision |
which systems are reachable from outside |
Network traps
| Trap |
Better reading |
| solving every access problem with IAM |
network exposure and filtering still matter |
| using route tables like firewalls |
routes choose path, filters choose access |
| exposing resources publicly because private design is harder |
strong answers reduce exposure first |
Cloud Guard mental model
| Stage |
What it does |
| logging and audit evidence |
provides raw security-relevant records |
| detectors |
identify problematic conditions |
| problems |
track findings that need action |
| responders |
trigger automated or guided response paths |
| notifications |
alert operators and workflows |
Detection and response table
| Need |
Strongest first lane |
| who changed what and when |
Audit |
| service and platform event visibility |
Logging |
| posture drift and risky configuration findings |
Cloud Guard |
| operator awareness |
notifications and routing |
| repeatable remediation |
responders or runbook-driven process |
Cloud Guard and operations traps
| Trap |
Better reading |
| treating Cloud Guard as a replacement for logging |
Cloud Guard depends on evidence and posture logic; logs still matter |
| expecting posture tooling to fix IAM design automatically |
posture tools do not replace clean identity architecture |
| treating notifications as the whole response strategy |
response needs workflow or operator action too |
| forgetting auditability |
strong security answers preserve investigation evidence |
High-confusion pairs
| Pair |
Keep this distinction clear |
| compartment vs subnet |
governance boundary versus network boundary |
| IAM policy vs NSG |
identity permission versus traffic filtering |
| Vault secret vs policy scope |
secret storage versus authorization boundary |
| Audit vs Logging |
who changed what versus operational event detail |
| Cloud Guard vs Audit |
posture findings versus raw authoritative change record |
Last 15-minute review
| If you only remember one thing from each lane… |
Keep this |
| IAM |
scope the right principal with the smallest useful verb |
| compartments |
governance and permission boundary, not network segmentation |
| Vault |
key and secret management lane |
| network security |
decide the path first, then narrow with workload or subnet controls |
| Cloud Guard |
posture detection is strongest when combined with logs, audit, and response |
What strong 1Z0-1104-25 answers usually do
- classify the issue first as identity, network, key management, or detection
- combine IAM, network, and auditability instead of assuming one layer is enough
- choose the narrowest control that still reduces blast radius
- treat visibility and response as part of the security design, not optional extras