OCI Security Professional common mistakes
OCI Security Professional · Understand the traps and how to avoid them.
Treating security lists and network security groups as interchangeable, then answering NSG questions by describing a subnet-level rule set (or vice versa).
Both are allow-only stateful virtual firewalls, so candidates memorize 'security list = subnet, NSG = VNIC' without internalizing the consequences: a security list applies to every VNIC in the subnet, while an NSG applies only to VNICs explicitly added to it, and a packet must be permitted by both layers to flow.
What to do instead
State the scope explicitly in every answer: security lists are attached to a subnet and affect all VNICs in it; NSGs are attached to individual VNICs and can span subnets. When troubleshooting, check both the subnet's security lists and every NSG on the source and destination VNICs. Note that NSGs are commonly used to isolate tiers (web, app, database) inside one subnet.
Assuming a route rule or internet gateway alone grants internet access, and forgetting that a public subnet also needs an internet gateway plus a route to 0.0.0.0/0, while a private subnet uses a NAT gateway for egress and a service gateway for OCI services.
Candidates conflate 'public subnet' with 'has internet access' and miss the two-part requirement (gateway exists and route rule points to it). They also forget that a NAT gateway is outbound-only and cannot accept inbound connections, and that a service gateway keeps traffic to Object Storage and other OCI services off the internet.
What to do instead
For each scenario, verify three things: the gateway exists, the route table has a rule to the correct gateway, and the security rules allow the traffic. Use internet gateway for bidirectional public traffic, NAT gateway for outbound-only from private subnets, service gateway for OCI service traffic, and DRG for on-premises or cross-VCN connectivity.
Answering that an instance can reach Object Storage over the service gateway even though the route table or the service gateway's service CIDR does not cover the target, or placing the service gateway in the wrong compartment/VCN.
The service gateway is often described only as 'private access to OCI services', so candidates skip the configuration detail: it must be in the VCN, referenced by a route rule, and scoped to the relevant service (for example Object Storage) with the right service CIDR.
What to do instead
Check that the service gateway is in the same VCN, that a route rule sends the service's CIDR to it, and that the security rules permit traffic to the service. Remember the service gateway is regional and does not require an internet gateway or NAT gateway.
Confusing IAM policy verbs and subject types, for example using 'manage' when 'use' is intended, or writing a policy for a group when the requirement is to grant a dynamic group (instances/functions) access.
The verb ladder (inspect, read, use, manage) and the tenancy/compartment scope are easy to memorize superficially. Candidates also forget that dynamic groups match instances by rules (compartment and tags) and are the mechanism for instance principals, not regular groups.
What to do instead
Map verbs to intent: inspect = list metadata, read = view details, use = work with existing resources, manage = full control including create/delete. For workloads, create a dynamic group with a matching rule (for example matching compartment and freeform tag) and grant it a policy. Verify the policy is in the correct compartment or tenancy and that the resource is in scope.
Treating a compartment as a security boundary and assuming resources in different compartments are isolated by default.
Compartments are for organization and policy scoping, not network or identity isolation. A VCN in one compartment can be peered with another, and a policy in a parent compartment can grant access across children. Candidates answer as if compartment boundaries block access.
What to do instead
Explain that isolation comes from IAM policies (least privilege, scoped to compartments), network controls (security lists, NSGs, route tables), and encryption, not from compartment placement alone. Policies inherit down the compartment tree, so audit parent-compartment policies when assessing exposure.
Assuming data in Object Storage or Block Volume is encrypted only if the customer enables it, or that customer-managed keys are required for encryption at rest.
Many cloud providers default to provider-managed encryption, and OCI does too. Candidates over-apply the 'bring your own key' model and answer that data is plaintext until a Vault key is assigned.
What to do instead
State that OCI encrypts data at rest by default using provider-managed keys. Customer-managed keys in Vault are for control, rotation, and separation of duties, and can be applied to Object Storage buckets and Block Volume boot/block volumes. Distinguish encryption at rest from in-transit (TLS) and from key management (Vault, HSM).
Describing Vault key rotation as re-encrypting all existing data, or confusing a master encryption key with a data encryption key and a secret.
Key hierarchy terminology is dense: master encryption keys wrap data encryption keys, and secrets store credentials. Candidates collapse these into one concept and then give wrong answers about what rotation does.
What to do instead
Explain the hierarchy: Vault holds master encryption keys (backed by HSM) that wrap data encryption keys used to encrypt data; rotating a master key re-wraps data keys without re-encrypting the bulk data. Secrets are separate objects for storing credentials and are versioned and rotated independently.
Confusing Cloud Guard, Security Zones, and Audit in answers about detection, prevention, and evidence.
All three are security services and candidates use them interchangeably. Cloud Guard detects misconfigurations and threats and can respond; Security Zones enforce policies at resource-creation time (preventive); Audit records API activity for compliance evidence.
What to do instead
Assign each service a role: Cloud Guard = detect and respond (problems, responders, recipes); Security Zones = prevent noncompliant resource creation; Audit = immutable log of API calls for forensics and compliance. For 'who deleted the bucket', the answer is Audit, not Cloud Guard.
Assuming VCN flow logs capture packet payloads or that Audit captures data-plane access to Object Storage objects.
Candidates treat all logging as equivalent. VCN flow logs record metadata about accepted/rejected flows (source, destination, port, action), not payloads. Audit captures control-plane API calls; object GET/PUT data-plane access is captured by Object Storage access logs or the service's own logging, not by Audit alone.
What to do instead
Match the log to the question: flow logs for network traffic metadata and rejected-flow analysis, Audit for API/control-plane activity and compliance evidence, Object Storage access logs for object-level access, and service logs for application events. Enable flow logs per VCN/subnet and send logs to Logging or Object Storage for retention.
Leaving the default security list open (0.0.0.0/0 on port 22 or 3389) or placing a database in a public subnet, then answering that the design is secure because a password or encryption is in place.
Candidates focus on identity and encryption and underweight network exposure. Default security lists allow broad SSH/RDP, and 'public subnet' is chosen for convenience during labs and carried into exam answers.
What to do instead
Apply defense in depth: restrict SSH/RDP to a bastion or use OCI Bastion service, place databases in private subnets with NSGs allowing only the app tier, and use least-privilege IAM plus encryption. In review questions, flag any 0.0.0.0/0 rule on management ports as a finding regardless of other controls.